除外フィルター
除外フィルター (Exclusion Filter) とは、ログインデックスに入る直前のログのうち、クエリに一致したものを索引から落とす Datadog の設定のこと。除外率を下げれば一部だけを通せ、落としたログも Live Tail とアーカイブとメトリクス生成には流れる。
概要
除外フィルターは、インデックスフィルターを通ってインデックスに向かうログを、クエリと除外率で選んで索引から外す設定です。1 つのインデックスに複数を並べられ、上から順に照合して最初に一致した有効なものだけが処理されます。除外されたログは検索とログを条件にしたモニターの対象から外れますが、Live Tail には流れ、メトリクス生成の材料になり、アーカイブにも送られます。気にするのは、索引の費用を下げたいとき、そして Live Tail には見えるのに Log Explorer で出てこないログの原因を探すときです。
インデックスの入口で捨てるものを決める設定
除外フィルター (Exclusion Filter) とは、ログインデックスに入る直前のログのうち、クエリに一致したものをインデックスから落とす設定です。既定では除外フィルターは無く、インデックスフィルターに一致したログは全て索引付けされます (2026 年 9 月時点・出典: Indexes)。パイプラインでの加工が済んだログは、まずインデックスフィルターでどのインデックスに向かうかが決まり、次にそのインデックスの除外フィルターで残すか落とすかが決まります。インデックスフィルターは「どこへ」、除外フィルターは「入れるか」を決める、役割の違う 2 段の門です。設定は対象を選ぶクエリ、除外率、有効と無効の切り替えの 3 点で、構成要素と既定値の細部はログインデックスの項に委ねます。
上から順に、最初に当たった 1 つだけが効く
1 つのインデックスに複数の除外フィルターを並べたとき、ログは上から順に照合され、最初に一致した有効なフィルターだけが処理されます。一致したログは、除外率の抽選で残る側に入った場合でも、後続のフィルターを全て飛ばします (2026 年 9 月時点・出典: Indexes)。並び順は一覧で入れ替えられます。公式ドキュメントは、request_id ごとの 50% 除外、脅威タグの保全、DEBUG の切り替え、2XX の 90% 除外を 1 つのインデックスに並べた例で、結果を次のように説明しています。
| 届いたログ | 結果 |
|---|---|
request_id を持つログ | 同じ request_id のログはまとめて残るか、まとめて落ちる (確率 50%) |
threat:true または compliance:true のタグ付き | request_id に関係なく残る |
| DEBUG ログ | request_id の規則に従って一貫して索引付け。DEBUG 用の除外フィルターを有効にしたときだけ別に抽選される |
| 2XX の Web アクセスログ | request_id があれば 50% が残る。無ければ 90% 除外の規則で抽選される |
この例が示すのは、上に置いた規則が下の規則の適用範囲を削るという性質です。並べる順の基本は「必ず残したいものを上に、広く落とすものを下に」で、広い条件を上に置くと下の細かい指定が空振りします。
除外率で「全部捨てる」と「一部だけ残す」を使い分ける
除外率は 0% から 100% まで指定でき、100% なら一致したログを全て落とし、それ未満なら残りを索引に通します (2026 年 9 月時点・出典: Indexes)。公式ドキュメントが挙げる使い方は 3 つの型に分かれます。1 つは status:DEBUG を 100% 除外にしておき、障害や重要なリリースのときだけ切り替えで無効にして DEBUG を通す型です。もう 1 つは、Web アクセスログの 3xx / 4xx / 5xx は全て残し、2xx だけ source:nginx AND http.status_code:[200 TO 299] で 95% 除外して傾向を追う型です。3 つ目は、env:production のログを @user.email の値ごとに 90% 除外し、残した利用者についてはログを欠けなく揃える型です。属性の値ごとに抽選できるので、一部の利用者だけ欠けのない全体像を残す設計が成り立ちます。
捨てたログは消えたのではなく、索引に入らないだけ
除外はログの削除ではありません。公式ドキュメントは、除外されたログはインデックスから捨てられるが、Live Tail には流れ、メトリクスの生成に使え、アーカイブにも送られる、と明記しています (2026 年 9 月時点・出典: Indexes)。
- パイプラインで加工済みのログが届く
- インデックスフィルターで行き先のインデックスが決まる
- 除外フィルターに一致し、抽選で落ちた分はインデックスに入らない
- 落ちた分も Live Tail に流れ、ログベースメトリクスの材料になり、アーカイブへ送られる
- インデックスに無いので、Log Explorer の検索とログを条件にしたモニターの対象にはならない
実務でつまずくのは最後の点です。Live Tail には見えているのに Log Explorer で検索すると出てこない、ログの件数を数えるモニターが鳴らない、という現象の原因が除外フィルターであることがあります。ログを条件にしたモニターはインデックス済みのログだけを評価する、と公式ドキュメントに明記されています (2026 年 9 月時点・出典: Log Monitor)。後から必要になったログは、ログアーカイブに送っていればリハイドレートで索引に戻せます。切り替えを無効に戻しても、効くのは以後に届くログだけです。
保持フィルターや日次クォータと何が違うか
名前の似た設定と混同しないようにします。APM の保持フィルターは取り込んだスパンのうち残すものを選ぶ規則で、除外フィルターは落とすものを選ぶ設定なので、向きが逆です。同じインデックスに設定する日次クォータは 1 日に索引する件数の上限で、内容を選ばずに量で止める仕組みです。両者の関係はログインデックスの項で扱っています。除外フィルターを気にする場面は 2 つあります。1 つ目は索引の費用を下げたいときで、入口で落とす件数がそのまま索引件数に効きます。件数に応じた課金の仕組みはログ料金の読み解きへ。2 つ目は、あるはずのログが検索で出ないときで、Log Management の設定画面にある除外フィルターの一覧と順番を最初の確認先にします。