containerized private minion (CPM) をインストールした後は、いくつかの方法でそのメンテナンスと監視を追跡することができます。
HTTPによるCPMの状態確認
稼働中の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ログを有効にするには、 --set synthetics.minionLogLevel=DEBUG オプションを、 helm install を実行する際に追加します。
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 モニタリング をサポートしています。このサポートを追加するために、シンセティックモニタリングはCPMによって産み出されたコンテナに一連の情報ラベルを付け、すべてのプレフィックスに synthetics-minion- を付けています。CPMは、simple browser、scripted browser、api test、step functionなどの非pingモニタを処理する"runners" というコンテナを生成します。これらのラベルを使用して、これらのランナーコンテナを識別することができます。ラベルの例を以下に示します。
シンセティック・ミニオン・ラナー・ロールシンセティック・ミニオン・ランナー・バージョン合成ミニオンコンテナーIDシンセティック・ミニオン-IDシンセティック・ミニオン ビルド・ナンバーシンセティック・ミニオン・ジョブシンセティック・ミニオン・アカウントシンセティック・ミニオン・モニターシンセティック・ミニオン・モニター・バージョンシンセティック・ミニオン・モニター・タイプシンセティック・ミニオン・モニター・タイプ・ラベル
ランナーコンテナは短時間で終了します。1つのランナー・コンテナは、1つの非pingモニター・ジョブを処理するために作成されます。ランナーは作成され、ジョブを処理した後、すぐに削除されます。ランナーコンテナは数秒しか存在せず、処理すべき非Pingモニタージョブがある場合にのみ作成されます。Pingモニターはランナーコンテナ作成のトリガーとならないため、上記のラベルは存在しません。
インフラストラクチャエージェントを使用してこれらのランナーコンテナを監視する場合、少なくとも1つのモニターが毎分実行されるように設定します。インフラストラクチャー・エージェントは、コンテナが削除される前に、コンテナの docker inspect から上記のラベルに気づき、収集する機会が増えます。
注： synthetics-minion-id ラベルは、この特定のランナーコンテナを生成したミニオンのIDを参照しています。runner自体のIDは追跡されません。