SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

「OpenTelemetry」で始めるオブザーバビリティ入門

OpenTelemetry入門【実践編】~OpenTelemetry Collectorでテレメトリーデータを扱う~


  • X ポスト
  • このエントリーをはてなブックマークに追加

OpenTelemetry Collectorのコンポーネント一覧

Receiver

 データの受信器です。トレース、メトリクス、ログを受信、収集することができます。OTLP ReceiverによりSDKやAPIによるアプリからのトレースやメトリクス、または他のOTel Collectorからのデータ転送をOTLPで受信できます。

 Host Metrics ReceiverによりOSのCPU、メモリ、ディスク、プロセスなどを収集できますし、ミドルウェア(NginxMySQLなど)からもメトリクスを収集することができます。

 ログ取得はfilelog receiverにより可能です。

 その他にもHTTPテスト(HTTP Check Receiver)やファイル更新日時の取得(File Stats Receiver)といったものもあります。

 例えば Prometheus などの監視ツールを利用している場合、Prometheus Receiverなどを活用することで、その監視ツール自体を統合することもできます。

 このように Receiver は多岐にわたって提供されています。あらゆるテレメトリーデータを統合的に扱うことができるOTel Collector の特長が表れているポイントの一つと言えるかと思います。

 どのようなReceiverが提供されているかはRegistyページから確認することができます。

Processor

 データの処理器です。Receiverで取得したデータに対して処理を行うことができます。

 データ送信負荷のコントロールをメモリリミッター(Memory Limiter Processor)や、バッチ化(Batch Processor)により行えます。

 データの加工処理として、Attributes ProcessorによりAttribute(システム名や環境名などメタデータ)の追加・変更・削除、Resource Detection ProcessorによりOTel Collectorがインストールされているホスト情報(OSやAWS EC2の場合はリージョンなど)を取得しAttributeとして付与するなど、これも多岐に渡った柔軟な処理が可能です。

 バックエンドがSaaSの場合に機密情報の取り扱いが議論になると思います。一般的な対策としてデータのフィルタリングやマスキングがありますが、それもProcessorを使用して対応することができます。

 そして忘れてはならないのがSamplerです。

 テレメトリーデータを取得する際に特にトレースが膨大になりがちで一般的にはサンプリング戦略を取る必要があります。

 ここでは詳細には立ち入りませんが、ProcessorとしてはTail Sampling ProcessorProbabilistic Sampling Processorが提供されています。

備考

  • 複数定義した場合、定義順に処理されます。
  • 何を使用すれば良いか迷うと思います。推奨のものを確認することができます。
  • Processorの一覧もご確認ください。

Exporter

 データの送信器です。Receiverで受信し、Processorで処理したデータをバックエンドに送信することができます。

 標準的にはOTLP(HTTP / gRPC)でバックエンド、もしくは別のOTel Collectorに送信することができます。OTLPは近年のオブザーバビリティツールであれば多くのものが対応しています。OTLPでの受信方法は各バックエンド側がドキュメントとして公開しているでしょう。

 ツール固有のExporterとして、例えばKafkaへ送信したり(Kafka Exporter)、ログをSplunkに送信することもできます。利用頻度が少ないデータはAWS S3に送ることもできますし(AWS S3 Exporter)、もしくはデバッグ用途にコンソールに出力することもできます(Debug Exporter)。

 このExporterの柔軟性もOTel Collectorの優れたところです。例えば以下のユースケースに対応できます。

  • 複数の宛先を指定しいくつかのバックエンドを同じデータで検証する
  • 本番環境と検証環境でエージェントは統一しつつも別々のバックエンドに送り(本番は有償SaaS、検証はOSSなど)、コストを合理化する
  • 本番環境の中でもデータの重要度、利用頻度に合わせてバックエンドを変えるOpenTelemetryに対応している(非網羅的な)ベンダーリストが参照できます。

備考

Extension

 Extensionはデータ送信パイプラインには直接的に関係しない拡張機能を提供します。

 例えばzPagesはOTel Collectorの処理状況に関する統計情報を提供します。Health CheckはKubernetesにおけるLiveness / Readiness Probeで使用可能なOTel Collectorの稼働状況を返します。他にもExporterの認証を行うためのExtensionもあります(BasicBearerOAuth2など)。

備考

  • Extensionはパイプラインの外で定義します。後ほど例を見ます。
  • Extensionの一覧をご確認ください。

Connector

 Connectorは比較的最近開発された機能で、ReceiverとExporterの両方の役割を担うことでパイプライン間の橋渡しをすることができます。これにより、より柔軟なパイプラインを構成することができます。

https://opentelemetry.io/ja/docs/collector/building/connector/
https://opentelemetry.io/ja/docs/collector/building/connector/

 トレースからRED(Request、Error、Duration)をメトリクスとして生成できるSpan Metrics Connectorや、ログのエラー数をAttribute別にカウントしメトリクス化(例えばアクセスログから4xx、5xxの件数をカウント)するCount Connectorなどがあります。

 執筆時点(2024年8月)ではRegistryページはConnectorの情報が掲載されていないようです。Registryページの代わりに以下のOpenTelemetry Collectorのレポジトリを参照ください。

  • https://github.com/open-telemetry/opentelemetry-collector/tree/main/connector
  • https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector

 

次のページ
実際にテレメトリーデータを送信してみる

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
「OpenTelemetry」で始めるオブザーバビリティ入門連載記事一覧

もっと読む

この記事の著者

山村 悟史(Splunk Services Japan合同会社)(ヤマムラ サトシ)

 Splunk Services Japan合同会社でオブザーバビリティソリューションを担当するエンジニア。 アプリ、サーバー、ネットワーク、セキュリティ運用の経験をバックグランドにオブザーバビリティの布教やツール導入のコンサルティング活動を行う。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/20081 2024/09/30 12:50

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング