# OTel Collector フォローアップサーベイ（2025） ## 概要 [[OpenTelemetry]] End User SIG が 2025 年に実施したフォローアップ調査。2024 年調査との比較で Collector のデプロイ規模拡大、ハイブリッド環境の浸透、運用上の摩擦点を定量化した。 ## デプロイ規模 - 本番 10 台超: 65%（前年比 +10%） - 2〜5 台: 15%（-7%） ## 環境分布 | 環境 | 2025 | 前年比 | |---|---|---| | Kubernetes | 81% | 横ばい | | VM | 51% | +18% | | ベアメタル | 18% | +7% | 小規模組織（100 台未満）の約 25%、大規模組織（100 台超）の約 50% が Kubernetes と VM のハイブリッドデプロイを採用。 ## Kubernetes デプロイパターン Gateway 58%（-7%）、DaemonSet 50%（-2%）、Sidecar 23%（-1%）、StatefulSet 14%（+1%）。 ## カスタマイズ 46% がカスタム Collector をビルド（+13%）。OCB（OpenTelemetry Collector Builder）利用率は 86%（前年 80%）だが、使いやすいと同意した回答者は 39% にとどまり、61% が中立〜否定的。 ## 監視 77% が Collector を監視（-6%）。収集対象はメトリクス 83%、ログ 61%、トレース 25%。大規模デプロイ（100 台超）はメトリクス中心でトレースは稀。 ## コンポーネント変動（信頼度 90%） - **レシーバ増加**: ファイルログ、Kubernetes クラスタ、ファイル - **プロセッサ増加**: 属性、トランスフォーム（メモリリミッタは減少） - **エクスポータ増加**: OTLP HTTP、Datadog（Loki は減少） - **コネクタ増加**: ルーティング、Datadog - **エクステンション増加**: ストレージ、zpages、ファイルストレージ ## 優先改善領域 1. 設定管理と解決: 63% 2. 安定性向上: 52% 3. Collector の可観測性: 43% 4. レシーバ/エクスポータの追加: 29% ## 主要課題 - 稼働中の設定変更が困難。全再起動なしの単一パイプライン再構成への要望が強い - 規模拡大に伴う性能ボトルネック（起動遅延、リソース消費） - ドキュメントの不足（高度なシナリオ、非英語資源） - カスタムコンポーネント開発の学習曲線 - 保守不十分なコンポーネント（AWS CloudWatch メトリクスレシーバ等） ## 出典 - [OTel Collector Follow-up Survey](https://opentelemetry.io/blog/2026/otel-collector-follow-up-survey-analysis/)