OpenChoreo、OpenTelemetry を活用して Kubernetes のイベントとトレースを永続化

CNCF Sandbox プロジェクトである OpenChoreo は、一般的な可観測性（Observability）の課題を解決するため、その Internal Developer Platform に OpenTelemetry Collector を統合しました。2026年10月下旬にリリースされたこのアップデートにより、プラットフォームチームは分散トレースをキャプチャし、API サーバーから消えてしまう可能性のある Kubernetes イベントを永続化できるようになります。

何が起きたか

Internal Developer Platform は、コードから本番環境へのシームレスなパスを提供することを目指していますが、可観測性はしばしば断片化した負担として残ります。開発者はツールの乱立、複雑な配線要件、そして分断されたダッシュボードに直面しています。OpenChoreo は、可観測性をアーキテクチャに直接組み込むことでこの問題に対処し、OpenTelemetry Collector を分散トレーシングと Kubernetes イベントの永続化という2つの重要な機能のコアエンジンとして使用しています。

このプラットフォームは、Kubernetes 上で動作する明確に分離されたプレーンで構成されています。コントロールプレーンは状態を管理し、データプレーンはワークロードを処理します。オプションのワークフロープレーンはビルドとテストを管理し、専用の可観測性プレーンはテレメトリデータを収集します。この分離により、可観測性レイヤーはアプリケーションのパフォーマンスに干渉することなく、ログ、メトリクス、トレース、イベントを独立して収集できます。システムはヘキサゴナルアーキテクチャを採用しており、取り込み用の標準 API とストレージバックエンド用のアダプターインターフェースを公開しています。これにより、チームはコード変更ではなく Helm チャートを通じて、OpenSearch や AWS X-Ray などのプロバイダーを切り替えることができます。

仕組み

分散トレーシングにおいて、OpenChoreo は標準的な OpenTelemetry SDK を活用しています。アプリケーションは各データプレーン内のローカル Collector へ OTLP 経由でスパンをエクスポートします。パイプラインはまずこれらのスパンを受信し、次に k8sattributes プロセッサーを使用して情報を強化します。このステップでは、スパンを発行元の Pod にマッチさせ、Kubernetes メタデータを付加することで、技術的な詳細をプロジェクトや環境といった OpenChoreo の概念にマッピングします。その後、tail_sampling プロセッサーがトレース全体を評価し、保持すべきものを決定することで、コンテキストを考慮したサンプリング判断を保証します。最後に、情報が強化されたトレースは中央 Collector またはクラウドバックエンドへ直接エクスポートされます。

Kubernetes イベントは、トレースとは異なり短命であり、特定の Pod に紐付けられていないため、別の課題をもたらします。API サーバーは通常、これらのイベントを1時間しか保持しません。OpenChoreo はこれを解決するために、目的別に構築された Collector ディストリビューションを展開します。単一レプリカの Collector は k8s_events レシーバーを使用し、クラスタ全体のイベントを監視します。カスタムプロセッサーである k8seventenrich は、メモリ内 informer キャッシュからオブジェクトのラベルとアノテーションを検索し、API サーバーに繰り返しアクセスすることなく、それらをリソース属性として追加します。これらの情報が強化されたイベントはバッチ処理され、永続的なログバックエンドへ送信されるため、デフォルトの保持期間が過ぎた後でもインシデント後の分析に利用可能になります。

主要な詳細

• OpenChoreo は、現在 CNCF Sandbox にあるモジュール型でオープンソースの Internal Developer Platform です。
• 可観測性プレーンは、ストレージバックエンドの切り替え用にアダプター API を備えたヘキサゴナルアーキテクチャを使用しています。
• 分散トレーシングでは、完全なトレースコンテキストに基づいて保持判断を行うために tail_sampling が使用されます。
• カスタムの k8seventenrich プロセッサーは、メモリ内キャッシュを使用して Kubernetes のラベルとオーナー参照をイベントに追加します。
• サポートされているトレーシングバックエンドには、OpenSearch、OpenObserve、AWS X-Ray、Azure Application Insights、Google Cloud Trace が含まれます。
• イベント用 Collector ディストリビューションは、OpenSearch、OTLP、AWS CloudWatch Logs、およびデバッグ出力向けのエクスポーターをサポートしています。

なぜ重要なのか

プラットフォームエンジニアにとって、主な利点は運用上の摩擦の削減です。OpenTelemetry を標準化することで、OpenChoreo はベンダーロックインを回避し、カスタム計装コードの必要性を減らします。設定によるバックエンドの切り替えが可能であるため、チームはプラットフォームのリファクタリングなしに、変化するコストやコンプライアンス要件に適応できます。さらに、MCP サーバーを介した AI エージェントの統合により、自動化されたデバッグツールが人間の開発者と同じ豊富なトレースデータにアクセスできるようになり、インシデント解決の加速が期待されます。

Kubernetes イベントの永続化は、インフラレベルの問題を診断する上で特に価値があります。リソース制限のスロットリングやスケジューリング失敗のような問題は、アプリケーションログには痕跡を残さないことがよくあります。これらのイベントをキャプチャし情報を強化することで、プラットフォームチームはデプロイメントやジョブのライフサイクルに対する可視性を獲得します。これは、一時的なクラスタノイズを信頼できる監査証跡に変え、デプロイメントがなぜ失敗したのか、またはピークトラフィック時にサービスが予期せずスケールした理由を理解するのに役立ちます。

実行可能なこと

• OpenChoreo 上で GCP マイクロサービスデモをデプロイし、複数サービス間の分散トレーシングをテストしてください。
• 提供されている Helm チャートを使用して observability-events-otel-collector モジュールをインストールし、永続イベントのキャプチャを開始してください。
• tail_sampling プロセッサーを設定し、エラーまたは高レイテンシを含むトレースのみを保持するようにして、ストレージコストを最適化してください。
• k8sattributes プロセッサーを使用して、生の Kubernetes メタデータを内部のプロジェクトおよび環境ラベルにマッピングしてください。
• OpenChoreo ポータルの「Traces」および「Events」タブを検討し、アプリケーションパフォーマンスとクラスタレベルのアクティビティを相関させてください。
• 特定のクラスタオブジェクト向けにイベント情報強化ロジックを拡張する必要がある場合は、カスタムの k8seventenrich プロセッサーコードを確認してください。