今、運用担当者が抑えておくべきOpenTelemetryとは？

クラウド環境やコンテナの利用など、分散型のアーキテクチャが一般化する中で、システムの「オブザーバビリティ（可観測性）」が求められるようになりました。このような中、システムの観測手法を標準化する「OpenTelemetry」というプロジェクトが進んでいます。OpenTelemetryは2021年にv1.0.0がリリースされ、現在ではおおむね機能実装が完了するなど、今後広く普及していくことが見込まれます。この記事では、今、運用担当者が押さえておくべきOpenTelemetryについてご紹介します。

OpenTelemetryの概要

近年、OpenTelemetryというキーワードを耳にする機会が増えてきました。OpenTelemetryとはどのような技術なのでしょうか。以下では、その概要について紹介します。

Telemetry（テレメトリー）とは

そもそも「Telemetry（テレメトリー）」とは何を意味する言葉なのでしょうか。

Telemetryは「遠隔測定」を意味する英単語であり、特にシステム運用監視の文脈では、遠隔からシステムのパフォーマンスや稼働状況のデータを収集し、監視と分析を行うプロセスを指します。

CPU使用率やストレージ容量といったインフラ層のデータに加え、ユーザーへのレスポンスタイムや処理回数などのアプリケーションレベルの情報も収集し、システムの状態を詳しく把握します。

Telemetryにおいて収集対象となるメトリクス・ログ・トレース

Telemetryとしてデータを収集する際には、主に「メトリクス」「ログ」「トレース」の3種類のデータを対象とすることが基本となります。それぞれのデータについての概要を以下でご紹介します。

メトリクス：CPU使用率やトランザクション量など、特定間隔で収集される数値データ
ログ：アプリケーションやOSなどから出力されるエラーログやアクセスログ
トレース：複数コンポーネントにまたがって処理されるリクエストの処理フローに関するデータ

これらを収集していくことで、システムの状況をできるだけ迅速かつ正確に把握していきます。

OpenTelemetryとは

システムを構成する際には、様々なベンダーの製品やソフトウェアを利用することになります。このような中で、メトリクスやログ、トレース情報を収集するためには、各々のベンダーが対応している仕組みを組み合わせて用いる必要があります。この際、製品同士の相性問題や多様な仕様を理解する必要性が生じるなど、利用者にとっては便益が低いといえます。

そこで、Telemetryに関して標準的な仕様を策定する動きが生まれました。OpenTelemetryは、ベンダーによらない標準的な仕様により、メトリクス・ログ・トレースなどのTelemetryデータの収集を実現するためのプロジェクトです。2021年にはバージョン1.0.0の仕様が公開され、今後多くの製品がOpenTelemetryの仕様に対応していくと思われます。

OpenTelemetryが生まれた背景

それでは、なぜOpenTelemetryプロジェクトが誕生したのでしょうか。以下では、OpenTelemetryが必要とされた背景を紹介します。

システムの「オブザーバビリティ」が求められるように

OpenTelemetryが生み出された背景として、まず押さえておくべきなのがオブザーバビリティを重要視する潮流です。オブザーバビリティ（Observability）とは、英語のObserve（観察する）とAbility（能力）を組み合わせた「システムの可観測性」を表す言葉です。

現代的なシステムアーキテクチャは分散型が中心であり、クラウドやコンテナの活用が一般化しています。このようなアーキテクチャにはスケーラビリティや柔軟性など様々なメリットがありますが、システムがどのように稼動しているかをとらえにくいという問題もあります。

現代的なアーキテクチャのシステムを安定的に運用していくためには、システムの内部的な状態を詳細に把握する必要があります。すなわち、オブザーバビリティの向上が求められることになります。Telemetryによりシステムの内部情報を収集することで、オブザーバビリティを高めていく動きが進んできました。

あわせて読みたい

オブザーバビリティ（O11y）を理解しシステムの安定運用を実現する【事例付き】 近年、システム運用管理においてオブザーバビリティという概念が注目を集めています。オブザーバビリティとは一体どのような概念なのでしょうか。また、オブザーバビリ...

OpenTracingとOpenCensusの統合

このような中、トレースやメトリクスを収集するための標準的な仕組みとして、OpenTracingとOpenCensusの2つのプロジェクトが個別に発足しました。

両者がカバーする領域は共通する部分も多かったことから、2019年、クラウドネイティブソフトウェアの標準化団体であるCloud Native Computing Foundation（CNCF）にてOpenTelemetryプロジェクトとして統合されることになりました。現在では、OpenTelemetryはTelemetryに関する唯一の標準仕様として、策定が進められています。

OpenTelemetryにより実現できること

以下では、OpenTelemetryにより実現できることを紹介します。

ベンダーへ依存しないTelemetryの実現

もっとも大きなポイントは、標準化により個別のベンダーへの依存を排除できるという点です。特定のベンダーの独自方式は、ベンダーの都合により変更や廃止が起きるリスクもありますが、OpenTelemetryを利用することでこのようなリスクを下げることができます。

スキル面でも、個々のベンダーごとに仕様を理解する必要がなくなるのはメリットといえるでしょう。

多様なプログラミング言語・環境への対応

OpenTelemetryは、ほぼすべての主要なプログラミング言語への実装が存在します。具体的には、以下のとおり数多くのプログラミング言語向けの実装が用意されています。これにより、一般的なアプリケーションであれば対応が可能となっています。

※OpenTelemetryの対応言語：
C++、.NET、Erlang、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift

なお、現バージョン（v1.8.3：本稿執筆時）では、プログラミング言語によってはα版・β版などでのリリースとなっているものもあります。最新の開発状況については、OpenTelemetryの以下のページを参照ください。

OpenTelemetry

Language APIs & SDKs OpenTelemetry code instrumentation is supported for many popular programming languages

API連携による多様な監視ツールへの対応

OpenTelemetryは「ほとんどの主要なOSSおよび商用バックエンドと互換性」を持つことを標榜しています。OpenTelemetryで収集したTelemetryデータは、API連携によりSaaS型のIT統合監視ツールであるLogicMonitorをはじめ、Splunk、New Relic、Dynatrace、Lightstep、Datadog などの各監視バックエンドツールと連携可能です。

各クラウドプラットフォームにおける監視サービスにおいても対応が進んでいます。AWSやAzure、GCPにおいても、それぞれ「AWS Distro for OpenTelemetry」「Azure Monitor」「Cloud Trace」にて対応されています。今後、さらに様々なベンダーやサービスで採用が進んでいくと想定されます。

OpenTelemetryの技術概要

最後に、OpenTelemetryを構成する技術の概要について簡単に紹介します。

メトリクス・ログ・トレース・バッゲージ

OpenTelemetryでは、上述したメトリクス・ログ・トレースに加えて、コンテキスト情報の付与を行うことができるバッゲージという機能も備わっています。本稿ではそれぞれの仕様について詳細な説明は割愛します。詳細な仕様については、以下のドキュメントにてご確認ください。

※各仕様について
メトリクス：https://opentelemetry.io/docs/concepts/signals/metrics/
ログ：https://opentelemetry.io/docs/concepts/signals/logs/
トレース：https://opentelemetry.io/docs/concepts/signals/traces/
バッゲージ：https://opentelemetry.io/docs/concepts/signals/baggage/

なお、本稿執筆（2023年4月）時点でOpenTelemetryのログ関連機能については、一部開発中というステータスとなっています。最新の開発状況については、こちらのリンクをご確認ください。

OpenTelemetry

Specification Status Summary OpenTelemetry is developed on a signal by signal basis. Tracing, metrics, baggage, and logging are examples of signals. Signals are built on top of context prop...

OpenTelemetry Collectorによるデータ集約・連携

OpenTelemetryについて押さえておくべき技術として「OpenTelemetry Collector」が挙げられます。

OpenTelemetry Collectorは、Telemetryデータの中継役として、受信や送信などの処理を担います。様々なアプリケーションやインフラストラクチャーから収集したデータを中継し、必要に応じてベンダー固有のデータ形式へ変換したうえで、バックでエンドである監視ツールへ連携します。OpenTelemetry Collectorを利用することで、様々な環境のTelemetryデータを一元的に収集し、バックエンドへ連携することができます。

OpenTelemetry Collectorは大まかにReceiver、Processor、Exporterの3つの要素で構成されています。ReceiverはTelemetryデータの受信を担い、Processorはデータの加工やフィルタリングなどを行います。最後にExporterによって他のツールが対応する形式に変換したうえで、データを送信します。

自動計装

OpenTelemetryでは、アプリケーションに対するTelemetryを行う際に、ソースコードを修正することなく計測できる自動計装（Automatic Instrumentation）が実装されています。自動計装を利用することで、アプリケーションに手を入れることなく計測が可能となります。

なお、自動計装は各プログラミング言語に固有の手段により実現されているため、言語によって利用方法が異なる点に注意が必要です。たとえば、JavaではJARファイルによりバイトコードを動的に挿入することで、Telemetryを実現します。

もちろん、自動計装を利用せず、個別に取得したいデータを手動で実装することもできます。

まとめ

この記事ではOpenTelemetryについてご紹介しました。OpenTelemetryは今後利用が拡大していくと想定され、まさに「今、運用担当者が押さえておくべき」技術といえるでしょう。今後、運用管理業務において様々なツールの導入を検討される際には、「OpenTelemetryへの対応」という観点でもチェックをしてみてはいかがでしょうか。