合成ジョブ マネージャーをインストールし た後、いくつかの方法でそのメンテナンスと監視を追跡できます。
HTTP を使用して合成ジョブ マネージャーのステータスを確認する HTTP を使用して実行中の合成ジョブ マネージャーに接続することは、正常で動作しているかどうかを確認する最も簡単な方法です。コンテナーはポート8080
を公開します。次のエンドポイントで合成ジョブ マネージャーを確認できます。
:8080/status/check
: ミニオンが実行する内部ヘルス チェックの詳細を提供します。HTTP 200
は、ステータスが正常であることを意味します。プライベートな場所でより多くの合成ジョブ マネージャーが必要かどうかを確認する プライベート ロケーションに複数の監視チェックがキューに入れられており、遅延が発生している場合は、監視チェックを実行するために使用可能な合成ジョブ マネージャーがさらに必要になる場合があります。Kubernetes では、これは、より多くの ping ランタイム レプリカと、API およびブラウザー ランタイムのより高い並列処理設定で対処できます。
これを確認する方法については、 プライベート ロケーションにさらに合成ジョブ マネージャーが必要ですか? を 参照してください。
レビューログ シンセティック ジョブ マネージャーのコンテナー ログを確認することで、ミニオンの健康状態を監視できます。
これは、合成ジョブ マネージャーが Docker コンテナー システム環境で適切に動作していることを示す合成ジョブ マネージャー ログの例です。
$ docker logs YOUR_CONTAINER_NAME
2022-09-14 19:00:27,966{PST} [main] INFO c.n.s.j.u.d.SyntheticsDockerUtility - Creating container for newrelic/synthetics-ping-runtime:latest
2022-09-14 19:00:28,239{PST} [main] INFO c.n.s.j.u.d.SyntheticsDockerUtility - Successfully created container 256ffb2683c1ca525b19d866980204255210f85e17d64bb7db0339943fb3ee01 for newrelic/synthetics-ping-runtime:latest
2022-09-14 19:00:28,240{PST} [main] INFO c.n.s.j.u.d.SyntheticsDockerUtility - Starting newrelic/synthetics-ping-runtime:latest with CONTAINER_ID: 256ffb2683c1ca525b19d866980204255210f85e17d64bb7db0339943fb3ee01
2022-09-14 19:00:28,714{PST} [main] INFO c.n.s.j.u.d.SyntheticsDockerUtility - Successfully started newrelic/synthetics-ping-runtime:latest with CONTAINER_ID: 256ffb2683c1ca525b19d866980204255210f85e17d64bb7db0339943fb3ee01
2022-09-14 19:00:28,751{PST} [main] INFO c.n.s.j.s.S.JobManagerService - Starting Workers
... logging continues ...
2022-09-14 19:00:32,001{PST} [main] INFO o.e.jetty.server.AbstractConnector - Started application@1c7843c3{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
2022-09-14 19:00:32,017{PST} [main] INFO o.e.jetty.server.AbstractConnector - Started admin@1c0e4262{HTTP/1.1, (http/1.1)}{0.0.0.0:8082}
2022-09-14 19:00:32,017{PST} [main] INFO org.eclipse.jetty.server.Server - Started @151139ms
これは、外形監視ジョブ マネージャーが Podman コンテナ システム環境で適切に動作していることを示す外形監視ジョブ マネージャー ログの例です。
$podman logs [YOUR_CONTAINER_NAME]
これは、合成ジョブ マネージャーが Kubernetes コンテナー オーケストレーション システム環境で適切に動作していることを示す合成ジョブ マネージャー ログの例です。
まず、ログを確認する Synthetics ジョブ マネージャー ポッドの名前を取得します。
$ kubectl get pods -n YOUR_NAMESPACE
次に、その合成ジョブ マネージャー ポッドと対話します。
$ kubectl logs -n YOUR_NAMESPACE YOUR_JOB_MANAGER_NAME
2022-09-14 19:02:50,055{PST} [main] INFO o.e.jetty.server.AbstractConnector - Started application@472c9f88{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
2022-09-14 19:02:50,139{PST} [main] INFO o.e.jetty.server.AbstractConnector - Started admin@605c7a9e{HTTP/1.1, (http/1.1)}{0.0.0.0:8082}
2022-09-14 19:02:50,140{PST} [main] INFO org.eclipse.jetty.server.Server - Started @22831ms
... logging continues ...
OpenShift ログを確認する これは、外形監視ジョブ マネージャーが OpenShift システム環境で適切に動作していることを示す外形監視ジョブ マネージャー ログの例です。
まず、ログを確認する Synthetics ジョブ マネージャー ポッドの名前を取得します。
$ oc get pods -n your-namespace
次に、その合成ジョブ マネージャー ポッドと対話します。
$ oc logs -n < your-namespace > Your_JOB_MANAGER_NAME
デバッグログの有効化 Synthetics ジョブ マネージャーで問題が発生した場合は、デバッグ ログを有効にして、問題のトラブルシューティングに役立てることができます。
ログのデフォルト レベルは、重要な情報と対処可能なエラーのみをユーザーに通知するように設定されています。これが不十分な場合は、 LOG_LEVEL
環境変数を使用して、より詳細なログを有効にすることができます。
重要 ログレベルをDEBUG
またはTRACE
に上げる場合は注意してください。ログ レベルが高くなると、より多くのデータが記録されます。これはデバッグに役立ちますが、機密データをキャプチャしたり、承認された場所以外に機密データを保存したりするリスクも高まります。データのプライバシーとセキュリティを確保するには、New Relic が収集する情報の種類を制限する必要があります。
ヒント -f
をDocker logs
に追加すると、コマンドはログに追従します。
$ docker run .. . -e LOG_LEVEL = DEBUG .. .
$ docker logs -f YOUR_CONTAINER_NAME
... verbose logging continues ...
ヒント -f
をPodman logs
に追加すると、コマンドはログに追従します。
podman run ... -e LOG_LEVEL=DEBUG ...
podman logs -f YOUR_CONTAINER_NAME
... verbose logging continues ...
ヒント -f
をKubernetes logs
に追加すると、コマンドはログに追従します。
DEBUG ログを有効にするには、 helm install
の実行時に--set synthetics.logLevel=DEBUG
オプションを追加します。
$ helm install YOUR_JOB_MANAGER_NAME YOUR_REPO_NAME/synthetics-job-manager -n YOUR_NAMESPACE --set synthetics.privateLocationKey = YOUR_PRIVATE_LOCATION_KEY --set synthetics.logLevel = DEBUG
ログを確認する Synthetics ジョブ マネージャー ポッドの名前を取得します。
$ kubectl get pods -n YOUR_NAMESPACE
次に、その合成ジョブ マネージャー ポッドと対話します。
$ kubectl logs -f -n YOUR_NAMESPACE YOUR_JOB_MANAGER_POD_NAME
... verbose logging continues ...
OpenShift デバッグログを有効にする ヒント -f
をOpenShift logs
に追加すると、コマンドはログに追従します。
DEBUG ログを有効にするには、 helm install
の実行時に--set synthetics.logLevel=DEBUG
オプションを追加します。
$ helm install release_name newrelic/synthetics-job-manager -n your_namespace --set synthetics.privateLocationKey = private_location_key --set image_stream_name.image.repository = image_repo --set image_stream_name.appVersionOverride = tag --set synthetics.logLevel = DEBUG
まず、ログを確認する Synthetics ジョブ マネージャー ポッドの名前を取得します。
$ oc get pods -n your-namespace
次に、その合成ジョブ マネージャー ポッドと対話します。
$ oc logs -f -n your-namespace Your_JOB_MANAGER_NAME
Kubernetesのデバッグ情報を取得する Kubernetes コンテナー オーケストレーション システム環境で合成ジョブ マネージャーに問題が発生した場合、合成ジョブ マネージャー ポッドとそれが実行されているノードに関する情報を取得して、トラブルシューティングに役立てることができます。
Synthetics ジョブ マネージャー ポッドの情報を取得するには、次のようにします。
$ kubectl describe pod -n YOUR_NAMESPACE YOUR_JOB_MANAGER_POD_NAME
Synthetics ジョブ マネージャー ポッドが実行されているノードの情報を取得するには、ノードを特定してから、次の操作を行います。
$ kubectl describe node NODE_ASSOCIATED_WITH_YOUR_JOB_MANAGER_POD_NAME
OpenShift デバッグ情報を取得する OpenShift システム環境で外形監視ジョブ マネージャーに問題が発生した場合は、外形監視ジョブ マネージャー ポッドとそれが実行されているノードに関する情報を取得して、トラブルシューティングに役立てることができます。
Synthetics ジョブ マネージャー ポッドの情報を取得するには、次のようにします。
$ oc describe pod -n < your-namespace > Your_JOB_MANAGER_NAME
New Relic Infrastructure で合成ジョブ マネージャーを監視する New Relic のインフラストラクチャ監視 は、 高度な Docker 監視 と高度な Kubernetes 監視 をサポートしています。
インフラストラクチャ エージェントを使用してこれらのランナー コンテナーを監視している場合は、少なくとも 1 つのモニターを毎分実行するように構成します。インフラストラクチャ エージェントは、コンテナが削除される前に、コンテナのdocker inspect
から上記のラベルに気づき、収集する機会が増えます。