インデックス

ログインデックスでは、さまざまな保持、割り当て、使用状況の監視、および課金のためにデータを値グループにセグメント化できるようにすることで、ログ管理予算をきめ細かく制御できます。インデックスは、Configuration ページの Indexes セクションにあります。インデックスをダブルクリックするか、Edit ボタンをクリックすると、過去 3 日間にインデックス化されたログの数とそれらの保存期間に関する情報が表示されます。

インデックス化されたログは、ファセット検索、パターン、分析、ダッシュボード、および監視に使用できます。

複数のインデックス

デフォルトでは、新しい各アカウントは、すべてのログのモノリシックセットを表す単一のインデックスを取得します。Datadog では、次が必要な場合に複数のインデックスを使用することを推奨します。

複数の保持期間
1日の割り当てを複数使用して、バジェットをより細かく管理したい場合。

Log Explorer は、複数のインデックスにわたるクエリをサポートしています。

インデックスを追加

“New Index” ボタンを使って、新しいインデックスを作成します。各アカウントで作成できるインデックスの最大数は決まっており、デフォルトでは 10 に設定されています。

注: インデックス名は文字で始まる必要があり、小文字、数字、または ‘-’ のみを含めることができます。

アカウントの最大インデックス数を増やす必要がある場合は、Datadog サポートにお問い合わせください。

インデックスの削除

組織からインデックスを削除するには、インデックスのアクショントレイにある「削除アイコン」を使用します。このオプションは、Modify index と User manage access の両方の権限を持つユーザーのみ使用することができます。

削除されたインデックスと同じ名前のインデックスを再作成することはできません。

注: 削除されたインデックスは、今後新しい受信ログを受け付けません。削除されたインデックス内のログは、クエリに使用できなくなります。適用される保持期間に従ってすべてのログがエージングアウトした後、そのインデックスはインデックスページに表示されなくなります。

インデックスフィルター

インデックスフィルターを使用すると、どのログをどのインデックスに流し入れるかを動的に管理できます。たとえば、最初のインデックスは status:notice 属性で絞り込まれるように設定し、2 つめのインデックスは status:error 属性で絞り込まれるように設定し、最後のインデックスはフィルターなしで作成した場合 (* と同じ)、status:notice ログはすべて最初のインデックスに、status:error ログはすべて 2 つめのインデックスに、その他のログは最後のインデックスに入ります。

注: ログは、フィルターに一致する最初のインデックスに保存されます。ドラッグアンドドロップを使用し、リストにあるインデックスの順番を用途に合わせて変更することができます。

除外フィルター

デフォルトでは、ログインデックスに除外フィルターは設定されません。つまり、インデックスフィルターに一致するログがすべてインデックス化されます。

ですが、すべてのログに同等の価値があるわけではないため、インデックスに流し入れたログの中でどれを削除するかを、除外フィルターを使用して制御することができます。除外したログはインデックスから破棄されますが、Livetail には残るので、メトリクスの生成やアーカイブに使用できます。

除外フィルターは、クエリ、サンプリング規則、および active/inactive のトグルで定義します。

デフォルトのクエリは * です。つまり、インデックスに入るすべてのログが除外されます。ログクエリを使用して、一部のログだけが除外されるように除外フィルターを設定します。
デフォルトのサンプリング規則は Exclude 100% of logs であり、クエリに一致する 100% のログが除外されます。サンプリングレートを 0% から 100% の間で調節し、さらに、そのサンプリングレートを個々のログに適用するか、それとも属性の一意の値によって定義されるロググループに適用するかを決めます。
デフォルトのトグルは active であり、インデックスに入れられたログが、除外フィルターのコンフィギュレーションに従って実際に破棄されます。このトグルを inactive にすると、インデックスに新しく入れられるログに対して除外フィルターが無視されます。

注: ログのインデックスフィルターは、最初に一致した active な除外フィルターだけを処理します。ログが除外フィルターに一致すると、(たとえサンプルとして抽出されなくても) その後の一連の除外フィルターがすべて無視されます。

ドラッグアンドドロップを使用し、リストにある除外フィルターの順番を用途に合わせて変更することができます。

例

オンとオフを切り替える

プラットフォームにインシデントが発生するまでデバッグログが必要ないこともあれば、クリティカルバージョンのアプリケーションのデプロイを注意深く監視したいこともあります。status:DEBUG に 100% の除外フィルターをセットアップすると、Datadog の UI から、あるいは必要なら API を使用して、トグルのオンとオフを切り替えることができます。

傾向を注視する

Web アクセスサーバーリクエストからのすべてのログを保持するのではなく、3xx、4xx、5xx のログをすべてインデックス化し、2xx のログの 95% を除外したい場合は、source:nginx AND http.status_code:[200 TO 299] を設定することで全体の傾向を追跡できます。 ヒント: ログから生成されるメトリクスを使用し、リクエストの数をカウントして、ステータスコード、ブラウザ、国でタグ付けすることにより、Web アクセスログを有益な KPI に変換することができます。

高レベルなエンティティを一貫してサンプリングする

1 日に何百万というユーザーが Web サイトにアクセスするとします。すべてのユーザーを監視する必要はないが、一部のユーザーから全体像を把握しておきたい場合は、すべてのプロダクションログ (env:production) に対して除外フィルターをセットアップし、@user.email のログの 90% を除外します。

トレース ID をログに挿入できるので、APM をログと併用することができます。ユーザーに関するログをすべて保持する必要はありませんが、ログによってトレースに必要な全体像を常に入手できるようにしておくことが、トラブルシューティングのために非常に重要です。計測するサービスからのログ (service:my_python_app) に適用される除外フィルターをセットアップし、Trace ID の 50% のログを除外してください。トレース ID リマッパーをパイプラインのアップストリームで必ず使用してください。

複数のインデックスにおけるサンプリング一貫性を確保するには:

各インデックスに除外ルールを一つ作成。
すべての除外ルールに、より高レベルのエンティティを定義する、同じサンプリングレートと同じ属性を使用。
除外ルール、フィルター、該当順序を再確認 (ログは、最初に一致する除外ルールでのみ渡されます)。

以下の例では、

一般的に、特定の request_id を持つすべてのログは、保持または除外されます（50% の確立)。
threat:true または compliance:true タグを持つログは、request_id にかかわらず保持されます。
DEBUG ログは、request_id サンプリングルールで一貫してインデックス化されます。ただし、デバッグログ除外フィルターが適用されている場合は、サンプリングされます。
実際の request_id を持つ 2XX ウェブアクセスログの 50% は、保持されます。その他の 2XX ウェブアクセスログは、90% 除外フィルタールールに基づき、すべてサンプリングされます。

ログの保持を更新

インデックス保持設定は、ログが Datadog に保存され、検索できる期間を決定します。保持は、アカウントコンフィギュレーションで許可されている任意の値に設定できます。現在の契約にない保持を追加するには、success@datadoghq.com のカスタマーサクセスにお問い合わせください。

日別の割り当てを設定する

1 日の割り当てを設定して、インデックスに格納されるログの数を日別に制限することができます。この割り当ては、格納されるべき (除外フィルターが適用された後など) すべてのログに対して適用されます。 1 日の割り当て数に到達したら、ログはインデックス化されなくなりますが、livetail では利用できるほか、アーカイブにも送信されるので、ログからメトリクスを生成するために使用できます。

この割り当ては、インデックスを編集していつでも更新または削除できます。