オブザーバビリティの聖杯を探して：Prometheus, Datadog, M3の深淵を読み解く
オブザーバビリティとは、単なる「監視」ではない。それはシステムの「内部状態」を、外部からいかに高解像度で再構成するかという、数学的かつ哲学的な営みだ。
多くの組織がツール選定で迷走するのは、ツールを「ただの監視箱」だと勘違いしているからだ。今日、我々はPrometheusという「エンジンの心臓」、Datadogという「全知のプラットフォーム」、そしてM3という「スケーラビリティの化身」を解剖し、お前たちのアーキテクチャに真の光をもたらす術を伝授する。
—
1. 概念の解剖：コストと運用の「生存圏」
ツール選定の基準は、単なる機能比較ではない。「誰が運用コストを支払うのか」というリソース配分の問題だ。
- Prometheus: 指標収集の「デファクト」。メモリ消費はTSDB（Time Series Database）の圧縮アルゴリズムに依存する。ローカルストレージ設計のため、長期保存にはThanosやCortex/Mimirが必須となる。
- Datadog: 「可観測性のSaaS」。エージェントのセットアップ一つでトポロジーまで描画する。コストは「データのカーディナリティ（高次元データ）」に正比例して爆発する。
- M3: Uberがスケール限界を突破するために生んだ怪物。PrometheusのAPIをそのまま受け入れつつ、分散型ストレージで数億のメトリクスを捌く。
比較の鉄則: 「管理対象のメトリクス数」と「クエリの複雑性」を掛け合わせ、それを自前で守るSREチームの年収（人件費）が、SaaSの請求書を上回るかを計算せよ。
—
2. ツール選定：お前の組織の「成熟度」を見極めろ
Prometheusを選ぶべき時
- 技術スタックがKubernetes（K8s）に深く沈んでいる: Service Discoveryが最強の武器となる。
- エッジケースの低レイヤ情報が欲しい: eBPFと組み合わせ、カーネルレベルのメトリクスを収集・加工する自由度が必須な場合、PrometheusのExporterエコシステムは神だ。
Datadogを選ぶべき時
- 「平均解決時間（MTTR）」の短縮が至上命題: ダッシュボード構築の工数をゼロにしたい、相関分析を人間ではなくアルゴリズムに任せたい場合、これに勝るものはない。
- DevOps文化が成熟していない: 監視基盤の維持にリソースを割く暇がないなら、金を払って時間を買うのが正解だ。
—
3. 移行の「死の罠」とハイブリッドのハック
移行時、多くのエンジニアが「メトリクスの整合性」で死ぬ。特に高負荷環境では、Prometheusのスクレイプ間隔とDatadogのAgent収集間隔の差異が、グラフに致命的なズレを生む。
ハイブリッド構成の知見：Prometheusを「エッジ」にする
すべてをDatadogに送る必要はない。高解像度な指標はPrometheus（+Thanos）でローカルに保持し、Datadogには「集計済みのサマリーメトリクス」のみを転送せよ。
Prometheusのremote_write設定例
全メトリクスではなく、重要なSLIのみをDatadogへ飛ばすフィルタリング
remote_write:
- url: “https://app.datadoghq.com/api/v1/series?api_key=…”
write_relabel_configs:
- source_labels: [__name__]
regex: ‘http_requests_total|process_cpu_seconds_total’ # 厳選された指標のみ
action: keep
—
4. 極限の最適化：エンジニアとしての「掌握」
Prometheusのメモリ消費を抑えるハック
Prometheusのメモリは「アクティブな時系列の数（カーディナリティ）」に支配される。ラベルにUIDなどのユニークなIDを入れるのは自殺行為だ。
- Cardinality Analysis: `prometheus-amtool` や `tsdb analyze` を使い、どのラベルがメモリを食っているか特定せよ。
- Recording Rulesの活用: 複雑なクエリは、API実行時に計算させるな。Recording Rulesで事前に集計し、ストレージに書き込め。
自動化の極み：APIによる監視構成管理
監視設定をGUIで行うのは、もはや「手動デプロイ」と同じ罪だ。PrometheusのルールファイルやDatadogのダッシュボードはすべて`Terraform`または`Pulumi`でIaC化し、GitHub ActionsでCI/CDパイプラインに組み込め。
Datadogのダッシュボードを自動生成する独自スクリプトの断片
from datadog_api_client import ApiClient, Configuration
from datadog_api_client.v1.api.dashboards_api import DashboardsApi
サービス展開時にダッシュボードを自動生成するロジック
def deploy_dashboard(service_name):
# テンプレートに基づき、サービス名で置換したJSONを生成
# 監視もコードとして流し込むことで、監視漏れを物理的に排除する
pass
—
結論：お前が選ぶべき道
1. スタートアップ・成長期: Datadogで「スピード」を買え。監視構築に時間をかけるな。
2. スケール期: Prometheus + Mimir/Thanosに移行し、コストを最適化しつつ、自社のメトリクスを「資産」として制御下に置け。
3. 頂点: eBPFを駆使し、PrometheusのExporterすら介さない「ゼロオーバーヘッド」な監視基盤を自作せよ。
監視とは、システムと対話するための「言語」だ。ツールに合わせるのではなく、ツールを自らのアーキテクチャの拡張として飼い慣らせ。それが、本物のアーキテクトだ。
現場で、コードの中で、また会おう。健闘を祈る。