【Datadog】Metrics vs. Events vs. Logs――Datadog データタイプを理解する
社内ブログを公開用にmodifyした記事です。
「Datadog には “データタイプが 3 つあるらしい」
- Metrics：時系列メトリクス
- Events：単発の出来事
- Logs：構造化／非構造化のテキスト
名前だけ聞くと直感で区別できそうですが、実務では“どのチャンネルで送るか”がコストと可観測性に直結します。本記事では、インジェスト方式・保存期間・クエリ性能・料金モデル・典型ユースケース を網羅しながら、最後に “混同しやすいシナリオ別ディシジョンツリー” を提示します。
1. Datadog が 3 レーンに分ける理由
1.1 モノリシック監視の崩壊と SaaS の台頭
オンプレ監視時代は「全部 Syslog」「全部 RDB」でも何とかなっていました。しかしマイクロサービス × クラウドネイティブで以下の課題が噴出します。
| 課題 | 具体例 | 結果 |
|---|---|---|
| スケール | 1 秒間に数百万行のアクセスログ | 保存／検索がボトルネック |
| 多様性 | JSON, Protobuf, 再試行イベント etc. | 正規化コストが爆発 |
| リアルタイム性 | SLO 1 分以内検知 | 汎用 RDB では遅延 |
Datadog は**「専門ストレージを 3 つ用意し、データの特性ごとに最適化する」**という設計を採ります。
1.2 3 つの最適化軸
-
クエリパターン
- Metrics：集計系（AVG, P95, RATE）
- Events：全文 × 時系列フィルタ
- Logs：全文 × Facet × 低レイテンシ
-
保持期間と圧縮
- Metrics はロールアップして長期保持
- Logs は短～中期を高速・それ以外はアーカイブ
-
料金モデル
- Metrics：ホスト数 + カスタムメトリクス数
- Events：Ingest 毎 GB + 発火量課金なし
- Logs：Ingest 毎 GB + Index 毎 GB
2. Metrics ――“連続データ” の高速集計ライン
2.1 データモデル
| フィールド | 例 | 説明 |
|---|---|---|
| metric | system.cpu.user |
名前空間はドット区切り |
| points | [(ts, value)] |
UNIX epoch, float |
| tags | env:prod, region:ap-n1 |
最大 100 個／ポイント |
主要タイプ
- Gauge：瞬間値。メモリ使用量など
- Count：単位時間あたりの値の総数。リクエスト数など
- Histogram/Distribution：P95, P99 解析向け
2.2 解像度とロールアップ
| 経過時間 | 解像度 | 用途 |
|---|---|---|
| 0–15 か月 | 1 秒 (APM High-Res) / 10 秒 | リアルタイムモニタ |
| 15–18 か月 | 1 分 | 中期分析 |
| 18–27 か月 | 1 時間 | 長期トレンド |
Tip: SLO モニタは 1 分ロールアップで十分な場合が多く、コスト最適化につながる。
2.3 代表ユースケース
- アラート閾値監視（CPU > 90%）
- SLO/Error Budget（4xx Rate ≤ 0.1%）
- キャパシティプランニング（週次 CPU 傾向）
3. Events ――“瞬間” をとらえるストリーム
3.1 Datadog Events Stream の正体
「本番デプロイ完了」「EC2 再起動」「K8s CrashLoopBackOff」など、一定の文脈を持った単発情報 をタイムラインで俯瞰できます。
| 属性 | 例 | 備考 |
|---|---|---|
| title | deploy@payment-service |
|
| text | version 2.1.3 |
|
| alert_type | `success | error |
| tags | env:prod |
3.2 イミュータブル設計
Events は更新不可・削除不可が基本。変更の必要がある場合は新たなイベントを追加し差分を説明します。これにより「事実を時系列で追う」監査ログとして有効です。
3.3 フィルタリング＆コラボレーション
- ランブック URL, JIRA チケット, Slack Thread などを直接埋め込める
- スター & コメントでチーム全員が時系列の会話を残せる
実戦パターン
- CI/CD と連携しデプロイ時に success イベントを送信
- Fail イベントに PagerDuty ID を添付
- Post-Mortem 作成時は該当イベントを検索してタイムラインを抽出
4. Logs ――“生の事実” と構造化のはざま
4.1 パイプライン概念
インジェスト → 取り込みパイプライン → ルールマッチング → Index と Archive/S3 へ。
- Parser：JSON/Grok/Regex でフィールド抽出
- Facet：インデックス化するカラム（高速フィルタ向け）
- Measure：数値型をメトリクス化（同期的）
4.2 保存戦略とコスト
| ステージ | 説明 | 料金 |
|---|---|---|
| Indexed | GUI 検索・Analytics 即時可 | GB 単価高 |
| Rehydrated | アーカイブから一時復元 | 復元 GB + 検索 GB |
| Archive | S3 など外部ストレージ | Datadog 無課金 |
Tip: “Logging without Limits™”はIndexed を絞り、Archive に全量流す設計が前提。
フィールド抽出とサンプリング比率を継続的に見直すことで 30–60% コスト削減が狙えます。
4.3 トレース & RUM とのクロスリンク
- APM Trace ID を Logs に注入 → ワンクリックでトレースへジャンプ
- RUM Session ID から問題ページのコンソールエラーへ遡る
5. データタイプ比較チャート
| 観点 | Metrics | Events | Logs |
|---|---|---|---|
| 時間特性 | 連続 | 点 | 点 (大量) |
| 典型サイズ | 数 byte/pt | 数百 byte | 数 KB/line |
| 検索負荷 | 集計系 (Time-Series DB) | 軽量全文 | 重量全文 (Facets 必須) |
| 長期保持 | 15–27 か月 (圧縮) | 任意 (GB 単価) | Indexed: 数日～月 Archive: 無制限 |
| 主用途 | アラート/SLO/容量計画 | デプロイ/監査 | デバッグ/フォレンジック |
| コスト起点 | メトリクス総数 | Ingest GB | Ingest + Index GB |
6. よくある“境界線”シナリオと判断基準
6.1 API エラーレート監視
- 1 分毎の 5xx Rate でアラート → Metrics
- 発生リクエストを詳細追跡 → Logs
6.2 デプロイパイプライン
- 成功失敗を時系列に残したい → Events
- デプロイジョブのステップログ全文 → Logs
6.3 セキュリティインシデント
- 攻撃試行回数のカウント → Metrics (Count)
- 侵害の疑いを一括検索 → Logs (Archive Rehydrate)
- SOC へのインシデント通知 → Events (alert_type=error)
7. アーキテクチャ別“ベストプラクティス”
再考中
### 7.1 コンテナ/Kubernetes
- Autodiscovery を用いたタグ自動付与
- Pod ログは STDOUT → Datadog Agent → Logs
- Pod 再起動は Kube-State-Metrics → Events
### 7.2 Serverless/Lambda
- Enhanced Metrics 有効化で ColdStart Latency を自動生成
- datadog_lambda_layer で実行ログを JSON 化し Logs へ
- エラー出力時に DD_EVENT_URL へ POST し Events に変換
~~### 7.3 IoT / エッジ
- 帯域制限下では StatsD Buffer → Metrics をバッチ送信
- 異常系だけを Ring Buffer から REST で Logs に流す
- ファームウェアアップデート完了を Events で受信
すべてをメトリクスとして受け取ることは難しい（不可能）ですし、Events,Logsも同様です。Datadogの概念として「全部Datadogに送ればなんとかする（意訳）」がありますので、3つのタイプを駆使してモニタリングやo11yを実現していきましょう
Discussion