Maintenance et monitoring des minions conteneurisés privés (CPM)

Après avoir installé votre minion privé conteneurisé (CPM), vous pouvez suivre sa maintenance et son monitoring de plusieurs manières :

• Vérifiez si les CPM sont sains et fonctionnent avec le point de terminaison d'état des CPM.
• Vérifiez si un site privé est sous-approvisionné et a besoin de plus de minions.
• Consultez vos Docker logs ou Kubernetes logs .

Vérifiez le statut des CPM en utilisant HTTP

Se connecter à un CPM en cours d'exécution à l'aide de HTTP est le moyen le plus simple de vérifier s'il est sain et fonctionne. Le conteneur expose deux ports : 8080 et 8180. Vous pouvez vérifier les CPM avec le point de terminaison suivant :

• :8080/status/check: fournit des détails sur les contrôles de santé internes effectués par le minion. HTTP 200 signifie que le statut est sain.
• :8080/status: fournit des détails sur le statut d'un minion, qui sont les mêmes données publiées dans un événement SyntheticsPrivateMinion .
• :8180/: fournit le point de terminaison de l'administrateur de l'application JVM . Il s'agit d'une vue avancée de l'état interne du kit de développement Java (JDK) d'un minion.

Vérifiez si votre site privé nécessite plus de minions

Si votre site privé a plusieurs contrôles du monitoring en file d'attente et que vous rencontrez des retards, vous aurez peut-être besoin de plus de minions disponibles pour exécuter les contrôles du monitoring.

Pour savoir comment vérifier cela, consultez Mon site privé a-t-il besoin de plus de minions ?

Logs de révision

Vous pouvez monitorer la santé de votre minion en consultant les logs des conteneurs 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 ...

$
kubectl get pods -n YOUR_NAMESPACE

$
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 ...

Activer les logs de débogage

Si vous rencontrez des problèmes avec vos CPM, vous pouvez activer les logs de débogage pour vous aider à résoudre les problèmes.

Le niveau du logging par défaut est défini pour informer uniquement l'utilisateur des informations clés et des erreurs exploitables. Si cela n’est pas suffisant, vous pouvez activer un logging plus détaillé en utilisant la variable d’environnement MINION_LOG_LEVEL .

$
docker run ... -e MINION_LOG_LEVEL=DEBUG ...
$
docker logs -f YOUR_CONTAINER_NAME
... verbose logging continues ...

$
helm install YOUR_CPM_NAME YOUR_REPO_NAME/synthetics-minion -n YOUR_NAMESPACE --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY --set synthetics.minionLogLevel=DEBUG

$
kubectl get pods -n YOUR_NAMESPACE

$
kubectl logs -f -n YOUR_NAMESPACE YOUR_CPM_POD_NAME
... verbose logging continues ...

Récupérer les informations de débogage de Kubernetes

Si vous rencontrez des problèmes avec vos CPM dans un environnement de système d'orchestration de conteneurs Kubernetes , vous pouvez récupérer des informations sur le pod CPM et le nœud sur lequel il s'exécute pour aider à résoudre le problème.

Pour récupérer les informations du pod CPM :

$
kubectl describe pod -n YOUR_NAMESPACE YOUR_CPM_POD_NAME

Pour récupérer des informations sur le nœud sur lequel le pod CPM s'exécute, identifiez le nœud, puis :

$
kubectl describe node NODE_ASSOCIATED_WITH_YOUR_CPM_POD_NAME

Monitorer les CPM avec New Relic Infrastructure

de de New Relic prend en monitoring infrastructure charge avancée Docker monitoring et avancée Kubernetes monitoring. Pour ajouter un support pour cela, Synthétique monitoring étiquette le conteneur généré par les CPM avec une série d'étiquettes informatives, toutes préfixées par synthetics-minion-. Les CPM génèrent des conteneurs appelés « runners » qui traitent des moniteurs non ping tels que : un navigateur simple, un navigateur scripté, un test API et une fonction d'étape. Vous pouvez utiliser ces étiquettes pour identifier ces conteneurs de coureurs. Voici quelques exemples d’étiquettes :

• synthetics-minion-runner-role
• synthetics-minion-runner-version
• synthetics-minion-container-id
• synthetics-minion-id
• synthetics-minion-build-number
• synthetics-minion-job
• synthetics-minion-account
• synthetics-minion-monitor
• synthetics-minion-monitor-version
• synthetics-minion-monitor-type
• synthetics-minion-monitor-type-label

Le conteneur Runner dure peu de temps. Un conteneur runner est créé pour traiter un travail du monitoring non ping. Le runner est créé, traite le travail et est rapidement supprimé. Un conteneur runner n'existe que quelques secondes et ne sera créé que s'il y a un travail du monitoring non ping à traiter. Le moniteur de ping ne déclenchera pas la création du conteneur runner, donc les étiquettes ci-dessus ne seront pas présentes.

Si vous utilisez l'agent infrastructure pour monitorer ces conteneurs d'exécution, configurez au moins un moniteur à exécuter chaque minute. L'agent d'infrastructure aura plus de possibilités de remarquer et de collecter les étiquettes ci-dessus à partir du docker inspect du conteneur avant qu'il ne soit supprimé.

Remarque : l'étiquette synthetics-minion-id fait référence à l'ID du minion qui a généré ce conteneur runner particulier. L'ID du coureur lui-même n'est pas suivi.