ログボリュームを削減するための戦略

Docs > Observability Pipelines（観測データの制御） > Observability Pipelines Guides > ログボリュームを削減するための戦略

概要

Observability Pipelines を使用すると、オンプレミスまたはクラウド環境からデータが離れる前に、ログを収集・処理し、どこへルーティングするかを決定できます。

ログはすべて同じ価値があるわけではありません。たとえば、ライブ運用のトラブルシューティングでは、error ログの方が info ログより有用であることが多いです。本番環境のログは、非本番環境のログよりも重要です。そのため、すべてのログをインデックスソリューションへルーティングすると、データ全体の価値が希薄化し、予算を超過する可能性があります。

次のような状況でも、ログボリュームとコストが不必要に増加することがあります:

アプリケーションチームが誤って debug ロギングを有効にしてしまう。
エラーループ条件を含む新しいビルドをリリースし、エラーが大量発生する。
チームが他のテレメトリーソリューションを実装するよりも簡単だと思い、ログにできる限り多くのパフォーマンスデータやメトリクスデータを追加しようとする。
ログに使用されないフィールドや値が余計に含まれている。

本ガイドでは、Observability Pipelines のプロセッサーを活用してログボリュームを削減する戦略を紹介し、コストを抑えつつ保存データの価値を高める方法を説明します。

ログボリュームを削減する戦略

次の戦略に従ってログボリュームを削減しましょう:

ログをサンプリングする

繰り返しが多くノイズが多い、または価値が低いと分かっている大量のログの一部を破棄することで、全体のログボリュームを削減します。サンプルプロセッサーを使用してフィルタークエリに一致するログのサブセットを抽出し、指定した割合のログのみを保持します。これにより、可視性と分析能力を維持しつつ、大量ログストリームの代表的なビューを得ることができます。

http.status_code:200 と http.method:GET に一致するログの 50% を保持するサンプルプロセッサー

ログをフィルタリングする

すべてのログが価値を持ち、保存が必要とは限りません。たとえば、非本番システムの debug ログを保持する必要はおそらくないでしょう。そのため、フィルタープロセッサーを使用してそれらのログを破棄し、ログ管理ソリューションへ送信しないようにします。

ログの属性を削除する

ログには数百の属性が含まれることがありますが、調査や分析に使用される属性はごくわずかです。使用されていない、または有用でない属性を削除することでログのサイズを縮小し、取り込みコストを下げるためにフィールド編集プロセッサーを使用します。

ログを削減する

システムは 1 秒あたり数百、場合によっては数千のログを出力します。これらのログを、連結、合計、値の配列化など、さまざまな方法でフィールドをマージし、1 つのイベントにまとめます。選択したマージ戦略に基づいて複数のログイベントを 1 つのイベントにまとめるには、リデュースプロセッサーを使用します。これにより、送信先へ送られるイベントの総数が削減されます。

ログを重複排除する

ログを重複排除すると、データの正確性と一貫性を維持し、誤ってログが重複送信される上流側のミスから保護できます。デデュプリケーションプロセッサーを使用してフィールドを比較し、内容が同一かどうかを確認して重複を破棄し、ログボリュームを削減しましょう。

クォータを実装する

クォータを利用すると、さまざまなレベルでログをガバナンスおよび制御できます。たとえば詳細レベルでは特定のアプリケーションログ (app:xyz) に上限を適用し、より高いレベルでは info ログ (status:info) に上限を適用できます。これにより、予算と使用量の要件を満たすことが可能です。

クォータプロセッサーを使用して次の設定を行います。

フィルターを定義する: 監視対象のログを絞り込むためのフィルターを設定します。これは環境単位の高レベルフィルターでも、チーム単位の詳細フィルターでも構いません。また、複数のログ属性を組み合わせてフィルタリングすることも可能です。
クォータを定義する: バイト数またはイベント数に基づいてクォータを設定します。クォータを超過したログを破棄するか、あるいは上限到達時にアラートのみを受け取り、調査・対処を行うかを選択できます。

http.status_code:200 のフィルタークエリと 1 TB/日の上限を設定したクォータプロセッサー

ログを直接アーカイブへルーティングする

ログを Datadog でリハイドレート可能な形式で、Amazon S3、Google Cloud Storage、Azure Storage など自社クラウドストレージへ直接ルーティングできます。必要に応じてアーカイブを Datadog へ再取り込みできます。詳細はログをアーカイブするを参照してください。