Prometheusを「卒業」するな、進化させろ：OTel Collectorによる次世代監視アーキテクチャの極意
多くのエンジニアが陥る罠がある。それは「Prometheusを捨ててOpenTelemetry (OTel) に完全移行する」という極端な思考だ。だが、現場の現実はもっと泥臭い。Prometheusの強力なエコシステムとクエリ言語（PromQL）を維持しつつ、OTelの柔軟なパイプラインを「接着剤」として導入する。これが、今の時代に求められる最も合理的で、かつ拡張性の高いアーキテクチャだ。
今日は、その設計の深淵を紐解こう。
—
1. なぜ「OTel Collector」を間に挟むべきなのか
PrometheusはPull型が基本だが、現代の分散システムではPullの限界がすぐに露呈する。サイドカーの乱立、サービスディスカバリの複雑化、そして「メトリクスの加工ができない」という致命的な制約。
OTel Collectorは、「メトリクスの関所」だ。ここでフィルタリング、リネーム、属性の追加を行い、Prometheusには「綺麗なデータ」だけを流し込む。これが運用コストを激減させる秘訣だ。
究極のCollector構成（YAMLベストプラクティス）
`otel-collector-config.yaml` の黄金構成を提示する。これをベースに、不要なメトリクスを削ぎ落とせ。
receivers:
otlp:
protocols:
grpc:
http:
prometheus:
config:
scrape_configs:
- job_name: ‘microservices’
scrape_interval: 15s
static_configs:
- targets: [‘app-server:8080’]
processors:
batch: # ネットワーク帯域を最適化
resourcedetection: # クラウドメタデータを自動付与
detectors: [env, ec2, gce]
filter/drop_noise: # 不要な高カーディナリティメトリクスを抹殺
metrics:
exclude:
match_type: strict
metric_names:
- “go_memstats_malloc_bytes” # 監視に不要なノイズをここで捨てる
exporters:
prometheus: # Prometheus形式で出力（Prometheusサーバがここをスクレイピング）
endpoint: “0.0.0.0:8889”
service:
pipelines:
metrics:
receivers: [otlp, prometheus]
processors: [batch, resourcedetection, filter/drop_noise]
exporters: [prometheus]
—
2. 現場で震えるほど役立つ「テックリードの極意」
1. チーム開発における「設定の共有化ルール」
設定ファイルは「DRY（Don’t Repeat Yourself）」を徹底せよ。OTel Collectorの設定をサービスごとに分割し、Helm Chartの共通Libraryとして管理する。開発者が触るのは、`values.yaml` の「追加属性（Tags）」レベルに限定させるのだ。
2. 「神プラグイン」と「キーボードショートカット」
- VSCode: `OpenTelemetry` 拡張機能
- OTLPフォーマットのバリデーションが必須だ。これを入れないと、インデントミスで深夜にデバッグする羽目になる。
- Prometheus UIの隠れた極意
- `Ctrl + Enter` (または `Cmd + Enter`): クエリの即時実行。
- `Shift + Up/Down`: クエリ履歴の高速スクロール。
- 「Instant Query」ではなく「Range Query」を常に意識する: グラフを描画する時は `rate()` や `irate()` を使え。ここを理解していないエンジニアは、単なる「数字の羅列」を見ているに過ぎない。
—
3. 失敗しないための移行戦略：段階的導入のすすめ
いきなり全部をOTelに置き換えるのは自殺行為だ。以下の順序で進めろ。
1. フェーズ1（観測の統一）: 現在のPrometheusはそのまま。各アプリにOTel SDKを組み込み、サイドカーとしてOTel Collectorを配置し、メトリクスをPrometheusへ転送させる。
2. フェーズ2（加工の集約）: 各アプリで行っていたメトリクスのリネームやタグ付けのロジックを、OTel Collectorの`transform`プロセッサへ移行する。
3. フェーズ3（バックエンドの拡張）: Prometheusを維持しつつ、OTel CollectorからGrafana MimirやManaged Prometheusなど、長期保存が可能なストレージへ二重書き出しを行う。
—
最後に：オブザーバビリティの真髄
ツールは単なる手段だ。君たちの仕事は「メトリクスを集めること」ではなく、「システムが悲鳴を上げる前に、その予兆を見つけること」にある。
高カーディナリティのメトリクスを無計画に増やすな。それは監視の質を高めるのではなく、単にクラウドの請求額を跳ね上げるだけだ。「このメトリクスは、深夜3時にアラートが鳴ったとき、解決のヒントになるか？」という問いを常に自問せよ。
次世代のアーキテクチャとは、技術的に高度なことではない。「何を残し、何を捨てるか」という意思決定の連続こそが、最強の監視システムを創り上げる。
さあ、コードを開いて設定ファイルを整理し始めよう。君たちのシステムに、ノイズのない静寂と、確実な可視性を。