Contents
Datadog の観測データ 3 層構造と基本概念
Datadog が提供する Metrics‑Logs‑Traces は、クラウドネイティブ環境における可観測性の土台です。本セクションでは、各層が何を表すのか、そしてそれぞれがどのように Datadog 上でデータモデル化されているのかを整理します。3 層を正しく理解することで、障害検知から根本原因解析まで一貫したワークフローを構築できます。
Metrics（メトリクス）の定義と役割
Metrics は数値化された時系列データです。CPU 使用率やリクエストレートなど「何が起きているか」を瞬時に把握でき、ダッシュボードやアラートの基盤となります。Datadog では ポイント／ホスト 単位で保存され、集計間隔やタグ付けによって柔軟な分析が可能です。
Logs（ログ）の定義と役割
Logs はテキストベースのイベント記録で、エラー詳細やデバッグ情報など「なぜ起きたか」を追跡するために重要です。Log Management ではインデックス化されたログを高速検索でき、メトリクスと組み合わせることで包括的な分析が実現します。
Traces（トレース）の定義と役割
Traces は分散アプリケーションのリクエストフローをスパン単位で追跡するデータです。サービス間呼び出しやボトルネックの特定に使われ、Datadog APM がリアルタイムに可視化します。
ポイント：3 層は「量」「内容」「流れ」の観点で相互補完し、単体では見えないインシデント原因を明らかにします。
データ取得方法と相関機能
このセクションでは、公式ドキュメントに基づく 具体的な設定手順 と、ログ・トレースを結びつける Connect Logs and Traces の仕組みを解説します。実装時の混乱を防ぐため、各設定項目の意味と適用例を詳述します。
Metrics と Logs の取得方法（logs_to_metrics）
Datadog Docs の「取り込んだログからメトリクスを生成する」に記載された手順です。以下は YAML 形式でエージェントに設定する最小構成例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
logs: - type: file # ログ取得元の種別 path: /var/log/app/*.log # 監視対象ファイルパターン service: my-app # サービス名（タグ付与用） source: java # データソース識別子 processors: - logs_to_metrics: # メトリクス変換プロセッサ name: request.errors # 生成するメトリクス名 query: "status:error" # ログ検索クエリ（Lucene 構文） aggregation_type: count # 集計方式（count, gauge, etc.） interval_seconds: 60 # 集計間隔（秒） |
手順のポイント
logs_to_metricsセクションは Processor の一種で、ログ行がマッチしたときに自動的にカウントを集計します。nameは Datadog UI でも検索しやすいよう、プロジェクト固有の命名規則を設けることが推奨されます。interval_secondsを短くするとリアルタイム性は上がりますが、ポイント消費量も増えるためコストと相談してください。
Traces の取得方法（APM エージェント）
Datadog APM は各言語向け公式エージェントをインストールするだけでトレース情報を自動収集できます。外部サイト iRet.media の記事は非公式 であるため、以下の公式リソースを参照してください。
- Java: https://docs.datadoghq.com/ja/tracing/setup_overview/java/
- Python: https://docs.datadoghq.com/ja/tracing/setup_overview/python/
- Go: https://docs.datadoghq.com/ja/tracing/setup_overview/go/
具体的なインストール手順（例：Python）
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# 1. Datadog Agent のインストール（Linux） DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=<YOUR_API_KEY> bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)" # 2. ddtrace ライブラリの導入 pip install ddtrace # 3. アプリ起動時に自動インストルメンテーションを有効化 export DD_SERVICE=my-python-app export DD_ENV=production export DD_TRACE_ENABLED=true ddtrace-run python app.py |
設定項目の意味
| 環境変数 | 説明 |
|---|---|
DD_SERVICE |
サービス名（Datadog UI のフィルタで使用） |
DD_ENV |
環境タグ（例：production, staging） |
DD_TRACE_ENABLED |
トレース送信の有効/無効を制御 |
Connect Logs and Traces による相関手法
公式ドキュメント「ログとトレースの相関」に沿って、log injection を有効化するだけで trace_id と span_id が自動的に各ログ行へ埋め込まれます。
|
1 2 3 4 |
apm_config: enabled: true log_injection: true # ここを true にすると trace_id/span_id が付与される |
上記設定後、アプリ側で生成された JSON ログは次のようになります。
|
1 2 3 4 5 6 7 |
{ "message": "DB query failed", "trace_id": "1234567890abcdef", "span_id": "fedcba0987654321", "level": "error" } |
活用フロー
- Datadog の Log Explorer で
trace_idを検索 → 該当ログがハイライト。 - ログエントリの右側に表示される 「View Trace」 ボタンをクリックすると、対応するトレース画面へ遷移。
- トレース上のスパンとログを横断的に確認でき、根本原因解析が迅速化します。
ポイント：取得機構は「自動収集」と「相関付与」の二段階で構成されており、運用負荷を最小限に抑えつつ全体像を把握できます。
ユースケース別 推奨組み合わせと導入シナリオ
ここでは実務で頻出する 3 パターンのシナリオを示し、設定フローと注意点 を具体的に解説します。各 H3 は簡潔な導入文から始め、手順一覧へとつなげます。
インシデント初動：Metrics + アラート
インシデントの早期検知には数値指標ベースのモニタリングが最も効果的です。以下は CPU 使用率を閾値で監視し、Slack に通知する手順です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# datadog.yaml（エージェント側設定例） monitors: - name: "High CPU usage" type: metric alert query: "avg(last_5m):avg:system.cpu.user{host:*} > 80" message: | {{#is_alert}} *CPU 使用率が 80% を超えました* :warning: ホスト: {{host.name}} 詳細は Datadog ダッシュボードをご確認ください。 @slack-channel {{/is_alert}} tags: - env:production options: notify_no_data: false evaluation_delay: 300 |
ポイント
evaluation_delayを設定すると、短時間のスパイクを除外できる。- Slack 通知は Integrations → Slack で Webhook を事前に作成しておく必要があります。
根本原因解析：Traces + Logs の相関
問題の詳細分析ではトレースとログの相関が不可欠です。以下は log_injection を有効化した上で、特定エラーログから該当スパンへ遷移する手順です。
- APM エージェント設定（前述の
apm_config.log_injection: true）を適用。 - ログパイプラインにフィルタ追加：
trace_idが空でない行だけをインデックス化し、ノイズ削減。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
logs: - type: file path: /var/log/app/*.log service: my-app source: python processors: - decode_json_fields: fields: ["message"] target: "" - exclude_at_match: # trace_id が無い行は除外 match: '"trace_id":null' |
- Log Explorer で
trace_id:<ID>を検索 → 「View Trace」ボタンでスパン詳細へ遷移。
パフォーマンス最適化：カスタムメトリクス + サンプリング
高頻度指標はコストが膨らみやすいため、サンプリング と カスタムメトリクス の組み合わせで最適化します。
カスタムメトリクス作成手順
conf.d/custom_metrics.yamlをエージェントに配置。metrics:セクションで名前・タイプ・値を定義。
|
1 2 3 4 5 6 7 8 9 10 |
init_config: instances: - name: request_rate type: gauge value: "{{request_per_sec}}" tags: - service:my-app - env:production |
- アプリ側で
DogStatsDに対し、1 秒ごとにリクエスト数を送信。
|
1 2 3 |
from datadog import statsd statsd.gauge('my_app.request_per_sec', request_count) |
APM サンプリング設定例（全体 10%）
|
1 2 3 4 5 6 7 |
apm_config: enabled: true sample_rate: 0.1 # 全トレースのうち 10% を送信 service: my-app: trace_sample_rate: 0.3 # 特定サービスだけは 30% に上げる |
注意点
sample_rateは エージェント側 の設定であり、Datadog UI 上のサンプリングとは別に機能します。- サンプリング率を変更した場合は、ポイント消費量と可視性のバランス を必ず評価してください。
コスト構造と価格情報の取り扱い
Datadog の料金は 使用量ベース で決まり、各層ごとに課金単位が異なります。以下の表は 2026 年 6 月時点の公式プライシング（Datadog Pricing）を元に作成しましたが、価格は随時変更される可能性があります。出典と更新手順 を必ず明示し、定期的に見直すことを推奨します。
| 層 | 課金単位 | 主な価格要素（2026‑06 時点） | コスト削減のポイント |
|---|---|---|---|
| Metrics | ポイント／ホスト（月） | カスタムメトリクス 1,000 ポイント ≈ $15 | logs_to_metrics の活用で不要なカスタムメトリクスを削減、集計間隔を長めに設定 |
| Logs | インデックス容量（GB）＋取り込み量（GB） | 1 GB インデックス = $0.10、取り込み 1 GB = $0.25 | ログ保持期間の短縮、exclude_at_match フィルタでノイズ除去 |
| APM (Traces) | トレース数／ホスト（月） | 100,000 トレース ≈ $31（サンプリング率に応じて変動） | sample_rate 設定で重要トレースのみ送信、不要サービスのエージェント停止 |
出典：Datadog 公式プライシングページ（2026‑06 更新）。本表は執筆時点の情報です。価格改訂が行われた場合は、本文中の「[最新プライシング]」リンク先を確認し、表の数値と出典日付を更新してください。
料金最適化のベストプラクティス
- Metrics‑to‑Logs 変換で不要なカスタムメトリクスを削減。
- APM サンプリング（
sample_rate）で送信トレース数を抑制。 - ログ除外フィルタ（
exclude_at_match）でインデックス容量を最小化。
ベストプラクティスと他社ツールとの相対的優位性
この章では、Datadog を実務に即活用できる設定例と、主要競合ツールとの比較ポイントを示します。
Metrics‑to‑Logs 変換の活用例
ログベースのエラーレートをメトリクス化すれば、アラート作成がシンプルになります。以下は Nginx の 404 エラーを 1 分ごとに集計し、閾値超過時に通知する設定です。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
logs: - type: file path: /var/log/nginx/access.log service: nginx source: nginx processors: - logs_to_metrics: name: nginx.404_rate query: "status:404" aggregation_type: count interval_seconds: 60 |
設定後の流れ
nginx.404_rateが Datadog UI の Metrics Explorer に自動登録。- このメトリクスを基に Monitor を作成し、閾値超過時に PagerDuty へ通知。
カスタムメトリクス作成手順（再掲）
conf.d/custom_metrics.yamlに YAML を配置。- 必要なら DogStatsD 経由でアプリ側から送信。
- Datadog UI の Metrics > Explorer で可視化し、ダッシュボードにピン留め。
サンプリング設定によるコスト削減
| 設定項目 | 推奨値 | 効果 |
|---|---|---|
apm_config.sample_rate |
0.1 （10%） | 全体トレース数を 90% 削減 |
service.<name>.trace_sample_rate |
0.3（重要サービスのみ） | クリティカルパスは可視性確保 |
他社ツールとの相対的優位性（簡潔比較）
| ツール | メリット | Datadog の優位点 |
|---|---|---|
| Prometheus | オープンソース、プルモデルが高速 | 1 つの SaaS で Metrics・Logs・Traces を統合管理、相関検索が標準装備 |
| ELK (Elasticsearch‑Logstash‑Kibana) | 強力な全文検索と可視化 | APM と Logs のネイティブ相関機能、ポイント課金で予算管理が容易 |
| Jaeger | 分散トレースに特化、軽量 | Metrics と Logs までカバーし、ダッシュボード・アラートを一元提供 |
結論：Datadog は「観測データのフルスタック」を SaaS で提供し、個別ツールの統合コストや運用負荷を大幅に削減します。
まとめ
- 3 層構造（Metrics‑Logs‑Traces） が Datadog の観測基盤を形成し、量・内容・流れを相互補完します。
- 各層は公式エージェントや
logs_to_metrics、APM エージェントで自動取得でき、Connect Logs and Tracesによりシームレスに相関付けが可能です。 - ユースケース別の推奨組み合わせ（インシデント初動→Metrics、根本原因解析→Traces+Logs、パフォーマンス最適化→カスタムメトリクス＋サンプリング）を導入すれば、運用効率と可視性が飛躍的に向上します。
- コスト構造は使用量ベース であり、Metrics‑to‑Logs 変換やサンプリング設定で最適化できます。価格情報は公式プライシングページを出典として定期的に更新してください。
- ベストプラクティス（ログからメトリクス生成、カスタムメトリクス作成、APM サンプリング）と 他社比較 を踏まえ、Datadog はフルスタック観測ツールとして高いコストパフォーマンスを提供します。
本稿の外部リンクはすべて公式ドキュメント（docs.datadoghq.com）に置き換えてあります。情報の正確性については、執筆時点での公式ページをご確認ください。