Sumologicで目にするOpen Telemetry Collectorとは(前編)

こんにちは。

技術部のtakaです。

Sumologicを利用しているユーザの方なら一度は見るSumologicのログ収集を行うエージェントであるコレクターを一覧表示するCollection画面に、「Open Telemetry Collection」というタブがあるのはご存じでしょうか？

そんなOpen Telemetryを前後編に分けて紹介させていただきます。

前編(この記事)では、Open Telemetryとはそもそも何を指しているのか、Open Telemetryそのものの利点とSumologicのOpen Telemetry Collectorとは何を行うことが出来、その利点はどこにあるのかを解説していきます。

そもそもOpen Telemetryとは

端的に言ってしまうと、Open Telemetryとは、オブザーバビリティデータの収集・加工・送信をベンダー中立性をもって標準化するオープンソースプロジェクトです。

このオープンソースプロジェクトの中でのOpen Telemetry Collectorとは、オブザーバビリティデータを収集・加工・送信を行うエージェントの事を指しています。

では、このオブザーバビリティデータ、ベンダー中立性とは何でしょうか？

オブザーバビリティデータとは

オブザーバビリティデータは、マイクロサービスと呼ばれるサービスを構築する開発・運用手法の中で、一連の処理の流れを把握する為のデータです。

現在、Amazonを筆頭に行われているサービスでは、独立した機能一つ一つを組み合わせて大きなアプリケーションやサービスを構築するマイクロサービスが主流となっています。

マイクロサービスは、機能がそれぞれ疎となっている事から、リリース作業時に他機能に影響を与えない点、障害発生時に他の機能へ飛び火しない点など一枚岩となってしまっているモノリシックサービスと比べて運用上のメリットが大きく、現在では主流となっています。

しかし、そんなメリットの大きいマイクロサービスでも、デメリットは存在します。

処理の一連の流れを追って把握する事が難しくなってしまうという部分です。

このデメリットを解決する為にマイクロサービスで行われる処理の一連の流れごとに識別子を付けて管理・監視を行うという考え方が生まれました。

この解決策を分散トレーシングといい、この一連の流れごとに識別子を付けたデータであるトレース、ある期間中に収集された測定値の集合体であるメトリクス、ログをオブザーバビリティデータと呼ばれています。

ベンダー中立性

ベンダー中立性とは、コレクターを利用する上で"ベンダーにとらわれることがない状態"を指しています。

このベンダー中立性によって、Open Telemetry Collectorは収集したテレメトリデータの送信先を制限されることなく使うことが出来るという訳です。

これの何がうれしいのかというと、一般的なモニタリングツールが独自で作っているエージェントを利用する場合(下左図)は、ただ汎用性が低いというだけでなく、インシデントの特定などを目的としたテレメトリデータの分析が難しくなってしまうという欠点がありますが、Open Telemetry Collectorの場合(下右図)は解消しています。

出典：Open Telemetry公式ドキュメント中のLimitations of non-OpenTelemetry Solutions(左図)、OpenTelemetry Solution(右図)

左の図では同じアプリケーションに対してトレース・メトリクス・ログを収集する際、それぞれ別々のモニタリングツールのコレクターで収集し、収集したものをツールのバックエンドにのみ送っている為、トレース・メトリクス・ログそれぞれが関連付けられていない状態です。

このように関連付けられていない場合、トレースまたはメトリクスとそれに紐づくログが直接確認できず、インシデントの特定といったテレメトリデータの分析に時間が掛かってしまいます。

一方、右の図ではOpen Telemetry Collectorがトレース・メトリクス・ログを全て収集し、コレクターのコンポーネントの一つであるProcessorと呼ばれるものでデータにメタデータ付加やフィルタリングなど加工処理が行われることで、テレメトリデータそれぞれを関連付けられます。

なお、次の記事でも詳しく解説させていただきますが、Open Telemetry CollectorにはProcessor以外にも主要なコンポーネントは二つ存在しており、それはReciverとExporterと呼ばれています。

この三つのコンポーネントは、以下のような役割を持ったコンポーネントとなっています。

• Receiverはどんなデータをどのように取り込ませるかの設定
• Processorはデータのフィルタリング・メタデータ付加・削除など加工処理設定
• Exporterは収集し加工したテレメトリデータを何処に送るかを設定

Open Telemetry 自体の利点

Open TelemetryがSumologicではどうなのかという話の前に、Open Telemetryそのものの利点について説明させてください。

その利点には、以下の3点があります。

• 前述した通り、ベンダー中立性がある点

• テレメトリデータの収集方法としてデファクトスタンダードな存在となりつつある点

出典：Jaeger公式ドキュメントのClient Libraries

上記URLで説明されている通り、Jaegerというマイクロサービス内で相互接続されたコンポーネントの問題をモニタリングする為にテレメトリデータを取集するソフトウェアでも、Jaeger独自形式のコレクターを非推奨とし、Open Telemetryへの移行が推奨されています。

またSIME製品だけで考えても、Sumologicを初め、DataDog、Splunkなど大手では既にOpen Telemetry Collectorを利用可能になっています。

それぞれのSIEM製品でOpen Telemetry Collectorについて公開されているドキュメントは以下の通りです。

•  アプリケーションのソースコードを変更せずともテレメトリデータを収集できる方法が存在する点

出典：OpenTelemetry公式ドキュメントの自動計装(Javascriptの場合)

自動計装(Automatic Instrumentation)という、アプリケーションに必要なパッケージのインストールと環境変数を設定することで簡単にテレメトリデータを収集できる便利な機能がOpen Telemetryには存在しています。

ただし、言語によって利用できない部分があるようなので注意してください。

上記URLのJavaScriptの場合は、環境変数の設定はトレースのみがサポートされていて、メトリクスやログに関しては開発中のようです。

Sumologicで実装されているOpen Telemetry CollectorとInstalled Collectorの違い

SumologicのInstalled CollectorとOpen Telemetry Collectorは、どちらも機器にインストールして動くエージェントです。

では、Open Telemetry CollectorとInstalled Collectorの違い、Open Telemetry Collectorの利点は何でしょうか？

Installed Collectorでは、そもそもトレースを収集することが出来ない

Installed Collectorはログとメトリクス情報は収集できるものの、トレースを収集することは仕様上できません。

機器にCollectorを導入しトレースを収集したい場合は、Open Telemetry Collectorで収集を行う必要があります。

Open Telemetry Collectorでは、自動検出機能が存在する

自動検出機能(Auto Discovery)は、Open Telemetry Collectorがインストールされた機器内のサービスを検出し、Open Telemetry Collector一覧画面で表示されます。

検出されたサービス(例ではApache)をクリックすると、誰でも簡単に収集したサービスのデータをダッシュボードで可視化できるApp catalogを作成することが出来ます。

こちらの機能について、現時点(2024/03/01)ではInstalled Collectorは利用することが出来ず、Open Telemetry CollectorがインストールされているLinux,MacOSのみ使うことが出来ます。

また、現時点で、検出できるサービスについては以下の通りです。

• Apache
• MySQL
• Ngnix
• ElasticSearch
• PostgreSQL
• Redis
• Kafka
• Docker
• RabbitMQ

最新の対応状況については、こちらのURLから自動検出機能について説明しているSumologic 公式ドキュメントから確認してください。

Open Telemetry Collectorでは、メトリクスの収集をほぼ設定することなく簡単に行える

上記画像のOpen Telemetry Collectorインストール画面の手順②のチェックマークが入った状態で以降の手順を行いインストールが完了後、すぐにメトリクスの収集を行うことが出来ます。(※こちらのインストール手順については、後編の記事で解説させていただきます)

このチェックボックスをクリックしコレクターをインストールを行った場合には、特定のパス上で、hostmetrics.yamlという設定ファイルがローカルに追加される状態となります。

この特定のパスは、プラットフォームによって異なります。

• Windowsの場合は、C:\ProgramData\SumoLogic\OpenTelemetry Collector\config\conf.d
• Linux,MacOSの場合は、/etc/otelcol-sumo/conf.d

設定ファイルについては上記のベンダー中立性で少しだけ触れさせていただきましたが、Open Telemetry Collectorコンポーネントの動作について定義した設定ファイルとなっており、これに基づいてメトリクスを収集・加工し、Sumologicに送ります。

このチェックボックスの設定は、Windows,Linux,Macのプラットフォームに対応しており、他のAnsible,Puppet,Chefのアプリケーションを通してプラットフォームにOpen Telemetry Collectorをインストールする際は、非対応となっています。

Installed Collectorの場合、メトリクスを収集しSumolgicに送るには、Installed Collectorをインストール後にデータを収集・受け取る為の環境であるソースを別途設定する必要があります。

Open Telemetry CollectorではNext-Gen Appsによって簡単にデータ収集・可視化できる

先ほど紹介した自動検出機能で漏れているアプリケーションでのデータ収集やメトリクス以外のテレメトリデータを収集したい場合に、SumologicのNext-Gen Appsを利用することで、簡単にデータ収集・ダッシュボードによる可視化が可能です。

このNext-Gen Appsの実際の動作としては、上図のSumologicGUI上で現在136種類実装されている中から利用したいアプリケーションを選択し、収集したデータに付けるメタデータの設定後、そのアプリケーションに合ったOpen Telemetry Collectorの設定ファイルをダウンロードし、収集を開始させることが出来ます。

その後Sumologicに収集されたテレメトリデータが送られ、SumologicGUIのダッシュボード上で表示されます。

Installed Collectorでは、データを収集・受け取る為の環境であるソースを設定後、Sumologicで提供のダッシュボードを適用できるClassic Appsを利用することで、収集と可視化を行うことが出来ます。

最後に

今回、前編に当たるこの記事では、Open Telemetryとはそもそも何を指しているのか、Open Telemetryそのものの利点とSumologicのOpen Telemetry Collectorとは何を行うことが出来、その利点はどこにあるのかを解説しました。

この記事の中で解説したOpen Telemetry CollectorとInstalled Collectorとの違いは以下の通りでした。

• Installed Collectorでは、そもそもトレースを収集することが出来ない
• Open Telemetry Collectorでは、自動検出機能が存在する
• Open Telemetry Collectorでは、メトリクスの収集をほぼ設定することなく簡単に行える
• Open Telemetry Collectorでは、Next-Gen Appsにより簡単にデータ収集・可視化できる

後編では、Open Telemetry Collectorのコンポーネントと設定ファイルについて、Sumologicでのインストール、アンインストール方法を説明する予定です。

最後までお付き合いいただきありがとうございました。