可観測性は、もはやサイト信頼性チームだけの責任ではありません。開発者には、自分が書くコードにtraces、logs、metricsを追加することが求められています。これにより、アプリケーションが本番環境に到達する前後で障害を診断し、挙動を理解できるようになります。2026年8月25日にCNCFのブログで公開された記事で、OpenTelemetryコミュニティマネージャー兼CNCFアンバサダーのAdriana Villelaと、OpenTelemetryドキュメント認定者兼CNCFアンバサダーのDiana Todeaは、OpenTelemetryを使ってこの作業の負担を軽減する実践的な道筋を紹介しています。
著者らは、開発者によくある異論から話を始めます。Instrumentationを追加すると、保守すべきコードが増え、複雑さが増し、エラーや技術的負債が発生する可能性があるというものです。しかし著者らは、このコストを、デバッグ時間の短縮、機能の完成とデプロイの迅速化、遅い経路や見えない再試行、エッジケースの発見、さらに分散システムへの理解向上といった、直接的な実務上のメリットと結び付けています。また、可観測性は、品質にばらつきがあるAI支援ツールによって生成されたアプリケーションを分解して理解するうえでも役立つと考えています。
自動化から始め、不足部分を追加する
最初の推奨事項は、利用可能であればZero-code instrumentationを使用することです。この仕組みは、ソースコードを変更せずに、実行時またはコンパイル時に一般的なフレームワークやライブラリへの呼び出しを捕捉することで、アプリケーションにInstrumentationを追加します。記事によると、この種のサポートはJava、.NET、Python、JavaScript、PHP、Goで利用できます。
著者らは、自動化だけで完全な解決策になるとは考えていません。自動化は、アプリケーションのロジック自体で何が重要なのかを必ずしも把握できないためです。そのため、Manual instrumentationで補完し、コード固有のtraces、metrics、logs、コンテキスト伝播、属性を追加する必要があります。また、新しいコードを書いている最中に可観測性を追加し、設計の詳細が開発者の記憶から薄れた数日後に戻って作業するのではなく、Observability-driven developmentを実践することも提案しています。
何を計測する価値があるのか
- 重要な作業単位：HTTP呼び出しなどの受信リクエスト、データベース、キャッシュ、API、Queuesへの送信接続に加え、ビジネス上重要な処理にspansを追加します。記事は、細かな呼び出しごとにspanを作成すると、重要なシグナルを覆い隠すノイズが生じる可能性があると警告しています。
- 影響の大きいイベント：特定の事象が発生した理由を説明するためにログを使用し、エラー、検証失敗、再試行とフォールバックの経路、認証失敗や権限拒否などのセキュリティイベントに焦点を当てます。
- 応答時間：レイテンシーのメトリクスは、特定のリクエストに通常より時間がかかる原因を特定するのに役立ちます。特に、ショッピングカートへの商品追加から購入完了までのような、複数ステップの経路で有効です。
- 内部フレームワークとライブラリ：チーム自身が開発したフレームワークやライブラリをInstrumentationすると、アプリケーションの大部分がそれらを通過するため、広範なカバレッジが得られる可能性があります。
AIはレビューの代替ではなくアシスタントとして使う
著者らは、AIを活用したコーディングツールによって、さまざまなOpenTelemetry APIやSDKを調査する時間を短縮でき、レガシーコードへの対応にも役立つと考えています。ただし、その活用には正確な指示が必要です。アシスタントの役割、目的、コードの場所、使用言語、必要な出力を明確にし、関連するドキュメントへのリンクやコード例を添えることを提案しています。
また、エージェントに判断の理由を説明させ、可能であれば別のエージェントを審判役として使ってその判断に異議を唱えさせ、ツールが提案した最初の変更を受け入れるのではなく、試行を繰り返して結果を改善するよう勧めています。これらの推奨事項は著者らの見解と経験を反映したものであり、AIが生成したコードが正しい、またはアプリケーションに適していることを保証するものではありません。
計測データを理解するためのローカルな経路
生成されたデータを読み取る手段がなければ、Instrumentationは完結しません。記事では、OpenTelemetry Collectorをベンダーに中立なエージェントとして説明しています。Collectorは複数のソースからtraces、logs、metricsを受け取り、必要に応じて処理した後、1つ以上の宛先へ送信します。構成要素は、データを受け取るReceivers、属性の変更や秘匿、サンプリングを行うProcessors、データを送信するExporters、各シグナル種別の経路を定めるPipelines、さらに2つのパイプラインを接続するConnectorsです。
開発目的では、OTLPをgRPCまたはHTTPで介してデータを受信し、Debugエクスポーターへ出力するシンプルな設定を記事が提案しています。また、SpanMetrics Connectorを使用してspanの期間をmetricsデータに変換し、レイテンシーの問題を監視できるようにします。その後、CollectorおよびDocker Composeと組み合わせて実行できる3つのオープンソースツールを紹介しています。tracesを表示するOTel Desktop Viewer、ターミナルインターフェースでtraces、logs、metrics、サービス間の関係を表示するotel-tui、そして同じ3種類のデータをダッシュボードで表示するOTel Frontです。
考慮すべき制約
この検証から、これらのツールに障害がないわけではないことが分かります。著者らはOpenTelemetry CollectorとDockerの経験があったため、設定はより容易でしたが、初心者はさらに大きな困難に直面する可能性があります。また、ツールは第三者が管理するオープンソースプロジェクトに依存しており、OpenTelemetry APIとSDKの最新バージョンに常に追随しているとは限らず、機能が完全に同等でない場合もあります。
記事は、エコシステム全体におけるより広範な課題も指摘しています。言語ごとのSpecial Interest Groupの活動状況のばらつき、RustやElixirなど一部言語における自動化の欠如、SDK、eBPF、コンパイル時Instrumentationの間にある多数の選択肢、さらにAPIの安定性、依存関係のアップグレード、一部の属性におけるCardinalityの高さに関する問題です。
編集部による読み解き：ここでの実務的な価値は、新しいツールを追加することではなく、可観測性を先送りされる作業からコード開発サイクルの一部へと変えることにあります。このガイドは、摩擦の少ない出発点を定めたうえで、自動化では把握できないものについて明確な境界を示しています。ただし、原典はツール間の定量的な性能比較を提示しておらず、1つの経路がすべての言語や環境に適していることも証明していません。そのため、推奨事項は開始時の枠組みとして扱い、設定をテストし、データ量とコスト、実際のアプリケーションへの適合性を見直す必要があります。