- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
ログインデックスでは、さまざまな保持、割り当て、使用状況の監視、および課金のためにデータを値グループにセグメント化できるようにすることで、ログ管理予算をきめ細かく制御できます。インデックスは、Configuration ページの Indexes セクションにあります。インデックスをダブルクリックするか、Edit ボタンをクリックすると、過去 3 日間にインデックス化されたログの数とそれらの保存期間に関する情報が表示されます。
インデックス化されたログは、ファセット検索、パターン、分析、および監視に使用できます。
デフォルトでは、新しい各アカウントは、すべてのログのモノリシックセットを表す単一のインデックスを取得します。Datadog では、次が必要な場合に複数のインデックスを使用することを推奨します。
Log Explorer は、複数のインデックスにわたるクエリをサポートしています。
“New Index” ボタンを使って、新しいインデックスを作成します。各アカウントで作成できるインデックスの最大数は決まっており、デフォルトでは 100 に設定されています。
注: インデックス名は文字で始まる必要があり、小文字、数字、または ‘-’ のみを含めることができます。
組織からインデックスを削除するには、インデックスのアクショントレイにある「削除アイコン」を使用します。このオプションは、Logs delete data
と User manage access
の両方の権限を持つユーザーのみ使用することができます。
注: 削除されたインデックスは、今後新しい受信ログを受け付けません。削除されたインデックス内のログは、クエリに使用できなくなります。適用される保持期間に従ってすべてのログがエージングアウトした後、そのインデックスはインデックスページに表示されなくなります。
インデックスフィルターを使用すると、どのログをどのインデックスに流し入れるかを動的に管理できます。たとえば、最初のインデックスは 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 に保存され、検索できる期間を決定します。保持は、アカウントコンフィギュレーションで許可されている任意の値に設定できます。
現在の契約にない保持を追加するには、success@datadoghq.com
のカスタマーサクセスにお問い合わせください。
注: 現在の契約にない保持を使用するには、組織の設定で管理者がオプションを有効にする必要があります。
1 日の割り当てを設定して、インデックスに格納されるログの数を日別に制限することができます。この割り当ては、格納されるべき (除外フィルターが適用された後など) すべてのログに対して適用されます。 1 日の割り当て数に到達したら、ログはインデックス化されなくなりますが、livetail では利用できるほか、アーカイブにも送信されるので、ログからメトリクスを生成するために使用できます。
この割り当ては、インデックスを編集していつでも更新または削除できます。
注: インデックスの 1 日の割り当ては、UTC 時間の 2:00pm に自動的にリセットされます。
日別の割り当てに達したらイベントが生成されます。
使用量を監視してアラートを出す方法については、ログの使用量を監視するを参照してください。
お役に立つドキュメント、リンクや記事: