Smart Agent からSplunk Distribution of the OpenTelemetry Collectorへの移行プロセス 🔗
注釈
このコンテンツは、Kubernetes、Linux、または Windows 環境で SignalFx SmartAgent を実行しており、テレメトリデータを収集するために Splunk Distribution of OpenTelemetry Collector に移行したい場合を想定しています。同じホスト上で両方のエージェントを同時に使用することはできないことに注意してください。これについての詳細は、マッピングサービスと移行影響レポート のセクション 相反するセマンティクス を参照してください。
Smart AgentからCollectorに移行するには、次の手順を実行します：
1.Collector を非運用環境にデプロイします。 🔗
Collectorを本番環境以外の環境、たとえば開発用のホストやVM、ステージング用のKubernetesクラスターなどにデプロイします。この環境は、本番環境のコピーまたは同一である必要があります。
Navigate to your instance of Splunk Observability Cloud and select in the navigation bar. Choose the platform you want to deploy the Collector to.
ご使用のプラットフォームのセットアップガイドに従って Collector をデプロイします。
注釈
初期設定に関するガイダンスについては、ガイドセットアップ内のツールチップを参照してください。
2.Collector のデプロイメントを検証します。 🔗
以下の順序で Collector のデプロイを検証します。
ダッシュボードを使用して検証する 🔗
Collector の内蔵ダッシュボードを見ることから始めます：
メモリやCPU使用率などのプロセス・メトリクス
テレメトリ処理（メトリクス、スパン、ログ）のためのドロップ、失敗、成功メトリクス
ナビゲーションバーで を選択します。
OpenTelemetry Collector を検索して、組み込みのダッシュボードグループにアクセスします。
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 を使用して、メトリクスが特定のインテグレーションから入力されていることを確認します。ナビゲーション・バーで を選択します。
現在のリストの一部としてインテグレーションを見つけます。たとえば、KubernetesプラットフォームにCollectorをデプロイした場合は、Containersカテゴリまでスクロールして、 を選択します。Kubernetes インテグレーションからデフォルトでプルインされているすべてのメトリクスと、フィルターリングまたは除外できる関連メタデータからの検索結果が表示されます。
例えば、 のように、特定のメトリクスを選択します。
選択した期間にわたる時系列データを表示するチャートとして、メトリクスを表示できるようになりました。
監視するように構成されたインテグレーションから（検索結果で、またはチャートに最近データポイントがない）メトリクスが見つからない場合は、ログを使用して検証する のセクションに進んでください。
注釈
メトリクスファインダーで検出されたメトリクスが、指定された期間チャートに表示されない場合、そのメトリクスはある時点で報告されています。指定した期間を変更して、特定のタイムスタンプのログを見やすくします。
ログを使用して検証する 🔗
ログを使用して、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(サービスが利用できない)：Log Observerを使っている場合、これは429と同じである(HECv1が応答する方法だから)。そうでなければ、ステータスページを確認してください。
特定のレシーバーがアプリケーションによって公開されたメトリクスをフェッチしていることを確認するには、次の例に示すように構成ファイルを更新します。
ロギング・レベルを debug に設定します：
service:
telemetry:
logs:
level: debug
SignalFx エクスポーターを使用して、log_data_points を true に設定します：
exporters:
signalfx:
...
log_data_points: true
...
設定を更新したら、Collector を再起動します。 。ご使用の環境のログを確認して、デプロイを確認します。
ログから問題を特定できない場合は、Splunk Observability Cloudに関するサポート を参照してください。環境、プラットフォーム、構成、ログに関する情報をできるだけ多く収集します。
3.既存の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. Estimate resource utilization (sizing) for the production environment 🔗
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. Deploy the Collector to the non-production environment using the updated configuration file 🔗
必要な更新と構成ファイルの変換を完了し、更新されたファイルを使用して非本番環境で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. Deploy the Collector to a production host using the updated configuration file 🔗
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の場合（インストーラー）：
コントロールパネルの から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 サポートポータル でケースを送信する
Contact Splunk Support .
見込み客および無料トライアルユーザー様
Splunk Answers のコミュニティサポートで質問し、回答を得る
Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。