プライベートロケーション 🔗
プライベートロケーションとは、パブリックネットワークを超えて Splunk Synthetic Monitoring ソリューションを迅速かつ簡単に導入できるソフトウェアパッケージのことで、ファイアウォールの内外を問わず、あらゆる環境であらゆる社内 Web アプリケーションの Web パフォーマンスの不具合を発見、修正、防止できるようになります。プライベートロケーションでは、Splunk Synthetics Monitoring のユーザーは開発サイクルの早い段階で、一般公開されていない社内サイトやアプリケーションに対してテストを行うことができます。
顧客は、Splunk Synthetics Monitoring の Web インターフェースから新しいプライベートロケーションを作成し、ランナーを開いて、そのロケーションに割り当てられたチェックを実行することができます。
ランナーとは何ですか？ 🔗
ランナーとは、特定のプライベートロケーションからテストを実行するためにセットアップされたDockerコンテナのことです。一つのプライベートロケーションに一つ以上のランナーを持つことができます。
ロケーションは、特定のプライベートロケーションに割り当てられたテストのキューで構成されます。ランナーがキューから実行をピックアップするため、アクティブなランナーが多ければ多いほど、テストのキューの処理が速くなります。
Splunk Synthetic Monitoring は、指定された場所に何人のランナーがいるかを追跡しません。ランナーのフリートの管理はユーザーに任されています。
プライベートロケーションのユースケース 🔗
一般に公開されていないプライベートアプリケーションをテストします。
公開ステージングサイトを持たない本番前のアプリケーションをテストします。
Splunk Synthetic Monitoring がアプリケーションにアクセスする際の柔軟性が向上します。
Splunk Synthetic Monitoring のパブリックロケーションで現在サポートされていないロケーションからテストします。
要件 🔗
要件 |
説明 |
|---|---|
Docker |
|
許可リスト |
|
オペレーティングシステム |
Linux、Windows、または macOS |
ブラウザテストを実行する際に最適なパフォーマンスを得るには：
Linux
2.3GHzデュアルコアIntel Xeon（または同等の）プロセッサー
8 GB RAM、2コア
新しいプライベートロケーションをセットアップする 🔗
以下の手順に従って、新しいプライベートロケーションをセットアップしてください：
Splunk Synthetic Monitoring で、設定の歯車アイコン、Private locations の順に選択します。
+ Add を選択し、名前を追加します。
ガイドされたセットアップの手順に従って、ランナーをセットアップしてください。
プライベートロケーションを保存します。
プライベートロケーションIDでできること 🔗
各プライベートロケーションには、対応するプライベートロケーションIDがあります。このIDを使って、以下のことができます：
チャートまたはダッシュボードを作成する
プライベートロケーションごとにメトリクスを検索する
Splunk Synthetics Monitoring API とやり取りする場合は、プライベートロケーション ID を参照してください。
トークンを管理する 🔗
トークンの更新と管理は各自の責任で行ってください。トークンは1年間有効です。セキュリティを高めるために、Dockerでトークン用のシークレット環境変数を作成してください。最初のトークンの有効期限が切れる前に、2つ目のトークンを作成することを検討してください。トークンの有効期限切れは通知されません。
Dockerでの作業 🔗
ここでは、Dockerで作業するためのガイダンスをいくつか紹介します。
Dockerでのロギングを制限する 🔗
ロギングを制限するには、以下の手順に従ってください：
以下のようなディレクトリにファイルを作成します：
/etc/docker/daemon.json.ファイルに追加します：
{
"log-driver": "local",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
docker サービスを再起動します：
sudo systemctl docker.service restart.
Synthetics の証明書を追加する 🔗
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検証を無効にできます。
Configuring Proxy Settings for Private Locations 🔗
In environments where direct internet access is restricted, you can route synthetic test traffic through a proxy server by configuring the following environment variables:
HTTP_PROXY: Specifies the proxy server for HTTP traffic.Example:
export HTTP_PROXY="\http://proxy.example.com:8080"
HTTPS_PROXY: Specifies the proxy server for HTTPS traffic.Example:
export HTTPS_PROXY="\https://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=*****" quay.io/signalfx/splunk-synthetics-runner:latest -e NO_PROXY=".signalfx.com,.amazonaws.com" -e HTTPS_PROXY="https://172.17.0.1:1234" -e HTTP_PROXY="http://172.17.0.1:1234"
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.
Ensure that these variables are correctly configured to comply with your network policies. This setup allows the synthetic tests to communicate securely and efficiently in a controlled network environment.
When using 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(for localhost communication)localhost(for resolving local tests)
These addresses ensure that internal services and tests run correctly without routing through a proxy, preventing potential failures.
Merging HTTP_PROXY and http_proxy:
The system automatically handles both
HTTP_PROXYandhttp_proxyenvironment variables. If you define one of these, ensure the other is also set, or they will be automatically merged at start-up.
Dockerfile defaults:
By default, the runner will set 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.
プライベートロケーションの健全性を評価する 🔗
プライベートロケーションの健全性は3つの要因に左右されます：
要因 |
説明 |
解決策 |
|---|---|---|
アクティブなランナー |
少なくとも1つのランナーがアクティブにチェックインしています。 |
チェックインするランナーがない場合は、プライベートロケーションに新しいランナーを設定します。 |
テストで使用中 |
プライベートロケーションは現在、1つ以上のテストで使用されています。 |
プライベートロケーションを削除する必要がある場合は、まずすべてのテストから削除する必要があります。 |
キューをクリアする |
指定された場所のキューは定期的にクリアされており、バックアップされていません。 |
キューがバックアップされている場合は、プライベートロケーションに新しいランナーを追加します。 |
キューの長さとレイテンシをトラブルシューティングする 🔗
もしキューのレイテンシと長さの両方が時間の経過とともに増加するようであれば、パフォーマンスを向上させるためにランナーを追加します。
もし、キューのレイテンシが増加しても、キューの長さが増加しない場合は、以下のトラブルシューティング方法を試してみてください：
あるステップがテストの残りを遅らせていないかチェックします。
あなたのマシンでプライベートロケーションのランナーを実行するのに十分なリソースがあるかどうかを調査してください。
キュー内の最大実行回数は100,000回。
1時間以上前の実行はキューから削除されます。