In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.
HTTP를 사용하여 실행 중인 합성 작업 관리자에 연결하는 것이 정상 작동하는지 확인하는 가장 쉬운 방법입니다. 컨테이너가 8080 포트를 노출합니다. 다음 엔드포인트를 사용하여 합성 작업 관리자를 확인할 수 있습니다.
:8080/status/check: 미니언이 수행하는 내부 상태 확인에 대한 세부 정보를 제공합니다. HTTP 200 은 상태가 정상임을 의미합니다.
개인 위치에 더 많은 합성 작업 관리자가 필요한지 확인하십시오.
개인 위치에 여러 모니터 검사가 대기 중이고 지연이 발생하는 경우 모니터 검사를 실행하는 데 사용할 수 있는 합성 작업 관리자가 더 필요할 수 있습니다. Kubernetes에서는 더 많은 핑 런타임 복제본과 API 및 브라우저 런타임에 대한 더 높은 병렬 처리 설정으로 이 문제를 해결할 수 있습니다.
다음은 합성 작업 관리자가 Docker 컨테이너 시스템 환경에서 제대로 작동하고 있음을 나타내는 합성 작업 관리자 로그의 예입니다.
$docker logs [YOUR_CONTAINER_NAME]
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
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
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
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
2022-09-14 19:00:28,751{PST} [main] INFO c.n.s.j.s.S.JobManagerService - Starting Workers
... logging continues ...
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}
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}
2022-09-14 19:00:32,017{PST} [main] INFO org.eclipse.jetty.server.Server - Started @151139ms
다음은 합성 작업 관리자가 Kubernetes 컨테이너 오케스트레이션 시스템 환경에서 제대로 작동하고 있음을 나타내는 합성 작업 관리자 로그의 예입니다.
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}
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}
2022-09-14 19:02:50,140{PST} [main] INFO org.eclipse.jetty.server.Server - Started @22831ms
... logging continues ...
디버그 로그 사용
합성 작업 관리자에 문제가 발생하면 디버그 로그를 활성화하여 문제를 해결할 수 있습니다.
기본 로깅 수준은 사용자에게 주요 정보와 실행 가능한 오류만 알리도록 설정됩니다. 이것이 충분하지 않으면 LOG_LEVEL 환경 변수를 사용하여 더 자세한 로깅을 활성화할 수 있습니다.
중요
로그 수준을 DEBUG 또는 TRACE 로 높이려면 주의하세요. 로그 수준이 높을수록 더 많은 데이터가 기록됩니다. 이는 디버깅에 도움이 될 수 있지만 중요한 데이터를 캡처하고 승인된 위치 외부에 중요한 데이터를 저장할 위험도 높아집니다. 데이터 개인 정보 보호 및 보안을 보장하려면 New Relic이 수집하는 정보 유형을 제한해야 합니다.
팁
Docker logs 에 -f 를 추가하면 명령이 로그를 따릅니다.
docker run ... -e LOG_LEVEL=DEBUG ...
docker logs -f YOUR_CONTAINER_NAME
... verbose logging continues ...
팁
Kubernetes logs 에 -f 를 추가하면 명령이 로그를 따릅니다.
DEBUG 로그를 활성화하려면 helm install 을 실행할 때 --set synthetics.logLevel=DEBUG 옵션을 추가합니다.