初心者向けガイド：OpenTelemetryによるオブザーバビリティ

複雑に拡張された分散環境、サーバーレスアーキテクチャー、そして増え続けるビジネスニーズにより、基盤となるインフラストラクチャを監視することは非常に困難になっています。しかし、企業の成功は、ITインフラストラクチャ、テクノロジーシステム、デジタルプラットフォーム、ネットワークなどの技術スタックの健全性に直結しています。

この健全性を維持するには監視が不可欠であるため、潜在的な問題をリアルタイムで特定できるツールが必要です。ダッシュボード、視覚的なサービスマップ、レポート機能により、メトリクスデータを収集して分析し、主要パフォーマンス指標を追跡し、異常に関するアラートを送信することでシステムを監視し、いつ何が起こったかを把握できるようにします。

なぜオブザーバビリティが必要なのか、そしてそれは何なのか？                     

監視で「いつ」「何が」起こったかを把握できるのに対して、「なぜ」「どのように」起こったのかを明らかにするのがオブザーバビリティです。これは、システムの出力を調べて現在の状態を解釈し、報告することによって機能します。

テレメトリー信号を構成する、従来のオブザーバビリティの4つの柱について考えてみましょう。これらはMELTと呼ばれることもあります。

• M（メトリクス）：定期的に設定された間隔で収集される測定値
• E（イベント）：収集されたメトリクスに異常な変化が見られたり、閾値に違反したりすると、イベントが発生する
• L（ログ）：タイムスタンプ付きのイベント記録
• T（トレース）：システムのさまざまなコンポーネントに統合された、論理操作の一部である一連のイベント。トレースは、スパンまたはトレース内の個々の操作に分類される

最近では、業界の知見として、アプリケーションの実行中にリソースの使用状況をコードの行番号まで掘り下げて理解することを含むように拡大しています。これはプロファイリングという5番目の柱となっています。

通常、この情報を生成するには、システムにカスタムコードを追加します。このプロセスはインストルメンテーションと呼ばれ、これによりオブザーバビリティが実現されます。

オブザーバビリティと監視の概念を結びつける

重要ポイント

• 監視はリアクティブ（事後対応的）です。
• オブザーバビリティはプロアクティブ（事前対応的）です。
• オブザーバビリティは、監視によって検出されたものを理解するのに役立ちます。
• 監視は「既知の未知」を、オブザーバビリティは「未知の未知」を明らかにします。

簡単な例え

アプリケーションA（あなたのアプリケーション）がデータベースDと対話しようとしたが、トラフィックが多すぎて失敗したとします。監視によって、既知の未知（つまり、何らかの理由によりアプリケーションがデータベースにアクセスできない）が通知されます。

別のアプリケーションB（その他のアプリケーション）も同じデータベースDと通信しており、データベースDで重いトランザクションを実行している事がトラフィックの原因だとします。オブザーバビリティは、トラフィックを引き起こし、データベースをビジー状態にしている別のアプリケーションBの存在を明らかにします。オブザーバビリティとは、原因があなたの環境にない場合でも異常を認識できるようにすることで、未知の未知を伝えることです。

このようなシナリオの場合、オブザーバビリティがあれば、アプリケーションAがデータベースDと実際にアクセスする前であってもその利用不可状態を警告することができます。オブザーバビリティソリューションにより、利用できない状態が警告され、プロセスが事後対応型ではなくプロアクティブ型に変わります。

監視ではデータベースDが利用不可であることは分かりますが、オブザーバビリティを使えば、その根本原因がアプリケーションBであることを突き止められるのです。

Open Telemetryとは

• トレース、メトリクス、ログなどのテレメトリーデータを生成、管理するオブザーバビリティフレームワークでありツールキットです。
• ベンダー、ツール、言語に依存しないため、さまざまな技術スタックやオブザーバビリティバックエンドで使用できます。
• テレメトリーの生成、収集、管理、エクスポートに重点を置いています。テレメトリーの保存と可視化は意図的に他のツールに任せています。
• Open Telemetryは、クラウドネイティブコンピューティングの採用を促進する、オープンソースソフトウェアファウンデーションであるCNCF（Cloud Native Compute Foundation）によってホストされています。
• Open Telemetryは、CNCFが現在育成している最も人気のあるプロジェクトとして、Kubernetesに次いで2番目に位置しています。

そして、OpenTelemetryは、New Relicが提供するようなオブザーバビリティバックエンドではありません。OpenTelemetryだけでは収集したデータを監視したり可視化することはできません。実際にその情報をを表示したり分析したりするには、モニタリングプラットフォームに接続する必要があります。

歴史

Open Telemetry以前は、Open CensusとOpen Tracingという2つのプロジェクトがありました。どちらのプロジェクトも、コードを計装し、テレメトリーデータを他のオブザーバビリティバックエンドに送信する方法を標準化することを目的としていました。Open Censusはメトリクスデータの生成と送信の標準を作成し、Open Tracingはトレースの標準を作成しました。

これらはその強みを統合してOpen Telemetryを誕生させ、単一の統合ソリューションを提供しています。ただし、現在以前の2つのプロジェクトのいずれかを使用している場合は、Open Telemetryにシームレスに移行できます。

豆知識 

OpenTelemetryは2019年にCNCFに受け入れられ、2021年にインキュベーション成熟度レベルに移行しました。

なぜOpen Telemetryなのか？

このドキュメントの前半で説明したように、オブザーバビリティが重要な理由を理解した今、それを可能にするテレメトリーデータ生成のための標準的なアプローチが必要です。まさにそれがOpenTelemetryが提供するものです。

• データの所有権： オープンソースであるため、生成するデータを自ら所有でき、ベンダーロックインのない柔軟性によって、好きなようにデータを管理できます！
• 一貫性： 標準化されたAPIと規約のセットにより、不整合がなくなります。
• 長期的なビジョン： テレメトリー設定は、今日のコード内コメントのように、簡単で、普遍的で、ベンダーニュートラルで、疎結合で、コードに組み込まれているべきです。これらはOpenTelemetryの長期的なビジョンと一致しており、これ以上の選択肢があるでしょうか？
• コラボレーションの強化： OpenTelemetryはまた、完全なカスタマイズを可能にし、セマンティック規約（キー・バリュー）ペアを追加することで、開発者、ベンダー、実務担当者の間の連係を強化し、企業がニーズに応じてデータをより意味のあるものにするのを助けます。

OpenTelemetryは当初、C++、.NET、Java、JavaScriptのような少数の言語に対して、本番環境に対応したトレーシング機能（主な焦点）を備えてをローンチされました。今日では、そのリストは劇的に拡大し、オブザーバビリティのすべての主要な柱をサポートする実装が、様々な開発段階（アルファ、ベータ、本番環境）で提供されています。

Open Telemetryの基本概念

MELTは、ソフトウェアが様々な方法で自身を記述するためのメカニズムを提供します。しかし、意味のあるインサイトを抽出するためには、2つの別々のコードベースからのインストルメンテーションを組み合わせる必要があり、これはコア設計原則に違反する横断的な関心事（cross-cutting concern）を生み出します。そのため、OpenTelemetryのクライアント設計では、将来的なソフトウェアの問題を防ぐために特別な注意が必要です。

これを容易にするため、OpenTelemetryは、横断的な関心事としてインポートする必要があるシグナルの部分と、独立して転送できる部分とを分離しています。各シグナルには4つのパッケージがあります。

• API： インストルメンテーションに使用される、横断的なパブリックインターフェースで構成されます。インターフェースを定義することで、テレメトリーデータの生成を支援します。
• SDK： OpenTelemetryプロジェクトによるAPIの実装です。SDKを使用するかどうかはユーザーの判断に委ねられます。これには、データ処理、サンプリング、エクスポートなどの機能が含まれます。
• セマンティック規約（Semantic Conventions）： すべてのシグナルの属性フィールドで使用されるべき、標準的なキー・バリューペアのセットです。これらのペアは、データ、リソース、メトリクスの意味を定義します。
• Contrib： OpenTelemetryプロジェクトによって維持されているが、標準SDKの一部ではないプラグインやインストルメンテーションは、contribパッケージと呼ばれます。

OpenTelemetryの基本アーキテクチャ

MELTは、APIとSDKの助けを借りてコードをインストルメントすることによって収集され、それからコレクターと呼ばれるものに送られます。MELTは、できればエクスポーターを通じてコレクターに送られます。これらの各々が何を意味するのかを詳しく見ていきましょう。

• エクスポーター（Exporter）： テレメトリーデータが送信されるバックエンドに準拠したデータを設定し、インストルメンテーションをバックエンドから分離します。
• コレクター（Collector）： コレクターは必須ではありませんが、収集されたテレメトリーデータに対して集約やサンプリングなどの機能を実行する、強力な中央コンポーネントとなり得ます。
  • 任意のバックエンドにデータを送信する柔軟性を提供し、安全な環境で推奨されます。コレクターには、レシーバー、プロセッサー、エクスポーターがコンポーネントとして含まれています。コレクターは2つの方法でデプロイできます。
    • エージェント：アプリケーションと同じホストに常駐するプロセス。
    • ゲートウェイ：テレメトリーデータが報告されるスタンドアロンのプロセスで。そこからデータはバックエンドに送信されます。
• OpenTelemetry Protocol (OTLP)： OpenTelemetryのネイティブプロトコルで、単一のデータストリームですべてのシグナルを送信することをサポートします。このOTLPは、選択したオブザーバビリティバックエンドの形式に完全に変換できます。

Open Telemetry用語集

• Baggage： トレースに加えて、OpenTelemetryは、オブザーバビリティイベント間のコンテキストをインデックス化し、構築するために、名前と値のペアを送信するメカニズムを提供します。
• コンテキスト伝播（Context Propagation）： OpenTelemetryのすべての横断的な関心事であるシグナルは、コンテキスト伝播と呼ばれる基礎的なメカニズムを共有しています。コンテキストは、論理的に連携するユニット間でAPIの境界を越えて意味（例：関連する実行）を運ぶ伝播メカニズムです。
• プロパゲーター（Propagators）： OpenTelemetryは、横断的な関心事の値を送信する様々な方法としてプロパゲーターを使用します。異なるプロパゲーターには、テレメトリーデータを転送する手段に関して異なる制約があります。
• インストルメンテーションライブラリ： OpenTelemetryが目指す究極の目標は、OpenTelemetry APIを直接呼び出すことで、世の中のすべてのライブラリを観測可能にすることです。今日では、特定のソフトウェアやライブラリに対してOpenTelemetryのオブザーバビリティを容易にする多くのライブラリが存在します。これらがOpenTelemetryリポジトリでホストされているかどうかを確認できます。検索には正確な命名規則を使用してください。

Open Telemetryの拡張性

OpenTelemetryの拡張性こそが、Open Telemetryを価値あるものにしています。カスタムライブラリをSDKに追加したり、SDKディストリビューションを作成したり、カスタムエクスポーターやプロパゲーターを構築したりするなど、あらゆるレベルで柔軟性を提供します。この多様性により、OpenTelemetryはあらゆる実装にとって最も実用的な選択肢となります。

Open TelemetryとNew Relicを併用する理由

• セキュリティ： New Relicと組み合わせることで、360度の完全なエンタープライズセキュリティを実現し、脅威の検出と軽減を支援します。
• 時間の節約： 自動化により、オブザーバビリティとモニタリングのためにNew Relicでアプリケーションをインストルメントするのが非常にシームレスになります。New RelicのIntelligent Observabilityはプロアクティブであり、大幅な時間を節約できます。
• 持続可能性： OpenTelemetryは急速に成長しているため、そのペースに追いつき、安定性を維持するのは難しい場合があります。New Relicは安定しています。アップグレードは本番環境で自動的に処理されます。
• スケーラビリティ： テレメトリーデータが増加するにつれて、取り込み、処理、監視のための安定したプラットフォームを持つことがさらに重要になります。New Relicのような頑健なツールは、膨大なデータを理解できます。
• デジタルエクスペリエンスモニタリング： New Relicはデータの相関付けを助け、ユーザーのデジタルエクスペリエンスに対する可視性を提供します。OpenTelemetryに対する広範なサポートにより、New Relicは高度なモニタリングを推進します。
• 堅牢性： New RelicのAIOPSとインテリジェントエンジンによるインフラとビジネスの健全性のプロアクティブな分析は、ビジネスに影響を与える可能性のある事柄の予測を提供し、対策を講じるのを助けます。

まとめ

お客様がNew RelicとOpenTelemetryを選択する理由は、New Relicがワンストップソリューションであり、すべてを集約し、深いインサイトを提供するためのハイパースケーラブルなテレメトリーデータプラットフォームを提供しているからです。New Relicは、シームレスな統合でOpenTelemetryをサポートするだけでなく、OTelの機能強化のための有意義なインサイトを提供することで、オープンソースコミュニティへのトップコントリビューターの一社でもあり、オブザーバビリティ分野での20年の経験を共有することで、今後も貢献し続けます。