プライベートロケーションのトラブルシューティング

New Relicの外形監視のプライベートロケーションの設定中に問題が発生した場合は、これらのトラブルシューティングのヒントを試して、一般的な外形監視 Job Manager の問題を特定してください。

仕事の需要と消費

現在のを特定し、ジョブマネージャーが業務量に対応できているかどうかを評価してください。

ジョブズは1分あたりのスループットを要求する。
```
SELECT rate(uniqueCount(jobId), 1 minute) FROM SyntheticRequest 
WHERE type != 'SIMPLE' FACET location SINCE 2 days ago
```

1分あたりのジョブ数の推移

SELECT rate(uniqueCount(jobId), 1 minute) FROM SyntheticRequest 
WHERE type != 'SIMPLE' FACET location SINCE 2 weeks ago TIMESERIES

キューの伸びを把握する。

SELECT derivative(checksPending, 1 minute) AS 'queue growth rate (per minute)' 
FROM SyntheticsPrivateLocationStatus WHERE name = 'YOUR_PRIVATE_LOCATION' SINCE 2 days ago TIMESERIES

消費率。

SELECT rate(uniqueCount(jobId), 1 minute) FROM SyntheticRequest 
WHERE type != 'SIMPLE' FACET location SINCE 2 weeks ago TIMESERIES

リソースを消費している障害のあるモニターをクリーンアップします。

SELECT 100*latest(minionJobsFailed)/latest(minionJobsReceived) AS 'job failure rate (%)' 
FROM SyntheticsPrivateMinion FACET minionLocation SINCE 2 weeks ago TIMESERIES MAX

メモリ使用量のトラブルシューティング

合成ジョブマネージャーごとに推奨されるメモリ割り当て:

Docker: Docker 合成ジョブマネージャーの CPU コアあたり 3.256 GiB
Kubernetes シンセティックジョブマネージャー (値は構成可能):
- ジョブマネージャーポッド用に 1.6 GiB
- ping ランタイムポッド用に 1.0 GiB
- Node.js API ランタイムポッドあたり 2 GiB
- Node.js ブラウザーランタイムポッドあたり 3 GiB
目標60%の最大メモリ使用率

現在の使用状況を確認するのに便利なクエリ。

ロケーションごとのメモリ使用量。

SELECT latest(minionPhysicalMemoryUsedPercentage) FROM SyntheticsPrivateMinion
FACET minionLocation SINCE 2 weeks ago TIMESERIES MAX

ホスト名ごとのメモリ使用量。

SELECT latest(minionPhysicalMemoryUsedPercentage) FROM SyntheticsPrivateMinion 
WHERE minionLocation = 'YOUR_PRIVATE_LOCATION' FACET minionHostname SINCE 2 weeks ago TIMESERIES MAX

Podmanでの共有メモリのサイズ設定により、Browserモニターがクラッシュします

Podmanベースのプライベートロケーションで実行されているBrowserモニターは、次のようなエラーで断続的に失敗する場合があります：

NoSuchSessionError: invalid session id: session deleted as the browser has closed the connection, disconnected: Unable to receive message from renderer

これは通常、スクリプトやネットワークの問題ではなく、共有メモリ（/dev/shm）の不足によって引き起こされるChromeレンダラープロセスのクラッシュです。Chromeはレンダリングにおいて共有メモリに大きく依存しており、特にログインフロー中にオリジン間でリダイレクトするページでは、Firefoxよりも早くメモリを消費する傾向があります—新しいオリジンごとに、同じ/dev/shmプールを利用する追加のレンダラープロセスが起動するためです。

Podmanのポッドが共有メモリを割り当てる方法

外形監視ジョブマネージャーが--podを使用してPodmanで実行される場合、そのポッドに参加しているすべてのコンテナは単一のIPCネームスペースを共有します。ポッド自体は、ポッドを作成したときのサイズ（デフォルトでは64 MiB）で/dev/shmを1回マウントします。そのサイズはpodman pod create時に設定され、後から個々のコンテナが変更または上書きすることはできません。

つまり、ポッドの/dev/shmマウントがコンテナごとの設定よりも優先されるため、コンテナがポッドに参加した後は、共有メモリの問題を解決するための以下の一般的な方法は機能しません：

...の代わりに podman run で --shm-size を渡しています podman pod create
-v /dev/shm:/dev/shm をオンにしたバインドマウント podman run

診断

何か変更を加える前に、以下のチェックを実行して原因を確認してください：

ポッドのcreateコマンドで--shm-sizeの値を確認してください：
bash
```
$podman pod inspect YOUR_POD_NAME --format '{{.CreateCommand}}'
```
これにより、ポッドを作成した正確なpodman pod createコマンドが出力されます。その出力から--shm-sizeを探してください。それが見つからない場合、設定しようとした内容に関係なく、ポッドはデフォルトの64 MiBで実行されています—これは、再作成する前に同じ名前の以前のポッドを完全に削除しなかった場合、またはその後ポッド内のコンテナを再起動しなかった場合に発生する可能性があります。
ブラウザランタイムコンテナのIDを確認してください：
bash
```
$podman ps --filter pod=YOUR_POD_NAME --filter ancestor=newrelic/synthetics-node-browser-runtime --format '{{.ID}}'
```
次のステップで、このIDをYOUR_BROWSER_RUNTIME_CONTAINER_IDとして使用してください。
理想的には失敗した実行中またはその直前に取得された、そのコンテナ内で実際に利用可能な共有メモリを確認してください：
bash
```
$podman exec YOUR_BROWSER_RUNTIME_CONTAINER_ID df -h /dev/shm
```
出力を設定したサイズと比較してください：
- Size が引き続き 64M を示している場合、サイズ変更は反映されていません。次のセクションの説明に従ってポッドを再作成してください。
- Sizeに設定した値が表示されている場合（たとえば、--shm-size=2gで作成されたポッドの場合は2.0G）、Used列とAvail列を確認してください。Availがゼロに近い場合、プールは枯渇しています—ポッド内のすべてのコンテナはこの同じ共有割り当てを利用するため、同じプライベートロケーションで複数のモニターが同時に実行されている場合は、--shm-sizeのサイズを大きくするか、同時に実行する数を減らしてください。Availにまだ余裕がある場合、プールはこの特定のクラッシュの原因ではないため、他の場所（たとえば、HEAVY_WORKER_MEMORY）を確認してください。

修理

既存のポッドを削除し、より大きな--shm-sizeで再作成してから、外形監視ジョブマネージャーを再起動して新しいポッドに再参加させます：

bash

$podman pod stop YOUR_POD_NAME
$podman pod rm YOUR_POD_NAME
$podman pod create --network slirp4netns --name YOUR_POD_NAME --add-host=podman.service:HOST_IP_ADDRESS --shm-size=2g

インストールドキュメントで使用されている値である2gから始めてください。ステップ3のチェックでプールがまだ枯渇していることが示された場合は、同時実行数を減らす前にさらに増やし（たとえば、4gに）、変更ごとにdf -h /dev/shmを再確認してください。

次に、Podmanの開始手順のpodman runコマンドを使用して、外形監視ジョブ・マネージャーを再度開始してください — ポッドを削除すると、その中で実行されていたコンテナも削除されます。

CPU使用率のトラブルシューティング

CPUの需要が高くなる可能性のある期間を特定する。

全体のCPU使用率

SELECT latest(minionProcessorsUsagePercentage) FROM SyntheticsPrivateMinion 
FACET minionLocation SINCE 2 weeks ago TIMESERIES MAX

指定した場所のCPU使用率。

SELECT latest(minionProcessorsUsagePercentage) FROM SyntheticsPrivateMinion 
WHERE minionLocation = 'YOUR_PRIVATE_LOCATION' FACET minionHostname SINCE 2 weeks ago TIMESERIES MAX

ネットワークトラブルシューティング

Network access is red:

外形監視ジョブマネージャーはNew Relicに対してパブリックネットワークへのアクセスを確認するチェックを行います。パブリックネットワークアクセスが利用できない場合、外形監視ジョブマネージャーのOverviewページのNetwork Accessアイコンが赤色になりますが、それ以外の場合、外形監視ジョブマネージャーは完全に機能します。これが想定される動作であれば、このエラーは無視しても問題ありません。

また、以下のようなログエントリが表示されることがあります。

2016-01-21 21:47:09,401 [dw-22 - GET /private-location/status] c.n.s.m.util.PrivateMinionUtils WARN Unable to detect Public Network Access trying to fetch https://newrelic.com/synthetics: java.net.ConnectException: Connection refused

New Relic access is red:

実行するジョブのリストを取得し、 New Relicユーザーインターフェースで表示できる結果を公開するには、外形監視 Job Manager がhttps://synthetics-horde.nr-data.netにアクセスできる必要があります。ファイアウォールルールで直接アクセスが許可されていない場合は、プロキシアクセスを設定できます。必要に応じて、DNS エンドポイントsynthetics-horde.nr-data.net 「許可」リストに追加します。

ホスト上で Docker コンテナを実行するとポートの競合が発生する

同じホスト上で複数のジョブマネージャコンテナを実行している場合、ポートの競合やリソースの競合が発生します。これを回避するには、各ジョブマネージャを別々のホストで実行するようにしてください。