見出し画像

翻訳しながらOpenTelemetryを触ってみる~Concepts編~

fumi

はじめに

マイクロサービスでは当たり前ですが一つのリクエストに対して複数のサービスを跨いで処理を行います。一方で処理時間や処理量を計測したくともそもそもどのようにすれば良いかわからないといった課題がありました。そこで今回はOpenTelementryについて学習してその課題を解決したいと思います。

今回の目標としてはOpenTlelemetryの概要とその計測方法の基礎について理解することです。コードを各箇所もあるのでライブラリと自分が使用する言語(Golang, Typescript)での利用方法について学習したいと思います。

進め方としては公式ドキュメントをもとに理解をしていきます。

Concepts

What is OpenTelemetry?

  • OpenTelemetryとはトレース・メトリックス・ログを作成・管理するためのAPIとSDKの統合ツール

  • JaegerやPrometheusなどにデータを送信することができる

なぜ必要で何ができるか

ここ翻訳がなかなか難しいです。
とりあえず標準化されたテレメトリーデータの生成が言語にかかわらずできるみたいなイメージでしょうか？

Opentelementryは何ではないか

  • JaegerやPrometheusのような監視用のバックエンドではない

  • 他のオープンソースや商用バックエンドにデータを公開する

つまりPrometheusのようにログを出して監視して簡単なデータ表示までできるというよりかはログを出して公開することによって他のサービスで使えるようにすることに特化しているといったイメージでしょうか？

Components

  • 言語を越えた仕様？

  • テレメトリーデータを収集・変換・公開するツール

  • 各言語用のSDK

  • サードパーティパッケージとの連携

Specification

  • API → トレース・メトリックス・ログデータの操作のための型を定義

  • SDK → 言語特有のAPIを実装。設定やデータ処理・公開方法も定義

  • Data → OpenTelemetry Protocol(OTLP)やベンダーによらない通信について定義

正直よくわからないです。OTLPとは？

Collector

  • OpenTelemetry Collector → テレメトリーデータの受信・送信・公開を行う

    • テレメトリーデータを複数のフォーマットで受信可能

    • 複数のバックエンドに対して送信することも可能

    • 公開前にフィルターをかけることも可能

Language SDKs

言語によらずOpenTelemetry APIを使って必要なデータをバックエンドに送信

ある程度それぞれのコンポーネントの役割がわかった気がします。

Data sources

  • OpenTelemetryが扱えるデータの型について解説しています。

Traces

  • Trace → リクエスト一つを追跡

    • アプリケーションのサービスが処理

    • 処理やネットワーク・セキュリティを越えて一つのTraceとなりうる

    • root spanを含む → エンドツーエンドのリクエスト全体の時間

    • spanは複数含む

  • Span → Traceのユニット一つ

    • オブジェクトであり一つのサービスによって行われた処理を表す

    • Spanは span contextを含む

    • span context → グローバルでユニークな値でどのリクエストかを表す

    • Spanはリクエストエラー・処理時間メトリックス・開始と終了時間・名前などを含む 

OpenTelemetryでは複数のspanを管理するためtracerインターフェースがある

  • tracerによってspanに対して情報を追加したり終わらせることができる

  • tracer providerを通してtracerを複数作ることができる

あまりにも長いので翻訳はしませんがその次に表示されているspanが生成されてから終了するまでのライフサイクルは理解するのに役に立ちました。一度読んでおくのをお勧めします。

Metrics

Prometheusで得た知識で大元はあっていたので特には書かないです。ただTracesとの違いが書かれてあったのでそこだけまとめておきます。

Traces → リクエストのライフサイクルを取得してリクエストの一部の状況を提供
Metrics → 統計の集合体を提供

簡単にいうとMetricsはリクエストの一部のサービスに対して数値的な状況が知りたい場合に使ってTracesは全体の状況が知れるといった感じでしょうか？

Logs・Baggageについても特には書きません。

Instrumenting

自動で計測する場合や手動で計測する場合で実装手順について説明してくれています。ただどうしても使用する言語によって実装方法が結構変わってくるみたいです。

これも言語によりますがJavaの場合ライブラリとしては3つあるみたいです。

  • Core →APIとSDKの実装・手動での計測に使用

  • Instrumentation → 基本的な機能＋様々なライブラリやフレームワークに対応した自動計測

  • Contrib → 任意のコンポーネント

  • Manual Instrumentationの箇所は少し具体的に書いているのでみておいた方が良いと思います。

読むより触った方が早い気がしました。

Instrumenting libraries

ライブラリーでの計測手法について書いています。自分の使用用途から外れているので飛ばします。

Data Collection

  • OpenTelemetry Collector → テレメントリーデータの収集を促進

  • ベンダーによらずデータの取得・処理・公開の実装が可能

  • これによりデータフォーマットの処理サービスやエージェントが不要となる

  • デフォルトではCollectorがテレメトリーデータが最終的に送られる場所

Deployment

  • 実際に使用する際の手法が書かれています。

Agent → アプリケーションと同じホストでインスタンスを立てる
Gateway → 一つ以上のインスタンスを独立したサービスとして立てる

Components

Collectorにも複数のコンポーネントが含まれているみたいです。

  • receivers → コレクターにどのようにデータを入れるか。プッシュかプルベース

  • processors → 受け取ったデータをどうするか

  • exporters → 受け取ったデータをどこに送信するか。プッシュかプルベース

名前に対して機能が直感でわかりやすいです。これらのコンポーネントはパイブライン？から設定できるみたいです。

Repositories

計測の方と同様に複数のライブラリに分かれるみたいです。

  • Core → 基本的なコンポーネント(先ほど上で説明したもの)

  • Contrib → Coreのコンポーネント＋任意や実験段階のコンポーネント

Glossary

どうしても新しい用語がいっぱい出てきて初見ではわかりづらいと思うので用語を解説したページを用意してくれています。


この記事が気に入ったらサポートをしてみませんか？