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

SignalFX Smart Agent から Splunk Distribution of OpenTelemetry Collector への移行プロセスについて説明します。

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

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

  1. Collector を非本番働環境にデプロイする

  2. Collector のデプロイメントを検証する

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

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

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

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

1. Collector を非本番働環境にデプロイする

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

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

ナビゲーションバーで「データ管理」を選択します。

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

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

2. Collector のデプロイメントを検証する

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

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

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

  • メモリやCPU使用率などのプロセス・メトリクス

  • テレメトリ処理（メトリクス、スパン、ログ）のためのドロップ、失敗、成功メトリクス

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

OpenTelemetry Collector の組み込みダッシュボードグループを検索します。OpenTelemetry Collector の表示があるタイル

[Critical Monitoring] セクションに移動し、データがドロップされていないかをレビューして、データ損失やテレメトリデータの欠落が発生していないことを確認します。メトリクス、スパン、ログのグラフが表示されます。

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

いずれかのグラフがゼロ以上の値を示している場合は、データがドロップされているため、その原因を調査する必要があります。さらに詳しく診断するには、「Validate using logs」を参照してください。

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 インテグレーションからプルされたすべてのメトリクスの検索結果と、フィルタリングまたは除外できる関連メタデータが表示されます。

インテグレーションを見つけます。

例えば、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:address already in use」というエラーメッセージが表示される場合があります。このメッセージが表示された場合は、設定を変更して別のポートを使用します。

  • 特定のユースケースを示す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 を再起動します。環境のログを確認して、デプロイメントを検証します。

ログから問題を特定できない場合は、サポートにお問い合わせください。環境、プラットフォーム、設定、ログに関する情報をできるだけ多く収集します。サポートの問い合わせオプションについては、「サポートプログラム」を参照してください。

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 のパフォーマンスの問題をデバッグし、過負荷を防ぐのに役立ちます。Smart Agent 構成ファイルに以下を追加します。

monitors:
   - type: internal-metrics

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

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

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

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

Collector がトレースデータとメトリクスデータの両方を処理する場合は、サイジング時に両方を考慮する必要があります。たとえば、1 秒あたり 7.5K のスパンと 1 秒あたり 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 に取り込まれていることを確認したら、最初の手順として、Smart Agent を停止して単一の本番ホストまたは VM から アンインストールし、移行を開始します。各環境では、以下のコマンドに従ってください。

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をデプロイします。

__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____

_________ __ ______ _____________ _____ _________

_________ __ ___________ _________ ___ ____ _____ _____

  • ___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________

  • ____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______