Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

第1章 OpenTelemetry の基礎概念とアーキテクチャ

本章では、OpenTelemetry が生まれた背景、オブザーバビリティ(可観測性)の考え方、3大シグナルの特徴、そして標準プロトコルである OTLP と OpenTelemetry Collector の仕組みを学びます。

オブザーバビリティ(可観測性)とは何か

システムが正しく動いているか、どこで問題が起きているかを把握する能力をオブザーバビリティと呼びます。

昔ながらのモノリシック(単一構成)なシステムでは、1台のサーバーが出力するログファイルを検索したり、CPU使用率を監視したりすることで問題を調査できました。しかし、現代のマイクロサービスやクラウド環境では、1つのユーザー操作に対して数十個以上の独立したサービスが通信し合って処理を完了します。

このような分散システムで障害や遅延が発生したとき、「どのサービスが原因か」「どの通信で時間がかかったのか」を突き止めることは非常に困難です。システムが出力する外部データから、内部の状態や原因を正確に理解できるようにする取り組みがオブザーバビリティです。

3大シグナル(トレース・メトリクス・ログ)

OpenTelemetry では、システムの状況を把握するためのデータを「シグナル」と呼びます。主要なシグナルは以下の 3 つです。

  • トレース(Traces)

    1 回のリクエストがシステム全体をどのように通り抜けたかを追跡するデータです。処理全体のまとまりを「トレース」、各サービス内で行われた個々の作業単位を「スパン(Span)」と呼びます。スパンには開始時刻、終了時刻、実行した処理名、属性情報(HTTP メソッドやユーザー ID など)が含まれます。これにより、処理の遅延箇所を一目で特定できます。

  • メトリクス(Metrics)

    システムの健康状態や処理量を数値として定期的に集計したデータです。リクエスト総数を数える「カウンター(Counter)」や、処理時間の分布を記録する「ヒストグラム(Histogram)」、現在のメモリ使用量を示す「ゲージ(Gauge)」などがあります。グラフ化することで異常な変化を素早く検知できます。

  • ログ(Logs)

    ある時点で発生した特定のイベントやエラーの詳細な記録です。タイムスタンプとメッセージ、エラーのスタックトレースなどが記録されます。トレースと連携させることで、「エラーが発生したときのスパン」に紐づく詳細ログを素早く確認できます。

OTLP(OpenTelemetry Protocol)の役割

OTLP は、トレース・メトリクス・ログを統一された形式で送受信するためのオープン標準プロトコルです。

従来の監視ツールは、ツールごとに専用のエージェントや通信形式が必要でした。そのため、監視ツールを別のサービスへ移行する際には、アプリケーションコードの書き換えが必要になるという「ベンダーロックイン」が発生していました。

OpenTelemetry では、OTLP という共通プロトコルを使用します。アプリケーションは OTLP 形式でデータを出力するだけで済み、データの保存先や可視化ツールを後から自由に変更できます。

OTLP は通信方式として主に以下の 2 つをサポートします。

  • gRPC(デフォルトポート: 4317)

    HTTP/2 と Protocol Buffers をベースにした高速・軽量なバイナリ通信です。常時接続による低オーバーヘッドが特徴で、バックエンド間の通信や高速処理が求められる環境に適しています。

  • HTTP/protobuf または HTTP/json(デフォルトポート: 4318)

    標準的な HTTP/1.1 または HTTP/2 を用いた通信です。ファイアウォールの制限がある環境や、gRPC を直接扱いにくい環境でも容易に利用できます。

SDK と Collector の役割分担

OpenTelemetry を利用するアーキテクチャには、「SDK 直接送信」と「Collector 経由送信」の 2 通りがあります。

  • OpenTelemetry SDK(直接送信)

    アプリケーションコード内にライブラリとして組み込みます。コード内の処理時間や数値を計測し、直接 Jaeger などのバックエンドへ OTLP で送信します。追加のサーバーを用意する必要がないため、開発環境や小規模なツール検証に最適です。

  • OpenTelemetry Collector(中継プロキシ)

    アプリケーションと可視化ツールの間に配置する中継サーバーです。アプリケーションからテレメトリデータを受信し、不要な情報の除外や加工、サンプリングを行った上で、複数のバックエンドへ振り分けて送信します。

実運用環境では、Collector の導入が推奨されます。Collector を介すことで、アプリケーション側を変更することなく送信先(Jaeger、Prometheus、クラウドサービスなど)の追加や変更が可能になります。また、暗号化通信の集約や、個人情報のマスキング処理などを一元管理できます。