중요 2024년 8월 26일부터 공개 또는 위치 위치에서 구형 런타임을 사용하여 새 모니터를 더 이상 생성할 수 없습니다.
2024년 10월 22일에 컨테이너화된 미니언(분당권수) 및 이것이 지원하는 구형 신세틱스 손잡이 버전의 지원이 종료 됩니다. 부동 위치 모니터의 성능 저하를 방지하려면 권장되는 마이그레이션 단계를 검토하십시오.
컨테이너화된 개인 미니언(CPM)을 설치 한 후 여러 가지 방법으로 유지 관리 및 모니터링을 추적할 수 있습니다.
HTTP를 사용하여 CPM 상태 확인 HTTP를 사용하여 실행 중인 CPM에 연결하는 것이 정상 상태이고 작동하는지 확인하는 가장 쉬운 방법입니다. 컨테이너는 두 개의 포트 8080 및 8180 )를 노출합니다. 다음 끝점에서 CPM을 확인할 수 있습니다.
:8080/status/check: 미니언이 수행하는 내부 상태 확인에 대한 세부 정보를 제공합니다. HTTP 200 은 상태가 정상임을 의미합니다.:8080/status: SyntheticsPrivateMinion 이벤트에 게시된 것과 동일한 데이터인 미니언의 상태에 대한 세부정보를 제공합니다.:8180/: JVM 애플리케이션 관리 엔드포인트를 제공합니다. 이것은 미니언의 JDK(Java Development Kit) 내부 상태에 대한 고급 보기입니다.개인 위치에 더 많은 미니언이 필요한지 확인하십시오. 개인 위치에 여러 모니터 검사가 대기 중이고 지연이 발생하는 경우 모니터 검사를 실행하는 데 사용할 수 있는 미니언이 더 필요할 수 있습니다.
이를 확인하는 방법을 알아보려면 내 개인 위치에 미니언이 더 필요합니까? 를 참조하세요.
로그 검토 CPM 컨테이너 로그를 보고 미니언의 상태를 모니터링할 수 있습니다.
다음은 미니언이 Docker 컨테이너 시스템 환경에서 제대로 작동하고 있음을 나타내는 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 ...
다음은 미니언이 Kubernetes 컨테이너 오케스트레이션 시스템 환경에서 제대로 작동하고 있음을 나타내는 CPM 로그의 예입니다.
먼저 로그를 검토할 CPM 포드의 이름을 가져옵니다.
kubectl get pods -n YOUR_NAMESPACE
그런 다음 해당 CPM 포드와 상호작용합니다.
$ 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 ...
디버그 로그 사용 CPM에 문제가 발생하면 디버그 로그를 활성화하여 문제를 해결할 수 있습니다.
기본 로깅 수준은 사용자에게 주요 정보와 실행 가능한 오류만 알리도록 설정됩니다. 이것이 충분하지 않으면 MINION_LOG_LEVEL 환경 변수를 사용하여 더 자세한 로깅을 활성화할 수 있습니다.
팁 Docker logs 에 -f 를 추가하면 명령이 로그를 따릅니다.
docker run ... -e MINION_LOG_LEVEL=DEBUG ...
docker logs -f YOUR_CONTAINER_NAME
... verbose logging continues ...
팁 Kubernetes logs 에 -f 를 추가하면 명령이 로그를 따릅니다.
DEBUG 로그를 활성화하려면 helm install 을 실행할 때 --set synthetics.minionLogLevel=DEBUG 옵션을 추가합니다.
helm install YOUR_CPM_NAME YOUR_REPO_NAME/synthetics-minion -n YOUR_NAMESPACE --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY --set synthetics.minionLogLevel=DEBUG
로그를 검토하려는 CPM 포드의 이름을 가져옵니다.
kubectl get pods -n YOUR_NAMESPACE
그런 다음 해당 CPM 포드와 상호작용합니다.
kubectl logs -f -n YOUR_NAMESPACE YOUR_CPM_POD_NAME
... verbose logging continues ...
Kubernetes 디버깅 정보 검색 Kubernetes 컨테이너 오케스트레이션 시스템 환경에서 CPM에 문제가 발생하는 경우 문제 해결에 도움이 되도록 CPM 포드 및 실행 중인 노드에 대한 정보를 검색할 수 있습니다.
CPM 포드에 대한 정보를 검색하려면:
kubectl describe pod -n YOUR_NAMESPACE YOUR_CPM_POD_NAME
CPM 포드가 실행 중인 노드에 대한 정보를 검색하려면 노드를 식별한 후 다음을 수행합니다.
kubectl describe node NODE_ASSOCIATED_WITH_YOUR_CPM_POD_NAME
New Relic 인프라로 CPM 모니터링 New Relic의 인프라 모니터링 은 고급 Docker 모니터링 및고급 Kubernetes 모니터링 을 지원합니다. 이에 대한 지원을 추가하기 위해 합성 모니터링은 CPM에 의해 생성된 컨테이너에 일련의 정보 레이블로 레이블을 지정하고 모두 synthetics-minion- 접두사가 붙습니다. CPM은 단순 브라우저, 스크립트 브라우저, API 테스트 및 단계 기능과 같은 핑이 아닌 모니터를 처리하는 "러너"라는 컨테이너를 생성합니다. 이러한 레이블을 사용하여 이러한 러너 컨테이너를 식별할 수 있습니다. 레이블의 예는 다음과 같습니다.
synthetics-minion-runner-rolesynthetics-minion-runner-versionsynthetics-minion-container-idsynthetics-minion-idsynthetics-minion-build-numbersynthetics-minion-jobsynthetics-minion-accountsynthetics-minion-monitorsynthetics-minion-monitor-versionsynthetics-minion-monitor-typesynthetics-minion-monitor-type-label러너 컨테이너는 짧은 시간 동안 지속됩니다. 하나의 비핑 모니터 작업을 처리하기 위해 하나의 러너 컨테이너가 생성됩니다. 러너가 생성되어 작업을 처리하고 빠르게 삭제됩니다. 러너 컨테이너는 몇 초 동안만 존재하며 처리할 ping이 아닌 모니터 작업이 있는 경우에만 생성됩니다. Ping 모니터는 러너 컨테이너 생성을 트리거하지 않으므로 위의 레이블이 표시되지 않습니다.
인프라 에이전트를 사용하여 이러한 러너 컨테이너를 모니터링하는 경우 매분 실행되도록 하나 이상의 모니터를 구성하십시오. 인프라 에이전트는 삭제되기 전에 컨테이너의 docker inspect 에서 위의 레이블을 확인하고 수집할 수 있는 더 많은 기회를 갖게 됩니다.
참고: synthetics-minion-id 레이블은 이 특정 러너 컨테이너를 생성한 미니언의 ID를 나타냅니다. 주자 자체의 ID는 추적되지 않습니다.