ログインデックス

概要

ログインデックスは、Datadog に送ったログのうちどれを検索・分析できる形で保存するかを決める入れ物です。公式ドキュメントでは、保持期間、日次クォータ、利用量の監視、そして課金の単位としてログを区分する仕組みと位置づけられています。ログの費用が読みにくいと言われる原因は、送った量で発生する課金と、索引に入れた件数で発生する課金が別に存在することにあります。この 2 段構えを分けて考えられるようになると、「全部保存するか、何も残さないか」という乱暴な二択から抜け出せます。デバッグログが一晩で膨らんだときに、翌朝の請求を心配せずに原因調査だけ続けられるかどうかは、索引をいくつ用意し、どのログをどの入れ物に入れ、1 日の上限をどこに置いたかで決まります。

索引に入ったログだけが検索できる

Datadog にログを送っても、送った全部がそのまま検索できるわけではありません。公式ドキュメントはログインデックスを、保持期間・日次クォータ・利用量の監視・課金のためにログを区分する仕組みと説明し、索引に入ったログについてファセット検索、パターン表示、分析、モニターが使えると述べています。裏を返すと、索引に入っていないログはこれらの対象外です。

新しいアカウントは、すべてのログを受け取る索引が 1 つだけある状態から始まります。この初期状態のまま運用すると、道筋の途中にある 3 つの制御 (振り分け・間引き・上限) がどれも効いていないため、送った量がそのまま索引付けの量になります。ログ費用の相談で最初に確認すべきなのは、収集の設定ではなく索引がいくつあるかです。

入れ物を分けるほど予算が読める、ただし順番が結果を決める

公式ドキュメントは、複数の保持期間を使い分けたい場合や、複数の日次クォータを持ちたい場合に索引を分けることを推奨しています。監査に関わるログは長め、動作確認のためのアクセスログは短め、というように、性質の違うログを 1 つの入れ物に同居させないための分割です。索引の数は既定で 1 アカウント 100 件 (2026 年 8 月時点)までで、サポートに依頼すれば引き上げられます。 名前の付け方には制約があり、先頭は英字、使えるのは小文字の英字・数字・ハイフンです。さらに、削除した索引はログの受け入れを止め、検索もできなくなり、同じ名前を二度と使えません。命名を後から直せない前提で決める必要がある、という意味です。 運用で見落としやすいのは順序です。フィルタは上から順に評価され、ログは最初に条件が一致した索引に入ります。並べ替えはドラッグ操作でできてしまうので、索引を 1 つ上に差し込む操作が、そのログを何日保存するか、どの単価で課金するかの付け替えになります。既存の索引に入っていたログの一部が静かに移動する形なので、並べ替えの前後で件数の変化を見ておくのが安全です。タグでサービスや環境を判別できるようにしておくと、この振り分け条件を短く書けます。

単価表を読むと、効く変数が保持日数ではないと分かる

2026 年 8 月時点の公式料金ページ (us リージョン・年契約 / 月契約 / オンデマンドの 3 建て) では、取り込みは 1 GB あたり 0.10 ドルで、対象は非圧縮データの処理取り込み、またはリハイドレート時の圧縮データスキャンと記載されています。索引付けは月あたり 100 万ログイベントを単位に、保持日数ごとの単価が置かれています。

30 日を超える保持は価格が公表されておらず、問い合わせ扱いです。本記事の価格は各時点の実例であり、執筆後の価格改定を反映するものではありません。 この表の形から読み取れることがあります。保持を 3 日から 30 日へ、つまり 10 倍に伸ばしても単価は約 2.4 倍です。一方、保持日数を変えずに支払い方をオンデマンドにすると、3 日保持では年契約の 1.5 倍になります。日数は費用に対してかなり鈍い変数で、保持を詰めても単価は 10 分の 1 にはならず、検索できる範囲が狭くなるだけです。 効く順に並べると、索引に入れる件数を減らすこと、使う量を先に約束すること、そのうえで保持日数を選ぶことになります。件数は除外フィルタと日次クォータで直接動かせるので、費用を下げたいときに最初に触るのはそちらです。保持日数の議論から入ると、調査できる期間を削ったのに請求額があまり変わらないという結果になりがちです。

索引に入れる前に落とす - 除外フィルタと日次クォータ

索引には既定で除外フィルタがありません。つまり、インデックスフィルタの条件に一致したログはすべて索引付けされます。ここに手を入れるのが、費用を抑える主な作業です。 除外フィルタは、対象を選ぶクエリ、サンプリング規則、有効と無効の切り替えの 3 点で構成されます。作った直後の既定値はクエリが *、規則が「一致したログの 100% を除外」で、有効な状態です。サンプリング率は 0% から 100% まで指定でき、ログを 1 件ずつ対象にする形と、属性値ごとのまとまりを対象にする形があります。まとまりの単位には @user.email やトレース ID のような属性を選べます。1 件ずつの場合、Datadog はトレース ID があるときにそれを使って判定するため、同じトレースに属するログが残るかどうかが揃い、トレースとの突合が壊れにくくなります。 落とし穴は評価の打ち切りです。処理されるのは最初に一致した有効なフィルタだけで、しかも一致したログはサンプリングで残された場合でも後続のフィルタを飛ばします。「デバッグログを 90% 落とす」フィルタを上に置き、その下に「特定サービスを全部落とす」フィルタを置くと、下の指定は上の条件に当たった分には届きません。複数の索引で率をそろえたいときは、同じサンプリング率と同じ属性を各索引の規則に書く必要があると公式に明記されています。 除外は削除ではありません。除外されたログも Live Tail には流れ、メトリクスの生成に使え、アーカイブにも送られます。「検索対象から外すが、傾向は数字で追い続ける」という設定ができるわけで、ログを消す判断とは性質が違います。 もう 1 つの守りが日次クォータです。索引ごとに 1 日に保存する件数の上限を 100 万件単位で置き、除外フィルタを通した後の量に対して効きます。上限に達すると索引付けは止まりますが、Live Tail での確認、アーカイブへの送出、メトリクスの生成は続きます。リセット時刻は既定で毎日 14:00 UTC (仕様は 2026 年 8 月時点) で、任意の時刻に変更できます。警告用のしきい値をクォータに対する割合で設定でき、指定できるのは 50% 以上です。上限としきい値の変更は即時に反映され、到達時にはイベントが生成されるので、モニターで通知に回せます。 この仕組みがあると、深夜にデバッグログが噴き出しても、費用は当日のうちに天井で止まり、Live Tail とアーカイブは残ります。予算の事故に気づく手段が月末の請求書しかない状態と比べたとき、これが観測の価値そのものです。

問いの形で確かめておきたいこと

索引から外したログは失われるのか。失われません。前節のとおり Live Tail・メトリクス・アーカイブは生きているため、「後から検索したくなる可能性は低いが、量は測りたい」ログの置き場所として使えます。 アーカイブに寄せれば安く検索できるのか。ここは分けて考える必要があります。2026 年 8 月時点の料金ページによれば、アーカイブからのリハイドレートはスキャンした圧縮データ 1 GB あたり 0.10 ドルで、再び索引に入れた分は、選んだ保持期間の契約単価であらためて課金されると明記されています。索引に戻さずアーカイブを直接検索する Archive Search もあり、こちらはスキャンした 1 GB あたり 0.05 ドル (年契約) です (出典: Rehydrating from Archives)。アーカイブは安い置き場ではありますが、安い検索窓ではありません。調査のたびに戻す運用が続くなら、最初から短い保持の索引に入れておくほうが単純で読みやすい費用になります。 1 日あたりの GB 数から索引付けの件数を計算できるのか。できません。公式には GB からイベント件数への換算式が用意されておらず、直近 24 時間のログ件数を数えるクエリを 30 日分に伸ばして見積もる方法が案内されています。見積もりの根拠を「1 件あたりのサイズはたぶんこれくらい」で作ると、桁が合わない請求が届きます。 索引を減らせば安くなるのか。索引の数そのものは課金対象ではありません。動くのは索引付けした件数と保持日数です。索引を統合すると、性質の違うログが同じ保持日数と同じ上限を共有することになり、短くてよいログのために長い保持を払う形に寄りやすくなります。 似た仕組みとの区別も押さえておきます。保持期間は索引ごとに設定する値で、ログインデックスはその設定を持つ入れ物です。カスタムメトリクスやカーディナリティはメトリクス側の課金の話で、ログの索引付けとは別勘定です。設定画面の場所と一次情報は Log Indexes、単価は Datadog 料金ページ、製品全体の位置づけは ログ管理のページで確認できます。