OpenTelemetry 로깅: 소개

OTel 로깅은 다양한 소스, 시스템 및 형식의 로그 데이터를 원래의 의미를 유지하면서 단일한 언어 중립 모델로 변환할 수 있도록 명확하고 통합된 매핑 구조를 제공합니다.

공급업체에 종속되지 않는 구조화된 데이터 모델을 통해 관측 가능성 툴은 로그를 더 쉽게 그리고 안정적으로 파싱하고 메타데이터를 추가하며 로그를 지표 및 추적과 연관 지어 엔드투엔드 가시성을 확보할 수 있습니다.

OTel 로깅은 전체 IT 아키텍처를 다시 계측하지 않고도 관측 가능성 백엔드를 자유롭게 교체하거나 혼합할 수 있도록 하며, 이로 인해 현대의 클라우드 네이티브 시스템에서 업계 표준 계측 방식으로 자리 잡았습니다. 이러한 기능은 IT 팀과 사이트 신뢰성 엔지니어(SRE)가 각 공급업체, 스택 및 장치가 서로 다른 로깅 스키마와 전송 프로토콜을 사용하는 환경에서 발생하는 관측 가능성 공백과 데이터 단편화 문제를 방지하는 데 도움을 줍니다.

OTel 로깅은 신호 간 자동 상관관계를 지원하여 디버깅을 크게 향상시키고 관측 가능성 공급업체 종속성을 줄입니다.

OpenTelemetry 로그는 OpenTelemetry의 핵심 구성 요소입니다. OpenTelemetry는 애플리케이션, 시스템 및 장치 계측을 위한 오픈 소스 관측 가능성 프레임워크로, 소프트웨어 개발 키트(SDK), 공급업체에 종속되지 않는 애플리케이션 프로그래밍 인터페이스(API) 및 기타 툴 모음을 포함합니다.

계측 코드는 과거에 매우 다양하게 존재했으며, 네트워크상의 모든 애플리케이션과 서비스에서 데이터를 수집할 수 있는 단일 상용 툴을 제공하는 공급자는 없었습니다. 이러한 기능 격차로 인해 다양한 프로그래밍 언어, 형식 및 런타임 환경에서 데이터를 수집하는 것이 어려웠고 경우에 따라 불가능했습니다.

기존 관측 가능성 접근 방식에서는 백엔드 인프라 및 구성 요소를 변경하는 작업이 시간과 노동이 많이 드는 과정이었습니다.

예를 들어 개발 팀이 백엔드 툴을 교체하려면 코드를 완전히 다시 계측하고 텔레메트리 데이터를 새 서버로 전송하기 위해 새로운 에이전트(자동 빌드 및 릴리스 작업을 수행하는 소프트웨어 구성 요소)를 구성해야 했습니다. 이러한 분산된 접근 방식은 데이터 사일로와 혼란을 초래하여 성능 문제를 효과적으로 해결하기 어렵게 만들었습니다.

OpenTelemetry는 텔레메트리 데이터가 수집, 분석 및 백엔드 플랫폼으로 전송되는 방식을 표준화함으로써 관측 가능성 툴의 중요한 발전을 이루었습니다. 이는 커뮤니티 주도 표준을 기반으로 한 오픈 소스 솔루션으로, 시스템 동작과 보안에 대한 데이터를 수집하고 분산 에코시스템에서 모니터링 및 관측 가능성을 간소화할 수 있도록 팀을 지원했습니다.

OpenTelemetry 로깅은 통합된 관측 가능성 파이프라인의 일부로 로그 레코드를 생성, 구조화, 전송 및 전달하는 여러 협력 구성 요소에 의존합니다. 여기에는 다음이 포함됩니다.

로그 레코드는 OpenTelemetry에서 단일 로그 이벤트를 나타내는 핵심 데이터 구조입니다. 이는 필드와 의미를 정의하는 표준 데이터 모델을 따르므로 서로 다른 언어와 시스템에서 생성된 로그도 백엔드에서 일관되게 해석될 수 있습니다.

로그 레코드는 하나의 이벤트를 설명하는 스프레드시트의 구조화된 행처럼 표시되며 “무슨 일이 발생했는가”, “언제 발생했는가”, “얼마나 중요한가”, “어디에서 발생했는가”와 같은 기본 질문에 답합니다.

로그 데이터 모델은 모든 언어와 시스템에서 모든 레코드가 따르는 공통 템플릿입니다. 이 모델은 어떤 최상위 필드가 존재하는지와 각 필드의 의미를 정의합니다.

일반적인 로그 데이터 모델에서는 레코드에 다음이 포함되어야 합니다.

• 타임스탬프 및 관측 타임스탬프(이벤트가 발생한 시점과 관측된 시점)

• 심각도 숫자 및 심각도 텍스트(로그 레벨), 이벤트의 중요도 설명

• 본문(주요 로그 메시지, 일반적으로 짧은 문자열 또는 JSON 객체)

• 속성(사용자 또는 HTTP 세부 정보와 같은 보다 세밀한 정보를 추가)

• 출력을 생성한 서비스와 배포 환경을 식별하는 리소스 정보

• 이벤트를 특정 요청과 연결하는 Trace ID 및 Span ID(데이터 상관관계 단순화)

데이터 모델이 부여하는 구조는 서로 다른 서비스와 기술에서 생성된 로그를 관측 가능성 파이프라인에 들어올 때 동일한 형태와 동작을 갖는 풍부하고 쿼리 가능한 텔레메트리 엔티티로 변환합니다. 로그 데이터 모델은 IT 팀이 로그를 추적과 연관시키고 서비스 또는 사용자 기준으로 그룹화하며 서로 호환되지 않는 다양한 로그 형식을 처리하는 대신 IT 환경 전반에서 동일한 방식으로 쿼리를 실행할 수 있도록 합니다.

로그 모델이 개방적이고 커뮤니티 기반이기 때문에 OTel의 계측 및 로그 파이프라인은 이식성이 있으며, 특정 단일 서비스형 소프트웨어(SaaS) 제품이나 독점 에이전트에 종속되지 않습니다. 이들은 다양한 프레임워크와 플랫폼에서 동작하며, 특히 여러 언어를 사용하는 마이크로서비스 환경에서 매우 유용합니다.

Logger는 로그 레코드를 작성하는 객체로, Java나 Python과 같은 다른 로깅 프레임워크의 로거 인스턴스와 유사합니다. 관측 가능성 플랫폼이 “이 오류를 로그로 기록하라” 또는 “이 정보 메시지를 로그로 기록하라”는 명령을 보내면 해당 메시지는 Logger로 전달됩니다.

애플리케이션이나 시스템의 각 부분은 각각의 Logger(예: “checkout”, “payments”)를 필요로 할 수 있지만, 모두 동일한 규칙에 따라 로그를 생성합니다.

Logger는 Logger Provider로부터 제공되며, 이 Provider는 Logger를 생성하고 올바른 파이프라인, 속성 및 Exporter로 구성하는 역할을 합니다.​ 소프트웨어 코드가 Logger를 요청하면 Provider는 이미 적절하게 구성된 Logger를 제공합니다.

이 설계는 시스템의 서로 다른 부분이 각기 다른 Logger를 사용하면서도 공통 구성을 공유하고 Logger Provider에 의해 중앙에서 관리되도록 합니다. 또한 모든 호출 지점을 수정하지 않고도 구현을 교체하고 로깅 동작을 전체적으로 조정할 수 있게 합니다.

OTel Collector는 다양한 소스로부터 로그 레코드를 포함한 텔레메트리 데이터를 수신, 처리 및 전송하는 별도의 서비스입니다. 애플리케이션은 로그(및 추적과 지표)를 Collector로 전송하며, Collector는 다양한 형식의 데이터를 수신해 표준화한 후 하나 이상의 백엔드로 전달합니다.

Collector는 receiver, processor 및 Exporter라는 세 가지 주요 구성 요소를 중심으로 구축된 전용 로그 파이프라인을 지원합니다.

Receiver는 OpenTelemetry Protocol(OTLP) 스트림과 파일 테일링 방식의 로그 파일과 같은 다양한 입력으로부터 로그를 수집합니다. Processor는 배치 처리, 속성 수정, 컨텍스트 보강(예: Kubernetes pod 메타데이터 추가), 필터링 및 샘플링과 같은 작업을 수행합니다. Collector 내 Exporter는 처리된 로그를 하나 이상의 대상으로 전달합니다.

로그 레코드 Exporter는 OTel Collector 또는 애플리케이션 SDK 내에 위치하며 텔레메트리 데이터가 백엔드 시스템으로 어디로, 어떻게 전달되는지를 정의합니다.

Logs SDK가 로그 레코드를 생성하고 처리한 후 Exporter는 로그 데이터 모델을 특정 프로토콜 또는 형식으로 인코딩하여 하위 “소비자”로 전송합니다. 소비자에는 OTel Collector, 관측 가능성 솔루션 또는 오픈 소스 저장소 등이 포함될 수 있습니다.

Exporter는 푸시 방식 또는 풀 방식으로 동작할 수 있으며 애플리케이션 코드를 수정하지 않고 동일한 로그 레코드를 여러 백엔드로 동시에 전송하도록 교체 및 결합할 수 있습니다. Exporter가 제공하는 유연성은 요구사항이 변경될 때 기업이 관측 가능성 아키텍처를 보다 쉽게 발전시킬 수 있도록 합니다.

Logs API와 Logs SDK는 멀티탭의 콘센트와 같은 방식으로 동작합니다. API는 콘센트 유형이고 SDK는 전기를 전달하는 멀티탭입니다.

OpenTelemetry API는 코드와 로깅 라이브러리가 호출하여 일관된 로그 항목을 생성하는 함수 집합으로 구성됩니다. 즉, Logs API는 로그가 OTel에 연결되기 위해 가져야 하는 “형태”를 정의합니다. Logs API는 이후 IT 팀이 어떤 관측 가능성 백엔드나 공급업체를 선택하더라도 동일한 API 호출이 동작하도록 보장합니다.

그러나 API는 단순한 인터페이스일 뿐입니다. 로그가 어디로 가는지 또는 어떻게 전송되는지는 결정할 수 없습니다. 이 역할을 수행하는 것이 OpenTelemetry SDK 또는 Logs SDK입니다.

Logs SDK는 API 엔드포인트로부터 로그를 받아 실제 처리를 수행합니다. 로그 레코드를 수신하고 서비스 이름이나 환경 정보 등을 추가해 보강하며 이를 배치 처리하여 전송할 수 있도록 준비합니다. 그 다음 Exporter를 사용하여 처리된 로그를 Collector 또는 로그 플랫폼으로 전송합니다.

로그 appender(로그 브리지라고도 함)는 Log4j, SLF4J와 같은 기존 로깅 라이브러리를 OpenTelemetry 로그 데이터 모델과 연결합니다.

소프트웨어 개발자가 Logs API를 직접 호출하는 대신 기존 로깅 프레임워크를 구성하여 각 기존 로그 이벤트를 OTel 로그 레코드로 변환하는 appender를 사용할 수 있습니다.

로그 브리지는 로그 레코드에 span 및 trace 컨텍스트를 주입할 수 있어 애플리케이션 코드가 추적 세부 정보를 인식하지 못하더라도 로그와 추적 간의 상관관계를 가능하게 합니다.

컨텍스트 전파 및 상관관계 메커니즘은 OpenTelemetry 로깅의 핵심 구성 요소입니다. 트레이스 span이 활성 상태일 때 로깅 브리지 또는 SDK는 각 로그 레코드에 현재 trace ID와 span ID를 자동으로 추가할 수 있습니다.

상관관계는 관측 가능성 백엔드가 동일한 요청 또는 워크플로를 나타내는 분산 추적과 로그를 연결하는 데 도움을 줍니다. 이러한 연결을 통해 팀은 문제 있는 로그 항목에서 요청의 전체 경로를 보여주는 추적으로 직접 이동할 수 있습니다. 또한 공통 리소스 및 컨텍스트 필드를 공유하는 지표, 추적 및 로그 간의 신호 교차 분석을 가능하게 합니다.

OTel은 로그 “유형”을 구조, 소스, 인코딩 또는 전송 프로토콜 기준 등 여러 방식으로 구분합니다.

구조화된 로그는 동일한 필드, 안정적인 이름 및 데이터 유형을 가진 일관된 스키마를 가지므로 관측 가능성 툴이 이를 안정적으로 파싱하고 쿼리할 수 있습니다. 로그는 JSON 또는 다른 형식으로 인코딩될 수 있지만, 구조화된 로그의 핵심은 예측 가능한 데이터 필드 집합입니다.

반구조화된 로그는 키-값 쌍이나 JSON 형태와 같은 일정한 구조를 일부 포함하지만 시간이 지나면서 스키마가 일관되지 않습니다. 자유 형식 텍스트보다 기계가 읽기 쉽지만 효과적인 분석을 위해서는 추가적인 파싱과 정규화가 필요합니다.

비구조화된 로그는 일정한 스키마가 없는 자유 형식 텍스트 메시지(임시 출력문이나 일반 텍스트 서버 로그 등)입니다. 사람이 작성하고 읽기에는 쉽지만 자동화된 시스템이 검색, 상관관계 분석 및 집계를 수행하려면 추가적인 파싱 작업이 많이 필요합니다. 

시스템 및 인프라 로그는 애플리케이션 코드가 아니라 운영 체제, 네트워크 장치, 클라우드 인프라 서비스 및 기타 플랫폼 구성 요소에 의해 생성됩니다. 이 로그는 OS 오류, 네트워크 문제 및 인프라 상태와 같은 이벤트를 기록하여 팀이 기반 환경의 상태와 성능을 이해할 수 있도록 합니다.

퍼스트파티 애플리케이션 로그는 내부 서비스와 애플리케이션에서 생성되며 일반적으로 OTel SDK, 로깅 라이브러리, 사이드카(기본 컨테이너와 함께 실행되며 동일한 리소스를 사용하는 두 번째 앱 컨테이너) 또는 에이전트를 통해 수집됩니다. 이 로그는 비즈니스 이벤트, 요청 처리, 사용자 행동 및 내부 오류를 설명합니다. 리소스 속성과 계측 범위(로그를 생성한 엔티티 내에서의 출처를 설명)를 추가하여 애플리케이션 동작에 대한 보다 완전한 정보를 제공할 수 있습니다.

타사 로그는 많은 기업 IT 환경이 의존하는 외부 서비스, 관리형 구성 요소 및 SaaS 제품(예: 외부 API 및 데이터베이스)에서 생성됩니다. OTel은 이러한 로그를 내부 로그와 함께 수집하여 외부 의존성이 전체 에코시스템에 어떤 영향을 미치는지 IT 팀이 파악할 수 있도록 합니다.

OTLP 로그는 OTLP 기본 데이터 모델로 표현되며 OTLP gRPC 또는 HTTP를 통해 전송됩니다. 각 로그는 공급업체 중립성과 추적 및 지표와의 빠른 상관관계를 위해 표준화됩니다.

파일 기반 로그는 파일(애플리케이션 로그 파일 또는 웹 서버 액세스 로그)에 기록되며, syslog 형식 로그는 syslog 프로토콜을 사용해 생성되는 메시지입니다. OTel은 일반적으로 파일을 테일링하거나 syslog 메시지를 수신하는 receiver를 사용하여 이러한 로그를 수집한 후 이를 OTel 로그 레코드로 변환하여 통합 처리합니다.

HTTP 및 JSON 로그는 JSON 형식으로 HTTP를 통해 전달됩니다. OpenTelemetry는 CSV, Common Log Format(CLF), LTSV 및 키-값 쌍도 지원합니다. 이러한 형식은 Collector에 의해 공통 OTel 로그 데이터 모델로 파싱되므로 네이티브 OTLP 로그와 동일한 방식으로 쿼리 및 상관관계 분석이 가능합니다.

SRE가 체크아웃 마이크로서비스의 관측 가능성 대시보드에서 “체크아웃 실패” 오류 증가를 확인했다고 가정해 보겠습니다. 이들은 이미 표준화되어 있고 “주문 접수” 로그 레코드마다 주문 금액, 품목 수, 추적 ID 등의 구조화된 속성이 포함된 OTel 로그를 분석하는 것으로 문제 해결을 시작할 수 있습니다.

엔지니어는 로그 속성을 쿼리하는 것만으로도 장애가 높은 주문량, 특정 배송 방식 또는 특정 지역과 관련이 있는지 빠르게 확인할 수 있습니다. 또한 OTel은 모든 텔레메트리 신호 전반에서 일관된 타임스탬프와 리소스 메타데이터를 사용하기 때문에 로그, 추적 및 지표 전반에서 시간 범위를 정렬할 수 있습니다.

엔지니어는 특정 결제 공급자를 통해 처리된 주문만 실패하고 있음을 확인합니다. 해당 공급자 속성을 공유하는 모든 로그를 추적하여 반복적인 세션 타임아웃을 발견합니다. 이러한 근거를 바탕으로 IT 팀은 사고를 적절한 담당자에게 신속히 전달하고 다른 공급자로 전환하는 등의 완화 전략을 실행할 수 있습니다.

OTel 로깅은 수집, 표준화, 상관관계 분석 및 로그 전송 절차 측면에서 기존 로깅과 크게 다릅니다. 

기존 로깅 시스템은 로그 패턴을 기반으로 로그 집계, 인덱싱, 검색 및 경고에 초점을 맞춥니다. 이들은 텍스트 검색 및 과거 데이터 분석에는 강력하지만 일반적으로 로그를 다른 텔레메트리 데이터와 분리된 상태에서 분석합니다.

기존 로깅 방식은 주로 텍스트 메시지를 로컬에 기록하는 데 초점을 두며 개발자가 단일 애플리케이션 또는 호스트에서 문제를 디버깅할 수 있도록 합니다. 이 방식은 사용자가 파일을 읽고 필터링한 뒤 나중에 로그 집계 시스템으로 전송할 것을 전제로 합니다. 또한 일반적으로 서비스 간 표준이 없는 일반 텍스트, 느슨하게 구조화된 JSON 또는 프레임워크별 형식과 같은 임시 형식을 사용합니다.

각 개발 팀이 자체 필드와 명명 규칙을 사용할 수 있기 때문에 시스템 간 분석은 번거로운 과정이 됩니다.

기존 로깅 툴은 상관관계 분석이나 마이그레이션 기능을 기본적으로 제공하지 않는 경우가 많기 때문에 데이터 상관관계 분석과 관측 가능성 백엔드와의 통합에는 수작업과 추가 단계가 필요합니다. IT 팀은 서비스 전반의 이벤트를 연결하기 위해 사용자 정의 규칙과 파싱 규칙을 만들어야 하며, 로그 데이터를 관측 가능성 스택에 통합하려면 일반적으로 사용자 정의 전송 툴이나 형식 어댑터가 필요합니다.

OpenTelemetry 로깅은 로그, 지표 및 추적을 공통 의미 규칙에 의해 관리되는 1급 상호 운용 가능한 신호로 취급하는 통합 관측 가능성 프레임워크의 일부입니다. 처음부터 로그를 분산 시스템 전반에서 상관관계 분석이 가능하도록 설계하며, 이는 시스템 동작을 엔드투엔드로 이해하기 위한 목적입니다.

기존 로깅이 스택 및 백엔드에 종속적인 반면 OTel 로깅은 의도적으로 중립적으로 설계되었습니다. 기존 로깅 프레임워크가 모든 로그 호출을 다시 작성하지 않고도 OTel 형식으로 데이터를 출력할 수 있도록 브리지와 appender를 제공합니다.

이러한 통합된 범위와 접근 방식은 IT 팀이 대시보드와 데이터 유형 간을 자유롭게 이동하며 복잡한 분산 장애를 이해할 수 있는 전체적인 문제 해결 워크플로를 구축할 수 있도록 합니다.

OTel 로깅은 추적 및 지표와 긴밀하게 통합되는 표준화되고 컨텍스트가 풍부한 로그를 제공하므로 문제 해결 및 분석이 기존 접근 방식보다 훨씬 더 효과적입니다. 이점은 다음과 같습니다.