OpenTelemetry의 로그 지원 철학, 로그 상관관계, 레거시 및 현대적 로그 소스 처리 방식, Collector와 자동 계측 접근 방식을 설명합니다.
모든 텔레메트리 신호 중에서 로그는 아마도 가장 큰 레거시를 가지고 있습니다. 대부분의 프로그래밍 언어에는 내장 로깅 기능이 있거나 잘 알려져 있고 널리 사용되는 로깅 라이브러리가 있습니다.
메트릭과 트레이스의 경우 OpenTelemetry는 백지 상태에서 설계하는 접근 방식을 취하며, 새로운 API를 명세하고 여러 언어에서 이 API의 완전한 구현을 제공합니다.
로그에 대한 우리의 접근 방식은 다소 다릅니다. OpenTelemetry가 로깅 영역에서 성공하려면 기존 로그와 로깅 라이브러리의 레거시를 지원하는 동시에, 가능한 경우 관측 가능성 세계의 나머지 부분과 더 나은 통합과 개선을 제공해야 합니다.
이것이 본질적으로 OpenTelemetry의 로그 지원 철학입니다. 우리는 기존 로깅 솔루션을 수용하고, OpenTelemetry가 기존 로깅 라이브러리, 로그 수집 및 처리 솔루션과 잘 작동하도록 보장합니다.
안타깝게도 기존 로깅 솔루션은 현재 다른 관측 가능성 신호와의 통합이 약합니다. 로그는 일반적으로 사용 가능한, 그리고 종종 불완전한 상관 정보(예: 시간 및 출처 속성)를 사용하는 링크 형태로 트레이싱 및 모니터링 도구에서 제한적인 지원만 받습니다. 이러한 상관관계는 속성이 종종 서로 다른 수단(예: 서로 다른 수집 에이전트 사용)을 통해 로그, 트레이스, 메트릭에 추가되기 때문에 취약할 수 있습니다. 로그의 출처와 소스(예: 애플리케이션 및 애플리케이션이 실행되는 위치/인프라)에 대한 정보를 트레이스 및 메트릭과 일관된 방식으로 포함하고, 모든 텔레메트리 데이터를 정확하고 견고한 방식으로 완전히 상관시킬 수 있도록 하는 표준화된 방법이 없습니다.
마찬가지로, 로그에는 요청 실행 컨텍스트를 전파하고 기록하는 표준화된 방법이 없습니다. 분산 시스템에서는 이로 인해 시스템의 서로 다른 구성 요소에서 수집된 로그가 서로 분리된 집합이 되는 경우가 많습니다.
오늘날 전형적인 비OpenTelemetry 관측 가능성 수집 파이프라인은 다음과 같습니다.
종종 서로 다른 라이브러리와 서로 다른 수집 에이전트가 서로 다른 프로토콜과 데이터 모델을 사용하며, 텔레메트리 데이터는 함께 잘 작동하는 방법을 모르는 별도의 백엔드로 들어가게 됩니다.
분산 트레이싱은 트레이스 컨텍스트 전파라는 개념을 도입했습니다.
그러나 근본적으로 로그가 동일한 컨텍스트 전파 개념을 채택하지 못할 이유는 없습니다. 기록된 로그가 트레이스 컨텍스트 식별자(예: trace 및 span ID 또는 사용자 정의 baggage)를 포함한다면 로그와 트레이스 간의 상관관계가 훨씬 풍부해지고, 분산 시스템의 서로 다른 구성 요소에서 생성된 로그 간의 상관관계도 가능해집니다. 이는 분산 시스템에서 로그의 가치를 크게 높여줄 것입니다.
이는 관측 가능성 도구의 유망한 진화 방향 중 하나입니다. 로그와 트레이스 및 메트릭 간의 상관관계를 표준화하고, 로그를 위한 분산 컨텍스트 전파 지원을 추가하며, 로그, 트레이스, 메트릭의 소스 속성 부여를 통합하면 레거시 및 현대 시스템 모두에서 관측 가능성 정보의 개별적 가치와 결합된 가치가 증가할 것입니다. 이것이 OpenTelemetry의 로그, 트레이스, 메트릭 수집에 대한 비전입니다.
우리는 OpenTelemetry 데이터 모델을 준수하는 방식으로 로그, 트레이스, 메트릭을 내보내고, 데이터를 OpenTelemetry Collector를 통해 전송하며, 그곳에서 데이터를 일관된 방식으로 보강하고 처리할 수 있습니다. 예를 들어 Collector는 Kubernetes Pod에서 오는 모든 텔레메트리 데이터에 Pod를 설명하는 여러 속성을 추가할 수 있으며, 이는 애플리케이션이 특별한 작업을 하지 않아도 k8sattributesprocessor를 사용해 자동으로 수행될 수 있습니다. 가장 중요한 점은 이러한 보강이 3가지 신호 모두에 대해 완전히 일관되다는 것입니다. Collector는 로그, 트레이스, 메트릭이 출처인 Kubernetes Pod를 설명하는 정확히 동일한 속성 이름과 값을 갖도록 보장합니다. 이를 통해 백엔드에서 Pod를 기준으로 신호를 정확하고 모호함 없이 상관시킬 수 있습니다.
트레이스와 메트릭의 경우 OpenTelemetry는 애플리케이션 개발자가 트레이스와 메트릭을 내보내기 위해 사용해야 하는 새로운 API를 정의합니다.
로그의 경우 우리는 같은 길을 택하지 않았습니다. 우리는 로깅 영역에 훨씬 더 크고 다양한 레거시가 존재한다는 점을 깨달았습니다. 서로 다른 언어에는 각자 고유한 API를 가진 많은 기존 로깅 라이브러리가 있습니다. 많은 프로그래밍 언어는 특정 로깅 라이브러리를 사용하는 확립된 표준을 가지고 있습니다. 예를 들어 Java 세계에는 Log4j나 Logback 같은 매우 인기 있고 널리 사용되는 여러 로깅 라이브러리가 있습니다.
또한 특정 형식으로 로그를 내보내는 셀 수 없이 많은 기존 사전 구축 애플리케이션 또는 시스템이 있습니다. 이러한 애플리케이션의 운영자는 로그가 어떻게 출력되는지에 대해 제어권이 없거나 제한적입니다. OpenTelemetry는 이러한 로그를 지원해야 합니다.
위와 같은 로깅 영역의 상태를 고려하여 우리는 다음과 같은 접근 방식을 취했습니다.
OpenTelemetry는 로그 데이터 모델을 정의합니다. 데이터 모델의 목적은 LogRecord가 무엇인지, 로깅 시스템이 어떤 데이터를 기록, 전송, 저장, 해석해야 하는지에 대해 공통된 이해를 갖는 것입니다.
새롭게 설계되는 로깅 시스템은 OpenTelemetry의 로그 데이터 모델에 따라 로그를 내보낼 것으로 기대됩니다. 이에 대해서는 뒤에서 더 설명합니다.
기존 로그 형식은 OpenTelemetry 로그 데이터 모델로 모호함 없이 매핑될 수 있습니다. OpenTelemetry Collector는 이러한 로그를 읽고 OpenTelemetry 로그 데이터 모델로 변환할 수 있습니다.
OpenTelemetry는 LogRecord를 내보내기 위한 Logs API를 정의합니다. 이것은 주로 라이브러리 작성자가 기존 로깅 라이브러리와 OpenTelemetry 로그 데이터 모델 사이를 연결하기 위해 API를 사용하는 log appender를 구축하도록 설계되었습니다. Logs API는 애플리케이션이 직접 사용할 수도 있으며, 이는 특히 다음과 같은 경우에 중요합니다.
기존 로깅 라이브러리는 일반적으로 OpenTelemetry에 정의된 것보다 훨씬 더 풍부한 기능 집합을 제공한다는 점에 유의하십시오. 그럼에도 언어는 직접 사용할 때 더 나은 개발자 경험을 위해 인체공학적 API를 제공할 수 있습니다.
이 접근 방식은 OpenTelemetry가 기존 시스템 및 애플리케이션 로그를 읽을 수 있게 하고, 새로 구축된 애플리케이션이 풍부하고 구조화된 OpenTelemetry 준수 로그를 내보낼 수 있는 방법을 제공하며, 모든 로그가 결국 백엔드가 처리할 수 있는 일관된 로그 데이터 모델에 따라 표현되도록 보장합니다.
이 문서의 뒤에서 OpenTelemetry가 다양한 로그 소스를 어떻게 처리하는지 더 자세히 논의하겠지만, 먼저 중요한 개념인 로그 상관관계를 더 자세히 설명해야 합니다.
로그는 몇 가지 차원에서 나머지 관측 가능성 데이터와 상관시킬 수 있습니다.
실행 시간 기준. 로그, 트레이스, 메트릭은 실행이 일어난 시점 또는 실행이 지속된 시간 범위를 기록할 수 있습니다. 이것은 가장 기본적인 형태의 상관관계입니다.
실행 컨텍스트 기준. 이는 트레이스 컨텍스트라고도 합니다. span에는 실행 컨텍스트(trace 및 span ID뿐 아니라 사용자 정의 컨텍스트)를 기록하는 것이 표준적인 관행입니다. OpenTelemetry는 가능한 경우 LogRecord에 TraceId와 SpanId를 포함함으로써 이 관행을 로그로 확장합니다. 이를 통해 동일한 실행 컨텍스트에 해당하는 로그와 트레이스를 직접 상관시킬 수 있습니다. 또한 특정 요청 실행에 참여한 분산 시스템의 서로 다른 구성 요소에서 나온 로그를 상관시키는 것도 가능합니다.
텔레메트리의 출처 기준. 이는 Resource 컨텍스트라고도 합니다. OpenTelemetry의 트레이스와 메트릭은 출처 Resource에 대한 정보를 포함합니다. 우리는 LogRecord에 Resource를 포함함으로써 이 관행을 로그로 확장합니다.
이 3가지 상관관계는 강력한 탐색, 필터링, 질의 및 분석 기능의 기반이 될 수 있습니다. OpenTelemetry는 이러한 상관관계를 가능하게 하는 방식으로 로그를 기록하고 수집하는 것을 목표로 합니다.
여러 종류의 레거시 및 현대적 로그 소스를 구분하는 것은 중요합니다. 첫째, 이는 우리가 이러한 로그에 정확히 어떻게 접근하고 어떻게 수집하는지에 직접적인 영향을 미칩니다. 둘째, 우리는 이러한 로그가 어떻게 생성되는지, 그리고 로그에 포함할 수 있는 정보를 수정할 수 있는지에 대해 서로 다른 수준의 제어권을 가집니다.
아래에서는 여러 로그 범주를 나열하고, 관측 가능성 솔루션에서 더 나은 경험을 위해 각 범주별로 무엇을 할 수 있는지 설명합니다.
이들은 운영 체제에 의해 생성되는 로그이며 우리가 제어할 수 없습니다. 형식을 변경하거나 어떤 정보가 포함되는지에 영향을 줄 수 없습니다. 시스템 형식의 예로는 Syslog와 Windows Event Logs가 있습니다.
시스템 로그는 호스트 수준(물리, 가상 또는 컨테이너화된 환경일 수 있음)에서 작성되며 미리 정의된 형식과 내용을 가집니다(애플리케이션도 표준 시스템 로그에 레코드를 쓸 수 있다는 점에 유의하십시오. 이 경우는 아래 서드파티 애플리케이션 섹션에서 다룹니다).
로그에 기록된 시스템 작업은 요청 실행의 결과일 수 있습니다. 그러나 시스템 로그는 일반적으로 트레이스 컨텍스트에 대한 데이터를 포함하지 않거나, 포함하더라도 매우 특이해서 식별, 파싱 및 사용이 어렵습니다. 이 때문에 시스템 로그에 대해 트레이스 컨텍스트 상관관계를 수행하는 것은 거의 불가능합니다. 그러나 우리는 수집 시점에 사용 가능한 호스트 정보를 나타내는 리소스 컨텍스트로 시스템 로그를 자동 보강할 수 있으며 또 그래야 합니다. 여기에는 호스트 이름, IP 주소, 컨테이너 또는 Pod 이름 등이 포함될 수 있습니다. 이 정보는 수집된 로그 데이터의 Resource 필드에 추가되어야 합니다.
OpenTelemetry Collector는 시스템 로그를 읽고(링크 TBD) resourcedetection 프로세서를 사용하여 자동으로 Resource 정보로 보강할 수 있습니다.
이들은 Kubernetes 이벤트와 같은 다양한 인프라 구성 요소에 의해 생성되는 로그입니다. 시스템 로그와 마찬가지로 인프라 로그에는 트레이스 컨텍스트가 없으며, 노드, Pod, 컨테이너 등에 대한 정보인 리소스 컨텍스트로 보강될 수 있습니다.
OpenTelemetry Collector 또는 다른 에이전트를 사용하여 가장 일반적인 인프라 컨트롤러의 로그를 조회할 수 있습니다.
애플리케이션은 일반적으로 표준 출력, 파일 또는 기타 특수 매체(예: 애플리케이션용 Windows Event Logs)에 로그를 작성합니다. 이러한 로그는 매우 다양한 형식을 가질 수 있으며, 다음과 같은 변형 범위에 걸쳐 있습니다.
구조화된 데이터를 쉽게 자동화되고 신뢰할 수 있는 방식으로 파싱할 수 없는 자유 형식 텍스트 형식.
구조화된 데이터를 추출하기 위해 파싱할 수 있는, 더 잘 정의되고 때로는 사용자 정의 가능한 형식(예: Apache 로그 또는 RFC5424 Syslog).
공식적으로 구조화된 형식(예: 잘 정의된 스키마를 가진 JSON 파일 또는 Windows Event Log).
수집 시스템은 가장 일반적으로 사용되는 애플리케이션을 식별할 수 있어야 하며, 이러한 로그를 구조화된 형식으로 변환할 수 있는 파서를 갖추어야 합니다. 시스템 및 인프라 로그와 마찬가지로 애플리케이션 로그에는 요청 컨텍스트가 없는 경우가 많지만, 호스트와 인프라를 설명하는 속성뿐 아니라 애플리케이션 수준 속성(예: 애플리케이션 이름, 버전, 데이터베이스 이름 - DBMS인 경우 등)을 포함하는 리소스 컨텍스트로 보강될 수 있습니다.
OpenTelemetry는 Collector의 filelog receiver를 사용하여 애플리케이션 로그를 수집할 것을 권장합니다. 또는 FluentBit와 같은 다른 로그 수집 에이전트가 로그를 수집한 다음 전송하여 OpenTelemetry Collector에서 로그를 추가로 처리하고 보강할 수 있습니다.
이들은 사내에서 생성된 애플리케이션입니다. 로그 수집 인프라를 설정하는 일을 맡은 사람들은 때때로 이러한 애플리케이션을 수정하여 로그가 작성되는 방식과 로그에 포함되는 정보를 바꿀 수 있습니다. 예를 들어 애플리케이션의 로그 포매터를 일반 텍스트 대신 JSON을 출력하도록 재구성하여 로그 수집의 신뢰성을 개선할 수 있습니다.
이러한 애플리케이션에 대한 더 큰 수정은 개발자가 수동으로 수행할 수 있습니다. 예를 들어 모든 로그 문에 트레이스 컨텍스트를 추가하는 것입니다. 그러나 필요한 노력 때문에 이는 실제로는 매우 드물 가능성이 큽니다.
수동 작업과는 달리, 애플리케이션이 사용하는 트레이스 로깅 라이브러리를 수정하여 모든 로그 문에 trace ID나 span ID와 같은 트레이스 컨텍스트를 자동으로 출력하게 하는 완전 또는 반자동 계측 솔루션을 제공함으로써, 더 적은 노력으로 애플리케이션 로그를 “업그레이드”할 수 있는 흥미로운 기회가 있습니다. 표준 준수 요청 전파가 사용되는 경우, 예를 들어 W3C TraceContext를 통해 들어오는 요청에서 트레이스 컨텍스트를 자동으로 추출할 수 있습니다. 또한 애플리케이션에서 나가는 요청에도 동일한 트레이스 컨텍스트 데이터를 주입할 수 있으므로, 애플리케이션 전반에 걸친 컨텍스트 전파가 이루어지고 이런 방식으로 계측할 수 있는 모든 애플리케이션에서 수집한 로그에 완전한 트레이스 컨텍스트를 가질 기회가 생깁니다.
일부 로깅 라이브러리는 이러한 방식으로 비교적 쉽게 확장되도록 설계되어 있습니다. 실제로 라이브러리를 수정할 필요는 없으며, 대신 이러한 라이브러리를 위한 “log appender” 또는 “log bridge” 구성 요소를 구현하고 이 구성 요소에서 추가적인 LogRecord 보강을 구현할 수 있습니다.
이러한 애플리케이션에서 로그를 수집하는 방법은 일반적으로 2가지가 있습니다.
첫 번째 접근 방식은 로그가 파일 또는 표준 출력에 기록된다고 가정할 때, 파일 로그를 읽고, 이를 tail하며, 로그 로테이션이 사용될 때 올바르게 동작하고, 선택적으로 로그를 파싱하여 더 구조화된 형식으로 변환할 수 있는 능력을 요구합니다. 파싱은 서로 다른 파서 유형에 대한 지원이 필요하며, 사용자 정의 형식을 파싱하도록 구성할 수 있어야 하고 사용자 정의 파서를 추가할 수 있는 기능도 필요합니다. 파서가 지원해야 하는 일반적인 형식의 예는 다음과 같습니다: CSV, Common Log Format, Labeled Tab-separated Values (LTSV), key-value Pair 형식, JSON 등. 이 접근 방식을 지원하기 위해 OpenTelemetry는 OpenTelemetry Collector를 사용하여 로그를 수집할 것을 권장합니다.
또는 Collector에 필요한 파일 읽기 및 파싱 기능이 없다면 FluentBit와 같은 다른 로그 수집 에이전트가 로그를 수집한 다음 로그를 전송하여 OpenTelemetry Collector로 보낼 수 있습니다.
중간 매체를 사용하는 장점은 애플리케이션이 로그를 어떻게 생성하고 어디에 기록하는지에 대해 변경이 없거나 최소한만 필요하다는 점입니다. 단점은 종종 만만치 않은 로그 파일 읽기 및 파싱 기능이 필요하다는 점입니다. 출력 형식이 잘 정의되어 있지 않다면 파싱은 신뢰할 수 없을 수도 있습니다. 트레이스 컨텍스트 기록 및 파싱에 대한 자세한 내용은 비OTLP 로그 형식의 트레이스 컨텍스트를 참조하십시오.
두 번째 접근 방식은 애플리케이션을 수정하여 로그가 네트워크 프로토콜, 예를 들어 OTLP를 통해 출력되도록 하는 것입니다. 이를 달성하는 가장 편리한 방법은 일반적으로 사용되는 로깅 라이브러리에 대한 애드온 또는 확장을 제공하는 것입니다. 이러한 애드온은 해당 네트워크 프로토콜을 통한 전송을 구현하며, 일반적으로 로깅 대상을 변경하기 위해 애플리케이션 코드에 작고 국소적인 변경만 필요합니다.
애플리케이션 로그도 서드파티 애플리케이션의 경우와 유사하게 리소스 컨텍스트로 보강되며, 따라서 모든 컨텍스트 차원에 걸쳐 완전한 상관 정보를 가질 가능성이 있습니다.
이 접근 방식의 단점은 로그를 로컬 파일에 두는 단순함(예: 로컬에서 로그 파일을 쉽게 검사할 수 있는 기능)이 사라지고, OpenTelemetry의 로깅 접근 방식에 대한 전면적인 수용이 필요하다는 점입니다. 또한 이 접근 방식은 로그를 전달해야 하는 대상이 OpenTelemetry가 보낼 수 있는 네트워크 프로토콜을 통해 로그를 수신할 수 있을 때만 작동합니다.
이 접근 방식의 장점은 잘 정의되고 공식적이며 고도로 구조화된 형식으로 로그를 내보내고, 파서, 로그 tailing, 로테이션과 같은 파일 로그와 관련된 모든 복잡성을 제거한다는 점입니다. 또한 로그 수집 에이전트를 사용하지 않고도 로그를 로깅 백엔드로 직접 보낼 수 있는 가능성을 제공합니다.
위에서 설명한 두 접근 방식을 모두 용이하게 하기 위해 OpenTelemetry는 API와 SDK를 제공하며, 이는 기존 로깅 라이브러리와 함께 사용되어 내보내는 로그에 트레이스 컨텍스트를 자동으로 주입하고 OTLP를 통해 로그를 쉽게 전송하는 방법을 제공합니다. 각 로깅 문을 수정하는 대신 log appenders는 API를 사용해 기존 로깅 라이브러리의 로그를 OpenTelemetry 데이터 모델로 연결하고, SDK는 로그가 어떻게 처리되고 내보내지는지를 제어합니다. 애플리케이션 개발자는 애플리케이션 시작 시 Appender와 SDK만 구성하면 됩니다.
이들은 그린필드 개발입니다. OpenTelemetry는 이러한 애플리케이션에서 로그를 어떻게 내보낼지(트레이스 및 메트릭과 함께)에 대한 권장 사항과 모범 사례를 제공합니다.
애플리케이션에는 로그를 내보내는 여러 옵션이 있습니다.
OpenTelemetry 로그 appender와 함께 기존 로깅 라이브러리 사용: 해당 언어와 프레임워크에서는 자동 계측 또는 OpenTelemetry 로그 appender를 사용하도록 로깅 라이브러리를 간단히 구성하는 것이 컨텍스트가 보강된 로그를 내보내는 가장 쉬운 방법입니다. 앞서 설명했듯이, 수동 계측 사례를 지원하기 위해 일부 인기 있는 로깅 라이브러리에 대한 확장을 제공합니다. 이러한 확장은 로그에 트레이스 컨텍스트를 포함하는 것을 지원하고, 로그를 텍스트 파일로 표현할 필요 없이 OTLP 프로토콜을 통해 백엔드 또는 Collector로 보낼 수 있게 합니다.
OpenTelemetry Logs API 직접 사용: 애플리케이션은 Logs API를 직접 사용하여 구조화된 로그와 이벤트를 내보낼 수 있습니다. 이 접근 방식은 의미 규약을 따르는 이벤트를 내보내는 데 잘 맞으며, 서로 다른 신호 전반에서 사용되는 속성을 더 쉽게 재사용할 수 있게 합니다. 언어가 더 편리한 인체공학적 API를 제공할 수 있다는 점에 유의하십시오.
접근 방식과 관계없이, 내보내는 로그에는 애플리케이션별 리소스 컨텍스트(예: 프로세스 ID, 프로그래밍 언어, 로깅 라이브러리 이름 및 버전 등)가 자동으로 추가됩니다. 이러한 로그에는 모든 컨텍스트 차원에 걸친 완전한 상관관계가 제공됩니다.
이것이 일반적인 새 애플리케이션이 OpenTelemetry API, SDK 및 기존 로그 라이브러리를 사용하는 방식입니다.
이 명세에 따른 로그 수집을 가능하게 하기 위해 우리는 OpenTelemetry Collector를 사용합니다.
로그 수집을 가능하게 하기 위해 다음 기능이 존재합니다.
로그 데이터 모델을 기반으로 한 로그 데이터 유형 및 로그 파이프라인 지원. 여기에는 로그 데이터에서 동작할 수 있는 attributesprocessor 같은 프로세서가 포함됩니다.
텍스트 파일에서 로그를 읽고, 파일을 tail하며, 일반적인 로그 로테이션 방식을 이해하고, 로그 파일 생성 시 디렉터리를 감시하며, 파일 위치를 체크포인트하고 체크포인트부터 읽기를 재개하는 기능. 이 기능은 Collector의 filelog receiver를 사용하거나 외부에서 실행되는 에이전트(예: FluentBit)를 사용해 구현됩니다.
일반적인 텍스트 형식의 로그를 파싱하고, 최종 사용자가 필요에 따라 파싱 형식을 사용자 정의하고 사용자 정의 파서를 추가할 수 있도록 하는 기능. 이를 위해 Collector의 parsers 또는 외부 에이전트에서의 파싱이 사용됩니다.
Syslog와 같은 로그용 일반 네트워크 프로토콜을 통해 로그를 수신하고, 이를 이 명세에서 정의한 의미 규약에 따라 해석하는 기능. 이를 위해 FluentBit 또는 유사한 에이전트가 사용됩니다. 시간이 지나면서 이 기능의 일부는 Collector로 직접 이전될 수 있습니다.
Syslog와 같은 로그용 일반 네트워크 프로토콜 또는 벤더별 로그 형식을 통해 로그를 전송하는 기능. Collector에는 이 기능을 직접 구현하는 exporter가 포함되어 있습니다.
우리는 가장 인기 있는 로깅 라이브러리 대부분에 대해 자동 계측을 제공할 수 있습니다. 자동 계측된 로깅 문은 다음을 수행합니다.
들어오는 트레이스 컨텍스트를 읽습니다(이는 자동 계측 라이브러리가 수행하는 더 넓은 범위의 계측의 일부입니다).
요청 컨텍스트의 trace ID 및 span ID 필드를 로깅 컨텍스트로 사용하도록 로깅 라이브러리를 구성하고, 이를 모든 로그 문에 자동으로 포함합니다.
이는 특정 언어(예: Java)에서 가능하며, 이를 수행하는 기존 오픈 소스 라이브러리를 재사용할 수 있습니다.
추가적인 선택적 수정으로는 파일이나 표준 출력에 기록하는 대신 또는 그와 더불어 OTLP를 통해 로그를 백엔드로 직접 보내도록 로거를 자동 계측하는 것이 있습니다.
이 페이지가 도움이 되었나요?
감사합니다. 여러분의 피드백에 감사드립니다!
이 페이지를 어떻게 개선할 수 있는지 알려주세요. 여러분의 피드백에 감사드립니다!
