Distributed System、Micro Serviceが乱舞する世界でシステムの動作を確認したり、エラーを追跡することはとても大変でした。このような環境では、複数のサービスが共通の形式のdataを送信し、それを連結してシステムを分析する必要が多くなりました。
Opentelemetry(以下otel)は、最新のソフトウェアトレンドでObservabilityを増やすために作成されたフレームワークです。 APIやコンベンション、ツールキットなどを提供します。
しかし、ただのサービス一つでもログを見るのはちょっと楽なようで、設定もあまり難しくなくて(奇妙なことをしなければ…)導入してみるのも悪くない。Observability
明確に定義するのは曖昧ですが、「なぜこのようなことが起こったのですか?」に対する答えを出す能力と定義することができるようです。
そうするためには、プログラムが「well instrumented」されている必要があります。
Opentelementryを実装してみるとたくさん出会う表現です。韓国語では「計測」という意味なのに、あれこれよく測定して記録しておくと思えばいいようです。
Opentelemetry(続いて)
OtelはVendor- and tool-agnostic で、広範囲に使用できます。 Observability backends として何をする必要が強制されません。 Otel規格を満足するオープンソースを使えばよいのです。
Opentelemetryについて知る必要がある少しの概念
Otelを構成する要素を覚えておく必要があります。
Distributed tracing
Log、Span、Trace
Context propagation
Signals
Collector
Distributed Tracing
Log
Spanはアクションの単位です。特定の動作の名前、時間に関連するデータ、spanに含まれるlogs span attributeと呼ばれる特性があります。
たとえば、http.request.method、url.pathなどの属性があります。
どのRequestの開始から完了までをTraceといいます。このトレースには、1つのシステムではなく複数のシステムのSpanを含めることができます。
最初のSpanをRoot Spanといいます。
Context propagation
コンテキスト情報を伝播し続け、関連するSignal同士およびTrace同士が接続できるようにします。
Propagationは、このコンテキスト情報Objectをシリアル化、逆シリアル化しながら、サービスとプロセスの間を通過します。通常はW3C TraceContext Propagatorを使用してください。
シグナルはOtelの収集要素です。合計4つで、Log、Metric、Trace、Baggageがあります。
Log
Metric
Trace
Key value storeでコンタクトのようにPropagationされる情報です。主にユーザーIDなどの追加情報を保存します。
Opentelemetry Collectorと呼ばれます。 Collectorはアプリケーションからテレメトリデータを受け取り、処理し、テレメトリリポジトリにエクスポートする役割を果たします。
コレクタなしで直接アプリケーションからリポジトリにテレメトリデータを撃っても構いませんが、コレクタを1つ置いておき、テレメトリデータの処理はコレクタに任せておき、アプリケーションは私のやることをお勧めします。
configurationも多様にでき、collectorでspan tail filteringなどができるなどcollectorを書けば利点が多いです。
以上がOpentelemetryの基本概念の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。