OpenTelemetry で生成したトレースを ElasticSearch (OpenSearch) に送りつけて可視化したい
hassaku63参考
OpenTelemetry collector を通して "Elastic APM" に送信する構成を取るらしい
hassaku63
サイドカーなどを使って agent 構成でデプロイして、アプリから agent にデータを送りつけるのが推奨らしい。データのやりとりは push/pull は選べる
agent を使うとメタデータをテレメトリデータに付与したりできるので、Client の処理をオフロードできる。リトライや暗号化などの処理も agent が担えるらしい。
OTel のライブラリは、ローカルに利用可能な Colletor がいることを前提にして、データを export する。
hassaku63とりあえず基本概念の理解が追いついてないので、リンク集をポストする
Otel 用語集
OTel general information
OTel configuration
OTel Tracing demo
hassaku63いくつか主要な登場人物がいるらしいのでそれを整理
- receiver
- collector
- exporter
- processor
glossary から原文引用しつつ解釈をメモする
| term | description | 解釈 |
|---|---|---|
| Colloctor | A vendor-agnostic implementation on how to receive, process, and export telemetry data. A single binary that can be deployed as an agent or gateway. | データの収集から外部への送信までひっくるめた概念らしい |
| Exporter | Provides functionality to emit telemetry to consumers. Used by Instrumentation Libraries and the Collector. Exporters can be push or pull based. | テレメトリデータを外部に送出する役目を持つ。各言語のライブラリを使うとか、 Collector 経由で間接的に利用するかで使うもの |
| Processor | Operation performed on data between being received and being exported. For example, batching. Used by Instrumentation Libraries and the Collector. | Collector 内蔵の機能の話をしているらしい。データを収集 (receive) してから送信 (export) するまでの処理ということなのでデータ変換を担っているように見える |
| Receiver | Term used by the Collector to define how telemetry data is received. Receivers can be push or pull based. | Collector に内蔵されているデータ収集関係の定義を指している？？ |
hassaku63基本的には OTel Collector を agent として起動して、適切に設定してやれば良さそう。
※ アプリ役となる何かを用意する必要があるのと、export 先として想定する OpenSearch の設定がどうなるかという話はまだ見えてない
Configuration やそのサンプル を見ると、 "receivers", "processors", "exporters" あたりは重要そうに見える。
ドキュメントによれば、これらを "service.pipelines" セクションで定義しておく必要がある。Service の設定項目を見ると、 "service" に書いたものが実際に enable されるコンポーネントであり、receivers, processors, exporters, extensions あたりはコンポーネントの宣言（実際に使われるかどうかの設定は含まない）である、という読み方をすれば良い。
ちょっと重要そうなのが以下
Note: Each receiver/processor/exporter can be used in more than one pipeline. For processor(s) referenced in multiple pipelines, each pipeline will get a separate instance of that processor(s). This is in contrast to receiver(s)/exporter(s) referenced in multiple pipelines, where only one instance of a receiver/exporter is used for all pipelines. Also note that the order of processors dictates the order in which data is processed.
パイプラインを複数定義して、コンポーネントを（定義上）使いまわした場合の話。
processor はパイプラインごとに別々のインスタンスを作るが、recerver/exporter はパイプライン間で同一インスタンスを共有する、とある。
また、processor は宣言した順序がそのまま処理順となることにも注意。
hassaku63OpenSearch - Trace analytics のドキュメントを見てみる。
プラグインによってトレーシングをサポートしているようで、プラグインを利用するためには OpenSearch もしくは ES 7.9 以降が必要。
Prerequisites を読みながら思ったことをメモする
テレメトリデータをアプリ側でよしなに生成する必要があるのは同じ。ここはライブラリなりエージェントなりを使う。 Jaeger, Zipkin が挙がっているが、Jaeger は OTel のプロジェクトに統合される的なことが書いてあった（要出典）ので今採用する意味は少ないように思える。Zipkin にしても、これはこれで可視化の機能を持っているのでこれ使うならそれでOKじゃんとなりそう...。OTel のコードベースで行けないものか？？ ES に対する exporter をサポートしているなら、Data Prepper を代替して使えるような気はする
テレメトリデータを生成したら Collector（厳密には receiver?）に送りつける。どうも X-Ray のための receiver をサポートしているらしい。
で、Data Prepper について。これは OpenSearch とは独立したコンポーネントである、と書いてある。よって AOS にデータを投げ込むなら side car なりでこいつを立てる必要がある、ということになりそう。正直 OTel のコードベースとやってることは変わりないように見えるし、できればそっちで済ませたい。
OpenTelemetry Collector sample configuration を読みながら思ったことをメモする
OTel Collector の exporters の設定に data prepper が登場している。ということは、data prepper は AOS 用の exporter という位置づけになる？？？（その割には結構色々 Config の概念があるような気もするけど）