# 10,000件の Slack メッセージが明らかにする OpenTelemetry 導入の課題

LLMS index: [llms.txt](/llms.txt)

---

![時間経過による Slack メッセージ量を示すカバー画像](cover.png)

OpenTelemetry コミュニティはここ数年で大きく成長し、その成長とともにコミュニティの会話の中に貴重なインサイトが隠されています。
私たちは、[CNCF Slack](https://slack.cncf.io/) の [`#otel-collector`](https://cloud-native.slack.com/archives/C01N6P7KR6W) チャンネルと [`#opentelemetry`](https://cloud-native.slack.com/archives/CJFCJHG4Q) チャンネルから、2019年5月から2025年12月までの約10,000件のメッセージを分析しました。
ユーザーが最も頻繁に直面する課題、最も多くの議論を生むコンポーネント、そしてコミュニティがドキュメントやツールの改善を必要としている領域を明らかにすることが目的です。

## データセット {#the-dataset}

分析対象は、最もアクティブな2つの OpenTelemetry Slack チャンネルにまたがる9,966件のメッセージです。

- **#otel-collector**: 5,570件のメッセージ（56%）
- **#opentelemetry**: 4,396件のメッセージ（44%）

これらのメッセージはいくつかのカテゴリに分類されます。

| カテゴリ         | 割合  |
| ---------------- | ----- |
| 質問             | 46.7% |
| エラー報告       | 25.9% |
| ディスカッション | 23.3% |
| 設定             | 3.0%  |
| ヘルプ回答       | 1.0%  |

質問とエラー報告の割合が高く（合計72%超）、これらのチャンネルがコミュニティにとって重要なサポートリソースとして機能していることを示しています。
最も頻繁に登場するトピックは、実際の導入における課題を反映しています。

類似メッセージをクラスタリングするために BERTopic を使用したトピックモデリングを適用し、次にセンチメントとフラストレーション指標を分析して、最も困難を引き起こすトピックを特定しました。
エラー報告、繰り返しのヘルプ要求、または混乱の表現を含むメッセージは、フラストレーション指標で高いスコアを記録しました。

## 最も議論された Collector コンポーネント {#most-discussed-collector-components}

トピックモデリングにより、コミュニティの議論を最も多く生む Collector コンポーネントについて明確なパターンが浮かび上がりました。
メッセージ量別の上位コンポーネントは次のとおりです。

### 1. Prometheus レシーバーとエクスポーター（498件、5.0%） {#1-prometheus-receiver-and-exporter-498-messages-50}

Prometheus との連携がコミュニティの議論を支配しています。
ユーザーからの質問が多いのは次の点です。

- メトリクスをスクレイプするための Prometheus レシーバーの設定
- Prometheus リモートライトエクスポーターのセットアップ
- パイプラインにおけるメトリクスの型とメタデータの保持についての理解
- 既存の Prometheus インフラストラクチャとの統合

Prometheus が広く採用されていることを考えれば、これは当然のことです。
多くの組織が、既存の Prometheus セットアップと統合したり、そこから移行したりすることで OpenTelemetry への取り組みを始めています。
特にリモートライトエクスポーターは多用されており、チームが OpenTelemetry を収集と処理に採用しながら、引き続き Prometheus をストレージバックエンドとして使用できるようになります。

### 2. k8sattributes プロセッサー（258件、2.6%） {#2-k8sattributes-processor-258-messages-26}

Kubernetes メタデータのエンリッチメントが2番目に多く議論されるトピックです。
よくある課題は次のとおりです。

- DaemonSet デプロイにおける Pod の関連付けとメタデータの抽出
- Kubernetes API へのアクセスに必要な RBAC 権限
- 大規模クラスターでのパフォーマンスへの影響
- kubeletstats レシーバーとの相互作用

Kubernetes 環境の複雑さと、リッチなメタデータコンテキストへの要求が、このプロセッサーを不可欠でありながら正しく設定するのが難しいものにしています。
Collector を DaemonSet として実行する場合とゲートウェイとして実行する場合では異なる Pod 関連付けルールが必要になることに気づくユーザーが多く、より明確なガイダンスがあれば避けられたはずのトラブルシューティングにつながっています。

### 3. テイルサンプリングプロセッサー（167件、1.7%） {#3-tail-sampling-processor-167-messages-17}

テイルベースサンプリングは多くの議論を生み出しており、他のトピックよりもフラストレーションのレベルが高い傾向にあります。
ユーザーが苦労するのは次の点です。

- ポリシーの設定と複数ポリシー間の相互作用
- 分散サービスにまたがるステートフルなサンプリング
- ヘッドベースサンプリングとテイルベースサンプリングのトレードオフ
- トレースがサンプリングされる、またはされない理由のデバッグ
- 判定待ち時間とレイテンシへの影響の理解

テイルベースサンプリングのステートフルな性質は、判定を下す前にトレースのすべてのスパンを収集する必要があり、ヘッドベースサンプリングでは生じない運用上の複雑さを加えます。
多くのチームが両方のアプローチを併用し、SDK レベルでヘッドベースサンプリングによるベースライン削減を行い、Collector でテイルベースサンプリングにより重要なトレースをインテリジェントに保持しています。

### 4. Kafka レシーバーとエクスポーター（131件、1.3%） {#4-kafka-receiver-and-exporter-131-messages-13}

Kafka との連携は頻繁に登場し、特に以下の点が話題になります。

- マネージド Kafka サービス（AWS MSK）との接続および認証の問題
- トピックの設定とコンシューマーグループの管理
- メッセージフォーマットとシリアライゼーション
- 高可用性デプロイパターン

### 5. メモリリミッタープロセッサー（125件、1.3%） {#5-memory-limiter-processor-125-messages-13}

リソース管理は一貫した関心事です。

- コンテナの制限に対する適切なメモリ制限の設定
- メモリリミッターと `GOMEMLIMIT` の相互作用
- メモリスパイクと OOM 状況のデバッグ
- pprof を使った CPU 使用率のプロファイリング

Go のメモリ管理、コンテナの制限、そしてメモリリミッタープロセッサーの間の関係を理解するには、複数の分野にまたがる知識が必要です。
`GOMEMLIMIT` サポートの追加が助けになっていますが、ユーザーは自分のデプロイシナリオに合った適切な設定のガイダンスを依然として必要としています。

## 問題領域とペインポイントのトップ10 {#top-10-problem-areas-and-pain-points}

コンポーネント固有の議論を超えて、フラストレーション分析によりユーザーが最も困難を感じるトピックが特定されました。
これらは、ドキュメントの改善、エラーメッセージの改善、またはツールの強化が最大のインパクトをもたらし得る領域です。

### 1. 接続とエクスポートの失敗 {#1-connection-and-export-failures}

最もフラストレーションの高い体験は、OTLP エクスポートの失敗に関するものです。
特に以下の点が挙げられます。

- バックエンドへのエクスポート時の `DEADLINE_EXCEEDED` エラー
- ロードバランサーにおける TLS 設定の問題
- gRPC と HTTP のプロトコルの混同
- プロキシ配下やクラウド環境での接続の問題

### 2. カスタム Collector ディストリビューション {#2-custom-collector-distributions}

`ocb`（OpenTelemetry Collector Builder）によるカスタムディストリビューションのビルドは大きなフラストレーションを生んでいます。

- コンポーネント間のバージョン競合
- 特定のプラットフォームでのビルド失敗（Windows MSI が特に困難）
- 依存関係の解決の問題
- どのコンポーネントを含めるべきかの理解

### 3. 設定の構文とバリデーション {#3-configuration-syntax-and-validation}

多くのユーザーが基本的な設定に苦労しています。

- わかりにくいエラーメッセージを生む YAML 構文エラー
- レシーバー、プロセッサー、エクスポーター間の関係の理解
- パイプラインの設定とデータフロー
- 環境変数の置換構文

### 4. コンテキスト伝搬 {#4-context-propagation}

分散トレーシングの基本が混乱を引き起こしています。

- B3 と W3C トレースコンテキストフォーマットの違い
- サービス境界をまたぐバゲージの伝搬
- SDK における extract と inject の操作
- 言語間の伝搬の問題

### 5. 属性とリソースの管理 {#5-attribute-and-resource-management}

データモデルの理解は困難を伴います。

- リソース属性とスパン/メトリクス/ログ属性の使い分け
- リソースレベルとシグナルレベル間での属性の移動
- セマンティック規約への準拠
- 属性のカーディナリティとその影響

### 6. OTTL（OpenTelemetry Transformation Language） {#6-ottl-opentelemetry-transformation-language}

OTTL は強力ですが、混乱を生んでいます。

- 関数の構文と利用可能な操作
- コンテキスト固有のパスとアクセサー
- 変換失敗のデバッグ
- 複雑な変換のパフォーマンスへの影響

### 7. Kubernetes Operator と自動計装 {#7-kubernetes-operator-and-auto-instrumentation}

Operator はデプロイを簡素化しますが、独自の課題も導入します。

- 計装のインジェクションが期待どおりに動作しない
- 複数の Collector デプロイモード（DaemonSet、Sidecar、Deployment）
- CRD の設定オプション
- インジェクトされたエージェントのトラブルシューティング

### 8. バックエンドとの統合 {#8-backend-integration}

オブザーバビリティバックエンドへの接続には手間がかかります。

- Jaeger の設定とレガシーセットアップからの移行
- ベンダー固有のエクスポーター設定
- マネージドサービスでの認証と認可
- マルチバックエンドルーティング

### 9. Docker とコンテナデプロイ {#9-docker-and-container-deployment}

コンテナ関連の問題は定期的に発生しています。

- イメージの選択（contrib と core）
- Docker Hub でのバージョンの可用性
- カスタムイメージのビルド
- リソース制限とパフォーマンスチューニング

### 10. キューとリトライの動作 {#10-queue-and-retry-behavior}

エクスポーターヘルパーの動作の理解に関するものです。

- 永続キューの設定とストレージ
- リトライポリシーとバックオフの動作
- データ損失のシナリオと防止策
- 高ボリュームデプロイにおけるキューのサイジング

## この分析が示すもの {#what-this-tells-us}

この分析からいくつかのテーマが浮かび上がります。

**Prometheus エコシステムは引き続き中心的な存在です。**
組織は Prometheus を放棄しているのではなく、OpenTelemetry と統合しています。
これらのエコシステムを橋渡しするドキュメントとツールは、引き続き価値を持ちます。

**Kubernetes の複雑さが OTel の複雑さを増幅しています。**
k8sattributes プロセッサーと Operator に関する議論は、Kubernetes 環境が設定とトラブルシューティングの追加レイヤーを導入することを示しています。
簡素化されたデプロイパターンとより良いデフォルト値が助けになるでしょう。

**サンプリングは概念的に難しいトピックです。**
テイルベースサンプリングは十分にドキュメント化されているにもかかわらず、継続的な混乱を引き起こしています。
インタラクティブなツールやサンプリング判定の可視化が、ユーザーの設定の理解やデバッグに役立つかもしれません。

**エラーメッセージの改善が必要です。**
フラストレーションの高い多くの議論は、わかりにくいエラーメッセージから始まっています。
修正の提案を含む実用的なエラーメッセージへの投資は、ユーザー体験を大幅に改善するでしょう。

**「はじめに」と「本番運用」の間のギャップは現実のものです。**
基本的なチュートリアルは機能しますが、適切なメモリ制限、永続キュー、マルチバックエンドルーティングを備えた本番環境へのスケーリングには、相当な学習が必要です。

## 今後に向けて {#moving-forward}

この分析が、メンテナーや SIG がドキュメント改善の効果が最も高い領域を特定する助けとなることを願っています。
データは、特に設定パターン、サンプリング戦略、マルチバックエンドデプロイに関する特定のトピックが繰り返しの質問を生んでおり、より良いガイドで対処できることを明確に示しています。

私自身、これらのペインポイントに直接取り組む一連の記事を準備しています。
Collector の設定ファイルを管理しやすい単位に分解する方法、テナントや環境に基づいてテレメトリーを複数のバックエンドにルーティングする方法、効果的なテイルベースサンプリング戦略の構築方法などのトピックを扱います。

## 謝辞 {#acknowledgments}

OpenTelemetry Slack コミュニティに参加してくださっているすべての方に感謝します。
皆さんの質問、エラー報告、ディスカッションは、お互いを助けるだけでなく、プロジェクトが改善すべき点についての貴重なシグナルを提供しています。
質問に回答し、自分の経験を共有してくださるコミュニティメンバーの方々に特に感謝します。
データ上は1%のヘルプ回答ですが、それは新しい参加者をこのコミュニティに迎え入れるための膨大なボランティア時間を表しています。

---

_この分析では、公開されている Slack メッセージに対してトピックモデリングとセンチメント分析を使用しました。
個々のメッセージはトピックに集約されており、このレポートでは個人を特定できる情報は使用していません。_