保持期間

概要

保持期間は、Datadog に送ったデータがどれだけの間保存され、検索や画面表示に使えるかを表す期間です。ここで多くの人がつまずくのは、Datadog に「保持期間」という単一の設定が存在しないことです。公式ドキュメントは対象データごとに既定の保持期間を定めており、15 ヶ月のものと 2 時間のものが同じ製品群の中に並んでいます。障害の振り返りを翌日に行うか 3 週間後に行うかで、手元に残っているデータの種類が変わるという意味です。さらにログとスパンについては契約プランと索引の設定が効くため、確認する場所が画面と契約書に分かれます。この記事では対象別の既定値と、保持を延ばす前に検討すべき代わりの手段を、2026 年 8 月時点の公式情報から整理します。

保持期間は 1 つの数字ではない

「Datadog のデータはどれくらい残るのか」という問いには、1 つの数字で答えられません。公式ドキュメントのデータ保持期間の一覧は、製品と対象データを行に取り、それぞれの既定値を並べる形になっています。メトリクスのタグと値は 15 ヶ月、コンテナのメタデータは 2 時間、実行中のプロセスとコンテナの情報は 36 時間です。同じ画面から見えているデータでも、明日まで残るとは限りません。 公式の用語集にも「retention」という単独の項目はありません。代わりに APM の「retention filter」が載っており、索引付けと同義の仕組みとして、15 日間保存する対象を決めるルールとして説明されています。つまり Datadog における保持期間は、単体の設定項目ではなく、対象データごとの既定値と、索引や契約の設定が組み合わさった結果として決まります。 この構造を知らないまま運用すると、必要な場面で必要なデータが無いという形で気づくことになります。金曜の夜に起きた性能劣化を月曜に調べ始めたとき、グラフの数値は残っているのに、その時刻に走っていたプロセスの一覧はもう見られません。逆に、対象ごとの既定値を把握していれば、「この種類のデータは翌営業日には消えるので、当日にスクリーンショットではなくモニターの通知やメモに残しておく」という運用が組めます。保持期間の理解は、事後調査の成否をそのまま左右します。

よく聞く言い方と、実際の既定値

現場で耳にする言い方と、公式の記述を対にして並べてみます。 「Datadog のデータは 15 ヶ月残る」。これはメトリクスのタグと値についての記述で、全体の話ではありません。同じ 15 ヶ月が適用される対象としては、イベント管理、Cloud SIEM のシグナル、クラウドコスト管理のコストメトリクス、Synthetics のテスト結果などが挙げられていますが、これらはいずれも個別に定められた値です。 「ログも他と同じ日数だけ残る」。ログ管理の保持期間は、公式の一覧では「顧客のプランによって決まる」とされています。実際にはログインデックスごとに保持日数を設定するため、同じアカウントの中で 3 日のものと 30 日のものが同時に存在します。ログについて「うちは何日か」を答えるには、索引の一覧を見る必要があります。 「トレースは 15 日残る」。APM の索引付きスパンは、15 日または 30 日でプランによって決まると書かれています。一方 APM のエラーは 15 日、サービスとリソースの統計値は 30 日で、一度画面で開いたトレースはアカウントが存続する間保存されます。同じ APM の中でも対象によって値が違うため、トレースが残っているかどうかは、どの見方で探すかによって答えが変わります。 「Session Replay は 30 日で消える」。既定は 30 日ですが、UI の拡張オプションを使う場合は 15 ヶ月と記載されています。オプションの有無で 15 倍近く変わる例です。 こうして並べると、覚えるべきなのは個々の日数そのものではないと分かります。覚えるべきは、対象ごとに違うという構造と、ログとスパンについては契約と設定が効くという 2 点です。

延ばす前に、代わりの手段を並べる

保持期間が足りないと感じたとき、最初に思いつくのは日数を延ばすことです。ただし、それが最も費用対効果の高い選択とは限りません。順に並べてみます。 まず検討したいのは、ログを数字に変換して長期に残す道です。索引の除外フィルタで検索対象から外したログも、メトリクスの生成には使えると公式に明記されています。「エラーの発生件数の推移だけを 1 年後も見たい」のであれば、ログ本文を長く保存する必要はありません。件数をメトリクスにしてしまえば、メトリクス側の保持期間で扱えます。 別の道としてアーカイブがあります。ただし前提を間違えないようにしてください。2026 年 8 月時点の料金ページによると、アーカイブを索引に戻さず直接検索する Archive Search はスキャンした 1 GB あたり 0.05 ドルから、そこから再取り込みして索引に戻した分は、選んだ保持期間の契約単価であらためて課金されます (出典: Rehydrating from Archives)。アーカイブは長期保管の手段であって、安く検索するための手段ではありません。年に一度の監査対応なら合いますが、週次の調査で毎回戻す運用なら、短い保持の索引を持つほうが安く済みます。 もう 1 つの道が Flex Logs です。2026 年 8 月時点の料金ページでは、保存イベント 100 万件あたり月額 0.05 ドル (年契約) からで、保持は 1 ヶ月から 15 ヶ月まで選べ、最低 30 日分が課金されると記載されています。なおこの単価は保存分のもので、Flex Logs で検索や集計を行う計算リソース (Flex Compute) の課金が別建てで存在します。2026 年 8 月時点の料金ページに公開単価は示されていないため、採用時は見積もりで確認してください。長期に残したいが検索頻度は低いログの置き場所として設計されている段です。本記事の価格は各時点の実例であり、執筆後の価格改定を反映するものではありません。 そして、日数を延ばす選択にも手続き上の制約があります。索引の保持期間として選べるのは、そのアカウントの構成で許可された値だけです。契約に含まれない保持期間を使いたい場合は、公式ドキュメントによれば Datadog のカスタマーサクセスに連絡し、加えて管理者が組織の設定で該当の項目を有効にする必要があります。障害の当日に思い立って延ばせる設定ではない、ということです。保持期間の設計は、事故が起きる前に済ませておく作業に属します。 この順序で考えると、判断の軸が「何日残すか」から「どの粒度で残すか」に移ります。本文をそのまま残すのか、数字だけ残すのか、圧縮して寝かせておくのか。粒度を選べる設計になっていること自体が、費用を天井なしに膨らませずに長期の傾向を追える理由です。

対象別の既定値と、隣り合う概念との区別

以下は 2026 年 8 月時点の公式ドキュメントに記載されている既定の保持期間から、設計の判断に使う頻度が高いものを抜き出したものです。契約プランやオプションで変わる行は、その旨を併記しています。

ダッシュボード、ノートブック、モニターの定義や、インシデント、参照テーブルのように、アカウントが存続する間保存される対象もあります。消えるのは観測されたデータで、設定した内容ではないという整理です。 最後に紛らわしい言葉を分けておきます。保持期間は「どれだけの間残すか」という期間の値です。ログインデックスはその値を設定する単位となる入れ物で、ログを振り分けた先ごとに別の期間を持てます。APM の retention filter は、期間を決める設定ではなく「どのスパンを索引に残すか」を選ぶルールで、公式の用語集では索引付けと同義とされています。スパンを対象に取るこのルールと、期間そのものを混同すると、費用の削減先を取り違えます。 一次情報は Datadog の公式ドキュメント Data Retention Periods、索引側の設定は Log Indexes、単価は Datadog 料金ページにあります。製品側の説明はログ管理と APM のページで確認できます。