Observabilityの3本柱を統合する
Observabilityの3本柱—メトリクス（Metrics）、ログ（Logs）、トレース（Traces）—を個別に運用するのは2025年では時代遅れだ。障害調査の際、メトリクスで異常を検知し、トレースで原因箇所を特定し、ログで詳細を確認する。この3つがシームレスに連携していなければ、調査に何倍もの時間がかかる。
KGAではDatadogを使用していたが、月間$12,000のコストが課題だった。2025年前半にGrafana + Tempo + Loki + Prometheusのオープンソーススタックに移行し、同等の機能をコスト65%削減で実現した。
OpenTelemetry: ベンダーニュートラルな計装
OpenTelemetry（OTel）は、CNCF incubatingプロジェクトで、メトリクス・ログ・トレースの計装（instrumentation）を統一する標準だ。ベンダーロックインを回避し、バックエンドを自由に切り替えられるのが最大の利点。
KGAの技術スタックはGo、TypeScript（Node.js）、Pythonの3言語。それぞれのOTel SDKでauto-instrumentationを設定し、OTel CollectorにOTLPプロトコルでデータを送信する構成だ。
Go: otel SDKのHTTP/gRPCミドルウェアでリクエストの自動トレーシング。データベースクエリはotelsqlドライバーで計装。手動計装（カスタムspan）は重要なビジネスロジックのみに限定し、計装のメンテナンスコストを抑えている。
Node.js: @opentelemetry/auto-instrumentations-nodeパッケージで、express、pg、redis等の主要ライブラリを自動計装。Next.js 16ではexperimental.instrumentationHookでサーバーサイドの計装が可能になった。
Python: opentelemetry-instrumentationパッケージでFastAPI、SQLAlchemy、requestsを自動計装。ML推論パイプラインには手動でspanを追加し、モデル推論時間やバッチサイズをトレースに記録。
OTel Collector: データパイプラインの中核
OTel Collectorは計装データの受信、加工、エクスポートを行うパイプラインだ。KGAではKubernetesのDaemonSetとしてデプロイし、各ノードのPodからのデータを集約する。
Collectorの設定で重要なのはサンプリング戦略だ。全トレースを保存するとストレージコストが爆発する。KGAではtail-based sampling（トレース全体を見てからサンプリング判定）を採用し、以下のルールを適用している。エラーを含むトレースは100%保存。レイテンシがP95以上のトレースは100%保存。正常なトレースは10%をランダムサンプリング。
この戦略でトレースのストレージ使用量を85%削減しつつ、障害調査に必要なデータを確実に保持している。
Grafana Tempo: 分散トレーシング
TempoはGrafana Labsのトレーシングバックエンドで、Jaegerの代替として選択した。最大の特徴はインデックス不要の設計で、トレースデータをobject storage（S3）に直接保存し、検索時にパスカンスキャンを行う。これによりストレージコストが大幅に削減される。
KGAの月間トレースデータ量は約500GB。Jaegerの場合Elasticsearchのインデックスが追加で必要だったが、TempoはS3保存のみで月額$12。Grafanaのトレースビューで、サービス間のリクエストフローを視覚的に追跡でき、各spanのレイテンシ、タグ、ログをドリルダウンできる。
TraceQL（Tempoの検索言語）は2025年に機能が大幅に拡張され、複雑な検索条件でトレースをフィルタリングできるようになった。例えば「HTTP 500を返し、かつDB呼び出しに1秒以上かかったトレース」のような条件検索が可能。
Grafana Loki: ログ集約
LokiはGrafana Labsの軽量ログ集約システムで、Elasticsearchの代替だ。「Prometheusのようなログシステム」を標榜し、ログの全文インデックスを作らず、ラベル（メタデータ）でインデックスする。この設計により、Elasticsearchと比較してストレージとCPU使用量が10分の1以下になる。
KGAの月間ログ量は約2TB（圧縮後500GB）。Elasticsearch運用時は月額$3,200だったが、Loki on S3で月額$40に削減。検索速度はElasticsearchに劣るが、ラベルによるフィルタリング後の絞り込み速度は実用的だ。
Grafanaのexplore画面で、ログとトレースの連携が特に強力だ。トレースIDをログに含めておくことで、トレースビューからワンクリックで関連ログにジャンプできる。逆に、エラーログからトレースIDをクリックしてトレース全体を表示することも可能。この双方向連携が障害調査の効率を劇的に向上させる。
Prometheus + Grafana: メトリクス
メトリクスは定番のPrometheus + Grafana構成。Kubernetes環境ではkube-prometheus-stackでデプロイし、ノード、Pod、コンテナのメトリクスを自動収集。アプリケーションのカスタムメトリクスはOTel SDKから直接、またはPrometheus client libraryで計装する。
長期保存にはGrafana MimirまたはThanosを使う。KGAではMimir（Grafana Labsの分散Prometheus）を選択し、S3バックエンドで1年分のメトリクスを保持。月額$85。
コスト比較サマリー
Datadog（移行前）: 月額$12,000。内訳はAPM $4,500、Logs $5,000、Infrastructure $2,500。Grafanaスタック（移行後）: 月額$4,200。内訳はインフラ費用（EC2/EKS）$3,800、S3ストレージ $350、人件費（運用工数増加分）$50相当。年間の削減額は約$93,600。ただしオープンソーススタックの運用には、Datadogのようなマネージドサービスより高いスキルと工数が必要だ。KGAではインフラチームに2名のObservability専任担当を置いている。この人件費を考慮しても十分にペイしているが、チーム規模が小さい場合はGrafana Cloud（マネージド版）の検討を推奨する。