OpenTelemetry Collector 開発
カスタムコンポーネントの開発
OpenTelemetry Collector 用のコンポーネントを構築するには、3つの主要な部分が必要です
- Configuration - ユーザーに公開される設定値
- Factory - 提供された値を使用してコンポーネントを作成する
- Business Logic - コンポーネントが実行する必要がある処理
ここでは、プロジェクトの重要な DevOps メトリクスを追跡できるように、Jenkins と連携するコンポーネントを構築する例を使用します。
測定しようとしているメトリクスは以下の通りです
- Lead time for changes - “コミットが本番環境にデプロイされるまでにかかる時間”
- Change failure rate - “本番環境で障害を引き起こすデプロイメントの割合”
- Deployment frequency - "[チーム]が本番環境に正常にリリースする頻度"
- Mean time to recover - "[チーム]が本番環境の障害から復旧するまでにかかる時間"
これらの指標は、ソフトウェア開発チームのパフォーマンスを示すために、Google の DevOps Research and Assessment（DORA）[^1] チームによって特定されました。Jenkins CI を選択した理由は、同じオープンソースソフトウェアのエコシステム内にとどまることで、将来ベンダーが管理する CI ツールが採用するための例として機能できるからです。
計装 vs コンポーネント
組織内のオブザーバビリティのレベルを向上させる際に考慮すべきことがあります。いくつかのトレードオフが生じるためです。
| メリット | デメリット | |
|---|---|---|
| （自動）計装 | システムを監視するために外部 API を監視する必要がありません。 | 計装を変更するにはプロジェクトへの変更が必要です。 |
| システムオーナー/開発者がオブザーバビリティを変更する権限を持てます。 | 追加のランタイム依存関係が必要です。 | |
| システムコンテキストを理解し、キャプチャしたデータを Exemplars と関連付けることができます。 | システムのパフォーマンスに影響を与える可能性があります。 | |
| コンポーネント | データ名やセマンティクスへの変更をシステムのリリースサイクルとは独立して展開できます。 | API の破壊的な変更には、システムと Collector の間で調整されたリリースが必要です。 |
| 収集されるデータの更新/拡張は、ユーザーにとってシームレスな変更です。 | キャプチャされたデータのセマンティクスが、新しいシステムリリースと一致しない形で予期せず壊れる可能性があります。 | |
| サポートチームがオブザーバビリティの実践について深い理解を持つ必要がありません。 | システムから外部に公開された情報のみを表面化できます。 |