Sen | Portfolio

OpenTelemetryへ入門

公開日：2025-04-02

#observability #監視 #OpenTelemetry

はじめに

現代のソフトウェアシステムは複雑化しており、分散システムやマイクロサービスアーキテクチャが一般的になっている。このような環境では、システムの健全性と性能を素早く/正確に理解するためのツール = オブザーバビリティが重要である。今回はオブザーバビリティの概念と、その実現手段として注目を集めているOpenTelemetryについて調査する

オブザーバビリティとはなにか

オブザーバビリティ（Observability）とは、システムの内部状態を外部から観測可能にする能力を指す。これは制御理論から派生した概念で、システムの出力（ログ、メトリクス、トレース）を観察することで、システム内部で何が起きているかを理解できるようにすること

オブザーバビリティの3つの柱は下記のテレメトリーデータで構成されている：

ログ（Logs） - 特定の時点でのイベントの詳細な記録
メトリクス（Metrics） - システムの状態を数値で表現した時系列データ
トレース（Traces） - 分散システム間のリクエストの流れを追跡するもの

これらのデータを組み合わせることで、システムの動作を総合的に把握し、問題が発生した際に迅速に原因を特定することができる

監視とはなにか

オブザーバビリティと似た意味で監視（Monitoring）という言葉が使われることがあるが、監視は、システムの健全性を継続的に確認し、事前に定義された閾値を超えた場合にアラートを発するプロセス。監視の主な目的は、問題が発生したことを検知し迅速に対応することである

監視の大まかな要素：

システムの可用性の確認
パフォーマンスメトリクスの収集
リソース使用状況（CPU、メモリ、ディスク等）の追跡
閾値ベースのアラート設定
ダッシュボードによる視覚化

伝統的な監視は、「何が」起きているかを示すことに焦点を当てている

オブザーバビリティと監視の違い

監視は、システムの状態や動作を定期的に観察し、特定の条件に基づいてアラートを発生させるプロセス。これにより、システムの正常性や異常を把握することができる
オブザーバビリティは、監視によって得られた情報を基に、システム全体の健全性や問題の根本原因を包括的に把握することを目指す

OpenTelemetryとは？

OpenTelemetry（略称：OTel）は、テレメトリデータ（ログ、メトリクス、トレース）の収集、処理、エクスポートを標準化するためのオープンソースプロジェクト. ベンダーに依存しない可観測性を実現するための標準仕様とツール群を提供する
オブザーバビリティを実現するためのツールは多く存在するが、OpenTelemetryはその中でもベンダーロックインがないことや、APIと規約の統一が図られているため、柔軟性と拡張性が高い

OpenTelemetryの構成要素

API (アプリケーションプログラミングインターフェース)
- テレメトリデータを収集するための言語固有のインターフェース
- 実装に依存しない形でトレース、メトリクス、ログを記録するための共通言語を提供
- アプリケーションコードとOpenTelemetryの間の橋渡し役
SDK (ソフトウェア開発キット)
- APIの実装を提供
- データの処理、サンプリング、エクスポートなどの機能を実装
- 各プログラミング言語に最適化されたバージョンが存在
テレメトリーデータのデータモデル
- 異なるシステム間で一貫したデータ形式を保証
- トレース、メトリクス、ログに関する標準的な構造とセマンティクスを定義
- ベンダー間の互換性を確保
セマンティック規約
- さまざまな種類の操作やデータに対する共通の名前を指定するもの
- セマンティック規約を使う利点は、コードベース、ライブラリ、プラットフォーム間で標準化できる共通の命名スキームに従うことができる
Collector (コレクター)
- テレメトリデータを受信、処理、エクスポートする独立したサービス
- 主な機能：
  - レシーバー: 様々なソースからデータを受信
  - プロセッサー: データの変換、フィルタリング、集約
  - エクスポーター: データを様々なバックエンドに送信
エクスポーター
- テレメトリデータを様々なバックエンドプラットフォームに送信するコンポーネント
- 標準エクスポーター: Prometheus、Jaeger、Zipkin、Elasticsearch等
- カスタムエクスポーターの開発も可能

コンポーネント間の連携フロー

連携フローは下記の流れの通り
1. アプリケーション内のOTel API/SDKがテレメトリデータを収集
2. SDKはデータを処理し（サンプリング、バッチ処理など）、エクスポーターを通じてCollectorまたは直接バックエンドに送信
3. Collectorはデータを受信し、必要に応じて処理（フィルタリング、変換など）
4. 処理されたデータは、Collectorのエクスポーターを通じて選択されたバックエンドプラットフォームに送信
5. バックエンドプラットフォームでデータの可視化、分析、アラート設定などが行われる
このアーキテクチャにより、OpenTelemetryは柔軟性と拡張性を備えながらも、一貫した方法でテレメトリデータを取り扱うことができる。特に重要なのは、データ収集とバックエンドの分離により、観測プラットフォームを自由に選択/変更できる点。これによりベンダーロックインを避け、組織のニーズに最適なツールを選択することが可能になる。

エクスポート先

OpenTelemetryは、さまざまなバックエンドプラットフォームにデータをエクスポートするためのエクスポーターを提供している。これにより、ユーザーは自分のニーズに最適なバックエンドを選択できる
エクスポート先はトレース、ログ、メトリクスごとに選択できる、また、オープンソースのバックエンドだけでなく、商用の監視サービス（New Relic、Datadog、Splunkなど）にも対応している

オープンソーススタックで自前運用する場合

トレース: Jaeger or Zipkin
メトリクス: Prometheus
ログ: Loki or Elasticsearch/OpenSearch
ダッシュボード・可視化: Grafana (およびKibanaなど)
メリット: カスタマイズ性・拡張性が高い。完全にオープンソースでロックインがない。
デメリット: インフラ構築・スケーリング・保守運用を自前でやる必要がある。

SaaS (マネージド) サービスで一元管理する場合

代表例: Datadog、Splunk Observability Cloud、New Relic One など
メリット: 「ログ」「メトリクス」「トレース」すべてをほぼワンクリックで集約・可視化。サーバレスにも対応。
デメリット: データ量やレイテンシ要件によってコストが大きく変動。ベンダーロックインが生じやすい。

クラウドベンダー純正ツールを利用する場合

AWS: CloudWatch (Metrics & Logs) + X-Ray (Tracing) + OpenSearch Service (ログ)
GCP: Cloud Monitoring (Metrics) + Cloud Logging + Cloud Trace + Cloud Spanner, BigQuery などとの連携
Azure: Azure Monitor (Metrics & Logs) + Application Insights (APM/Tracing)
メリット: 同一クラウド上での管理がしやすく、シームレスに連携できる。
デメリット: マルチクラウド環境では統合が難しくなりがち。コスト計算が複雑。

まとめ

今回は、オブザーバビリティの概念とOpenTelemetryの基本的な構成要素について調査した
調査する中で監視とオブザーバビリティの違い、OpenTelemetryの構成要素やエクスポート先について理解を深めることができた
OpenTelemtryは、テレメトリーデータを収集して可視化するための強力なツールであり、その採用はサービスのスケールによって必要性が変わるが、監視などの初期導入時には今後の展開も踏まえてOpenTelemetryを検討すべきであると考える
今後は、OpenTelemetryをコードに組み込み、実際にデータを収集する方法について調査していく