뉴렐릭의 OpenTelemetry 로그

이 문서는 뉴렐릭이 전용 OTLP 엔드포인트를 통해 수신된 OpenTelemetry 로그를 어떻게 처리하는지 설명합니다.

OpenTelemetry 로그를 뉴렐릭으로 보내는 방법은 크게 두 가지가 있습니다.

수집기로 직접 전송:
- 애플리케이션이 로그를 뉴렐릭 OTLP 엔드포인트로 직접 보낼 수 있습니다.
- 구현과 관련된 자세한 내용은 OpenTelemetry 언어 문서를 참조하고, 뉴렐릭을 사용한 모니터링 서비스에 대한 자세한 내용은 OpenTelemetry APM 모니터링을 참조하시기 바랍니다.
파일 또는 stdout를 통한 전송:
- 파일이나 표준 출력(stdout)에 기록된 애플리케이션 로그를 스크랩을 하는 방법입니다.
- OpenTelemetry 수집기가 보통 이 작업에 사용되며, 스크랩된 로그는 뉴렐릭 OTLP 엔드포인트로 전달됩니다.
- 보다 자세한 정보는 아래의 OpenTelemetry 리소스를 참조하십시오.

선택한 수집 방법에 관계없이 성공적인 통합을 위해서는 로그를 해당 엔드포인트로 내보내도록 로그 소스를 구성해야 합니다. 계속 진행하기 전에 엔드포인트 설정 요구 사항을 확인하십시오.

OTLP 로그 레코드 매핑

뉴렐릭은 OTLP 로그 레코드를 Log 데이터 유형에 매핑합니다. 아래 표는 LogRecord proto 메시지의 필드가 뉴렐릭 Log에 매핑되는 방식을 설명합니다.

OTLP `logs.proto` 필드	뉴렐릭 `Log` 필드
`ResourceLogs.Resource.attributes`	각 키/값은 `Log` 필드의 속성입니다 [1]
`ScopeLogs.InstrumentationScope.name`	`otel.library.name`
`ScopeLogs.InstrumentationScope.version`	`otel.library.version`
`ScopeLogs.InstrumentationScope.attributes`	각 키/값은 `Log` 필드의 속성입니다 [1]
`LogRecord.time_unix_nanos`	`timestamp` [2]
`LogRecord.severity_number`	`severity.number`
`LogRecord.severity_text`	`severity.text`
`LogRecord.body`	`message`, 또는 구문 분석이 된 속성 [3]
`LogRecord.attributes`	각 키/값은 `Log` 필드의 속성입니다 [1]
`LogRecord.dropped_attribute_count`	`otel.dropped_attributes_count`
`LogRecord.flags`	`w3c.flags` (정수)
`LogRecord.trace_id`	`trace.id`
`LogRecord.span_id`	`span.id`

표 각주

[1] 리소스 속성, 범위 속성, 로그 레코드 속성, 최상위 레벨 로그 레코드 필드 및 LogRecord.body의 구문 분석된 속성이 충돌하는 경우 [3] 선례의 순서(높은 순에서 낮은 순)는 LogRecord.body -> 최상위 레벨 LogRecord.* 필드 > LogRecord.attributes > ScopeLogs.InstrumentationScope.attributes > ResourceLogs.Resource.attributes입니다.

뉴렐릭 OTLP 엔드포인트가 지원하는 속성 유형에 대한 자세한 내용은 OTLP 속성 유형을 참조하고, 속성에 대해 수행되는 유효성 검사에 대한 자세한 내용은 OTLP 속성 제한을 참조하십시오.

[2] LogRecord.time_unix_nanos가 없으면 timestamp가 뉴렐릭이 데이터를 수신한 시간으로 설정됩니다.

[3] 로그 구문 분석은 LogRecord.body에 적용되어 다음에서 속성을 추출하려고 시도합니다.

평문 로그 텍스트: 문자열 값은 message 속성으로 설정됩니다.
문자열화된 JSON: 로그가 JSON으로 포맷되었지만 평문 텍스트 문자열로 전송되는 경우, 키/값 쌍은 결과 로그의 속성이 됩니다. 자세한 내용은 JSON 구문 분석 문서를 참조하십시오. 이 기능은 파일이나 stdout에서 로그를 수집할 때 특히 유용합니다. 이 경우 로그 레코드(APM 서비스 상호 연관에 필요)와 연결된 리소스 속성이 없고 LogRecord.trace_id /LogRecord.span_id(트레이스 상호 연관에 필요)에 대한 값이 없는 것이 일반적입니다. 필수 필드를 성공적으로 구문 분석할 수 있으면 문맥적 로그가 의도한 대로 작동합니다.
맵 구조: 데이터가 OTLP 사양에 따라 맵으로 포맷된 경우 JSON 구문 분석과 유사하게 속성으로 구문 분석되고 평면화됩니다. 자세한 내용은 JSON 구문 분석 문서를 참조하십시오.

OpenTelemetry APM 서비스와의 상관관계

로그에 필수 속성이 포함된 경우 로그는 서비스 엔터티와 상호 연관됩니다. 일반적으로 이는 ResourceLogs.Resource.attributes 같은 로그의 리소스 속성에서 나오지만 OTLP 매핑의 각주 3에 설명된 대로 LogRecord.body에서 구문 분석이 될 수도 있습니다.

서비스의 로그를 보려면 해당 서비스의 로그 페이지로 이동하십시오.

트레이스와의 상호 연관

trace.id와 span.id 속성을 완료(resolve) 할 수 있는 경우 로그는 트레이스와 상호 연관됩니다. 일반적으로 이는 LogRecord.trace_id와 LogRecord.span_id 필드에서 나오지만 OTLP 매핑의 각주 3번에 설명된 대로 LogRecord.body에서 구문 분석이 될 수도 있습니다.

특정 트레이스의 컨텍스트에서 기록된 로그를 보는 방법은 두 가지가 있습니다.

트레이스 세부정보 페이지에서 로그 탭으로 이동합니다.
서비스의 로그 페이지로 이동하여 로그를 클릭하여 로그 세부 정보를 엽니다. 트레이스와 연관이 된 경우 로그 세부정보에서 트레이스 세부정보로 이동할 수 있습니다.

뉴렐릭 커스텀 이벤트로 로그

OpenTelemetry는 이벤트를 공백 없는 EventName을 갖는 LogRecord로 정의합니다. 커스텀 이벤트는 뉴렐릭 플랫폼의 핵심 신호입니다. 이름은 동일하지만, OpenTelemetry Event와 뉴렐릭 커스텀 이벤트는 동일한 개념이 아닙니다.

OpenTelemetry EventName은 커스텀 이벤트 유형과 포맷이나 의미가 다릅니다. OpenTelemetry 이벤트 이름은 네임스페이스로 완전히 정규화되고 소문자 스네이크 케이스를 따르지만(예: com.acme.my_event), 커스텀 이벤트 유형은 파스칼 케이스를 따릅니다. (예: MyEvent)
OpenTelemetry 이벤트는 향상된 구조화된 로그라고 생각하면 됩니다. 구조화된 로그와 마찬가지로, 데이터는 자유로운 형식의 텍스트가 아닌 키/값 쌍으로 인코딩됩니다. 또한, EventName은 발생한 이벤트의 클래스/유형을 명확하게 나타내는 신호 역할을 합니다. 커스텀 이벤트는 SELECT * FROM MyEvent를 사용하여 NRQL로 액세스할 수 있는 완전히 새로운 이벤트 유형으로 취급됩니다.

이러한 차이점으로 인해 OpenTelemetry 이벤트는 뉴렐릭 Logs로 수집됩니다. 대부분의 경우 OpenTelemetry 이벤트는 뉴렐릭 커스텀 이벤트보다 뉴렐릭 Logs와 더 유사하기 때문입니다.

그러나 LogRecord.attributes에 newrelic.event.type=<EventType> 포맷으로 항목을 추가하여 OpenTelemetry LogRecord를 커스텀 이벤트로 수집해야 한다는 것을 명시할 수 있습니다 .

예를 들어 속성이 newrelic.event.type=MyEvent인 LogRecord는 type=MyEvent를 사용하여 커스텀 이벤트로 수집되고 SELECT * FROM MyEvent를 사용하여 NRQL 통해 액세스할 수 있습니다.