最初に宣伝させてください。Tianqiong はオープンソース化されています: https://github.com/XiaoMi/mone。クラウド ネイティブ テクノロジ/研究開発効率に興味のある友人は、参加 (フォーク、スター) を歓迎します。
OpenTelemetry の概要
オープンテレメトリーとは何ですか? 「OpenTelemetry (略して OTel とも呼ばれます) は、リンク トレース、メトリクス、ログなどのテレメトリ データを検出、生成、収集、エクスポートするためのベンダー中立のオープンソース可観測性フレームワークです。業界標準として、それ自体が多くのサプライヤーの影響を受けています。公式の紹介文から、次の重要な点がわかります。
OpenTelemetry は可観測性フレームワークです。可観測性の三銃士は、リンク トラッキング、インジケーターの監視、ロギングであり、可観測性フレームワークとしての OpenTelemetry は、これら 3 つの側面でのデータの検出、生成、収集、エクスポートに使用されます。
OpenTelemetry の目標、またはその固有の使命は、可観測性フレームワークの標準となることです。標準として、ベンダーに依存しない必要があり、生成されるデータはこれらのベンダーをサポートする必要があります。ここでいうサプライヤーとは、OpenTelemetry によって生成されたデータを解析、保存、表示するために使用されるサードパーティのソフトウェアまたはフレームワークを指します。たとえば、リンクトラッキングではZipKinとJaeger、インジケーターモニタリングではPrometheusなどが挙げられます。また、OpenTelemetry は優れたスケーラビリティを備え、カスタマイズされたデータ エクスポート方法をサポートする必要があります。これらすべてはすでに行われています。
では、OpenTelemetry はこれら 3 つの次元でデータをどのように検出、生成、収集、エクスポートするのでしょうか? 公式サイトからサンプル画像を引用させていただきます。
マイクロサービスのアプリケーション コードでは、OTel が提供する自動インストルメンテーションを使用して、実行時に独自のアプリケーション コードを生成および変更するか、他のミドルウェアおよびフレームワーク コードのバイトコードを使用してデータを生成できます。または、OTel が提供する API と SDK を使用します。そして、データを生成するコードの側面と同様のコードを手動で追加します。現在、OTel は、Kubernetes Operator を通じて OTel の Javaagent を自動的に追加してデータを自動的に生成するなど、クラウド ネイティブと緊密に統合されたツールも提供しています。
生成されたデータは、OTLP (OpenTelemetry Protocol) を通じて OTel Collector と呼ばれる「コレクター」に送信できます。OTel Collector は、データ解析、データ形式変換、データ マーキング、データ フィルタリングなどの機能を提供し、OTel によって生成されたデータをバックエンド サプライヤーのデータ形式に合わせることができます。
OTel Collector を通じて収集されたデータを使用し、組み込みの形式変換を通じて、Prometheus 時系列データベース、ES、HBaseカラム ストレージ データベースなどのサードパーティ ストレージにエクスポートできます。サードパーティのサービスにエクスポートしたり、ログ ファイルに直接印刷したりすることもできます。
公式の紹介を見ると、OpenTelemetry はコンポーネント、API、SDK の集合体であることがわかり、本番環境では必要に応じてプラグインを追加して使用できるため、非常に便利です。これらのコンポーネントを理解できれば、多くのユースケースにソリューションを提供できます。同様に、学習コストも高くなります。特に Go 言語を理解していないと、落胆する要素がいくつかあります。
OpenTelemetryの使用法
調査
私たちは、OTel が提供する自動インストルメンテーションを習慣的にプローブと呼んでいます。名前が示すように、プローブはインターセプトする必要があるクラスとメソッドを検出し、特定の可観測性データを生成するために特定の機能強化を行うことができます。OpenTelemetry は複数の言語でプローブを提供しますが、ここではデモンストレーションとして Java 言語を使用します。Java 言語では -javaagent パラメータを使用して起動プロセス中にプローブを使用し、バイトコード拡張テクノロジ (OTel は ByteBuddy バイトコード コンポーネントを使用します) を通じて、アプリケーション コード内のどのクラスとメソッドをインターセプトする必要があるかを検出できるためです。可観測性データを生成します。ただし、この方法には言語の制限があり、たとえば Go 言語にはそのような自動化された方法がない可能性があります。
OpenTelemetry の Git から opentelemetry-java-instrumentation プロジェクトを見つけることができます。このプロジェクトはプローブのソース ファイルです。
opentelemetry-java-instrumentation をローカルでクローンし、ローカルでコンパイルし、opentelemetry-java-instrumentation のルート ディレクトリで ./gradlew Assembly を実行してビルドしてコンパイルします。コンパイルが成功すると、pentelemetry-javaagent-0.1.0-SNAPSHOT-all.jar が opentelemetry-java-instrumentation/javaagent/build/libs ディレクトリに生成されます。この jar ファイルが最終プローブです。
生成された opentelemetry-javaagent-0.1.0-SNAPSHOT-all.jar をサーバーのアプリケーション ディレクトリにアップロードします。アプリケーションが起動したら、JVM パラメータを追加します: -javaagent:${アプリケーション ディレクトリ}/opentelemetry-javaagent-0.1.0 - SNAPSHOT-all.jar、正常に起動すると、プローブが動作し始めます。
opentelemetry-java-instrumentation はプロジェクトと依存関係の管理に Gradle を使用するため、最初のコンパイル プロセスは順風満帆ではない可能性があります。Gradle を理解していない人でも簡単にコンパイルできるように、Hera の opentelemetry-java-instrumentation のコンパイル プロセスを参照するのが最善です。スムーズかつ迅速に。
また、opentelemetry-java-instrumentation は単なるプローブのソース コード ファイルです。依存する API と SDK は opentelemetry-java プロジェクトにあります。カスタム リンク トラッキング (Trace) など、さらにカスタマイズされた開発を実行したい場合は、 ) エクスポート メソッド、カスタム メトリクスのエクスポート メソッド (Metrics)、カスタム スパン (span) の内容などは、opentelemetry-java プロジェクトですべて変更する必要があります。この点については、Hera の opentelemetry-java も参照できます。opentelemetry-java-instrumentation で参照用にコンパイルおよびアップロードする方法が確認できます。
API と SDK を使用した手動インストルメンテーション
ここでは、opentelemetry-api、opentelemetry-sdk などの OpenTelemetry 関連の依存関係を導入し、メソッドを使用してデータを定義および生成する必要があります。この方法の利点は、スパン、メトリック、その他のデータをコード内のどこにでも生成できることですが、欠点も明らかです。
コードが非常に肥大化しているように見えます。
開発者のコーディング作業負荷の増加。
特に Java では、アプリケーション自体への依存関係が増加し、依存関係が多すぎると深刻な競合が発生する可能性があります。
豊富な実務経験のない開発者の場合、使用法を誤るとプログラム内で予期せぬエラーが発生したり、メモリ リークによりアプリケーション全体が使用できなくなったりする可能性があります。
したがって、生産プロセスでは、Hera は手動検出ツールをユーザーに公開せず、メソッド レベルのアノテーションを提供し、プローブを使用してそのようなアノテーションを持つメソッドを均一に処理します。もちろん、コード内の任意の場所で可観測性データを生成したいユーザーにとっては、手動インストルメンテーションと同様の方法が依然として必要です。
オーテルコレクター
小規模なアプリケーションの場合、可観測性データをプローブからバックエンド ストレージに直接送信することは非常に便利なプロセスであり、多くの場合、OTel Collector は必要ありません。しかし、このツールを使用すると、データをバックエンドに送信できない場合のオプションを提供できます。具体的な使用方法については、公式 Web サイトのドキュメントを参照してください: https://opentelemetry.io/docs/collector/
Kubernetes オペレーター
現在、大企業であろうと中小企業であろうと、K8s は比較的一般的な選択肢であるため、OpenTelemetry は自動検出を実装し、可観測性データを収集するための Kubernetes Operator も提供しています。興味がある場合は、公式 Web サイトのドキュメントを参照してください: https://opentelemetry.io/docs/k8s-operator/
OpenTelemetry の内容は常に充実しており、例えば Ebpf のサポートでは、Hera 社のプローブ自動検出装置が現在最もよく使われており、そのスケーラビリティにより、これをベースに多くの機能を充実させることができます。Hera で使用および拡張されたその他の関数は、opentelemetry-java-instrumentation ソース コードの解釈に関する後続の一連の記事で紹介されます。
プローブの比較
Hera の初期段階では、プローブの選択は、その後の一連のテクノロジー選択の決定と適応に関連するため、特に重要です。Hera はクラウド時代のアプリケーション可観測性プラットフォームとして位置付けられています。監視、リンク、ログの三剣士が密接に関連している必要があります。関連付けとジャンプ作業を完了するには、リンクにいくつかの属性を追加する必要があります。 Mone の既存のアプリケーションおよび権限と組み合わせることができるため、テクノロジーのスケーラビリティに非常に高い要件が課されます。下の図は、OpenTelemetry、SkyWalking、Jaeger-agent の比較表です。
当时的OpenTelemetry我们主要是用它来产生Tracing数据，后端由Tracing数据转换为请求类型的监控指标（Request Scope Metrics），OpenTelemetry在Hera中的应用这一部分内容我会在后续的文章中进行讲解。基于可扩展性和标准化，我们选择了OpenTelemetry，也确实在它的基础上添改了很多，在Hera的整体架构中，它也发挥着非常重要的作用。