After installing your containerized private minion (CPM), you can keep track of its maintenance and monitoring in several ways:
- Check if the CPM is healthy and working with the CPM status endpoint.
- See if a private location is under-provisioned and needs more minions.
- Review your Docker logs or Kubernetes logs.
You can also get notified of monitor failures with New Relic's alerts.
Connecting to a running CPM using HTTP is the easiest way to check if it's healthy and working. The container exposes two ports:
8180. You can check the CPM with the following endpoints:
:8080/status/check: provides details about internal health checks that the minion performs.
HTTP 200means the status is healthy.
:8080/status: provides details about a minion's status, which is the same data published in Insights as
:8180/: provides JVM application admin endpoints. This is an advanced view of a minion's Java Development Kit (JDK) internal state.
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?
You can monitor your minion's health by looking at CPM container 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.
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
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:
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.
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.
If you need more help, check out these support and learning resources:
- Browse the Explorers Hub to get help from the community and join in discussions.
- Find answers on our sites and learn how to use our support portal.
- Run New Relic Diagnostics, our troubleshooting tool for Linux, Windows, and macOS.
- Review New Relic's data security and licenses documentation.