- はじめに
- エージェント
- インテグレーション
- Watchdog
- イベント
- ダッシュボード
- モバイルアプリケーション
- インフラストラクチャー
- サーバーレス
- メトリクス
- ノートブック
- アラート設定
- APM & Continuous Profiler
- CI Visibility
- RUM & セッションリプレイ
- データベース モニタリング
- ログ管理
- セキュリティプラットフォーム
- Synthetic モニタリング
- ネットワークモニタリング
- 開発者
- API
- アカウントの管理
- データセキュリティ
- ヘルプ
ログインデックスでは、さまざまな保持、割り当て、使用状況の監視、および課金のためにデータを値グループにセグメント化できるようにすることで、ログ管理予算をきめ細かく制御できます。インデックスは、Configuration ページの Indexes セクションにあります。インデックスをダブルクリックするか、Edit ボタンをクリックすると、過去 3 日間にインデックス化されたログの数とそれらの保存期間に関する情報が表示されます。
インデックス化されたログは、ファセット検索、パターン、分析、ダッシュボード、および監視に使用できます。
デフォルトでは、各アカウントには、すべてのログのモノリシックセットを表す単一のインデックスがあります。Datadog では、次が必要な場合に複数のインデックスも提供します。
Log Explorer は、複数のインデックスにわたるクエリをサポートしています。
複数のインデックスがアクティブになっている場合は、“New Index” ボタンを使用して新しいインデックスを作成します。
注: インデックス名は文字で始まる必要があり、小文字、数字、または ‘-’ のみを含めることができます。
インデックスフィルターを使用すると、どのログをどのインデックスに流し入れるかを動的に管理できます。たとえば、最初のインデックスは status:notice
属性で絞り込まれるように設定し、2 つめのインデックスは status:error
属性で絞り込まれるように設定し、最後のインデックスはフィルターなしで作成した場合 (*
と同じ)、status:notice
ログはすべて最初のインデックスに、status:error
ログはすべて 2 つめのインデックスに、その他のログは最後のインデックスに入ります。
注: ログは、フィルターに一致する最初のインデックスに保存されます。ドラッグアンドドロップを使用し、リストにあるインデックスの順番を用途に合わせて変更することができます。
デフォルトでは、ログインデックスに除外フィルターは設定されません。つまり、インデックスフィルターに一致するログがすべてインデックス化されます。
ですが、すべてのログに同等の価値があるわけではないため、インデックスに流し入れたログの中でどれを削除するかを、除外フィルターを使用して制御することができます。除外したログはインデックスから破棄されますが、Livetail には残るので、メトリクスの生成やアーカイブに使用できます。
除外フィルターは、クエリ、サンプリング規則、および active/inactive のトグルで定義します。
*
です。つまり、インデックスに入るすべてのログが除外されます。ログクエリを使用して、一部のログだけが除外されるように除外フィルターを設定します。Exclude 100% of logs
であり、クエリに一致する 100% のログが除外されます。サンプリングレートを 0% から 100% の間で調節し、さらに、そのサンプリングレートを個々のログに適用するか、それとも属性の一意の値によって定義されるロググループに適用するかを決めます。注: ログのインデックスフィルターは、最初に一致した 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 に保存され、検索できる期間を決定します。保持は、アカウントコンフィギュレーションで許可されている任意の値に設定できます。 現在の契約にない保持を追加するには、Datadog サポートにお問い合わせください。
1 日の割り当てを設定して、インデックスに格納されるログの数を日別に制限することができます。この割り当ては、格納されるべき (除外フィルターが適用された後など) すべてのログに対して適用されます。 1 日の割り当て数に到達したら、ログはインデックス化されなくなりますが、livetail では利用できるほか、アーカイブにも送信されるので、ログからメトリクスを生成するために使用できます。
この割り当ては、インデックスを編集していつでも更新または削除できます。
注: インデックスの 1 日の割り当ては、UTC 時間の 2:00pm に自動的にリセットされます。
日別の割り当てに達したらイベントが生成されます。
ログ使用ガイドに従って、現在の使用量を監視し、アラートを発動させる方法をご確認ください。
お役に立つドキュメント、リンクや記事: