로그는 애플리케이션 로그, 시스템 생성 이벤트 또는 시스템 로그를 나타낼 수 있습니다. OpenTelemetry는 로그 데이터를 나타내는 로그 데이터 모델 을 정의했습니다.
OpenTelemetry 도구를 사용하여 로그를 보내고 애플리케이션과 상관 관계를 지정하고 New Relic에서 볼 수 있습니다.
중요
OpenTelemetry Protocol이 성숙해지고 더 많은 구성 요소가 stable 로 선언됨에 따라 2022년 9월 이전에 OTLP 끝점에서 지원하는 버전을 v0.10.0에서 최신 릴리스인 v0.16.0 이상으로 이동할 예정입니다.
커뮤니티가 보다 안정적인 OTLP 릴리스를 향해 이동함에 따라 중단을 최소화하기 위해 취할 수 있는 조치 및 v0.10.0 지원 EOL 일정에 대한 추가 커뮤니케이션이 곧 있을 예정입니다.
New Relic에 로그 보내기
OpenTelemetry Collector 및 OpenTelemetry Collector Contrib 리포지토리에는 로그 데이터를 사용하기 위한 여러 구성 요소가 포함되어 있습니다. 일반적인 패턴은 다음과 같이 수집기를 구성하는 것입니다.
- 모든 로그 수신자로부터 로그를 수신합니다. 일부 수신기 옵션에는 Filelog Receiver , Fluent Forward Receiver 및 Syslog Receiver 가 있습니다.
- 로그를 처리하여 잠재적으로 리소스 정보로 주석을 달 수 있습니다. 일부 프로세서 옵션에는 리소스 감지 프로세서 및 리소스 프로세서 가 포함됩니다.
- OTLP 내보내기를 통해 로그를 New Relic으로 내보냅니다.
애플리케이션 로그의 상관 관계 분석
애플리케이션 로그는 애플리케이션에서 생성된 다른 원격 분석 데이터와 상관 관계가 있는 경우 더 유용합니다. 서비스에 대한 OpenTelemetry 의미 체계 규칙은 service.name
을 필수 필드로 지정합니다. 동일한 service.name
을 사용하여 New Relic에 전송된 모든 애플리케이션 메트릭, 추적 및 로그 데이터는 동일한 엔티티 와 연결됩니다.
로그가 service.name
리소스 속성으로 주석 처리되는 방식에 대한 세부 사항은 애플리케이션 환경에 따라 다릅니다.
- 애플리케이션은 구조화된 JSON 로그를 생성할 수 있으며
service.name
을 다른 필드로 포함하도록 구성할 수 있습니다. service.name
속성으로 로그에 주석을 달도록 리소스 프로세서 로 구성할 수 있는 전용 Collector Agent 인스턴스와 함께 애플리케이션을 배포할 수 있습니다.
선택적으로 추가 애플리케이션 추적 컨텍스트 (실행 컨텍스트라고도 함)를 로그 메시지에 전파할 수 있습니다. 설정 및 가용성은 응용 프로그램에서 사용하는 언어 및 로깅 프레임워크에 따라 다릅니다. 일반적인 전략은 구조화된 JSON 로그를 작성하도록 애플리케이션을 설정하고 사용 가능한 로그 메시지의 지정된 추적 컨텍스트 필드 로 추적 컨텍스트를 추출하도록 구성하는 것입니다.
GitHub의 Logs in Context with Log4j2 예제는 Log4j2를 사용하는 간단한 Java 애플리케이션에 대한 종단 간 작업 예제를 보여줍니다.
OpenTelemetry 로그 보기
다음 두 가지 방법으로 로그를 볼 수 있습니다.
시간 필드
timeUnixNano
필드는 로그 데이터에 대한 OpenTelemetry 사양에 따라 선택 사항입니다. timeUnixNano
이(가) 없으면 New Relic은 New Relic 로그 타임스탬프에 대해 데이터가 수신된 시간을 사용합니다.