• EnglishEspañol日本語한국어Português
  • Log inStart now

Containerized private minion (CPM) maintenance and monitoring

After installing your containerized private minion (CPM), you can keep track of its maintenance and monitoring in several ways:

Tip

You can also get notified of monitor failures with New Relic's alerts.

Check CPM status using HTTP

Connecting to a running CPM using HTTP is the easiest way to check if it's healthy and working. The container exposes two ports: 8080 and 8180. You can check the CPM with the following endpoints:

  • :8080/status/check: provides details about internal health checks that the minion performs. HTTP 200 means the status is healthy.
  • :8080/status: provides details about a minion's status, which is the same data published in a SyntheticsPrivateMinion event.
  • :8180/: provides JVM application admin endpoints. This is an advanced view of a minion's Java Development Kit (JDK) internal state.

Check if your private location requires more minions

If your private location has multiple monitor checks queued up and you experience delays, you may need more minions available to execute the monitor checks.

To learn how to verify this, see Does my private location need more minions?

Review logs

You can monitor your minion's health by looking at CPM container logs.

Enable debug logs

If you experience issues with your CPM, you can enable debug logs to help troubleshoot issues.

The default level of logging is set to only inform the user of key information and actionable errors. If this is insufficient, you can enable a more verbose logging by using the MINION_LOG_LEVEL environment variable.

Retrieve Kubernetes debugging information

If you experience issues with your CPM in a Kubernetes container orchestration system environment, you can retrieve information about the CPM pod and the node it is running on to help troubleshoot.

To retrieve information for the CPM pod:

kubectl describe pod -n YOUR_NAMESPACE YOUR_CPM_POD_NAME

To retrieve information for the node the CPM pod is running on, identify the node, and then:

kubectl describe node NODE_ASSOCIATED_WITH_YOUR_CPM_POD_NAME

Monitor CPMs with New Relic Infrastructure

New Relic's infrastructure monitoring supports advanced Docker monitoring and advanced Kubernetes monitoring. To add support for this, synthetic monitoring labels the containers spawned by CPM with a series of informative labels, all prefixed with synthetics-minion-. The CPM spawns containers called "runners" which process non-ping monitors like: simple browser, scripted browser, api test, and step function. You can use these labels to identify these runner containers. Example labels include:

  • 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

Runner containers last a short time. One runner container is created to process one non-ping monitor job. The runner is created, processes the job, and is quickly deleted. A runner container exists for only a few seconds and will be created only if there is a non-ping monitor job to process. Ping monitors will not trigger runner container creation, so the above labels will not be present.

If you are using the infrastructure agent to monitor these runner containers, configure at least one monitor to run each minute. The infrastructure agent will have more opportunity to notice and collect the above labels from the docker inspect of the container before it is deleted.

Note: the synthetics-minion-id label refers to the ID of the minion which spawned this particular runner container. The ID of the runner itself is not tracked.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.