実際にテレメトリーデータを送信してみる
例として、とあるAWS EC2上のアプリサーバーにOTel Collectorをインストールし各種テレメトリーデータを送信したいとします。
Receiver：以下を取得します。
- トレース：OTel SDKからOTLPで送信されるトレースの受信
- メトリクス：OSのCPU、メモリなどの収集
- ログ：アプリログの収集
そのうえで、
- Extension：zPageによりOTel Collectorの処理統計も入手できるようにします
- Processor：メモリリミッターとバッチ化およびEC2情報の付与
-
Exporter：
- トレース：Zipkinと別のバックエンド（現在Zipkinを使用しており、別のオブザーバビリティツールを検証したいようなシナリオです）
- メトリクス：バックエンド
- ログ：Splunk
というシナリオで、OTel Collectorの設定をしてみます。
receivers:
otlp:
protocols:
grpc:
http:
hostmetrics:
collection_interval: 10s
scrapers:
cpu:
disk:
filesystem:
memory:
network:
load:
paging:
processes:
process:
filelog/app_log:
include: [ /var/log/myservice/*.json ]
operators:
- type: json_parser
timestamp:
parse_from: attributes.time
layout: '%Y-%m-%d %H:%M:%S'
processors:
batch:
memory_limiter:
check_interval: 1s
limit_mib: 4000
spike_limit_mib: 800
resourcedetection:
detectors: ["ec2"]
exporters:
zipkin:
endpoint: "https://some.url:9411/api/v2/spans"
otlphttp:
endpoint: https://example.com:4318
splunk_hec:
token: "00000000-0000-0000-0000-0000000000000"
endpoint: "https://splunk:8088/services/collector"
extensions:
zpages:
service:
extensions:
- zpages
pipelines:
traces:
receivers:
- otlp
processors:
- memory_limiter
- batch
- resourcedetection
exporters:
- zipkin
- otlphttp
metrics:
receivers:
- hostmetrics
processors:
- memory_limiter
- batch
- resourcedetection
exporters:
- otlphttp
logs:
receivers:
- filelog/app_log
processors:
- memory_limiter
- batch
- resourcedetection
exporters:
- splunk_hec
このように構成としてはシンプルです。
`receivers`、`processors`、`exporters`で各種コンポーネントの個別の定義を行っておきます。
多くはデフォルト値を持っており、Batch Processorのように、名前を定義するだけで済むものもあります。どのようなオプションが使用できるかは各コンポーネントのページを参照してください。
また、「filelog/app_log」のように/の後に任意の名前を付けることができます。
そして`service.pipelines`で`traces`、`metrics`、`logs`のパイプラインを定義し、その中で定義済みのコンポーネントを呼び出しています。
パイプラインで`receivers`、`processors`、`exporters`は配列で定義している通り任意の数を取ることができます。`processors`は任意、`receivers`と`exporters`は必須です。
Extentionは`service.extensions`で呼び出します。
パイプラインの可視化
定義情報が増えてくるとパイプラインの状況であったり、設定不備が追いづらくなります。
その時にOTelBinというサイトが便利です。
例えば上記の設定を可視化してみるとこうなります。
最終的なパイプラインの状況が図示されました。
もし設定に問題があればそれも警告してくれます。
各コンポーネントのステータスについて
`service.pipelines`の`traces`、`metrics`、`logs`で呼び出せるreceiverは何かと疑問に思うかもしれません。
ここでgithub上で見ることができる各コンポーネントのステータス情報についてお話ししたいと思います。
Filelog Receiverを例にとりましょう。
特に重要な情報は`Stability`と`Distributions`です。
`Stability`：`beta: logs`という文言があり、これはlogsパイプラインで使用でき、Stabilityとしてはbetaであることを示しています。
Alphaは下位互換性の保証がないため本番環境での使用は推奨されません。
Betaになると互換性を守る必要があるためある程度は本番環境で使用でき、StableになるといわゆるGeneral Availability（一般公開）となります。
`Distributions`：これについては、これからお話ししましょう。OpenTelemetry Collectorの二種類のレポジトリ
OTel CollectorにはCoreとDistribという二種類のレポジトリがあります。
Core
Coreはその名の通り、OTel Collectorのコアとなる機能が提供されています。
Receiverで言えばOTLP、Processorはメモリリミッターやバッチ、ExporterはOTLPやDebugです。
機能は安定している一方、機能数は限定されています。
Contrib
ContribはCoreを全て含み、その他の追加機能を含みます。実質的にはこちらを利用します。
カスタム
Contribは試してみるには良いですが、不要コンポーネントが多くフルパッケージではリソースの無駄遣いになります。またセキュリティ面でもアタックサーフェスを増やすことにもなります。
そこでOpenTelemetry Collector builder (OCB) というカスタムのパッケージを作成する機能が提供されており、本番環境にデプロイする際はこれを使用し必要なコンポーネントのみに絞ることが推奨されています。
または既存のコンポーネントに必要とするものがない場合、自身でGo言語で開発することもできます。
各ベンダーのDistribution
各バックエンドのベンダーがカスタマイズしたOTel Collectorを提供している場合があります。
例えばAWSはAWS Distro for OpenTelemetry、SplunkはSplunk Distribution of the OpenTelemetry Collectorを提供しています。
これらはCore、Contribをベースとし、以下の特徴があります。
- コンポーネントが精査されている
- 追加機能が付与されている場合がある
- 設定が標準設定されている
特に設定について、各ベンダーによる「ベストプラクティス」が最初から定義されていることが多いです。
上記でコンポーネントを見てきましたが、特にProcessorについて何を設定すれば良いか、一から調査し考えることは難しいかと思います。その場合にベストプラクティスを使用できるのは大きなポイントかと思います。
ベンダーからDistributionが提供されている場合、特に理由がない限りはそれを使用するのが良いでしょう。
OpenTelemetry Collectorのインストール方法
最後に具体的なインストール方法を見たいと思います。
対応OS・アーキテクチャ
Docker、Linux、Windows、Mac、Kubernetesがサポートされています。
対応OSやCPUアーキテクチャと、各インストール方法の詳細を見てみましょう。
注意点としてContribを使用する場合は「contrib」を含むファイルを取得してください。
リリースページは以下です。
Contribパッケージのインストールおよび設定例を以下に示します。
docker pull otel/opentelemetry-collector-contrib:<バージョン> docker run -v $(pwd)/config.yaml:/etc/otelcol-contrib/config.yaml otel/opentelemetry-collector-contrib:<バージョン>
sudo yum update sudo yum -y install wget systemctl wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/<バージョン>/otelcol-contrib_<バージョン>_linux_.rpm sudo rpm -ivh otelcol-contrib_<バージョン>_linux_ .rpm
設定ファイルは
`/etc/otelcol/otelcol-contrib.conf`
設定変更後、再読み込みしステータスを確認。
sudo systemctl restart otelcol-contrib sudo systemctl status otelcol-contrib
ホスト数が多い場合はAnsibleやPuppetなどによるデプロイ自動化を是非検討しましょう。
Kubernetesへのデプロイ
KubernetesへはHelm Chartでデプロイすることができます。
各Node、Pod、Containerのテレメトリーデータを取得するためのDaemonsetとClusterのデータを取得するためのDeploymentの二種類が含まれます。
KubernetesのAttribute（NodeやPod名など）を取得するためのProcessorなどが存在しています。
上記ページに記載の通りPresetをenabledにすることをおすすめします。
または最近はOperatorが開発されています。
こちらを使用することの最大のメリットとしては、Container上のアプリへの自動計装が非常に簡単に可能になるという点です（計装については次回解説します）。
例えば、自動計装対象のPodのAnnotationに「instrumentation.opentelemetry.io/inject-java: "true"」のように指定するだけで自動計装が完了します。
一方、Operatorを使用せずに自動計装を行う場合はDockerfileでの定義が必要になります。
まとめ
今回はOpenTelemetryフレームワークの内、OpenTelemetry Collectorについて解説しました。
これでシステム全体でテレメトリーデータの取り扱いを統一しつつも任意のバックエンドに送信することができるようになりました。
本記事では一通り基礎的な知識をお伝えしましたが、紹介しきれない機能も多くありますので、是非公式ページも参照してください。
次回はついにアプリからトレースを取得するための計装方法について解説します。
お楽しみに！
