OpenTelemetry 관측 가능성¶

관측 가능성 구축 시 해결해야 할 과제¶

1. 분산 추적은 프런트엔드와 백엔드를 어떻게 연계하는가?

2. 분산 추적을 해당 로그 및 메트릭과 어떻게 연계하는가?

1. OpenTelemetry는 다양한 언어의 SDK를 구현합니다. 프런트엔드 트레이스는 주로 opentelemetry-js를 통해 구현되며, 백엔드에도 Java, Go, Python 등 관련 언어의 구현이 있습니다. 각 언어는 자체 trace 정보를 통합하여 opentelemetry-collector(이하 otel-collector)에 보고합니다.

2. Java 언어를 예로 들면, opentelemetry-java(이하 "Agent")는 javaagent 방식을 통해 애플리케이션에 주입됩니다. 애플리케이션에서 trace 정보가 생성되면 MDC를 설정하여 traceId와 spanId를 로그에 매개변수로 전달할 수 있으므로, 로그 출력 시 traceId와 spanId가 포함됩니다.

매핑 진단 컨텍스트(MDC)는

서로 다른 출처에서 생성된 인터리브 로그 출력을 구분하는 도구입니다. — log4j MDC 문서

MDC는 스레드 로컬 컨텍스트 정보를 포함하며, 이후 로깅 라이브러리에서 캡처한 각 로그 이벤트에 복사됩니다.

OTel Java 에이전트는 현재 스팬에 대한 몇 가지 정보를 각 로그 레코드 이벤트의 MDC 복사본에 주입합니다:

• trace_id - 현재 트레이스 ID (Span.current().getSpanContext().getTraceId()와 동일);
• span_id - 현재 스팬 ID (Span.current().getSpanContext().getSpanId()와 동일);
• trace_flags - W3C 추적 플래그 형식에 따른 현재 트레이스 플래그 (Span.current().getSpanContext().getTraceFlags().asHex()와 동일).

이 세 가지 정보는 패턴/형식에서 지정하여 로깅 라이브러리에서 생성된 로그 명령문에 포함될 수 있습니다.

참고: logback을 사용하는 Spring Boot 구성의 경우 logging.pattern.level만 재정의하여 MDC를 로그 줄에 추가할 수 있습니다:

logging.pattern.level = trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p

이렇게 하면 애플리케이션 로그를 파싱하는 모든 서비스나 도구에서 트레이스/스팬을 로그 명령문과 연결할 수 있습니다.

1. OpenTelemetry는 메트릭 수집도 지원합니다. otel-collector를 통해 메트릭을 Prometheus와 같은 해당 exporter로 출력한 후 Grafana를 통해 시각화할 수 있습니다. otlpExporter는 메트릭 출력을 지원하며, 메트릭과 로그 및 트레이스의 연관은 tag를 server.name으로 설정하여 수행할 수 있습니다.

OpenTelemetry의 목적은 데이터 형식을 통일하는 것입니다. 즉, 장기적으로 OpenTelemetry는 관측 가능성 제품 자체에 집중할 계획이 없습니다. 사용자들은 여전히 OpenTelemetry를 데이터 중계소로 사용하거나 OpenTelemetry의 데이터 표준을 사용하여 자체 관측 가능성 제품을 구축할 것입니다.

OpenTelemetry를 통한 엔드투엔드 전체 트레이스 관측 가능성 구축¶

다음은 OpenTelemetry 기반의 엔드투엔드 전체 트레이스 관측 가능성 구축을 위한 세 가지 방안을 소개합니다:

1. 기존 모니터링 기반의 대규모 통합¶

주로 otel-collector를 통해 로그, 메트릭, 트레이스를 각각 ELK, Prometheus 및 Jaeger와 같은 관련 APM 공급업체로 전송합니다.

2. Grafana全家桶 기반¶

최근 Grafana는 관측 가능성 분야에도 진출하여 Grafana Cloud와 Grafana Labs를 설립하고 자체 솔루션을 출시했습니다. Grafana Tempo는 오픈 소스이며 사용하기 쉽고 대규모 분산 추적 백엔드입니다. Tempo는 비용 효율적이며 객체 스토리지만 있으면 실행 가능하고 Grafana, Prometheus, Loki와 깊이 통합됩니다. Tempo는 Jaeger, Zipkin, OpenTelemetry를 포함한 모든 오픈 소스 추적 프로토콜과 함께 사용할 수 있으므로 OpenTelemetry의 trace 데이터를 직접 수신할 수 있습니다. Loki는 OpenTelemetry의 로그 데이터를 수집하고, Grafana는 여전히 Prometheus를 사용하여 메트릭 데이터를 수신합니다.

위 두 가지 방안은 데이터 형식 문제를 해결하지만, 엄밀히 말하면 제품이라기보다는 기술에 가깝고 기본적으로 오픈 소스 도구의 조합입니다. 비즈니스 문제가 발생했을 때 여전히 다른 도구를 사용하여 문제를 분석해야 하며, 로그, 메트릭, 트레이스가 제대로 통합되지 않아 운영 및 개발자의 운영 및 커뮤니케이션 비용이 줄어들지 않습니다. 따라서 통합된 로그, 메트릭, 트레이스 기반의 데이터 분석 플랫폼이 특히 중요합니다. Grafana도 이 방향으로 노력하고 있지만 데이터 사일로를 완전히 해결하지는 못했으며, 서로 다른 구조의 데이터에 여전히 다른 쿼리 언어를 사용합니다. Grafana는 현재 로그 데이터와 trace 데이터의 연계를 구현했지만, trace 데이터가 로그 데이터를 역방향으로 연계할 수는 없습니다. Grafana 팀은 데이터 간 상호 연결 쿼리 및 분석을 위해 계속 노력해야 합니다.

3. Guance - 상용 관측 가능성 제품 기반¶

Guance은 메트릭 데이터, 로그 데이터, APM, RUM, 인프라, 컨테이너, 미들웨어, 네트워크 성능 등 다양한 데이터를 통합적으로 수집 및 관리하는 플랫폼입니다. Guance을 사용하면 로그 트레이스 간의 관측을 넘어 애플리케이션을全方位적으로 관측할 수 있습니다.

DataKit은 Guance의 프런트엔드 게이트웨이입니다. 데이터를 Guance로 전송하려면 DataKit을 올바르게 구성해야 하며, DataKit을 사용하면 다음과 같은 이점이 있습니다:

1. 호스트 환경에서는 각 호스트에 DataKit이 있으며, 데이터는 먼저 로컬 DataKit으로 전송되어 캐싱, 전처리된 후 보고됩니다. 이는 네트워크 지터를 방지하고 에지 처리 기능을 제공하여 백엔드 데이터 처리 부담을 줄여줍니다.
2. Kubernetes 환경에서는 각 노드에 DataKit의 DaemonSet이 있으며, Kubernetes의 로컬 트래픽 메커니즘을 활용하여 각 노드의 Pod에서 생성된 데이터가 먼저 로컬 노드의 DataKit으로 전송됩니다. 이는 네트워크 지터를 방지하고 APM 데이터에 Pod 및 노드 레이블을 추가하여 분산 환경에서 위치 파악을 용이하게 합니다.

DataKit의 설계理念도 OpenTelemetry를 참고하여 OTLP 프로토콜을 지원하므로, Collector를 거치지 않고 직접 DataKit으로 전송하거나 Collector의 exporter를 OTLP(DataKit)으로 설정할 수 있습니다.

방안 비교¶