🔭

Splunk OpenTelemetry Collectorは何が便利なのか調べてみた

2023/05/01に公開

Splunk

OpenTelemetry

tech

はじめに

Splunk Observability Cloud（以下、Splunk o11y）は独自エージェントは持たずOpenTelemetry完全準拠です。
さらにOpenTelemetry Collectorについて、独自に機能拡張したSplunk Distribution of OpenTelemetry Collector（以下、Splunk Otel Collector）を提供しています。
※ちなみにSplunkはOtelの断トツのトップコントリビューターで、独自に機能拡張するだけではなく本家にも貢献しています。

本家Otel Collector Contribとの違いを見てみたいと思います。

比較表

こちらに公開されています。

記事作成時点のキャプチャを貼ります。

それぞれの機能について調べてみたので、簡単に解説したいと思います。

解説

Splunk support

これは機能と言うよりサポートポリシーですね。本家の場合でも「Best effort」でサポートされるようです。

Installer scripts for Linux and Windows

そのままで、Linux用とWindows用のインストーラーが用意されています。

本家はリリースから持ってくる必要があるので地味に面倒
テレメトリーデータ送信やProcessorなど諸々の設定も自動化してくれる

Configured for Observability Cloud

linux、windows、kubernetes用にSplunk o11y用のexporterのコンフィグがデフォルトで用意されている。REALMとアクセストークンを指定すればそれだけでOK。

Zero config automatic instrumentation

Auto Instrumentationを更にAutoにしたもので、ホスト、コンテナ上でアプリが起動したら自動的にAuto Instrumentationがかかる。

Discovery mode

これ。

事前に定義された設定ファイルを使ってExtensionとReceiverを試行してみて、データがうまく取れたら有効化する機能（多分、、、）。
まだ実験段階の模様。今はPostgresql receiverの設定があった。
種類が増えていくと便利そうですね。ホストによってコンフィグをいちいち書き換えずに済むようになる。

Recipes for configuration management tools

書いてある通り、Otel Collectorをホストに配布するために各種構成管理ツールのレシピが提供されている。

Helm chart and Kubernetes operator

KubernetesへのOtel CollectorのDeploy用のHelm chartが用意されている。k8sに合わせたprocessorなんかもデフォルトで設定してくれる。

Built-in dashboards

これはOtel側じゃないですね。Splunk o11yに各製品、OSS用のビルトインダッシュボードが各種用意されているのでOtel Collectorでメトリクス取得⇒可視化が簡単にできますよ、というお話。

AlwaysOn Profiling

プロファイリング（関数ごとのCPU、メモリ使用量分析）が常に可能（AlwaysOn）という機能。

ボトルネックになっている関数の調査だったりメモリリークが起きていないかみたいな調査ができる。

Network Explorer

Kubernetes内のネットワークのトポロジー作成したり負荷かけてる通信を分析できるよという機能。最近流行りのeBPFを使うそうです。

Log collection and export

Splunk Cloud / Enterpriseへのログ送信が簡単にできるようにデフォルト設定を用意しているよというお話。
Splunkへのログ送信についての詳細はここでも書いています。

APM、インフラ、ログ間で紐づけができる機能。サービスが動いているホストのダッシュボードを確認したり、あるトレースで発生したログを確認したり。Otel Collectorで付与したサービス名やホスト名（k8sはPod名）などのメタデータでお互いが関連付けできる。

RUM correlation

多分この件。
RUMのスパンとAPMのスパンをリンクできるよ：

Otelでフロントエンドとバックエンドの紐づけは課題だったのですがSplunk otelは解決しています。
アプリ側の処理で生成されたTrace ID、Span IDをクライアント側にServer-Timing Headerに埋め込んで返し、RUM側のOtelエージェントがフロントエンドのトレースと紐づけるという処理をするようです。

Access-Control-Expose-Headers: Server-Timing
Server-Timing: traceparent;desc="00-<serverTraceId>-<serverSpanId>-01"

まとめ

Otel Collectorは自由度が高い分、最初の設定をどうしたらいいか分からないという取っつきにくさがあるのですが、その辺りを手厚くサポートしてくれているという印象がありました。
実際、何も考えずコマンドを叩けばとりあえずテレメトリーデータ収集を始めることができるのでOtel Collectorの敷居を格段に下げているなと思います。