DEVOPS

Universal ForwarderとOpenTelemetry Collectorの統合:Splunk Add-On for OpenTelemetry Collector

Splunkはオブザーバビリティ分野ではログやマシンデータの高度な分析が可能であるSplunk Cloud / Enterprise(以下Splunk Core)と、フロントエンドからバックエンドまでのエンド・ツー・エンドの可視化が可能なSplunk Observability Cloudを提供しています。

歴史的経緯から、エージェントとしてSplunk CoreへはUniversal Forwarder(UF)を使用しログを送信し、Splunk Observability CloudへはSplunk Distribution of OpenTelemetry Collector(OTel Collector)を使用しメトリクス、トレース、ログ(fluentdをバンドル)を送信するようになっていました。

このようにエージェントが分離されている中、Splunkでも統合の重要性は認識されており、そしてついにUFのAdd-onとしてOTel Collectorを展開できるようになりました。

Splunk Add-On for OpenTelemetry Collector(OTel Collector Add-on)

マニュアル

この記事では、本Add-onについて詳細に見ていきたいと思います。

メリット

OpenTelemetry CollectorとUniversal Forwarderを使用することで、オブザーバビリティにとって必要なテレメトリーデータの取得を死角なしに行えます。

OpenTelemetry CollectorとUniversal Forwarder

Splunk Coreでログ分析を中心にされてきたお客様にとって、オブザーバビリティへの拡張を容易にできます。これによりフロントエンドやバックエンドまでトランザクションレベルでの分析をトレース、メトリクスを用いて可能になります。

また、メトリクス(CPU使用率など)をUFからログデータとして変換し、取得していた場合、メトリクスに置き換えることでパフォーマンス向上や取得間隔短縮といったメリットも得られます。

一方、OTel Collectorを既にお使いのお客様にとっては、ログ取得に一日の長のあるUFを利用できます。ログ送信の信頼性もさることながら、数多くのAdd-on(ログ取得テンプレート)により取得設定の時間短縮および自動パース処理による容易なデータ分析を享受できます。

また、Deployment Serverを使用することで、OTel Collector含む、コンフィグ配布がリモートから容易に行えることも大きなメリットです。

アーキテクチャ

本Add-onとしては、UFのAdd-onとしてOTel Collectorを配布、インストールを行います。そのためアーキテクチャとしてはシンプルで、UFとOTel Collectorは引き続き個別に動作します。

アーキテクチャ基本的なアーキテクチャ

UFからはログ(テキストファイルであればなんでも)をSplunk Coreに送信します。

通常は9997/tcpでSplunk独自プロトコルで送信しますが、HTTP Proxyを通す必要があるなど、状況によってはhttpout機能によりHEC(HTTP Event Collector)によりHTTPによる送信が可能です。その場合のポートは443/tcp(Splunk Cloud)、8088/tcp(Splunk Enterprise※変更可能)です。

OTel Collectorからはメトリクス、トレースをHTTPS(443/tcp)によりSplunk Observability Cloudへ送信します。

HTTP Proxyを経由する場合HTTP Proxyを経由する場合

多段構成を組むこともできます。外への通信が特定ホストに制限されているシステムでは、しばしばこのような構成を取ります。

多段構成多段構成

注:OTel Collectorは開発が盛んですので使用ポートは今後変わる可能性もあります

配布方法

配布方法は特に本Add-onに限って特別なことはありません。

1. Deployment Serverによる配布、2. 構成管理ツール利用、3. マニュアル配布があります。

1. Deployment Serverによる配布

もしDeployment Serverがあるようでしたら推奨する方法です。OTel Collectorの設定を配布できるのが最大のポイントです。

例えば、特定ホストで新規に取得したいメトリクスが増えた場合(Apache httpdメトリクスなど)、Deployment Serverから一括でコンフィグファイルを配布できます。

2. 構成管理ツール利用

Deployment Serverではなく、既存の構成管理ツール(Ansibleなど)を使用している場合は、そちらでも結構です。

3. マニュアル配布

比較的エージェント数が少ない場合はマニュアル配布でも結構かと思います。ただし、Deployment Serverの利用は是非ご検討ください。

設定方法

設定すべき項目は大きく以下になります。詳細情報はマニュアルをご参照ください。

  1. Splunk Observability CloudのAccess Token設定
  2. データ送信先Realmの設定
  3. OTel Collectorデータ取得の設定(必要に応じて。ホスト関連のメトリクスはデフォルトで収集されます)

注:本ブログ執筆中の最新バージョンであるver 1.1.0に基づきます。今後変わる可能性もあります。

まとめ

本記事ではOpenTelemetry CollectorとUniversal Forwarderを統合するためのSplunk Add-On for OpenTelemetry Collectorをご紹介しました。

オブザーバビリティにはテレメトリーデータの取得、活用が必須です。本Add-onを使うことで、これまでSplunkが得意としていたログの取得に加え、OpenTelemetry Collectorによるトレース、メトリクス取得を一つのエージェントのように統合することができます。

オブザーバビリティにご関心のある方は無料トライアルを始めてみませんか?

是非ご連絡ください!

山村 悟史
Posted by

山村 悟史

データに翻弄されることなく価値を引き出すSplunkのData-to-Everythingの思想に共感し2020年Splunk Services Japan合同会社入社。現在は幅広いお客様へSplunkとは?を知って頂くためプリセールス活動として提案、検証、ワークショップなどを実施。
入社前は主にITサービスマネジメントプラットフォーム構築、データセンタ管理などを経験。

TAGS
Show All Tags
Show Less Tags