メトリクスの管理と最適化 - 多次元データの設計と活用
オブザーバビリティ（可観測性）の土台を支えるのは、数値データである「メトリクス」です。Datadogの強力な分析機能やダッシュボード、アラートエンジンの裏側には、毎秒数百万、数千万件という膨大な時系列データが流れています。
しかし、メトリクスは単に「値を送れば良い」というものではありません。用途に合わせた「型（Type）」の選択、フィルタリングを左右する「タグ（Tag）」の設計、そして時系列データの爆発を引き起こす「カーディナリティ（Cardinality）」の管理。これらを正しく理解し制御できていなければ、監視の精度が落ちるだけでなく、予期せぬコスト増大に直結します。
本記事では、Datadogにおけるメトリクスのライフサイクルを徹底的に解剖し、効率的かつ持続可能なメトリクス管理のベストプラクティスを詳説します。
1. メトリクス・タイプの完全理解：どれを選ぶべきか？
Datadogは、データの性質に応じて複数の「メトリクス・タイプ」をサポートしています。正しい型を選ぶことは、グラフの正確性と集計の効率に直結します。
主要タイプの比較表
| タイプ | データの性質 | 適した用途 | 特徴 |
|---|---|---|---|
| Gauge (ゲージ) | 特定時点の「値」 | メモリ使用量、温度、DB接続数 | 増減する値をそのまま記録。 |
| Count (カウント) | 期間内の「合計」 | リクエスト数、エラー発生数 | 期間ごとの合計（Sum）として集計。 |
| Rate (レート) | 1秒あたりの「平均発生数」 | スループット (req/sec) | Countを時間で割ったもの。 |
| Distribution (分布) | 値の「散らばり」 | レスポンスタイム (p95, p99) | グローバルな統計値を計算可能。 |
| Set (セット) | 一意な要素の「数」 | ユニークユーザー数 | 重複を排除してカウント。 |
2. 集計の仕組み：時間集計と空間集計
Datadogでメトリクスを表示する際、裏側では2種類の集計が行われています。この概念は、特にアラートの閾値を正確に設定するために重要です。
時間集計 (Time Aggregation)
15分間のグラフを表示する場合、1秒ごとの細かいデータをそのまま描画すると重くなってしまいます。そのため、一定間隔（バケット）ごとにデータを1つの点にまとめます。
avg,max,min,sumなどの方法で丸められます。
空間集計 (Space Aggregation)
「全サーバーのCPU使用率の平均」を出す場合など、複数の時系列データを1つにまとめる処理です。
3. カスタムメトリクスと DogStatsD の活用
標準のインテグレーションでカバーできないアプリケーション固有の指標（例：注文金額、在庫数）は、DogStatsD を通じて送信します。
DogStatsD のメリット
- UDP通信: 送信側プログラムをブロックしないため、アプリケーションのパフォーマンスへの影響が極めて小さい。
- バッチ処理: Agentがローカルでデータを集計してからDatadogへ送るため、ネットワーク負荷を抑えられる。
IMPORTANT
アプリケーションコードでメトリクスを送る際は、直接APIを叩くのではなく、必ずローカルのAgentが提供するDogStatsDエンドポイントを経由してください。
4. カーディナリティの罠：コスト爆発を防ぐ
メトリクス管理において最大の敵が「高カーディナリティ」です。これは、タグの組み合わせパターンが膨大になり、時系列データの数が爆発的に増える現象を指します。
危険なタグの例
- ❌
user_id: 数十万人規模のユーザーIDをタグに含めると、数十万通りの個別のメトリクスが生成されます。 - ❌
request_id: リクエストごとに異なる一意なID。 - ❌
container_id: コンテナが再起動するたびに新しいIDが生成され、古いデータと合算できなくなります。
対策
タグには「集計したい単位」のみを含めます。個別のIDを確認したい場合は、メトリクスではなく「ログ」や「トレース」にその情報を載せるのが正しい設計です。
5. Metrics Summary：資産の棚卸し
Datadogの「Metrics Summary」画面は、現在送信されているすべてのメトリクスの健康状態を確認するための管理コンソールです。
- 高い送信頻度の特定: 無駄に高い頻度で送られているメトリクスを見つけ、収集間隔を調整します。
- 未使用メトリクスの削除: どのダッシュボードやモニターにも使われていない「迷子」のメトリクスを特定し、コストを削減します。
- タグの構成確認: どのタグがカーディナリティを押し上げているかを可視化します。
6. メトリクス vs. ログ：使い分けの判断基準
すべての情報をメトリクスで取ろうとするのは誤りです。以下の基準で使い分けを判断してください。
| 特徴 | メトリクス | ログ |
|---|---|---|
| 得意なこと | 傾向の把握、アラート、高速な集計 | 詳細な事象の特定、エラー内容の確認 |
| 保持期間 | 長期（15ヶ月間、精度は落ちる） | 短期（通常15〜30日間） |
| コスト構造 | カスタムメトリクスの数に比例 | 送信・保管されるデータ量に比例 |
| 例 | 「エラー率の推移」を確認する | 「特定ユーザーのスタックトレース」を見る |
7. まとめ：持続可能なメトリクス設計
メトリクスは、システムの「体温計」であり「心電図」です。 適切な型を選び、空間集計と時間集計を使い分け、そしてタグを賢く設計することで、あなたのインフラは驚くほど明瞭に可視化されます。
一方で、カーディナリティの管理を怠れば、監視基盤そのものがコストの負債となってしまいます。「この情報はメトリクスで出すべきか、それともログで出すべきか」を常に問い続け、整理されたメトリクス群を維持することが、プロフェッショナルな監視エンジニアへの道です。
整理され、洗練されたメトリクスで埋め尽くされたダッシュボードは、単なる監視ツールを超え、ビジネスの意思決定を支える強力なインテリジェンス・ツールへと進化するはずです。
関連記事:
出典: