Datadog

Datadog 総合技術ガイド -- 機能・アーキテクチャ・設定の全容

目次

  1. はじめに -- Datadog とは何か
  2. Datadog のアーキテクチャ概要
  3. Datadog Agent の仕組みと設計
  4. インフラストラクチャモニタリング
  5. APM（Application Performance Monitoring）
  6. ログ管理（Log Management）
  7. メトリクス収集とカスタムメトリクス
  8. ダッシュボードと可視化
  9. アラートとモニター設定
  10. Synthetics（外形監視）
  11. RUM（Real User Monitoring）
  12. CI Visibility
  13. Database Monitoring
  14. Network Performance Monitoring（NPM）
  15. Security Monitoring（Cloud SIEM）
  16. Cloud Cost Management
  17. Kubernetes / コンテナ環境での運用
  18. Terraform による IaC 管理
  19. API とプログラマティックアクセス
  20. ベストプラクティスとアンチパターン
  21. まとめ

1. はじめに -- Datadog とは何か

1.1 概要

Datadog は、クラウドスケールのアプリケーションに対する統合型オブザーバビリティ＆セキュリティプラットフォームである。2010 年に Olivier Pomel と Alexis Le-Quoc によって設立され、インフラストラクチャ監視、アプリケーションパフォーマンス監視（APM）、ログ管理、セキュリティ監視を単一のプラットフォーム上で提供する。

従来の監視ツールが「インフラ」「アプリ」「ログ」といった領域ごとにサイロ化していた問題を、Datadog は オブザーバビリティの三本柱（メトリクス・トレース・ログ） を統合することで解決した。さらに近年は、セキュリティ、CI/CD、コスト管理など、DevOps ライフサイクル全体をカバーするプラットフォームへと進化している。

1.2 主要な設計思想

  • 統合プラットフォーム: メトリクス、トレース、ログ、セキュリティイベントを単一の UI と API で横断的に分析可能
  • タグベースのアーキテクチャ: すべてのデータにタグ（key:value ペア）を付与し、任意の切り口で集計・フィルタリング
  • SaaS ファースト: データの収集・保存・分析をクラウド側で処理し、ユーザーは Agent のデプロイのみに集中
  • スケーラビリティ: 数十万ホスト、数百万コンテナ規模のインフラに対応する設計
  • 開発者中心: API ファースト、IaC（Infrastructure as Code）対応、CI/CD パイプラインとの統合

1.3 競合製品との位置づけ

特性DatadogPrometheus + GrafanaSplunkNew RelicDynatrace
デプロイモデルSaaSセルフホストSaaS / オンプレSaaSSaaS / Managed
メトリクス優優可優優
APM優可（Jaeger等と併用）可優優
ログ管理優可（Loki等と併用）優優良
セキュリティ良不可優可良
コスト高低（運用コスト高）高中高
統合性優可良優優

Datadog の最大の強みは、750 以上のインテグレーション（2025 年時点）と、全機能を横断するシームレスな体験にある。一方、コストが高くなりがちであるため、メトリクスのカーディナリティ管理やログのフィルタリングが重要となる。

2. Datadog のアーキテクチャ概要

2.1 全体アーキテクチャ

Datadog のアーキテクチャは、大きく データ収集層、データ転送層、バックエンド処理層、プレゼンテーション層 の 4 層に分かれる。

+------------------------------------------------------------------+
|                    プレゼンテーション層                              |
|  Dashboard / Monitors / Notebook / Service Map / Explorer         |
|  Watchdog / SLO / API                                             |
+------------------------------------------------------------------+
                              |
+------------------------------------------------------------------+
|                    バックエンド処理層（Datadog Cloud）               |
|  メトリクスDB(時系列DB) / トレースDB / ログインデックス(カラムナー)  |
|  イベント処理パイプライン / ML/AI(Watchdog) / アラートエンジン      |
+------------------------------------------------------------------+
                              |
+------------------------------------------------------------------+
|                     データ転送層                                    |
|  HTTPS (TLS 1.2+) / gRPC / WebSocket                             |
|  エンドポイント: app.datadoghq.com, intake.logs.datadoghq.com     |
|  リージョン: US1, US3, US5, EU1, AP1, US1-FED                     |
+------------------------------------------------------------------+
                              |
+------------------------------------------------------------------+
|                     データ収集層                                    |
|  Agent(dd-agent v7) / トレースライブラリ(dd-trace) / ログフォワーダ |
|  インテグレーション(750+) / DogStatsD / Cluster Agent              |
|  Lambda Extension / API 直接送信                                   |
+------------------------------------------------------------------+

2.2 データフロー

  1. メトリクス: Agent がホスト/コンテナのシステムメトリクスを 15 秒間隔で収集 -> HTTPS で Datadog バックエンドに送信 -> 時系列データベースに保存 -> ダッシュボード/モニターで利用
  2. トレース: アプリケーションに組み込まれた dd-trace ライブラリがスパンを生成 -> Agent のトレースポート（8126）に送信 -> Agent がサンプリング・集約して Datadog に転送
  3. ログ: アプリケーション/システムのログを Agent が収集（ファイルテーリング、Docker ログ、Syslog 等）-> パイプライン処理（パース、エンリッチメント）-> インデックス化 or アーカイブ

2.3 マルチリージョンアーキテクチャ

リージョンサイト URL所在地備考
US1datadoghq.com米国東部デフォルト
US3us3.datadoghq.com米国
US5us5.datadoghq.com米国
EU1datadoghq.euドイツ（フランクフルト）GDPR 対応
AP1ap1.datadoghq.com日本（東京）2023年~
US1-FEDddog-gov.com米国FedRAMP 認定

設定例（Agent の datadog.yaml）:

# EU リージョンを使用する場合
site: datadoghq.eu

# AP1 リージョンを使用する場合
site: ap1.datadoghq.com

2.4 データ保持ポリシー

データ種別デフォルト保持期間最大保持期間備考
メトリクス（フル解像度）15日15日
メトリクス（1分ロールアップ）30日30日自動ロールアップ
メトリクス（1時間ロールアップ）15ヶ月15ヶ月自動ロールアップ
トレース（サンプル済みスパン）15日15日
トレース（メトリクス）15ヶ月15ヶ月
ログ（インデックス化済み）プランによる3/7/15/30/45/60日
ログ（アーカイブ）無制限無制限S3/GCS/Azure Blob
イベント13ヶ月13ヶ月

3. Datadog Agent の仕組みと設計

3.1 Agent の概要

Datadog Agent は、ホスト上で動作する軽量なソフトウェアで、メトリクス、トレース、ログの収集を担う。現行バージョンは Agent v7 であり、Go 言語で実装されている（一部 Python によるチェック実行エンジンを内蔵）。

3.2 Agent のコンポーネント構成

  • Collector: 定期的にチェック（Integration）を実行し、メトリクスを収集。デフォルト間隔は 15 秒
  • DogStatsD: UDP ポート 8125 で StatsD 互換のカスタムメトリクスを受信
  • Trace Agent (APM Agent): TCP ポート 8126 でトレースデータを受信。サンプリングとスパン集約を行う
  • Log Agent: ファイルテーリング、Docker/コンテナログ、TCP/UDP ソケット経由でログを収集
  • Process Agent: ホスト上で動作するプロセス情報を収集（Live Processes 機能）
  • System Probe: eBPF を活用してカーネルレベルのネットワークデータを収集（NPM 機能）
  • Security Agent: Cloud Workload Security、Compliance Monitoring のデータを収集
  • Forwarder: 収集したデータをバッファリングし、Datadog バックエンドに HTTPS で送信

3.3 Agent のインストールと基本設定

Linux（Ubuntu/Debian）でのインストール

DD_API_KEY=<YOUR_API_KEY> DD_SITE="datadoghq.com" \
  bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh)"

Docker でのインストール

docker run -d --name datadog-agent \
  -e DD_API_KEY=<YOUR_API_KEY> \
  -e DD_SITE="datadoghq.com" \
  -e DD_APM_ENABLED=true \
  -e DD_LOGS_ENABLED=true \
  -e DD_PROCESS_AGENT_ENABLED=true \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /proc/:/host/proc/:ro \
  -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
  -p 8125:8125/udp \
  -p 8126:8126/tcp \
  gcr.io/datadoghq/agent:7

3.4 Agent のメイン設定ファイル

/etc/datadog-agent/datadog.yaml:

api_key: <YOUR_API_KEY>
site: datadoghq.com
hostname: web-server-01
env: production

tags:
  - team:backend
  - service:api-gateway
  - region:ap-northeast-1

logs_enabled: true
logs_config:
  container_collect_all: true
  processing_rules:
    - type: exclude_at_match
      name: exclude_healthcheck
      pattern: "GET /health"

apm_config:
  enabled: true
  max_traces_per_second: 200
  max_memory: 5e8
  max_cpu_percent: 50

process_config:
  process_collection:
    enabled: true
  container_collection:
    enabled: true

proxy:
  https: http://proxy.internal:3128
  no_proxy:
    - 169.254.169.254

secret_backend_command: /usr/local/bin/dd-secret-helper
disable_gui: true

3.5 Agent のヘルスチェックとトラブルシューティング

sudo datadog-agent status
sudo datadog-agent configcheck
sudo datadog-agent check <integration_name>
sudo datadog-agent flare
tail -f /var/log/datadog/agent.log
sudo datadog-agent dogstatsd-stats

3.6 Agent のリソース消費

環境CPUメモリディスク
ベアメタル（基本チェックのみ）0.5-1%250-350 MB1 GB
Docker ホスト（10コンテナ）1-2%350-500 MB1 GB
Kubernetes ノード（APM + ログ）2-5%500-800 MB2 GB
高負荷環境（全機能有効）5-10%800 MB - 1.2 GB2 GB

4. インフラストラクチャモニタリング

4.1 概要

Agent が自動収集するシステムメトリクスに加え、750 以上のインテグレーションを通じてサードパーティサービスのメトリクスも統合的に管理できる。

4.2 クラウドインテグレーション

AWS インテグレーション設定

IAM ロールベースのアクセスを推奨。主要な権限: cloudwatch:Get*, ec2:Describe*, ecs:Describe*, rds:Describe*, s3:GetBucket*, lambda:List* 等。

GCP インテグレーション設定

gcloud iam service-accounts create datadog-integration --display-name="Datadog Integration"
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:datadog-integration@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/compute.viewer"
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:datadog-integration@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/monitoring.viewer"

4.3 主要なシステムメトリクス

メトリクス名説明型
system.cpu.userユーザー空間のCPU使用率gauge
system.cpu.systemカーネル空間のCPU使用率gauge
system.cpu.iowaitI/O待ちCPU使用率gauge
system.mem.used使用中メモリgauge
system.disk.in_useディスク使用率gauge
system.net.bytes_rcvd受信バイト数gauge
system.net.bytes_sent送信バイト数gauge
system.load.1 / .5 / .15ロードアベレージgauge

4.4 インテグレーションの設定例

Nginx インテグレーション

# /etc/datadog-agent/conf.d/nginx.d/conf.yaml
init_config:
instances:
  - nginx_status_url: http://localhost:8080/nginx_status
    tags:
      - service:web-frontend
      - env:production

PostgreSQL インテグレーション

# /etc/datadog-agent/conf.d/postgres.d/conf.yaml
init_config:
instances:
  - host: localhost
    port: 5432
    username: datadog
    password: "ENC[datadog_agent_password]"
    dbname: myapp_production
    ssl: require
    tags:
      - service:user-database
      - env:production
    collect_function_metrics: true
    collect_activity_metrics: true
    custom_queries:
      - metric_prefix: postgresql.custom
        query: |
          SELECT schemaname, relname AS table_name,
            n_tup_ins AS inserts, n_tup_upd AS updates, n_tup_del AS deletes
          FROM pg_stat_user_tables WHERE schemaname = 'public'
        columns:
          - name: schema
            type: tag
          - name: table
            type: tag
          - name: inserts
            type: monotonic_count
          - name: updates
            type: monotonic_count
          - name: deletes
            type: monotonic_count

Redis インテグレーション

# /etc/datadog-agent/conf.d/redisdb.d/conf.yaml
init_config:
instances:
  - host: redis-primary.internal
    port: 6379
    password: "ENC[redis_password]"
    tags:
      - service:session-store
      - role:primary
    command_stats: true

5. APM（Application Performance Monitoring）

5.1 APM の概要

APM の中核概念:

  • トレース (Trace): 1 つのリクエストがシステムを通過する際の全経路
  • スパン (Span): トレース内の 1 つの操作単位
  • サービス (Service): 独立してデプロイ可能なソフトウェアコンポーネント
  • リソース (Resource): サービス内の特定のエンドポイントやクエリ

5.2 トレースライブラリの設定

Python (dd-trace-py)

from ddtrace import tracer, patch_all
patch_all()

@tracer.wrap(service='user-service', resource='get_user')
def get_user(user_id):
    with tracer.trace('db.query', service='user-database') as span:
        span.set_tag('db.type', 'postgresql')
        span.set_tag('user.id', user_id)
        user = db.query("SELECT * FROM users WHERE id = %s", [user_id])
    return user

環境変数:

export DD_SERVICE=my-python-app
export DD_ENV=production
export DD_VERSION=1.2.3
export DD_LOGS_INJECTION=true
export DD_TRACE_SAMPLE_RATE=1.0
export DD_PROFILING_ENABLED=true

Java (dd-trace-java)

java -javaagent:/path/to/dd-java-agent.jar \
  -Ddd.service=my-java-app \
  -Ddd.env=production \
  -Ddd.version=1.2.3 \
  -Ddd.profiling.enabled=true \
  -jar myapp.jar

Go (dd-trace-go)

tracer.Start(
    tracer.WithService("my-go-service"),
    tracer.WithEnv("production"),
    tracer.WithServiceVersion("1.2.3"),
)
defer tracer.Stop()

Node.js (dd-trace-js)

const tracer = require('dd-trace').init({
  service: 'my-node-app',
  env: 'production',
  version: '1.2.3',
  logInjection: true,
  runtimeMetrics: true,
  profiling: true,
});

5.3 分散トレーシングとコンテキスト伝播

サポートされる伝播規格:

  • Datadog 独自形式: x-datadog-trace-id, x-datadog-parent-id
  • W3C Trace Context: traceparent, tracestate
  • B3 (Zipkin): X-B3-TraceId, X-B3-SpanId
apm_config:
  propagation_style_inject: ["datadog", "tracecontext"]
  propagation_style_extract: ["datadog", "tracecontext", "b3"]

5.4 トレースサンプリング

apm_config:
  max_traces_per_second: 200
  errors_per_second: 50
  rare_sampler:
    enabled: true
    target_tps: 5

DD_TRACE_SAMPLING_RULES='[
  {"service": "critical-api", "sample_rate": 1.0},
  {"service": "batch-job", "sample_rate": 0.1},
  {"name": "health.check", "sample_rate": 0.0}
]'

5.5 Continuous Profiler

収集されるデータ: CPU プロファイル、メモリプロファイル、ウォールタイムプロファイル、ロックプロファイル、例外プロファイル。

6. ログ管理（Log Management）

6.1 概要

「取り込みとインデックス化の分離」が特徴。全ログを取り込みつつ、インデックス化するログを選択的にフィルタリングしてコストを最適化する。

ログソース -> 取り込み -> パイプライン処理 -> ルーティング
                                              |-> インデックス化（検索・分析可能）
                                              |-> アーカイブ（S3/GCS等に長期保存）
                                              +-> メトリクス生成（ログベースメトリクス）

6.2 ログ収集の設定

# /etc/datadog-agent/conf.d/app_logs.d/conf.yaml
logs:
  - type: file
    path: /var/log/myapp/application.log
    service: my-application
    source: java
    tags: ["env:production", "team:backend"]

  # 複数行ログの処理
  - type: file
    path: /var/log/myapp/error.log
    service: my-application
    source: java
    log_processing_rules:
      - type: multi_line
        name: java_stacktrace
        pattern: '\d{4}-\d{2}-\d{2}'

  # 機密情報のスクラビング
  - type: file
    path: /var/log/myapp/api.log
    service: my-application
    source: python
    log_processing_rules:
      - type: mask_sequences
        name: mask_credit_card
        replace_placeholder: "[REDACTED_CC]"
        pattern: '\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14})\b'

  # 特定パターンの除外
  - type: file
    path: /var/log/myapp/application.log
    service: my-application
    source: java
    log_processing_rules:
      - type: exclude_at_match
        name: exclude_healthcheck
        pattern: 'GET /health HTTP'

6.3 ログパイプライン（Grok パーサー）

rule %{ip:network.client.ip} - %{word:usr.id} \[%{date("dd/MMM/yyyy:HH:mm:ss Z"):date}\] "%{word:http.method} %{notSpace:http.url} HTTP/%{number:http.version}" %{integer:http.status_code} %{integer:network.bytes_written} %{number:duration}

6.4 インデックス管理

{
  "indexes": [
    { "name": "errors-high-retention", "filter": { "query": "status:error OR status:critical" }, "num_retention_days": 30, "daily_limit": 10000000 },
    { "name": "production-logs", "filter": { "query": "env:production -status:debug" }, "num_retention_days": 15, "daily_limit": 50000000 },
    { "name": "staging-logs", "filter": { "query": "env:staging" }, "num_retention_days": 3, "daily_limit": 5000000 }
  ]
}

6.5 ログからメトリクスの生成

ログをインデックス化せずにメトリクスとして長期保持が可能。

6.6 ログアーカイブ

S3/GCS/Azure Blob Storage に長期保存。Rehydration 機能で後から検索可能。

7. メトリクス収集とカスタムメトリクス

7.1 メトリクスの種類

型説明例
COUNT一定期間内のイベント発生回数リクエスト数
GAUGEある時点での値CPU使用率
RATE一定期間あたりの変化率リクエスト/秒
HISTOGRAM値の分布レスポンスタイム
DISTRIBUTIONグローバル分布レイテンシ分布
SETユニーク値のカウントユニークユーザー数

7.2 DogStatsD によるカスタムメトリクス

from datadog import initialize, statsd
initialize(statsd_host='localhost', statsd_port=8125)

statsd.increment('myapp.request.count', tags=['endpoint:/api/users', 'method:GET'])
statsd.gauge('myapp.queue.depth', 42, tags=['queue:email'])
statsd.histogram('myapp.request.duration', 0.235, tags=['endpoint:/api/users'])
statsd.distribution('myapp.request.latency', 0.235, tags=['endpoint:/api/users'])

@statsd.timed('myapp.function.duration', tags=['function:process_order'])
def process_order(order_id):
    pass

7.3 メトリクスのカーディナリティ管理

dogstatsd_mapper_profiles:
  - name: replace_high_cardinality
    prefix: "myapp."
    mappings:
      - match: "myapp.request.*.duration"
        match_type: "wildcard"
        name: "myapp.request.duration"
        tags:
          endpoint: "$1"
dogstatsd_tag_cardinality: low

7.4 Metrics without Limits

取り込み後にタグの組み合わせをカスタマイズし、クエリ可能なカーディナリティを制御する機能。

8. ダッシュボードと可視化

8.1 ダッシュボードの種類

  1. タイムボード: 全ウィジェットが同一の時間軸を共有。インシデント調査に適する
  2. スクリーンボード: フリーフォームレイアウト。ステータスボードに適する
  3. ノートブック: マークダウンとグラフの組み合わせ。ポストモーテムに適する

8.2 テンプレート変数

avg:system.cpu.user{$env, $service, $region} by {host}

9. アラートとモニター設定

9.1 モニターの種類

Metric Monitor, Query Alert, APM Monitor, Log Monitor, Composite Monitor, Anomaly Monitor, Forecast Monitor, Outlier Monitor, SLO Monitor 等。

9.2 設定例

{
  "name": "[Production] High CPU Usage on {{host.name}}",
  "type": "query alert",
  "query": "avg(last_5m):avg:system.cpu.user{env:production} by {host} > 90",
  "options": {
    "thresholds": { "critical": 90, "warning": 80 },
    "notify_no_data": true,
    "no_data_timeframe": 10,
    "renotify_interval": 30
  }
}

9.3 異常検知モニター

{
  "query": "avg(last_1h):anomalies(sum:trace.http.request.hits{env:production} by {service}.as_count(), 'agile', 3, direction='both', seasonality='weekly') >= 1"
}

9.4 SLO

{
  "name": "API Availability SLO",
  "type": "metric",
  "query": {
    "numerator": "sum:trace.http.request.hits{env:production,service:api-gateway}.as_count() - sum:trace.http.request.errors{env:production,service:api-gateway,http.status_code:5*}.as_count()",
    "denominator": "sum:trace.http.request.hits{env:production,service:api-gateway}.as_count()"
  },
  "thresholds": [{ "timeframe": "30d", "target": 99.9, "warning": 99.95 }]
}

9.5 通知先

@slack-<workspace>-<channel>
@pagerduty-<service>
@opsgenie-<team>
@webhook-<name>

# 条件付き通知
{{#is_alert}}@pagerduty-critical{{/is_alert}}
{{#is_warning}}@slack-warning-channel{{/is_warning}}

10. Synthetics（外形監視）

10.1 API テスト

{
  "name": "API Health Check",
  "type": "api",
  "subtype": "http",
  "config": {
    "request": { "method": "GET", "url": "https://api.example.com/v1/health", "timeout": 30 },
    "assertions": [
      { "type": "statusCode", "operator": "is", "target": 200 },
      { "type": "responseTime", "operator": "lessThan", "target": 2000 }
    ]
  },
  "locations": ["aws:ap-northeast-1", "aws:us-east-1", "aws:eu-west-1"],
  "options": { "tick_every": 60, "min_location_failed": 2, "retry": { "count": 2, "interval": 500 } }
}

10.2 ブラウザテスト

実際のブラウザ（Chrome）を使用してユーザーの操作フローをシミュレート。ステップベースの定義。

11. RUM（Real User Monitoring）

<script>
  window.DD_RUM && window.DD_RUM.init({
    clientToken: '<CLIENT_TOKEN>',
    applicationId: '<APPLICATION_ID>',
    site: 'datadoghq.com',
    service: 'my-web-app',
    sessionSampleRate: 100,
    sessionReplaySampleRate: 20,
    trackUserInteractions: true,
    trackResources: true,
    trackLongTasks: true,
    defaultPrivacyLevel: 'mask-user-input',
    allowedTracingUrls: [{ match: "https://api.example.com", propagatorTypes: ["datadog"] }]
  });
</script>

Core Web Vitals

メトリクス良好要改善悪い
LCP< 2.5s2.5-4s> 4s
FID< 100ms100-300ms> 300ms
CLS< 0.10.1-0.25> 0.25
INP< 200ms200-500ms> 500ms

12. CI Visibility

# .github/workflows/ci.yml
- name: Upload Test Results
  env:
    DD_API_KEY: ${{ secrets.DD_API_KEY }}
  run: |
    datadog-ci junit upload --service my-service ./test-results/junit.xml

13. Database Monitoring

対応DB: PostgreSQL (9.6+), MySQL (5.6+), SQL Server (2014+), Oracle (19c+), MongoDB (4.4+)。

instances:
  - host: db-primary.internal
    port: 5432
    username: datadog
    dbname: myapp_production
    dbm: true
    query_samples: { enabled: true, explain_parameterized_queries: true }
    query_metrics: { enabled: true }
    query_activity: { enabled: true, collection_interval: 10 }

14. Network Performance Monitoring（NPM）

eBPF 技術を活用してカーネルレベルでネットワークトラフィックを監視。

network_config: { enabled: true }
dns_config: { enabled: true }

収集データ: network.tcp.sent_bytes, network.tcp.recv_bytes, network.tcp.retransmits, network.tcp.rtt, network.dns.timeouts, network.dns.failures

15. Security Monitoring（Cloud SIEM）

  • Cloud SIEM: ログベースの脅威検出
  • CSPM: クラウドリソースのコンプライアンス監査
  • CWS: ランタイムでのワークロード保護
  • ASM: アプリケーション層の脅威検出

16. Cloud Cost Management

クラウドコストデータをオブザーバビリティデータと関連付けて分析。

sum:aws.cost.amortized{service:ec2} by {team}

17. Kubernetes / コンテナ環境での運用

17.1 Helm チャートによるデプロイ

datadog:
  apiKey: <YOUR_API_KEY>
  site: datadoghq.com
  clusterName: production-cluster-01
  logs: { enabled: true, containerCollectAll: true }
  apm: { portEnabled: true, socketEnabled: true }
  processAgent: { enabled: true }
  networkMonitoring: { enabled: true }
  securityAgent: { compliance: { enabled: true }, runtime: { enabled: true } }

clusterAgent:
  enabled: true
  replicas: 2
  admissionController: { enabled: true }
  metricsProvider: { enabled: true, useDatadogMetrics: true }

agents:
  tolerations: [{ operator: Exists }]

17.2 Autodiscovery

annotations:
  ad.datadoghq.com/redis.checks: |
    { "redisdb": { "instances": [{ "host": "%%host%%", "port": "6379" }] } }

17.3 HPA との統合

apiVersion: datadoghq.com/v1alpha1
kind: DatadogMetric
metadata:
  name: web-app-requests-per-pod
spec:
  query: "sum:trace.http.request.hits{service:web-app,env:production}.as_count() / count:kubernetes.pod.ready{service:web-app,env:production}"

18. Terraform による IaC 管理

resource "datadog_monitor" "high_cpu" {
  name  = "[${var.env}] High CPU Usage on {{host.name}}"
  type  = "query alert"
  query = "avg(last_5m):avg:system.cpu.user{env:${var.env}} by {host} > 90"
  monitor_thresholds { critical = 90; warning = 80 }
  tags = ["env:${var.env}", "terraform:true"]
}

resource "datadog_service_level_objective" "api_availability" {
  name = "API Availability - ${var.env}"
  type = "metric"
  query {
    numerator   = "sum:trace.http.request.hits{env:${var.env},service:api-gateway}.as_count() - sum:trace.http.request.errors{env:${var.env},service:api-gateway,http.status_code:5*}.as_count()"
    denominator = "sum:trace.http.request.hits{env:${var.env},service:api-gateway}.as_count()"
  }
  thresholds { timeframe = "30d"; target = 99.9; warning = 99.95 }
}

19. API とプログラマティックアクセス

19.1 認証

  • API Key: データ送信用
  • Application Key: データ読み取り・管理用（ユーザーに紐づく）

19.2 使用例

curl -X POST "https://api.datadoghq.com/api/v2/series" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -d '{"series": [{"metric": "custom.deployment.count", "type": 1, "points": [{"timestamp": 1704067200, "value": 1}], "tags": ["service:web-app"]}]}'

# datadog-ci CLI
datadog-ci synthetics run-tests --public-id abc-123-xyz
datadog-ci sourcemaps upload ./dist --service my-web-app --release-version 1.2.3
datadog-ci junit upload --service my-service ./test-results/junit.xml

20. ベストプラクティスとアンチパターン

20.1 タグ設計

env: production | staging | development    # 必須
service: user-api | payment-service        # 必須
version: 1.2.3                             # 推奨
team: backend | frontend | infrastructure  # 推奨
region: ap-northeast-1 | us-east-1         # 推奨

20.2 コスト最適化

  1. 高カーディナリティタグを避ける。Metrics without Limits を活用
  2. ログのインデックス化前にフィルタリング。ログからメトリクス生成を活用
  3. サービスの重要度に応じてサンプリングレートを調整
  4. 不要なインテグレーションの無効化

20.3 アンチパターン

アンチパターン推奨アプローチ
全ログをインデックス化フィルタリング+アーカイブで必要なログのみインデックス化
高カーディナリティタグの無制限使用Metrics without Limits とタグ設計で制御
モニター閾値を勘に頼る異常検知モニターやベースラインアラート活用
全サービスに同一サンプリングレート重要度に応じて調整
ダッシュボードにウィジェット詰め込み目的別にダッシュボード分割
Agent設定をホストごとに手動管理Terraform/Helm/Ansible で一元管理
アラート疲れ（過剰な通知）優先度設計、複合モニター、ダウンタイム設定

21. まとめ

21.1 機能領域の全体像

領域機能主な価値
インフラ監視ホスト/コンテナ/クラウド監視インフラの可視性
APM分散トレーシング、プロファイリングパフォーマンス最適化
ログ管理収集、処理、分析、アーカイブ統合ログ分析
メトリクスカスタムメトリクス、DogStatsDビジネスメトリクス
SyntheticsAPI/ブラウザテストプロアクティブ監視
RUMリアルユーザー体験測定UX 最適化
CI VisibilityCI/CD パイプライン監視デリバリー効率
DBMクエリパフォーマンス監視DB 最適化
NPMネットワークトラフィック監視ネットワーク可視性
SecuritySIEM、CSPM、CWS、ASMセキュリティ体制強化
Cost Managementクラウドコスト分析コスト最適化

21.2 導入ロードマップ

Phase 1 (1-2週間): 基盤構築
  Agent デプロイ / インフラ監視 / クラウドインテグレーション / 基本ダッシュボード

Phase 2 (2-4週間): オブザーバビリティの確立
  APM 導入 / ログ収集 / アラート・モニター / SLO 定義

Phase 3 (1-2ヶ月): 高度な機能の活用
  Synthetics / RUM / DBM / NPM / CI Visibility

Phase 4 (継続的): 最適化と拡張
  コスト最適化 / Security Monitoring / Terraform IaC / カスタムインテグレーション

21.3 参考リソース

本記事は 2025 年時点の Datadog の機能とアーキテクチャに基づいて作成されています。最新の情報については公式ドキュメントを参照してください。