分析バックエンドに問題がなければ、Collectorの動作を確認する
分析バックエンドを見ても、テレメトリーデータの到着が確認できませんでした。次は一つ上の上流、OpenTelemetry Collector（以下、Collector）の状況を調べてみましょう。
Collectorには、Collector自身の内部テレメトリーをエクスポートすることができ、ログはもちろん、メトリクスとトレース（トレースは実験段階）、プロファイルを出力できます。
公式ドキュメント：内部テレメトリー
メトリクスを見る
Collectorはデフォルトで、Prometheus形式でメトリクスをエクスポートしています。それをスクレイプし、分析バックエンドに送ることで、遠隔測定（テレメトリー）が簡単に実現できます。ここでは、prometheus/internalというレシーバーを定義し、そのメトリクスをmetrics/internalというパイプラインを通じてバックエンドに送るように設定してみましょう。
receivers:
prometheus/internal:
config:
scrape_configs:
- job_name: 'otel-collector'
scrape_interval: 10s
static_configs:
- targets: ["localhost:8888"]
service:
pipelines:
metrics/internal:
receivers: [prometheus/internal]
processors: [memory_limiter, batch, resourcedetection]
exporters: [signalfx]
これにより、Collector自身が公開しているメトリクスを10秒ごとにスクレイプし、分析バックエンド（今回の場合はsignafx）に送っています。どのようなメトリクスを送っているかは、公式ドキュメントで確認できますが、以下はよく使われるメトリクスの例です。
-
otelcol_process_uptime：対象のインスタンス（VMもしくはノード）のCollectorが起動しているかがわかります。このメトリクスが見つからない場合には、Collectorが起動していないか、もしくはメトリクスのエクスポートに問題があります。 -
otelcol_exporter_sent_spansなど：対象のエクスポーターがテレメトリーを送信できているかがわかります。このメトリクスに反応がない場合には、レシーバーがデータを受信していない、パイプラインがうまく設定できていない、Collectorとバックエンドの間で何らかのトラブルがある、などがわかります。 -
otelcol_exporter_send_failed_spansなど：エクスポーターで、エラーやドロップが発生しているかがわかります。このメトリクスに反応がある場合、送信先（URLなど）や認証トークンなどが正しく設定されているか、もしくはバックエンド側のキャパシティやライセンス上の問題がないかを確認することになります。 -
otelcol_receiver_accepted_spansなど：対象のレシーバーは受信できているかがかわります。このメトリクスに反応がない場合、SDKなどのテレメトリーデータ生成元がデータを送っているか、レシーバーの設定が意図通り設定されているかを確認しましょう。
Collectorを起動したのにこれらのメトリクスが見つからなかったり、メトリクスの値に何らかの問題がある場合には、Collectorのログを確認したり、もしくはSDK側の状況を調査しにいくことになります。
どのようなメトリクスを監視すればいいかは、公式ドキュメントにもまとめられていますので、確認してみてください。
ログを見る
Collector自身メトリクスを確認したところ、何かがうまく動いていないことがわかりました。その場合は、Collectorのログを確認していきましょう。Linuxホストで運用している場合、インストール方法にもよりますが、大抵はjournalctlコマンドでサービスのログを検索できるでしょう（-uオプションの値は状況によって調整してください）。
sudo journalctl -u otelcol
別のデプロイ方法、たとえばKubernetesにdaemonsetとしてデプロイしている場合は、当該ポッドのログを見てみましょう。
デフォルトではinfoレベルのログが出力されており、サービスの開始や各コンポーネント（レシーバー、プロセッサー、エクスポーターなど）が起動した旨のログが残されます。このとき、設定したオプションの値も記録されるので、何か心配なことがあれば、設定ファイルと合わせてログも確認するようにしましょう。
Dec 10 09:57:42 show-no-config-i-02e023fb1ae7edd98 systemd[1]: Started Splunk OpenTelemetry Collector.
Dec 10 09:57:44 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: 2024/12/10 09:57:44 settings.go:477: Set config to /etc/otel/collector/agent_config.yaml
Dec 10 09:57:44 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: 2024-12-10T09:57:44.844Z info telemetry/metrics.go:70 Serving metrics {"address": "127.0.0.1:8888", "metrics level": "Normal"}
Dec 10 09:57:44 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: 2024-12-10T09:57:44.845Z info memorylimiter@v0.113.0/memorylimiter.go:75 Memory limiter configured {"kind": "processor", "name": "memory_limiter", "pipeline": "logs/entities", "limit_mib": 460, "spike_limit_mib": 92>
Dec 10 09:57:44 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: 2024-12-10T09:57:44.847Z info signalfxexporter@v0.113.0/factory.go:101 Correlation tracking enabled {"kind": "exporter", "data_type": "traces", "name": "signalfx", "endpoint": "https://api.us1.signalfx.com"}
Dec 10 09:57:44 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: 2024-12-10T09:57:44.848Z info service@v0.113.0/service.go:238 Starting otelcol... {"Version": "v0.113.0", "NumCPU": 8}
…
また、たとえばエクスポートできない場合などは、その旨のエラーログが残されます。その際は、エクスポート先の設定が正しいか、ログと設定ファイルを見比べながら確認していきましょう。以下の例では、メトリクスがエクスポートできなくなっていることを示しています。401 Unauthorizedのメッセージを信じるのであれば、認証トークンが無効化されているかもしれません。
Dec 10 10:10:45 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: 2024-12-10T10:10:45.107Z error internal/queue_sender.go:92 Exporting failed. Dropping data. {"kind": "exporter", "data_type": "metrics", "name": "signalfx", "error": "not retryable error: Permanent error: \"HTTP/2.0 401 Unauthorized\\n …
Dec 10 10:10:45 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: go.opentelemetry.io/collector/exporter/exporterhelper/internal.NewQueueSender.func1
Dec 10 10:10:45 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: go.opentelemetry.io/collector/exporter@v0.113.0/exporterhelper/internal/queue_sender.go:92
Dec 10 10:10:45 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: go.opentelemetry.io/collector/exporter/internal/queue.(*Consumers[...]).Start.func1
Dec 10 10:10:45 show-no-config-i-02e023fb1ae7edd98 otelcol[159874]: go.opentelemetry.io/collector/exporter@v0.113.0/internal/queue/consumers.go:43
実際のテレメトリーデータが実際にどう処理されているかを知りたい知りたい場合には、debugエクスポーターを使うこともできます。
receivers:
zipkin:
exporters:
debug:
service:
pipelines:
traces:
receivers: [zipkin]
processors: []
exporters: [debug]
注意：自己監視の落とし穴
Collectorのテレメトリーはとても役に立つものなので、全てのテレメトリーを収集して分析バックエンドに送って、一元管理したくなるかもしれません。上記の例では、Collectorが8888ポートで公開しているメトリクスをprometheus/internalレシーバーでスクレイピングし、ホストメトリクスなどとは別のパイプラインを通じてSaaSにエクスポートしています。
同様のことをログでも実現したくなるかもしれませんが、おすすめはできません。
Collectorのログを送るパイプラインを作ると、おそらく、通常時は期待通りに動くでしょう。Collectorや各コンポーネントが動作していることがわかります。しかし、なんらかの影響で何かが壊れた場合、たとえばエクスポート先のサービスのキャパシティが不足してログを受け付けなくなった場合、その旨のエラーログが出力されます。そのエラーログをエクスポートしようとして、再び失敗し、さらにエラーログが出力され、それをエクスポートしようとして……といった、テレメトリーのループが起こり、エクスポート先のバックエンドに負荷をかけたり、Collectorにかかるリソースを過剰に消費したりします。この懸念は、スパンを送る場合でも同様です。
メトリクスの場合は、最大でも上記のprometheus/internalレシーバーに関するメトリクスのみが追加されるため、メトリクスの処理と送信に与える影響は0ではありませんが、全体に与える影響は限定されます。心配な場合には、負荷試験を実施するのがおすすめです。
別の案として、Collectorを監視するCollectorを別に用意するという手もあるかもしれません。そうすると、プロダクション環境でのCollectorの動作をより厳密に監視することができます。
