--- title: Synthetics job manager maintenance and monitoring source: https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/job-manager-maintenance-monitoring --- After [installing your synthetics job manager](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/install-job-manager), you can keep track of its maintenance and monitoring in several ways: - Check if the synthetics job manager is healthy and working with the [synthetics job manager status endpoint](#sjm-status). - See if a private location is under-provisioned and [needs more synthetics job managers](#more-jobmanagers). - Review your [Docker logs](#monitor-docker-logs), [Podman logs](#monitor-podman-logs), [Kubernetes logs](#monitor-docker-logs) or [OpenShift logs](#review-openshift-logs). > #### 💡 TIP > > You can also get notified of monitor failures with [New Relic's alerts](https://docs.newrelic.com/docs/synthetics/synthetic-monitors/using-monitors/alerts-synthetic-monitoring). ## Check synthetics job manager status using HTTP [#sjm-status] Connecting to a running synthetics job manager using HTTP is the easiest way to check if it's healthy and working. The container exposes port `8080`. You can check the synthetics job manager with the following endpoints: - `:8080/status/check`: provides details about internal health checks that the Synthetics Job Manager performs. `HTTP 200` means the status is healthy. ## Check if your private location requires more synthetics job managers [#more-jobmanagers] If your private location has multiple monitor checks queued up and you experience delays, you may need more synthetics job managers available to execute the monitor checks. In Kubernetes, this could be addressed with more ping runtime replicas and higher parallelism settings for API and browser runtimes. To learn how to verify this, see [Does my private location need more synthetics job managers?](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/private-locations/monitor-private-locations/#more-minions) ## Review logs [#monitor-docker-logs] You can monitor your Synthetics Job Manager's health by looking at synthetics job manager container logs. **Review Docker logs** This is an example of a synthetics job manager log indicating that the synthetics job manager is working properly in a Docker container system environment: ````shell docker logs YOUR_CONTAINER_NAME [output] 2022-09-14 19:00:27,966{PST} [main] INFO c.n.s.j.u.d.SyntheticsDockerUtility - Creating container for newrelic/synthetics-ping-runtime:latest [output] 2022-09-14 19:00:28,239{PST} [main] INFO c.n.s.j.u.d.SyntheticsDockerUtility - Successfully created container 256ffb2683c1ca525b19d866980204255210f85e17d64bb7db0339943fb3ee01 for newrelic/synthetics-ping-runtime:latest [output] 2022-09-14 19:00:28,240{PST} [main] INFO c.n.s.j.u.d.SyntheticsDockerUtility - Starting newrelic/synthetics-ping-runtime:latest with CONTAINER_ID: 256ffb2683c1ca525b19d866980204255210f85e17d64bb7db0339943fb3ee01 [output] 2022-09-14 19:00:28,714{PST} [main] INFO c.n.s.j.u.d.SyntheticsDockerUtility - Successfully started newrelic/synthetics-ping-runtime:latest with CONTAINER_ID: 256ffb2683c1ca525b19d866980204255210f85e17d64bb7db0339943fb3ee01 [output] 2022-09-14 19:00:28,751{PST} [main] INFO c.n.s.j.s.S.JobManagerService - Starting Workers [output] ... logging continues ... [output] 2022-09-14 19:00:32,001{PST} [main] INFO o.e.jetty.server.AbstractConnector - Started application@1c7843c3{HTTP/1.1, (http/1.1)}{0.0.0.0:8080} [output] 2022-09-14 19:00:32,017{PST} [main] INFO o.e.jetty.server.AbstractConnector - Started admin@1c0e4262{HTTP/1.1, (http/1.1)}{0.0.0.0:8082} [output] 2022-09-14 19:00:32,017{PST} [main] INFO org.eclipse.jetty.server.Server - Started @151139ms ``` ```` **Review Podman logs** This is an example of a synthetics job manager log indicating that the synthetics job manager is working properly in a Podman container system environment: ```` $podman logs [YOUR_CONTAINER_NAME] ``` ```` **Review Kubernetes logs** This is an example of a synthetics job manager log indicating that the synthetics job manager is working properly in a Kubernetes container orchestration system environment: First, get the name of the synthetics job manager pod you want to review logs for: ````sh kubectl get pods -n YOUR_NAMESPACE ``` Then, interact with that synthetics job manager pod: ```shell kubectl logs -n YOUR_NAMESPACE YOUR_JOB_MANAGER_NAME [output] 2022-09-14 19:02:50,055{PST} [main] INFO o.e.jetty.server.AbstractConnector - Started application@472c9f88{HTTP/1.1, (http/1.1)}{0.0.0.0:8080} [output] 2022-09-14 19:02:50,139{PST} [main] INFO o.e.jetty.server.AbstractConnector - Started admin@605c7a9e{HTTP/1.1, (http/1.1)}{0.0.0.0:8082} [output] 2022-09-14 19:02:50,140{PST} [main] INFO org.eclipse.jetty.server.Server - Started @22831ms [output] ... logging continues ... ``` ```` **Review OpenShift logs** This is an example of a synthetics job manager log indicating that the synthetics job manager is working properly in OpenShift system environment: First, get the name of the synthetics job manager pod you want to review logs for: ````shell oc get pods -n your-namespace ``` Then, interact with that synthetics job manager pod: ```shell oc logs -n Your_JOB_MANAGER_NAME ``` ```` ## Enable debug logs [#monitor-docker-debug-logs] If you experience issues with your synthetics job manager, 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 `LOG_LEVEL` environment variable. > #### ⚠️ IMPORTANT > > Be careful increasing the log level to `DEBUG` or `TRACE`. Higher log levels will record more data—that can help you debug, but also increases the risk of capturing sensitive data and storing sensitive data outside of your approved locations. To ensure data privacy and security, you should limit the types of information New Relic collects. **Enable Docker debug logs** > #### 💡 TIP > > Adding `-f` to the `Docker logs` makes the command follow logs. ````shell docker run ... -e LOG_LEVEL=DEBUG ... docker logs -f YOUR_CONTAINER_NAME [output] ... verbose logging continues ... ``` ```` **Enable Podman debug logs** > #### 💡 TIP > > Adding `-f` to the `Podman logs` makes the command follow logs. ```` podman run ... -e LOG_LEVEL=DEBUG ... podman logs -f YOUR_CONTAINER_NAME ... verbose logging continues ... ``` ```` **Enable Kubernetes debug logs** > #### 💡 TIP > > Adding `-f` to the `Kubernetes logs` makes the command follow logs. To enable DEBUG logs add the `--set synthetics.logLevel=DEBUG` option when running your `helm install`: ````shell helm install YOUR_JOB_MANAGER_NAME YOUR_REPO_NAME/synthetics-job-manager -n YOUR_NAMESPACE --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY --set synthetics.logLevel=DEBUG ``` Get the name of the synthetics job manager pod you want to review logs for: ```shell kubectl get pods -n YOUR_NAMESPACE ``` Then, interact with that synthetics job manager pod: ```shell kubectl logs -f -n YOUR_NAMESPACE YOUR_JOB_MANAGER_POD_NAME [output] ... verbose logging continues ... ``` ```` **Enable OpenShift debug logs** > #### 💡 TIP > > Adding `-f` to the `OpenShift logs` makes the command follow logs. To enable DEBUG logs add the `--set synthetics.logLevel=DEBUG` option when running your `helm install`: ````shell helm install release_name newrelic/synthetics-job-manager -n your_namespace --set synthetics.privateLocationKey=private_location_key --set image_stream_name.image.repository=image_repo --set image_stream_name.appVersionOverride=tag --set synthetics.logLevel=DEBUG ``` First, get the name of the synthetics job manager pod you want to review logs for: ```shell oc get pods -n your-namespace ``` Then, interact with that synthetics job manager pod: ```shell oc logs -f -n your-namespace Your_JOB_MANAGER_NAME ``` ```` ## Retrieve debugging information [#retrieve-debugging-information] You can retrieve debugging information about your synthetics job manager to help troubleshoot issues. This includes information about the synthetics job manager pod and the node it is running on. **Retrieve for Kubernetes** If you experience issues with your synthetics job manager in a Kubernetes container orchestration system environment, you can retrieve information about the synthetics job manager pod and the node it is running on to help troubleshoot. To retrieve information for the synthetics job manager pod: ```shell kubectl describe pod -n YOUR_NAMESPACE YOUR_JOB_MANAGER_POD_NAME ``` To retrieve information for the node the synthetics job manager pod is running on, identify the node, and then: ```shell kubectl describe node NODE_ASSOCIATED_WITH_YOUR_JOB_MANAGER_POD_NAME ``` **Retrieve for OpenShift** If you experience issues with your synthetics job manager in OpenShift system environment, you can retrieve information about the synthetics job manager pod and the node it is running on to help troubleshoot. To retrieve information for the synthetics job manager pod: ```shell oc describe pod -n Your_JOB_MANAGER_NAME ``` ## Monitor synthetics job managers with New Relic Infrastructure [#monitor-via-infrastructure] [New Relic's infrastructure monitoring](https://docs.newrelic.com/docs/infrastructure) supports [advanced Docker monitoring](https://docs.newrelic.com/docs/infrastructure/new-relic-infrastructure/data-instrumentation/docker-instrumentation-infrastructure) and [advanced Kubernetes monitoring](https://docs.newrelic.com/docs/integrations/kubernetes-integration/get-started/introduction-kubernetes-integration). 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.