Datadog運用のベストプラクティス：タグ設計・監視対象の絞り込み・アラート・コスト抑制

Datadogを入れた直後は動きます。困りはじめるのは半年後です。ダッシュボードが増え、アラートが鳴り止まなくなり、請求額の内訳が説明できなくなる。この記事では、そこに至らないための設計を、タグの命名規約、Agentが拾う範囲の絞り込み、カスタムメトリクスの数え方、アラート設計、ログとAPMの取り込み制御という順で整理します。数値は2026年8月時点の公式ドキュメントで確認した値です。

まとめ：Datadogの運用設計で最初に決める4つの土台

結論から置きます。運用が破綻するかどうかは、タグ体系、収集対象の範囲、カスタムメトリクスのカーディナリティ、アラートの発火条件という4つで決まります。いずれも、データが溜まってから変えるとダッシュボードとモニターの作り直しが発生する領域です。

タグはenv・service・versionの統合サービスタグ付けを土台に置いてください。この3つが揃っていないと、メトリクスからトレース、トレースからログへの横断が成立しません。タグは小文字に正規化される仕様のため、キャメルケースのタグキーは後から食い違いを生みます。

費用の増え方は、ホスト数よりも「メトリクス名とタグ値の組み合わせの数」で決まります。包含枠はProがホストあたり100件、Enterpriseが200件。ユーザーIDのような値をタグへ入れた瞬間に突破します。

アラートは、鳴った全件に人が反応できる本数へ絞り込んでください。閾値だけを置いて評価ウィンドウと復旧閾値を省くと、フラッピングで通知が増え、無視される通知が定着します。製品そのものの機能範囲はDatadogとは何か？機能やメリット、導入の背景を詳しく解説で整理しています。

統合サービスタグ付けを起点にしたタグ命名規約と再取得できない設計判断

タグ設計は、後から直す手段が実質的に無い領域です。送信済みのテレメトリへ遡ってタグを付け直すことはできません。最初の1回で決め切る前提で組み立てます。

env・service・versionを全テレメトリに揃える統合サービスタグ付け

統合サービスタグ付けは、env、service、versionという3つの予約タグでメトリクス・トレース・ログを結び付ける仕組みです。非コンテナ環境ではDD_ENV・DD_SERVICE・DD_VERSIONを環境変数として渡し、Kubernetesではラベルtags.datadoghq.com/env等と同名の環境変数を併用します。

設定漏れより厄介なのが、食い違いです。公式ドキュメントは、グローバルにenvタグを設定した状態でPod側へ別のenvタグを置くと、そのPodのデータに両方のenvタグが付くと明記しています。片方だけを見ているダッシュボードでは、二重に集計されているのか単に足りないのかを判別できません。versionタグにコミットハッシュを載せておけば、リリース前後の比較はタグの切り替えだけで済みます。

小文字と200字上限に沿ったタグキーの命名規約と禁止パターン

タグは200字まで。key:value形式の場合は、キーとコロンと値の合計で200字を数えます。使える文字はUnicodeの文字・数字・アンダースコア・マイナス・コロン・ピリオド・スラッシュで、それ以外はアンダースコアへ自動変換されます。連続したアンダースコアは1つにまとめられる仕様です。

実務で効くのは小文字への正規化です。スパンタグとメトリクスタグは小文字へ正規化されるため、teamNameとteamnameは同じものになります。逆に値側の表記ゆれは残ったまま。env:prodとenv:productionが混ざると、どちらのモニターにも半分しか乗りません。値の語彙表を先に作り、10語程度へ固定してください。予約タグキーはhost、device、source、service、env、version、teamの7つで、ここへ自社の意味を上書きしない点も規約に書きます。

チーム・課金・環境の3系統で分けるタグ体系の設計と棚卸し頻度

タグを増やす前に、何のための軸かを分けます。必要になるのは、障害時に絞り込む軸、費用を配賦する軸、環境を切り替える軸の3系統。役割を混ぜたタグは、どちらの用途でも中途半端になります。

棚卸しは四半期に1回で足ります。見るのは、値の種類が1つしかないタグと、数千種類あるタグの両端。前者は情報量が無く、後者は課金へ跳ね返ります。

Agentが収集する対象の絞り込みとコンテナ単位の除外設定の実装

Agentは既定で見つかるものを広く拾います。Kubernetes環境ではサイドカーやジョブ用の短命Podまで対象に入り、ホスト数と取り込み量の双方を押し上げます。

DD_CONTAINER_EXCLUDEで収集対象から外すコンテナの指定方法

コンテナの除外はAgent 7.20以降で6つの環境変数から指定します。全データを対象とするDD_CONTAINER_EXCLUDEとDD_CONTAINER_INCLUDE、メトリクスだけのDD_CONTAINER_EXCLUDE_METRICS系、ログだけのDD_CONTAINER_EXCLUDE_LOGS系。値はスペース区切りの正規表現で、接頭辞はname:、image:、kube_namespace:の3種です。

最初に外す候補は、CIのビルド用Pod、CronJobが生成する短命コンテナ、サービスメッシュのサイドカーの3つ。kube_namespace:で指定すれば個別のコンテナ名を追う必要はありません。Agent 7.45以降はPodアノテーションad.datadoghq.com/excludeでPod側から除外を宣言でき、7.73以降ではCEL式のcel_workload_excludeも使えます。監視項目の決め方はKubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断で扱っています。

メトリクスとログで収集範囲を分ける除外設定と優先順位の落とし穴

メトリクスとログは、必要な粒度が違います。バッチ処理のコンテナは、リソース使用量のメトリクスは要らない一方、失敗時のログは残したい。この場合はDD_CONTAINER_EXCLUDE_METRICSだけを指定します。全データ用の変数で一括除外すると、障害時に手掛かりが消えます。

設定を書いたのに効かない、という相談の大半は優先順位です。公式ドキュメントは「インクルードがエクスクルードに優先する」と明記しています。広めのインクルードを1行書いた結果、その後に並べた除外がすべて無効化されている例が典型。例外はPodの除外アノテーションで、こちらはインクルード規則より優先されます。

インテグレーションを有効化する数の基準とメトリクス増加の抑え方

インテグレーションは、有効化した数だけメトリクスが増えます。基準は単純で、そのメトリクスを見て人が何かを変えるかどうか。MySQLのコネクション数は閾値を超えたら接続プールを直しますが、同時に取れる数十のカウンタの多くは障害調査で一度も開かれません。90日間どこからも参照されていないカスタムメトリクスは、メトリクスサマリー画面で洗い出して送信元を止める候補にしてください。

カスタムメトリクスのカーディナリティと課金へ波及する設計上の境界線

メトリクス名とタグ値の組み合わせで数が決まる課金単位の仕組み

公式ドキュメントの定義では、カスタムメトリクスは「メトリクス名とタグ値の組み合わせ」で一意に識別され、hostタグもその組み合わせに含まれます。2台のホスト、2つのエンドポイント値、2つのステータスコードを持つメトリクスは、組み合わせの積で4つのカスタムメトリクスとして数えられる、という例が示されています。

誤解されがちな点も明記されています。タグを足せば必ず増えるわけではありません。件数は、そのデータセットで最も細かいタグに引きずられます。増やしているのは常に、値の種類が多いタグのほうです。

ホストあたり100件・200件という包含枠から逆算する設計の考え方

包含枠は、Proがホストあたり100件、Enterpriseが200件のインデックス済みカスタムメトリクスです。枠はインフラ全体で合算され、ホスト間で融通できます。50ホストのPro契約なら5,000件が枠内。

逆算すると設計が決まります。50サービスが動く環境で5,000件なら、1サービスあたり100件。「1メトリクスにつきタグの組み合わせが何通りになるか」を実装前に計算しておけば、送信を始めてから枠を超えて慌てる事態を避けられます。枠を超えた分は契約で定めた超過料金が発生する仕組みです。

ユーザーIDやリクエストIDをタグにした場合の増加パターンと対処

枠を壊す原因は、ほぼ2つ。一意な識別子をタグに入れることと、エラーメッセージをそのままタグ値にすることです。ユーザーID単位のタグは、利用者が1万人いれば1万通りの組み合わせを作ります。1メトリクスで枠の2倍を消費する計算です。

対処は、識別子をタグではなくログやトレースの属性へ移すことです。ログの属性やスパンタグはカスタムメトリクスとして数えられないため、個別の調査はログやトレースの検索へ、集計はサービス単位・エンドポイント単位のメトリクスへ、と分担を切り替えます。応急処置として Metrics without Limits で不要なタグを集計対象から外す手もありますが、恒久策は送信側の修正です。

アラート設計の型：閾値・評価ウィンドウ・通知先の決め方と再通知

モニターは作るのが簡単で、消すのが難しい機能です。作る時点で、鳴ったら何をするかまで決めておきます。

5分・15分・1時間から選ぶ評価ウィンドウと誤検知発生の関係

ローリング評価ウィンドウは直近5分・15分・1時間、またはカスタムで最大1か月まで指定でき、ログモニターの上限は2日です。加えて、現在の時間・現在の日・現在の月を対象とする累積ウィンドウがあり、こちらはメトリクスモニターのみで使えます。

選び方の目安は、対象指標の変動周期です。CPU使用率のようにスパイクが常態の指標を5分で見ると、デプロイのたびに鳴ります。逆にエラー率を1時間で平均すると、5分間の全断が閾値に届かず見逃されがちです。即応が要る指標は5分、傾向を見る指標は1時間以上で分けてください。

アラート閾値と復旧閾値を別に置くフラッピング抑止の具体的な設定手順

閾値ちょうどを行き来する指標は、アラートと復旧を繰り返します。Datadogのモニターはアラート閾値・警告閾値それぞれに復旧閾値を個別設定できるため、発火をCPU 85%、復旧を75%のように離して置いてください。この10ポイントの差が、通知の往復を止めます。

1. アラート閾値を、対応が必要になる水準で設定する
2. 警告閾値を、その手前で確認したい水準に置く
3. 復旧閾値をアラート閾値より低い値に設定する
4. 自動解決を、データ送信が止まった場合の待ち時間に合わせて選ぶ

自動解決は「なし」「1時間後」「2時間後」から選びますが、これはデータの送信が止まった場合にのみ働く設定です。閾値を下回って回復した通常のケースは復旧閾値の側で扱います。混同すると、解決済みのアラートが数時間残ります。

通知先とメッセージ本文に入れる情報・オンコール呼び出しの基準

通知メッセージには、対応者が最初に開く場所を書きます。影響しているサービス名、確認すべきダッシュボードのリンク、最初に取る手順の3点。テンプレート変数でサービス名やホスト名を差し込めるため、モニターごとに文面を書き分ける手間はかかりません。

オンコールで人を起こす基準は、事業影響が出ているか、夜間に打てる手があるかの2点で決めます。ディスク使用率80%は翌営業日でよく、決済APIのエラー率上昇は即時。この線引きを通知先チャンネルの分離として実装してください。通知本数が増えて対応が形骸化する現象そのものはアラート疲れとは｜原因と対策を監視の実装視点で解説で扱っています。

ログのインデックス設計と除外フィルタによる保管コストの抑え方

ログは、取り込み量と検索できる状態で保管する量が別勘定です。全部をインデックスへ入れる設計は、費用でも検索性でも不利になります。

保持日数を分けた複数インデックスとパイプライン処理の順序設計

インデックスはアカウントあたり既定100が上限で、実務では10前後に収まります。分け方の軸は保持日数。監査要件のあるアクセスログは長め、デバッグ用のログは短め、という形で複数のインデックスへ振り分けます。

順序には注意が必要です。ログはパイプラインで属性の抽出とパースを終えてからインデックスのフィルタへ掛かるため、パース前の属性を条件にしたフィルタは一致しません。送信側でのログ整形の考え方は構造化ログとは｜JSONでログを機械可読にする仕組みとslog／structlog実装で整理しています。

除外フィルタのサンプリング率0〜100%で残すログを選ぶ基準

除外フィルタは、条件に一致したログを0%から100%の範囲でサンプリングして除外します。100%なら全件をインデックスから外し、80%なら5件に1件だけ残る動き。除外されたログも取り込み自体は行われるため、減るのはインデックス側の量です。

最初に対象にするのは、ヘルスチェックのアクセスログ、正常終了したバッチの完了ログ、INFOレベルの定型ログの3つ。エラーとWARNは残し、INFOを10%程度へ絞る設定から始めると、検索の手掛かりを保ったまま量を落とせます。個別のログへサンプリングを掛ける際は、ログに含まれるトレースIDが判定に使われるため、トレースと紐づいたログが優先的に残ります。

日次クォータと警告閾値で取り込み量の急増を止める運用の組み方

インデックスには日次クォータを百万件単位で設定できます。既定のリセット時刻は14:00 UTC。警告閾値はクォータの50%から設定でき、上限に達する前に通知を受け取れます。

クォータは平常時の1.5倍程度が扱いやすい水準です。障害でエラーログが噴き出したときに、その日の請求が想定の10倍になる事故を止められます。ただし超過分のログはインデックスに入らず、後から検索できません。障害調査に使うインデックスへは余裕を持たせ、デバッグ用の短期インデックスへ厳しめのクォータを置く配分にしてください。

APMのインジェスト制御とトレース保持量を絞る場合の判断基準

Agent既定の毎秒10トレースという目標値とサービス間の配分

ヘッドベースサンプリングでは、Agentが全体で毎秒10トレースという目標値に向けてサンプリング率を自動調整します。設定値はtarget_traces_per_second、環境変数ではDD_APM_TARGET_TPSで、既定は10。トラフィックの多いサービスへ7、少ないサービスへ3といった具合に配分され、スパイクに応じて上下します。

この目標値はDatadog製のSDKにのみ効きます。OpenTelemetryのSDKで計装している場合、Agent側の設定は効かず、SDK側のサンプラーで制御することになります。両方のSDKが混在する環境では、片方だけ絞ったつもりで全体の量が減っていない事態が起こりがちです。

サンプリング規則で特定エンドポイントの取得率を上げる場合の条件

全体を絞りつつ決済や認証の経路だけ取得率を上げたい場合は、DD_TRACE_SAMPLING_RULESでサービスやリソース単位の規則を書きます。SDK側の規則がAgentの既定より優先されます。

取得率を上げる判断は、そのエンドポイントの個別トレースを実際に開いて調査するかどうかで決めます。障害時に必ず追いかける決済APIは100%へ近づける価値がありますが、日次バッチのトレースを1件ずつ見ることはまずありません。絞るべきは、毎秒数百リクエストを処理する参照系の正常応答のほうです。

Datadogに載せない範囲の線引きと監視をやめる判断の条件

監視対象に載せる基準：障害時に人が確認する指標かどうかの線引き

載せる基準は1つで足ります。障害が起きたとき、その指標を人が見るかどうか。見ないなら載せません。「いつか使うかもしれない」で載せた指標は、使われないまま毎月課金され、ダッシュボードの視認性を下げ続けます。

判定は運用実績で行えます。過去半年のインシデント対応記録を開き、参照された画面とクエリを数えてください。実際に見られているのは全体の1〜2割。削って困ったものだけ戻す運用のほうが、増やし続けるより速く収束します。

Datadogに寄せない方が運用が軽くなる3つの場面と代替の置き方

言い切ります。次の3つは、Datadogに寄せない構成のほうが軽くなります。1つ目は監査保管が目的の長期ログ。7年保管が要件なら、オブジェクトストレージへ出して必要時に取り出す形が費用面で優位で、検索の即時性は要件に入っていません。2つ目は開発環境の常時監視です。ホスト課金は本番と同額でありながら、障害の即応は不要。CI実行時だけ計測する構成へ切り替えます。3つ目は、単一のバッチサーバーのようにスケールしない対象。APMまで入れる必要はありません。

逆に寄せる価値が明確なのは、依存関係が追えなくなったマイクロサービス構成と、フロントエンドからバックエンドまでを1本のトレースで追いたい場面。自前のツールの組み合わせでは再現に時間がかかります。監視基盤の設計と運用を内部の体制と合わせて見直す段階であれば、保守運用・内製化支援で設計から引き継ぎまでを支援しています。

見送るべき構成：全ホスト一律の詳細監視と全ログのインデックス化

見送るべき構成を条件付きで挙げます。第一に、全ホストへ一律に同じインテグレーション一式を入れる構成。役割の違うホストへ同じ監視を並べると、使わないメトリクスが台数分だけ増えます。役割ごとに設定を分けてください。

第二に、全ログを無条件でインデックスへ入れる構成です。取り込みは全件で構いませんが、インデックスは除外フィルタを通した後の量に絞ります。第三に、ダッシュボードを部署ごとに自由増殖させる運用。テンプレート変数を使えば1枚でサービス横断を賄えます。同じ内容の複製が20枚並ぶ状態は誤判断の温床です。

よくある質問

Datadogの運用設計について、実装時に問い合わせの多い5点をまとめました。

Datadogのタグは後から変更できますか？

今後送信されるデータには新しいタグが付きますが、過去に送信済みのデータへ遡って付け直すことはできません。命名を変えると変更日を境に新旧のタグが並存し、その期間をまたぐダッシュボードやモニターには両方の条件が要ります。env・service・versionのような基幹のタグを最初に決め切る理由がこれです。値の表記ゆれだけなら、ログ側はパイプラインのリマッパーで寄せられます。

カスタムメトリクスが急に増えた原因はどう調べますか？

メトリクスサマリー画面で、各メトリクスのカーディナリティ（タグ値の組み合わせ数）を確認します。上位の数本が全体を占めている状態がほとんどです。該当メトリクスのタグ一覧を開き、値の種類が数百以上あるタグを特定してください。多くの場合、ユーザーID、リクエストID、URLのパスパラメータのいずれかです。

Datadog Agentのバージョンはどの程度の頻度で上げるべきですか？

2026年8月時点の最新は7.82.1（2026年8月10日公開）で、マイナー版は月に1回程度のペースで出ています。毎回追う必要はなく、四半期に1回、あるいは使いたい機能が入った時点で上げる運用で足ります。注意すべきは、新しい機能ほどAgentの版に依存する点。Podアノテーションによる除外は7.45以降という下限があります。

ログの取り込み量とインデックス量はどちらを先に減らすべきですか？

先に手を付けるべきはインデックス側です。除外フィルタの設定だけで完結し、送信側のコードや基盤の変更を伴いません。取り込み量そのものを減らすにはAgent側での収集対象の絞り込みかログ出力レベルの見直しが要り、リリース作業を伴います。まずインデックスで削る順序が現実的です。

アラートは何本くらいが適正な数ですか？

絶対的な本数の基準はありませんが、判断できる目安はあります。1週間に鳴った通知のうち、人が何らかの操作をしたものの割合を数えてください。5割を下回っているなら、モニターが多すぎるか閾値が緩すぎます。サービス単位では、Golden Signalsに沿った4〜6本を軸に、事業固有の指標を数本足す構成が扱いやすい規模です。

関連記事

• Datadogとは何か？機能やメリット、導入の背景を詳しく解説：製品全体の機能範囲を押さえたい場合の入口。
• Golden Signals（4つのゴールデンシグナル）とは？SREの監視指標と実装・アラート設計を解説：どの指標を監視対象に選ぶかの土台。
• アラート疲れとは｜原因と対策を監視の実装視点で解説：通知が形骸化する原因と削減の進め方。
• Kubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断：コンテナ環境での監視範囲の判断。
• TerraformでDatadogを管理する方法｜Provider設定・モニター・インポート実践ガイド：決めた設計をコードで管理する手順。