Smart Agent からSplunk Distribution of the OpenTelemetry Collectorへの移行プロセス 🔗

注釈

このコンテンツは、Kubernetes、Linux、またはWindows環境でSignalFx SmartAgentを実行しており、テレメトリデータを収集するためにSplunk Distribution of OpenTelemetry Collectorに移行したい場合を想定しています。同じホスト上で両方のエージェントを同時に使用することはできないことに注意してください。

Smart AgentからCollectorに移行するには、次の手順を実行します：

Collector を非実稼働環境にデプロイする
Collector のデプロイを検証する
既存のSmart Agent 設定ファイルを探す
本番環境のリソース使用率（サイジング）の見積もり
更新された設定ファイルを使用して、Collectorを非本番環境にデプロイします。
更新された設定ファイルを使用して、Collectorを本番ホストにデプロイします。

1.Collector を非運用環境にデプロイします。 🔗

Collectorを本番環境以外の環境、たとえば開発用のホストやVM、ステージング用のKubernetesクラスターなどにデプロイします。この環境は、本番環境のコピーまたは同一である必要があります。

Splunk Observability Cloudのインスタンスに移動し、ナビゲーションバーで Data Management > Available integrations を選択します。Collectorをデプロイするプラットフォームを選択します。

ご使用のプラットフォームのセットアップガイドに従って Collector をデプロイします。

注釈

初期設定に関するガイダンスについては、ガイドセットアップ内のツールチップを参照してください。

2.Collector のデプロイメントを検証します。 🔗

以下の順序で Collector のデプロイを検証します。

ダッシュボードを使用して検証する 🔗

Collector の内蔵ダッシュボードを見ることから始めます：

メモリやCPU使用率などのプロセス・メトリクス
テレメトリ処理（メトリクス、スパン、ログ）のためのドロップ、失敗、成功メトリクス

ナビゲーションバーで Dashboards を選択します。

OpenTelemetry Collector を検索して、組み込みのダッシュボードグループにアクセスします。

Critical Monitoring セクションに移動し、データ・ロスがないか、テレメトリデータがドロップされていないかを確認します。メトリクス、スパン、およびログのチャートが表示されるはずです。

Critical Monitoringセクションに移動し、データが削除されていないか確認します。

チャートのいずれかがゼロ以上の値を示している場合、データがドロップされているので、その原因を調査する必要があります。さらに詳しく診断するには、ログを使用して検証するを参照してください。

zPagesを使用して検証する 🔗

Collector が正しく設定されていることを確認するには、zPages 拡張機能を有効にします。

これはデフォルトでポート55679上にローカルに公開され、以下の概要を示すために使用できます：

サービスおよびビルド、ランタイム情報 ( http://localhost:<port>/debug/servicez )
パイプラインの実行 ( http://localhost:<port>/debug/pipelinez )
エクステンション ( http://localhost:<port>/debug/extensionz )
機能ゲート ( http://localhost:<port>/debug/featurez )``
スパンとエラーサンプル ( http://localhost:<port>/debug/tracez )
RPC統計 ( http://localhost:<port>/debug/servicez/rpcz )

コンテナ環境では、このポートをローカルだけでなく、パブリック・インターフェイスに公開することができます。これは、コンフィギュレーションに以下の行を追加することで設定できます：

extensions:
   zpages:
      endpoint: 0.0.0.0:55679

メトリクスファインダーを使用して検証する 🔗

Metric Finder を使用して、メトリクスが特定のインテグレーションから入力されていることを確認します。ナビゲーション・バーで Metric Finder を選択します。

現在のリストの一部としてインテグレーションを見つけます。たとえば、KubernetesプラットフォームにCollectorをデプロイした場合は、Containersカテゴリまでスクロールして、Kubernetes を選択します。Kubernetes インテグレーションからデフォルトでプルインされているすべてのメトリクスと、フィルターリングまたは除外できる関連メタデータからの検索結果が表示されます。

例えば、container_cpu_utilization のように、特定のメトリクスを選択します。

選択した期間にわたる時系列データを表示するチャートとして、メトリクスを表示できるようになりました。

監視するように構成されたインテグレーションから（検索結果で、またはチャートに最近データポイントがない）メトリクスが見つからない場合は、ログを使用して検証するのセクションに進んでください。

注釈

メトリクスファインダーで検出されたメトリクスが、指定された期間チャートに表示されない場合、そのメトリクスはある時点で報告されています。指定した期間を変更して、特定のタイムスタンプのログを見やすくします。

ログを使用して検証する 🔗

ログを使用して、Collector のデプロイを検証できます。環境に応じて、次のコマンドを使用します：

Dockerの場合：

docker logs my-container >my-container.log

Journald の場合：

journalctl -u my-service >my-service.log

Kubernetesの場合：

kubectl describe pod my-pod kubectl logs my-pod otel-collector >my-pod-otel.log kubectl logs my-pod fluentd >my-pod-fluentd.log

以下のエラーがないかチェックします：

ポートの競合：「bind：すでに使用されているアドレス」というエラーメッセージが表示されることがあります。このメッセージが表示された場合は、別のポートを使用するように設定を変更してください。
特定のユースケースを示すHTTPエラーコード：
- 401（認証されていません）：設定されたアクセストークンまたはレルムが不正です。
- 404（見つかりません）：エンドポイントやパス（例えば/v1/log）のようなコンフィギュレーション・パラメーターが間違っている可能性が高く、ネットワーク/ファイアウォール/ポートの問題である可能性があります。
- 429（リクエストが多すぎる）：Orgは送信されるトラフィック量に対してプロビジョニングされていません。
- 503 (サービス利用不可): ステータスのページを確認してください。

特定のレシーバーがアプリケーションによって公開されたメトリクスをフェッチしていることを確認するには、次の例に示すように構成ファイルを更新します。

ロギング・レベルを debug に設定します：

service:
   telemetry:
      logs:
         level: debug

SignalFx エクスポーターを使用して、log_data_points を true に設定します：

exporters:
   signalfx:
      ...
      log_data_points: true
      ...

設定を更新したら、Collector を再起動します。。ご使用の環境のログを確認して、デプロイを確認します。

ログから問題を特定できない場合は、Splunk Observability Cloudに関するサポートを参照してください。環境、プラットフォーム、構成、ログに関する情報をできるだけ多く収集します。

1. 既存のSmart Agent設定ファイルを探す 🔗

Smart Agent は、agent.yamlファイルを編集することで設定できます。デフォルトでは、設定は、Linuxでは /etc/signalfx/agent.yaml 、Windowsでは \ProgramData\SignalFxAgent\agent.yaml にインストールされます。-config コマンドラインフラグを使用してSmart Agent のインストール中に場所を上書きすると、設定ファイルは指定した場所に保存されます。

以下はYAMLコンフィギュレーションファイルの例で、該当する場合はデフォルト値を使用します：

signalFxAccessToken: {"#from": "env:SIGNALFX_ACCESS_TOKEN"}
ingestUrl: https://ingest.us1.signalfx.com
apiUrl: https://api.us1.signalfx.com

bundleDir: /opt/my-smart-agent-bundle

procPath: /my_custom_proc
etcPath: /my_custom_etc
varPath: /my_custom_var
runPath: /my_custom_run
sysPath: /my_custom_sys

observers:
   - type: k8s-api

collectd:
   readThreads: 10
   writeQueueLimitHigh: 1000000
   writeQueueLimitLow: 600000
configDir: "/tmp/signalfx-agent/collectd"

monitors:
   - type: collectd/activemq
      discoveryRule: container_image =~ "activemq" && private_port == 1099
      extraDimensions:
         my_dimension: my_dimension_value
   - type: collectd/apache
      discoveryRule: container_image =~ "apache" && private_port == 80
   - type: postgresql
      discoveryRule: container_image =~ "postgresql" && private_port == 7199
      extraDimensions:
         my_other_dimension: my_other_dimension_value
   - type: processlist

4. 本番環境のリソース使用率（サイジング）の見積もり 🔗

Collectorと対応するVMまたはホストのサイズは、収集するテレメトリに基づいて設定する必要があります。Collectorには、1 CPUコアあたり次が必要です：

毎秒15,000スパン
毎秒20,000データポイント
毎秒10,000ログレコード

Smart Agent には、エージェントの内部状態に関するメトリクスを出力する内部メトリクス・モニターがあります。これは、Collectorのパフォーマンスの問題をデバッグしたり、Collectorが過負荷になっていないことを確認したりするのに便利です。Smart Agent構成ファイルに以下を追加します：

monitors:
   - type: internal-metrics

このSmart Agent構成ファイルへの追加は、Smart Agentを介して送信されるデータを確認するためにのみ必要であることに注意してください。更新された構成ファイルを使用して Collector を本番ホストにデプロイすると、Smart Agent 構成ファイルは削除されます。

設定ファイルの更新後、Smart Agent を再起動します。

その後、sfxagent.datapoints_sent と sfxagent.trace_spans_sent メトリクスを使用して、それぞれ Splunk Observability Cloud に送信されるデータポイントとスパンの数を推定できます。これらをダッシュボードにプロットし、ディメンションに基づいてフィルターリングすることで、クラスターまたはホストごとの合計を確認できます。

注釈

ログの推奨サイジングは、Collector と一緒に起動できるtd-agent（Fluentd）も考慮しています。

Collectorがトレースデータとメトリクスデータの両方を処理する場合は、サイジング時に両方を考慮する必要があります。たとえば、7.5Kスパン/秒と10Kデータポイント/秒の場合、1 CPUコアが必要になります。

1 CPU に対して 2 GB のメモリを使用します。デフォルトでは、Collector は 512 MB のメモリを使用するように設定されています。

以下の例に示すように、すべての Collector インスタンスで memory_limiter プロセッサーを設定します：

processors:
   memory_limiter:
      check_interval:
      limit_mib:
      spike_limit_mib:

注釈

memory_limiter プロセッサーを、レシーバーの直後の、パイプラインの最初のプロセッサーとして定義します。

5. 更新された設定ファイルを使用して、Collectorを非本番環境にデプロイする 🔗

必要な更新と構成ファイルの変換を完了し、更新されたファイルを使用して非本番環境でCollectorを再起動します。

Collector の再起動 🔗

Linuxの場合：

sudo systemctl restart splunk-otel-collector

Windowsの場合：

Stop-Service splunk-otel-collector
Start-Service splunk-otel-collector

Kubernetesの場合：

helm upgrade my-splunk-otel-collector --values my_values.yaml splunk-otel-collector-chart/splunk-otel-collector

Collector が正常に再起動されたら、デプロイを検証します。データが収集されていること、および更新された構成ファイルにエラーがないことを確認します。

6. 更新された設定ファイルを使用して、Collectorを本番ホストにデプロイする 🔗

Collector を非運用環境に正常にデプロイし、データが期待通りに Splunk Observability Cloud に取り込まれていることを確認したら、最初のステップとして、単一の運用ホストまたは VM から Smart Agent を停止してアンインストールし、移行を開始します。それぞれの環境について、以下のコマンドに従ってください：

Linuxの場合：

Ubuntuを含むDebianベースのディストリビューションでは、以下のコマンドを実行します：

sudo dpkg --remove signalfx-agent

Red Hat、CentOS、その他のRPMベースのインストールでは、以下のコマンドを実行します：

sudo rpm -e signalfx-agent

Windowsの場合（インストーラー）：

コントロールパネルの Programs and Features からSmart Agent をアンインストールします。

Windowsの場合（ZIPファイル）：

以下のPowerShellコマンドを実行して、signalfx-agent サービスを停止し、アンインストールします：

SignalFxAgent\bin\signalfx-agent.exe -service "stop"
SignalFxAgent\bin\signalfx-agent.exe -service "uninstall"

Smart Agentをアンインストールした後、更新された設定ファイルを使用してCollectorを本番ホストにデプロイし、Collectorのデプロイを検証します。

1台のホストで確認した後、残りのホストに同じ設定でCollectorをデプロイします。

Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。

Splunk Observability Cloudをご利用のお客様

Splunk サポートポータルでケースを送信する
Splunkサポートに連絡する

見込み客および無料トライアルユーザー様

Splunk Answers のコミュニティサポートで質問し、回答を得る
Join the Splunk #observability user group Slack channel to communicate with customers, partners, and Splunk employees worldwide. To join, see Chat groups in the Get Started with Splunk Community manual.

このページは 2025年02月11日に最終更新されました。

Related Topics