containerized private minion (CPM) をインストールした後は、いくつかの方法でそのメンテナンスと監視を追跡することができます。
HTTPによるCPMの状態確認
HTTP を使用して実行中の CPM に接続することは、正常で機能しているかどうかを確認する最も簡単な方法です。コンテナは8080と8180の 2 つのポートを公開します。次のエンドポイントで CPM を確認できます。
:8080/status/check: ミニオンが実行する内部ヘルス チェックの詳細を提供します。HTTP 200は、ステータスが正常であることを意味します。:8080/status: ミニオンのステータスに関する詳細を提供します。これは、 SyntheticsPrivateMinionイベントで公開されたデータと同じです。:8180/: JVM アプリケーション管理エンドポイントを提供します。これは、ミニオンの Java Development Kit (JDK) 内部状態の高度なビューです。
プライベートな場所にミニオンが必要かどうかをチェック
プライベートな場所で複数のモニターチェックがキューイングされていて、遅延が発生した場合、モニターチェックを実行するために利用できるミニオンの数が必要になることがあります。
この確認方法については、 Does my private location need more minions?
レビューログ
CPMコンテナのログを見ることで、ミニオンの健康状態を監視することができます。
これは、Dockerコンテナシステム環境でミニオンが正常に動作していることを示すCPMログの一例です。
$docker logs [YOUR_CONTAINER_NAME]
2018-10-10 11:33:29,856 - Minion ID: a21f6d7f-4f65-4dec-92fb-88cb975d2a19
2018-10-10 11:33:29,869 - Publishing resources for Private Minion API: /status/check, /build-info, /status
2018-10-10 11:33:40,527 - Minion is configured, checking if it is healthy...
2018-10-10 11:33:43,471 - Launching in PRIVATE Location: 123456-example_private_loc-480
2018-10-10 11:33:43,723 - Configured 2 heavy worker threads, and 50 light worker threads
2018-10-10 11:33:43,796 -
2018-10-10 11:33:43,796 - **************************************************************************
2018-10-10 11:33:43,796 - * Synthetics Minion is ready and servicing location 'example_private_location'
2018-10-10 11:33:43,796 - **************************************************************************
... logging continues ...
これは、Kubernetesコンテナオーケストレーションシステム環境でミニオンが正常に動作していることを示すCPMログの例です。
まず、ログを確認したいCPMポッドの名前を取得します。
kubectl get pods -n YOUR_NAMESPACE
そして、そのCPMポッドと対話する。
$ kubectl logs -n YOUR_NAMESPACE YOUR_CPM_NAME
2020-05-11 22:57:24,084 - Minion will use 2 heavy workers
2020-05-11 22:57:24,149 - Minion will use 50 lightweight workers
2020-05-11 22:57:27,973 - Minion Container System: KUBERNETES
2020-05-11 22:57:30,158 - Minion deployment mode: PRIVATE_MINION_POD_KUBERNETES
2020-05-11 22:57:30,178 - No volume mounted at '/var/lib/newrelic/synthetics' in ':rw' mode: Private Minion's ID will change with each boot
2020-05-11 22:57:30,284 - Minion ID: a21f6d7f-4f65-4dec-92fb-88cb975d2a19
2020-05-11 22:57:30,654 - Publishing resources for Private Minion API: /status/check, /build-info, /status
2020-05-11 22:57:31,595 - Minion is configured, checking if it is healthy...
2020-05-11 22:57:35,457 - Launching in PRIVATE Location: 123456-example_private_loc-480
2020-05-11 22:57:36,060 - Executor for async-worker-* threads configured with a max pool size of 16
2020-05-11 22:57:36,072 - Configured 2 heavy worker threads, and 50 lightweight worker threads
2020-05-11 22:57:36,087 -
2020-05-11 22:57:36,087 - **************************************************************************
2020-05-11 22:57:36,087 - * Synthetics Minion 3.0.1 is ready and servicing location 'example_private_location'
2020-05-11 22:57:36,087 - **************************************************************************
2020-05-11 22:57:36,087 -
... logging continues ...
デバッグログの有効化
CPMで問題が発生した場合、デバッグログを有効にすることで、問題のトラブルシューティングに役立てることができます。
ログのデフォルト レベルは、重要な情報と対処可能なエラーのみをユーザーに通知するように設定されています。これが不十分な場合は、 MINION_LOG_LEVEL環境変数を使用して、より詳細なログを有効にすることができます。
ヒント
-fをDocker logsに追加すると、コマンドはログに追従します。
docker run ... -e MINION_LOG_LEVEL=DEBUG ...
docker logs -f YOUR_CONTAINER_NAME
... verbose logging continues ...
ヒント
-fをKubernetes logsに追加すると、コマンドはログに追従します。
DEBUG ログを有効にするには、 helm installの実行時に--set synthetics.minionLogLevel=DEBUGオプションを追加します。
helm install YOUR_CPM_NAME YOUR_REPO_NAME/synthetics-minion -n YOUR_NAMESPACE --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY --set synthetics.minionLogLevel=DEBUG
ログを確認したいCPMポッドの名前を取得します。
kubectl get pods -n YOUR_NAMESPACE
そして、そのCPMポッドと対話する。
kubectl logs -f -n YOUR_NAMESPACE YOUR_CPM_POD_NAME
... verbose logging continues ...
Kubernetesのデバッグ情報を取得する
Kubernetesコンテナオーケストレーションシステム環境でCPMに問題が発生した場合、CPMポッドとそれが実行されているノードに関する情報を取得し、トラブルシューティングに役立てることができます。
CPMポッドの情報を取得するには
kubectl describe pod -n YOUR_NAMESPACE YOUR_CPM_POD_NAME
CPMポッドが動作しているノードの情報を取得するには、ノードを特定してから
kubectl describe node NODE_ASSOCIATED_WITH_YOUR_CPM_POD_NAME
New RelicのインフラでCPMを監視
New Relic のインフラストラクチャ監視は、 高度な Docker 監視と高度な Kubernetes 監視をサポートしています。これに対するサポートを追加するために、Synthetic Monitoring は、CPM によって生成されたコンテナーに一連の有益なラベルを付け、すべてsynthetics-minion-で始まるラベルを付けます。CPM は、「ランナー」と呼ばれるコンテナーを生成します。このコンテナーは、単純なブラウザー、スクリプト化されたブラウザー、API テスト、およびステップ関数などの非 ping モニターを処理します。これらのラベルを使用して、これらのランナー コンテナーを識別できます。ラベルの例は次のとおりです。
synthetics-minion-runner-rolesynthetics-minion-runner-versionsynthetics-minion-container-idsynthetics-minion-idsynthetics-minion-build-numbersynthetics-minion-jobsynthetics-minion-accountsynthetics-minion-monitorsynthetics-minion-monitor-versionsynthetics-minion-monitor-typesynthetics-minion-monitor-type-label
ランナーコンテナは短時間で終了します。1つのランナー・コンテナは、1つの非pingモニター・ジョブを処理するために作成されます。ランナーは作成され、ジョブを処理した後、すぐに削除されます。ランナーコンテナは数秒しか存在せず、処理すべき非Pingモニタージョブがある場合にのみ作成されます。Pingモニターはランナーコンテナ作成のトリガーとならないため、上記のラベルは存在しません。
インフラストラクチャ エージェントを使用してこれらのランナー コンテナーを監視している場合は、少なくとも 1 つのモニターを毎分実行するように構成します。インフラストラクチャ エージェントは、コンテナが削除される前に、コンテナのdocker inspectから上記のラベルに気づき、収集する機会が増えます。
注: synthetics-minion-idラベルは、この特定のランナー コンテナーをスポーンしたミニオンの ID を参照します。ランナー自体の ID は追跡されません。