OpenTelemetry Collector を開発する
カスタムコンポーネントの開発
Open Telemetry Collectorのためのコンポーネントを構築するには、以下の3つの主要な部分が必要です:
- Configuration - ユーザーが設定できる値は何か
- Factory - 提供された値を使ってコンポーネントを作成する
- Business Logic - コンポーネントが実行する必要があること
これについて、プロジェクトの重要なDevOpsメトリクスを追跡するためにJenkinsと連携するコンポーネントを構築する例を考えていきます。
測定しようとしているメトリクスは次のとおりです:
- 変更に対するリードタイム - 「コミットが本番環境に入るまでにかかる時間」
- 変更失敗率 - 「本番環境での障害を引き起こすデプロイの割合」
- デプロイ頻度 - 「[チーム]が本番環境に成功してリリースする頻度」
- 平均復旧時間 - 「[チーム]が本番環境の障害から復旧するのにかかる時間」
これらの指標は Google の DevOps Research and Assessment (DORA) チームによって特定されたもので、ソフトウェア開発チームのパフォーマンスを示すのに役立ちます。Jenkins CI を選択した理由は、私たちが同じオープンソースソフトウェアエコシステムに留まり、将来的にベンダー管理のCIツールが採用する例となることができるためです。
計装 🆚 コンポーネント
組織内でオブザーバビリティを向上させる際には、トレードオフが発生するため、考慮する点があります。
長所 | 短所 | |
---|---|---|
(自動)計装1 | システムを観測するために外部APIが不要 | 計装を変更するにはプロジェクトの変更が必要 |
システム所有者/開発者は可観測性の変更が可能 | ランタイムへの追加の依存が必要 | |
システムの文脈を理解し、Exemplar とキャプチャされたデータを関連付けることが可能 | システムのパフォーマンスに影響を与える可能性がある | |
コンポーネント | データ名や意味の変更をシステムのリリースサイクルから独立した展開が可能 | APIの破壊的な変更の可能性があり、システムとコレクター間でリリースの調整が必要 |
その後の利用に合わせて収集されるデータの更新/拡張が容易 | キャプチャされたデータの意味がシステムリリースと一致せず、予期せず壊れる可能性がある |
計装(instrument, インストゥルメント)とは、アプリケーションなどのシステムコンポーネントに対して、トレースやメトリクス、ログなどのテレメトリーデータを出力させる実装。計装ライブラリを最低限セットアップするだけで一通りのトレースやメトリクスなどを出力できるような対応を「自動計装」と呼びます。 ↩︎