プライベートロケーション 🔗
A private location is a software package that offers a quick and easy deployment of Splunk Synthetic Monitoring solutions beyond the public network so that you can find, fix, and prevent web performance defects on any internal web application, in any environment - whether inside or outside of your firewalls. Private locations allow Splunk Synthetics Monitoring users to test sooner in the development cycle and against internal sites or applications that aren’t available to the public.
顧客は、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 🔗
インターネットへの直接アクセスが制限されている環境では、以下の環境変数を設定することで、合成テストのトラフィックをプロキシサーバー経由でルーティングすることができます：
HTTP_PROXY: HTTPトラフィックのプロキシサーバーを指定します。例：
export HTTP_PROXY="\http://proxy.example.com:8080"
HTTPS_PROXY：HTTPSトラフィックのプロキシサーバーを指定します。例：
export HTTPS_PROXY="\https://proxy.example.com:8443"
NO_PROXY: プロキシをバイパスするドメインまたはIPアドレスをカンマ区切りで指定します。例：
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 と HTTPS_PROXY は、http://172.17.0.1:1234 のプロキシを経由してトラフィックをルーティングするように設定されています。
NO_PROXY は、ローカルアドレスと、.signalfx.comや.amazonaws.comのような特定のドメインのプロキシをバイパスするように設定されています。
これらの変数がネットワークポリシーに従って正しく設定されていることを確認してください。この設定により、制御されたネットワーク環境で、合成テストが安全かつ効率的に通信できるようになります。
ランナーを使用する場合、ブラウザベースのテストで問題が発生しないように、プロキシ設定を正しく行うことが重要です。環境を設定する際には、以下の手順に従ってください：
Ensure proper NO_PROXY setup:
NO_PROXYを設定する際には、必ず以下のアドレスを含めてください：127.0.0.1(localhost通信用)localhost(ローカルテストの解決用)
これらのアドレスは、プロキシを経由せずに内部サービスやテストが正しく実行されることを保証し、潜在的な障害を防ぎます。
HTTP_PROXYとhttp_proxyのマージ：
システムは
HTTP_PROXYとhttp_proxyの両方の環境変数を自動的に処理します。どちらか一方を定義した場合は、もう一方も設定されていることを確認してください。そのようにしない場合、起動時に自動的にマージされます。
Dockerfile defaults:
デフォルトでは、ランナーはDockerfileの
NO_PROXY変数に127.0.0.1を含めるように設定されます。NO_PROXYをオーバーライドする場合、127.0.0.1とlocalhostが存在することを確認する必要があります。存在しない場合、ブラウザテストが失敗する可能性があります。
プライベートロケーションの健全性を評価する 🔗
プライベートロケーションの健全性は3つの要因に左右されます：
要因 |
説明 |
解決策 |
|---|---|---|
アクティブなランナー |
少なくとも1つのランナーがアクティブにチェックインしています。 |
チェックインするランナーがない場合は、プライベートロケーションに新しいランナーを設定します。 |
テストで使用中 |
プライベートロケーションは現在、1つ以上のテストで使用されています。 |
プライベートロケーションを削除する必要がある場合は、まずすべてのテストから削除する必要があります。 |
キューをクリアする |
指定された場所のキューは定期的にクリアされており、バックアップされていません。 |
キューがバックアップされている場合は、プライベートロケーションに新しいランナーを追加します。 |
キューの長さとレイテンシをトラブルシューティングする 🔗
もしキューのレイテンシと長さの両方が時間の経過とともに増加するようであれば、パフォーマンスを向上させるためにランナーを追加します。
もし、キューのレイテンシが増加しても、キューの長さが増加しない場合は、以下のトラブルシューティング方法を試してみてください：
あるステップがテストの残りを遅らせていないかチェックします。
あなたのマシンでプライベートロケーションのランナーを実行するのに十分なリソースがあるかどうかを調査してください。
キュー内の最大実行回数は100,000回。
1時間以上前の実行はキューから削除されます。