OpenTelemetryで本番Linuxサービスの観測基盤を段階設計する｜収集エージェント選択と展開・切り戻し判断

なぜ今 OpenTelemetry なのか──可観測性基盤の現在地

ログ・メトリクス・トレースという三つのシグナルを統一仕様で扱うことを目的に生まれた OpenTelemetry（以下 OTel）は、2024年末にメトリクスとトレースの仕様が GA を迎え、2025年後半にはログ仕様も安定版に移行しました。現場では「Prometheus と Fluentd が混在していて運用コストが高い」という声が絶えませんが、OTel の統一モデルはその課題に正面から答える設計になっています。

ただし「OTel に移行すれば万事解決」という話ではありません。OTel はあくまでテレメトリの収集・変換・転送の標準仕様と SDK・エージェントのエコシステムであり、バックエンド（Grafana、Jaeger、Tempo、Mimir、Victoria Metrics など）は引き続き別途選択が必要です。観測基盤の設計で失敗するパターンの多くは「一気に全部置き換えようとする」か「バックエンドが決まる前にエージェントを展開する」かのどちらかです。本記事では段階設計の考え方を軸に、収集エージェントの選択から切り戻し判断まで順を追って整理します。

収集エージェント選択の判断軸──OTel Collector・Grafana Alloy・Fluent Bit

2026年時点で本番 Linux 環境に展開される収集エージェントの主流は次の三択に絞られてきています。それぞれの位置づけを明確にしてから選択することが、後の運用コストを大きく左右します。

• OpenTelemetry Collector：OTel プロジェクト本体が提供するリファレンス実装。receiver・processor・exporter のパイプライン構成が柔軟で、ベンダー中立性が最も高い。Contrib ディストリビューションには 100 以上の receiver が含まれる。設定の学習コストはやや高め。
• Grafana Alloy：旧 Grafana Agent を再設計したエージェント。River（旧称）から改称された Alloy 設定言語を使い、OTel パイプラインと Prometheus スタックの両方を1エージェントで担える。Grafana スタックを使っている現場では選択肢に入りやすい。
• Fluent Bit：軽量ログ収集に特化した実績のあるエージェント。OTel エクスポーターを内蔵しているため、既存の Fluent Bit 基盤を活かしながら OTel バックエンドへ転送するブリッジ用途に向いている。トレースは苦手。

判断の起点はバックエンドとチームのスキルセットです。Grafana 系スタックを既に運用しているなら Alloy の統合効果が出やすく、バックエンドがベンダー製（Datadog・New Relic など）ならその SDK や公式エージェントとの併用も現実的な選択肢です。純粋に OTel 仕様に準拠した長期運用を志向するなら OTel Collector が最も将来リスクが低くなります。

段階設計の実務──フェーズ分けと展開手順

観測基盤の移行は「ログ → メトリクス → トレース」の順に段階を設けるのが安全です。トレースはアプリケーションコードへの計装が必要なため、インフラ側の整備が先に完了していないと計装の効果が出ません。

Phase 1：ログ収集の OTel 化

まず OTel Collector を systemd ユニットとして展開し、既存ログ収集経路の隣に並走させます。filelog receiver でジャーナルやファイルログを読み取り、既存バックエンド（Loki・Elasticsearch 等）に加えて OTel エクスポーターへ転送する二重送信構成をとります。この段階では既存経路を切らないことがポイントです。

# /etc/otelcol/config.yaml の最小構成例（ログのみ）
receivers:
  filelog:
    include: [/var/log/syslog, /var/log/app/*.log]
    start_at: end

processors:
  batch:
    timeout: 5s

exporters:
  otlphttp/backend:
    endpoint: https://otel-backend.example.internal:4318

service:
  pipelines:
    logs:
      receivers: [filelog]
      processors: [batch]
      exporters: [otlphttp/backend]

systemd ユニットは otelcol-contrib パッケージをディストリビューションのリポジトリか GitHub リリースから取得して配置します。2026年時点では Ubuntu 24.04 LTS・Debian 12・RHEL 9 系いずれも公式パッケージが整備されています。

Phase 2：メトリクス統合

Phase 1 の安定を2〜4週間確認した後、既存の Prometheus エクスポーター群を prometheus receiver で取り込む形でメトリクスパイプラインを追加します。scrape_config の書き方は Prometheus と互換性があるため移行コストは低めです。既存の Prometheus サーバーを即座に廃止する必要はなく、remote_write で OTel Collector の OTLP receiver に流す構成でも段階移行は可能です。

Phase 3：トレース収集

アプリケーションへの OTel SDK 計装が完了したサービスから順次トレースを有効化します。otlp receiver（gRPC ポート 4317・HTTP ポート 4318）を Collector 側で開放し、SDK の設定で OTEL_EXPORTER_OTLP_ENDPOINT 環境変数を Collector に向けるだけで転送が始まります。サービスメッシュ（Istio・Linkerd）を使っている環境では、サイドカーの自動計装と重複しないよう設定を確認してください。

展開後の検証と正常性確認

Collector 自身がテレメトリを出力する設計になっているため、展開直後に以下の観点で動作を確認します。

Collector の extensions: health_check エンドポイント（デフォルト :13133/）が HTTP 200 を返すこと

service: telemetry: metrics で自己メトリクスを有効化し、otelcol_receiver_accepted_log_records などのカウンターが増加していること

バックエンド側で受信データのタイムスタンプ・ラベル・リソース属性が意図通りに付与されていること

特に otelcol_exporter_send_failed_* 系のカウンターが増え続ける場合は、バックエンドとの接続断またはデータ形式の不一致が疑われます。Collector のログレベルを一時的に debug に変更して原因を特定します（本番では info 以上を推奨）。

切り戻し判断と実施手順

段階設計の最大の利点は、各フェーズで問題が出ても既存経路を停止していないため即時切り戻しが可能な点です。切り戻しの判断基準を事前に設けておくことで、現場での迷いを減らせます。

判断の目安として、以下のいずれかが該当する場合は Collector を停止して旧経路に戻すことを検討します。

• Collector のメモリ使用量が継続的に上昇し、設定した上限（memory_limiter processor）を繰り返し超過する
• ログ・メトリクスの欠損が確認でき、Collector のキュー詰まりが原因と特定された
• バックエンド側の受信コストが想定を大きく超え、フィルタリング設計の見直しが必要になった

切り戻し手順は systemctl stop otelcol-contrib の1コマンドで Collector を停止するだけです。既存経路が並走していれば、ログやメトリクスの収集は旧エージェントが継続します。Phase 1 から並走構成を厳守している理由はここにあります。Collector の設定変更を伴う場合は、変更前の設定ファイルを /etc/otelcol/config.yaml.YYYYMMDD の形でバックアップし、otelcol-contrib validate --config で事前バリデーションを行う習慣をつけると切り戻し時の作業が速くなります。

2026年現行環境での注意点と OTel エコシステムの動向

2026年時点での主な環境差分として押さえておきたい点をまとめます。

OTLP/HTTP がデファクトに：かつては gRPC（ポート 4317）が主流でしたが、ファイアウォール・ロードバランサーとの相性から OTLP/HTTP（ポート 4318）を採用する現場が増えています。特にコンテナ環境（Kubernetes + ALB/Nginx）では HTTP の方が設定の手間が少ない傾向があります。

eBPF ベースの自動計装：Beyla（Grafana）や OpenTelemetry eBPF Profiler など、eBPF を使ってアプリケーションコードを変更せずにトレースを取得するツールが実用段階に入っています。kernel 5.8 以降（Ubuntu 22.04 LTS 以降・RHEL 9 系）であれば多くの機能が利用可能です。ただし CAP_BPF ケーパビリティと seccomp プロファイルの調整が必要なため、本番投入前にセキュリティ要件との整合を確認してください。

OTel Collector の設定言語変化：Collector v0.100 以降ではコネクター機能が安定し、トレースからメトリクスを生成する spanmetrics connector などが正式に使えるようになっています。古い参考記事では beta 機能として紹介されているものが GA に昇格しているケースがあるため、公式の Collector のリリースノートで現在のステータスを確認する習慣が重要です。

ディストリビューション選択の変化：OTel Collector は「Core」と「Contrib」の二ディストリビューション体制から、2025年以降はカスタムビルド（ocb: OpenTelemetry Collector Builder）による必要コンポーネントのみのビルドが推奨される流れになっています。Contrib に含まれる全コンポーネントをロードした状態は起動メモリが大きく、本番サーバーでは不要なコンポーネントを含まないカスタムビルドが安定運用に有利です。

観測基盤の整備は一度構築して終わりではなく、バックエンドの刷新やアプリケーション側の計装追加とともに継続的に進化します。段階設計と切り戻し可能な構成を維持することが、長期的な運用コストを抑える最大の鍵です。OTel の仕様と実装の成熟が進んだ今こそ、既存の多段エージェント構成を整理する良いタイミングといえます。