New Relic으로 OpenTelemetry 문제 해결

New Relic으로 OpenTelemetry 문제를 해결하는 것은 모범 사례 를 따르고 있는지 확인하는 문제일 수 있지만 때로는 문제를 진단하기 위해 추가 단계를 수행해야 할 수도 있습니다. 다음은 문제를 해결하기 위한 단계 및 도구와 함께 발생할 수 있는 특정 문제의 몇 가지 예입니다.

OTLP를 통해 전송된 OpenTelemetry 데이터는 쿼리할 수 없습니다.

문제

OTLP를 사용하여 OpenTelemetry 메트릭, 로그 또는 추적을 전송했으며 데이터를 볼 수 없습니다. 더 깊이 파고 들기 전에 다음을 확인했는지 확인하십시오.

• 구성된 OTLP 끝점은 문서화된 끝점 중 하나와 일치하고 형식이 적절 하며 OTLP/gRPC용 기본 포트 (4317) 또는 OTLP/HTTP용 기본 포트 (4318)를 포함합니다. 포트 443도 두 전송 모두에서 지원됩니다. 해당되는 경우 FedRAMP 규정 준수를 위한 특정 끝점을 확인하십시오.
• 지역에 따라 올바른 엔드포인트를 사용하고 있는지 확인합니다. 예를 들어 유럽에 기반을 두고 있고 미국 엔드포인트로 데이터를 보내도록 내보내기를 구성한 경우 엔드포인트가 지역별로 다르기 때문에 데이터를 내보내지 못합니다.
• 아웃바운드 트래픽은 방화벽에 의해 제한되지 않습니다. 당사의 네트워크 문서는 명시적으로 허용해야 할 수 있는 도메인 및 네트워크 블록에 대해 설명합니다.
• 클라이언트는 TLS 1.2 이상을 사용하도록 구성되어 있으며 요청에는 유효한 New Relic 계정(수집) 라이선스 키 가 있는 api-key 헤더가 포함되어 있습니다.
• 요청에는 유효한 protobuf 페이로드가 포함되며 가급적 gzip 압축 이 활성화된 상태에서 gRPC 또는 HTTP 전송을 사용합니다. 요청 페이로드는 1MB(10^6바이트) 이하여야 합니다. JSON 인코딩 protobuf 페이로드도 지원됩니다.
• 클라이언트 출력 및 로그에 4xx 또는 5xx 응답 코드가 반환되고 있다고 표시되지 않습니다.

해결책

원격 측정 데이터가 당사 플랫폼에 성공적으로 전달되었는지 검증하는 데 사용할 수 있는 도구가 많이 있습니다. 좋은 첫 번째 단계는 데이터 수집을 패싯 하기 위해 데이터 관리 허브 를 확인하고 다양한 소스에서 도착하는 데이터의 양을 확인하는 것입니다. 데이터 탐색기 또는쿼리 빌더 를 사용하여 instrumentation.provider 또는 newrelic.source 속성으로 패싯 데이터를 찾을 수도 있습니다.

FROM Log, Metric, Span SELECT datapointcount() WHERE instrumentation.provider = 'opentelemetry' FACET instrumentation.provider, newrelic.source

이 쿼리는 데이터가 OTLP를 통해 도착하는지 여부를 알려야 합니다. 예상한 데이터가 없으면 다음 대체 쿼리를 시도하십시오.

FROM Log, Metric, Span SELECT count(*) where newrelic.source LIKE 'api.%.otlp'

NrIntegrationError 이벤트 를 쿼리하여 통합 오류를 확인할 수도 있습니다. 이렇게 하면 구성 또는 형식 문제가 있는지 또는 플랫폼 제한에 도달했는지 확인하는 데 도움이 될 수 있습니다.

New Relic UI의 다양한 부분은 제대로 작동하기 위해 특정 속성의 존재에 의존합니다. 여러 위치에서 NRQL 콘솔 기능을 사용하여 쿼리의 WHERE 또는 FACET 절에서 필수 속성을 확인할 수 있습니다. 또한 해당 절을 편집하고 쿼리를 다시 실행하여 해당 속성이 누락된 데이터가 있는지 확인할 수 있습니다. 필수 속성의 예로는 service.name 및 service.instance.id 이 있습니다. 전체 예제 목록은 리소스 를 참조하세요.

OpenTelemetry 엔터티 또는 관계가 누락되었습니다.

문제

서비스 또는 인프라 구성 요소에서 OpenTelemetry 데이터를 보냈고 엔터티 또는 해당 관계 가 누락되었거나 잘못되었습니다.

해결책

OpenTelemetry 항목은 EXT-SERVICE 항목 유형에 대해 설명된 공개 규칙 에 따라 합성됩니다. 일치하는 표준 규칙은 OpenTelemetry 의미 체계 규칙 을 따르는 service.name 차원의 존재 여부에 따라 다릅니다.

OpenTelemetry Java SDK로 service.name 을 설정하려면 리소스 에 포함합니다.

var resource = Resource.getDefault()
    .merge(Resource.builder().put(SERVICE_NAME, serviceName).build());

SDK에 따라 OTEL_RESOURCE_ATTRIBUTES 또는 OTEL_SERVICE_NAME 환경 변수 에서 선언하여 service.name 을 설정할 수도 있습니다.

로그 관리를 위해 구조화된 로그 템플릿을 사용하여 service.name 를 삽입할 수 있습니다. 다음은 몇 가지 로그 예입니다.

• 서비스 이름 설정
• Log4j2를 사용한 컨텍스트의 로그

OpenTelemetry 수집기 문제 해결

수집기 문제 해결 팁 및 모니터링 사례를 위한 가장 좋은 장소는 OpenTelemetry 커뮤니티의 최신 지침입니다. 커뮤니티 문제 해결 문서는 아래 링크를 참조하십시오.

수집기 로그

구성 service::telemetry::logs 에서 로그 수준을 설정합니다. 기본 수준은 INFO 입니다. 지원되는 레벨은 DEBUG , INFO , WARN , ERROR , DPANIC , PANIC , FATAL 입니다.

문제 해결 팁은 로그 문제 해결(GitHub) 을 참조하세요.

수집기 측정항목

다음 NRQL 쿼리는 New Relic의 수집기 자체에서 사용 가능한 모든 메트릭을 보여줍니다.

FROM Metric SELECT uniques(metricName) WHERE metricName like ‘otelcol_%’ LIMIT MAX

문제 해결 팁은 다음을 참조하세요.

• 메트릭 문제 해결(GitHub)
• 수집기 메트릭 모니터링(GitHub)

수집기 추적

문제 해결 팁은 zPages(Github) 를 참조하십시오.