OpenTelemetry Collector を開発する

カスタムコンポーネントの開発

Open Telemetry Collectorのためのコンポーネントを構築するには、以下の3つの主要な部分が必要です:

  1. Configuration - ユーザーが設定できる値は何か
  2. Factory - 提供された値を使ってコンポーネントを作成する
  3. Business Logic - コンポーネントが実行する必要があること

これについて、プロジェクトの重要なDevOpsメトリクスを追跡するためにJenkinsと連携するコンポーネントを構築する例を考えていきます。

測定しようとしているメトリクスは次のとおりです:

  1. 変更に対するリードタイム - 「コミットが本番環境に入るまでにかかる時間」
  2. 変更失敗率 - 「本番環境での障害を引き起こすデプロイの割合」
  3. デプロイ頻度 - 「[チーム]が本番環境に成功してリリースする頻度」
  4. 平均復旧時間 - 「[チーム]が本番環境の障害から復旧するのにかかる時間」

これらの指標は Google の DevOps Research and Assessment (DORA) チームによって特定されたもので、ソフトウェア開発チームのパフォーマンスを示すのに役立ちます。Jenkins CI を選択した理由は、私たちが同じオープンソースソフトウェアエコシステムに留まり、将来的にベンダー管理のCIツールが採用する例となることができるためです。

計装 🆚 コンポーネント

組織内でオブザーバビリティを向上させる際には、トレードオフが発生するため、考慮する点があります。

長所短所
(自動)計装1システムを観測するために外部APIが不要計装を変更するにはプロジェクトの変更が必要
システム所有者/開発者は可観測性の変更が可能ランタイムへの追加の依存が必要
システムの文脈を理解し、Exemplar とキャプチャされたデータを関連付けることが可能システムのパフォーマンスに影響を与える可能性がある
コンポーネントデータ名や意味の変更をシステムのリリースサイクルから独立した展開が可能APIの破壊的な変更の可能性があり、システムとコレクター間でリリースの調整が必要
その後の利用に合わせて収集されるデータの更新/拡張が容易キャプチャされたデータの意味がシステムリリースと一致せず、予期せず壊れる可能性がある

  1. 計装(instrument, インストゥルメント)とは、アプリケーションなどのシステムコンポーネントに対して、トレースやメトリクス、ログなどのテレメトリーデータを出力させる実装。計装ライブラリを最低限セットアップするだけで一通りのトレースやメトリクスなどを出力できるような対応を「自動計装」と呼びます。 ↩︎