プライベートロケーション 🔗
A private location is a name you create in Splunk Synthetic Monitoring to represent a custom location from which you can run synthetic tests. The name you give to a private location allows you to specify that name in a synthetic test’s Locations field. To run synthetic tests from private locations, you must also set up one or more private runners within the private location to do the actual communication with your test targets and with Splunk Synthetic Monitoring.
プライベートロケーションのユースケース 🔗
Private locations provide a way for you to find, fix, and prevent performance problems in internal applications in any environment, inside or outside of your firewalls. You can use private locations to run tests earlier in your development cycle against internal sites or applications that aren’t available to the public. You can also use private locations to test public endpoints from locations that aren’t included in the list of Splunk Synthetic Monitoring public locations.
To summarize, here are sample use cases for private locations:
一般に公開されていないプライベートアプリケーションをテストします。
公開ステージングサイトを持たない本番前のアプリケーションをテストします。
Gain a higher level of flexibility by giving Splunk Synthetic Monitoring access to applications.
Splunk Synthetic Monitoring のパブリックロケーションで現在サポートされていないロケーションからテストします。
新しいプライベートロケーションをセットアップする 🔗
以下の手順に従って、新しいプライベートロケーションをセットアップしてください：
Splunk Synthetic Monitoring で、設定の歯車アイコン、Private locations の順に選択します。
+ Add を選択し、名前を追加します。
Follow the steps in the guided setup to set up one or more private runners for that private location.
プライベートロケーションを保存します。
プライベートロケーションIDでできること 🔗
各プライベートロケーションには、対応するプライベートロケーションIDがあります。このIDを使って、以下のことができます：
チャートまたはダッシュボードを作成する
プライベートロケーションごとにメトリクスを検索する
Splunk Synthetics Monitoring API とやり取りする場合は、プライベートロケーション ID を参照してください。
トークンを管理する 🔗
トークンの更新と管理は各自の責任で行ってください。トークンは1年間有効です。セキュリティを高めるために、Dockerでトークン用のシークレット環境変数を作成してください。最初のトークンの有効期限が切れる前に、2つ目のトークンを作成することを検討してください。トークンの有効期限切れは通知されません。
Assess the health of a private location 🔗
プライベートロケーションの健全性は3つの要因に左右されます：
要因 |
説明 |
解決策 |
|---|---|---|
アクティブなランナー |
少なくとも1つのランナーがアクティブにチェックインしています。 |
チェックインするランナーがない場合は、プライベートロケーションに新しいランナーを設定します。 |
テストで使用中 |
プライベートロケーションは現在、1つ以上のテストで使用されています。 |
プライベートロケーションを削除する必要がある場合は、まずすべてのテストから削除する必要があります。 |
キューをクリアする |
指定された場所のキューは定期的にクリアされており、バックアップされていません。 |
キューがバックアップされている場合は、プライベートロケーションに新しいランナーを追加します。 |
キューの長さとレイテンシをトラブルシューティングする 🔗
もしキューのレイテンシと長さの両方が時間の経過とともに増加するようであれば、パフォーマンスを向上させるためにランナーを追加します。
If your queue latency increases but your queue length doesn’t, try these troubleshooting methods:
Check to see if a step is delaying the rest of the test.
あなたのマシンでプライベートロケーションのランナーを実行するのに十分なリソースがあるかどうかを調査してください。
キュー内の最大実行回数は100,000回。
1時間以上前の実行はキューから削除されます。
Private runners 🔗
A private runner queries Splunk Synthetic Monitoring for tests configured to run in its inherent private location, performs the test’s steps on your private target, and reports the results back to Splunk Synthetic Monitoring. Because a private runner must have access to your private target, it is a Docker image which you deploy on your own infrastructure, within your own internal network. See プライベートロケーション.
If you deploy multiple private runners on behalf of a single private location, they can process that location’s test queue faster. Splunk Synthetic Monitoring doesn’t track how many private runners you’ve deployed for a given private location. It’s up to you to manage your own fleet of private runners.
Requirements for private runners 🔗
要件 |
説明 |
|---|---|
Docker |
|
許可リスト |
|
オペレーティングシステム |
Linux、Windows、または macOS |
For optimal performance when running browser tests:
Linux
2.3GHzデュアルコアIntel Xeon（または同等の）プロセッサー
8 GB RAM、2コア
Dockerでの作業 🔗
Follow these steps to limit logging in Docker:
以下のようなディレクトリにファイルを作成します：
/etc/docker/daemon.json.ファイルに追加します：
{
"log-driver": "local",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
docker サービスを再起動します：
sudo systemctl docker.service restart.
Add certificates 🔗
Splunk Synthetic Monitoring supports injecting custom root CA certificates for Uptime tests running from your private locations. Client keys and certificates aren’t supported at this time.
ホストマシン上に
certsというフォルダを作成し、その中に CA 証明書（CRT 形式）を配置します。コンテナ
(-v ./certs:/usr/local/share/ca-certificates/my_certs/)にボリュームとしてcertsフォルダを追加します。コンテナ起動時に使用するコマンドを変更し、エージェントバイナリ
(bash -c "sudo update-ca-certificates && bundle exec bin/start_runner)を起動する前に CA 証明書キャッシュを更新します。
例えば、あるコマンドを自分の環境に合わせて修正した後のイメージは以下のとおりです：
docker run -e "RUNNER_TOKEN=<insert-token>" --volume=`pwd`/certs:/usr/local/share/ca-certificates/my_certs/ quay.io/signalfx/splunk-synthetics-runner:latest bash -c "sudo update-ca-certificates && bundle exec bin/start_runner"
注釈
カスタムルート CA 証明書は、ブラウザテストではサポートされていません。ブラウザテストでは、正確なテストのために SSL/TLS 検証が必要です。必要に応じて、ブラウザテストのSSL/TLS検証を無効にできます。
Configure proxy settings for a private runner 🔗
インターネットへの直接アクセスが制限されている環境では、以下の環境変数を設定することで、合成テストのトラフィックをプロキシサーバー経由でルーティングすることができます：
http_proxy: Specifies the proxy server for HTTP traffic.Example:
export http_proxy="http://proxy.example.com:8443"
https_proxy: Specifies the proxy server for HTTPS traffic.Example:
export https_proxy="http://proxy.example.com:8443"
no_proxy: Specifies a comma-separated list of domains or IP addresses that should bypass the proxy.Example:
export no_proxy="localhost,127.0.0.1,.internal-domain.com"
例えば、あるコマンドを自分の環境に合わせて修正した後のイメージは以下のとおりです：
docker run --cap-add NET_ADMIN -e "RUNNER_TOKEN=*****" -e "no_proxy=.signalfx.com,.amazonaws.com,127.0.0.1,localhost" -e "https_proxy=http://172.17.0.1:1234" -e "http_proxy=http://172.17.0.1:1234" quay.io/signalfx/splunk-synthetics-runner:latest
In this example:
http_proxy and https_proxy are set to route traffic through a proxy at http://172.17.0.1:1234.
no_proxy is configured to bypass the proxy for local addresses and specific domains like .signalfx.com and .amazonaws.com.
これらの変数がネットワークポリシーに従って正しく設定されていることを確認してください。この設定により、制御されたネットワーク環境で、合成テストが安全かつ効率的に通信できるようになります。
When using a private runner, it’s important to correctly configure the proxy settings to avoid issues with browser-based tests. The following steps should be followed when setting up their environment:
Ensure proper no_proxy setup:
When configuring
no_proxyalways include the following addresses:127.0.0.1(localhost通信用)localhost(ローカルテストの解決用)
これらのアドレスは、プロキシを経由せずに内部サービスやテストが正しく実行されることを保証し、潜在的な障害を防ぎます。
Dockerfile defaults:
By default, the private runner sets the
no_proxyvariable in the Dockerfile to include127.0.0.1. If you overrideno_proxy, you must ensure that127.0.0.1andlocalhostare still present, or browser tests may fail.
注釈
Lower case variable names take precedence and are best practice.