조용한 개발 노트

10편에서 샘플링이 Observability의 성패를 좌우한다고 이야기했다. 그런데 샘플링까지 잘 설정했는데도, 여전히 이런 말을 듣게 되는 경우가 있다.“Trace는 보이는데, 그래서 뭐가 문제인지는 모르겠다.”이 단계에서의 문제는 도구가 아니다. 대부분 표현 방식과 해석 방식에 있다.문제 1. 이름이 의미를 전달하지 못한다Trace를 열었을 때 가장 먼저 보이는 것은 Span의 이름이다.그런데 이런 이름을 자주 보게 된다.method.invokeservice.callprocess기술적으로는 맞을 수 있다. 하지만 이 이름들만으로는 무슨 일이 일어났는지 설명할 수 없다.OpenTelemetry 공식 문서는 Span 이름이 “무엇을 했는지”를 한 문장으로 설명해야 한다고 강조한다.예를 들어:GET /or..

9편에서 OpenTelemetry Collector 설정을 “관측 데이터가 흐르는 설계도”로 읽는 법을 살펴봤다. 이제 남은 가장 어려운 질문이 있다.“그 많은 Trace를 다 모아야 할까?”결론부터 말하면 아니다. 샘플링을 잘못하면 Observability는 비용만 늘리고, 정작 중요한 순간에는 아무것도 설명해주지 못한다.왜 샘플링이 필요한가분산 추적은 본질적으로 데이터가 많다.요청 하나당 여러 개의 Span트래픽이 늘수록 기하급수적으로 증가저장-전송-분석 비용이 모두 따라온다“일단 다 모아두고 나중에 보자”는 전략은 거의 항상 실패한다. 비용이 먼저 한계에 도달하기 때문이다.그래서 OpenTelemetry는 샘플링을 설계의 일부로 취급한다.샘플링의 본질: 무엇을 포기할 것인가샘플링은 기술 문제가 아니..

8편에서 OpenTelemetry Collector가 관측 데이터의 흐름을 통제하는 축이라는 이야기를 했다. 하지만 실제로 Collector를 마주하면, 대부분 여기서 멈춘다.“설정 파일이 너무 복잡하다.”이 편의 목표는 단순하다. Collector 설정을 ‘외울 대상’이 아니라 ‘해석 가능한 구조’로 만드는 것이다.Collector 설정은 파이프라인 정의다Collector 설정 파일의 핵심은 개별 옵션이 아니다.데이터가 어디서 들어와서, 어떻게 처리되고, 어디로 나가는지를 정의하는 파이프라인이다.이 관점으로 보면, 설정 파일은 크게 세 덩어리로 나뉜다.receivers: 데이터를 어디서 받을 것인가processors: 받은 데이터를 어떻게 다룰 것인가exporters: 데이터를 어디로 보낼 것인가그리고..

7편에서 Java Agent 하나로 요청 흐름이 바로 보이기 시작한다는 이야기를 했다. 여기까지 오면 이런 생각이 들기 쉽다.“이 정도면 Agent만 써도 충분한 거 아닌가?”소규모 환경에서는 맞는 말이다. 하지만 서비스 수가 늘고, 환경이 복잡해질수록 Collector 없이 버티기 어려운 지점이 반드시 온다.Agent만 쓰면 어디서 막히는가Java Agent는 애플리케이션 내부에서 관측 데이터를 만들어내는 역할을 훌륭하게 수행한다. 문제는 그 다음 단계다.모든 서비스가 각자 백엔드로 직접 전송한다환경마다 설정이 조금씩 달라진다샘플링-필터링 정책을 바꾸려면 전부 재배포한다이 구조에서는 관측이 늘어날수록 운영 부담이 기하급수적으로 커진다.Collector는 무엇을 하는 컴포넌트인가OpenTelemetry ..

6편에서 OTLP와 gRPC를 통해 관측 데이터가 어떻게 전달되는지를 살펴봤다. 그 다음에 자연스럽게 드는 질문은 이거다.“그 많은 Trace-Span은 대체 누가 언제 만드는 걸까?”OpenTelemetry에서 가장 빠르게 답을 주는 방식이 바로 Java Agent 기반 자동 계측(Auto Instrumentation)이다.Java Agent는 무엇을 하는가Java Agent는 JVM이 클래스를 로딩하는 시점에 바이트코드를 가로채서, 관측 로직을 자동으로 삽입한다.중요한 점은, 이 과정에서 애플리케이션 코드는 전혀 수정되지 않는다는 것이다.빌드 스크립트 변경 없음비즈니스 코드 수정 없음프레임워크 코드 호출 방식 그대로 유지JVM 실행 옵션 하나로 관측이 시작되는 이유다.자동 계측은 무엇을 자동으로 만들..

5편에서 OpenTelemetry는 라이브러리가 아니라 표준과 규약의 집합이라는 이야기를 했다. 그렇다면 다음 질문은 자연스럽다.“이 표준 데이터는 대체 어떻게 전달되는 걸까?”OpenTelemetry는 이를 위해 OTLP(OpenTelemetry Protocol)라는 전송 규약을 정의한다. 그리고 기본 전송 방식으로 gRPC를 선택했다.OTLP는 무엇을 위한 프로토콜인가OTLP는 traces-metrics-logs 데이터를 애플리케이션에서 Collector 또는 백엔드로 일관된 형식으로 전달하기 위한 표준이다.여기서 중요한 전제는, OTLP가 다루는 데이터의 성격이다.단일 이벤트가 아니라 연속적인 데이터 스트림요청 단위 Span이 대량으로 생성됨지연이 쌓이면 관측 자체가 무의미해짐즉, OTLP는 “가끔..

4편에서 로그-메트릭-트레이스를 같은 요청으로 연결해야 의미가 생긴다는 이야기를 했다. 그런데 여기서 많은 사람들이 한 번 더 헷갈린다.“그래서 OpenTelemetry를 쓰면 되는 거지? 라이브러리 하나 붙이면 해결되는 거 아니야?”이 질문 자체가 문제의 출발점이다. OpenTelemetry는 라이브러리가 아니다.왜 라이브러리라고 생각하게 될까대부분의 개발자는 이렇게 접한다.Spring Boot에 의존성 추가Java Agent 실행 옵션 추가대시보드에 Trace가 보이기 시작이 경험만 보면, OpenTelemetry는 “관측을 해주는 도구”처럼 보인다. 하지만 실제로 OpenTelemetry가 해결하려는 문제는 훨씬 구조적이다.OpenTelemetry가 해결하려는 진짜 문제OpenTelemetry 이전..

3편에서 Trace가 끊어지는 가장 큰 원인이 Context Propagation이라는 이야기를 했다. 그런데 Context를 잘 전달했더라도, 여전히 이런 상황은 자주 발생한다.“메트릭은 분명히 나빠졌는데, 로그에서는 큰 문제가 안 보인다.” “로그에는 에러가 있는데, 지표는 정상이다.”이 혼란의 원인은 단순하다. 각각 다른 질문에 답하는 도구를, 하나의 답을 기대하며 보고 있기 때문이다.Signals는 역할이 다르다OpenTelemetry 공식 문서는 관측 신호(signals)를 traces, metrics, logs 세 가지로 나눈다. 이 분류는 구현 편의가 아니라, 각각이 답하는 질문이 다르기 때문이다.Metrics: 지금 시스템 상태가 정상인가? (전체적인 건강 상태를 빠르게 본다)Logs: 어..

2편에서 Trace와 Span을 통해 요청 하나의 흐름을 연결해서 볼 수 있다는 이야기를 했다. 그런데 실제 환경에서는 이런 경험을 자주 하게 된다.“분명 트레이싱을 붙였는데, 서비스 A까지만 보이고 서비스 B부터는 trace가 끊긴다.”이 문제의 핵심은 Trace도 Span도 아니다. Context Propagation이다.traceId는 왜 저절로 이어지지 않을까흔히 하는 오해가 있다. “같은 요청이면 traceId는 자동으로 따라다니는 것 아닌가?”하지만 분산 시스템에서 요청은 하나의 프로세스-하나의 스레드 안에서 끝나지 않는다.HTTP 요청으로 들어왔다가다른 서비스로 HTTP 또는 gRPC 호출을 하고비동기 작업이나 메시지 큐를 거치고다시 다른 스레드에서 처리된다이 경계들을 넘는 순간, 아무 작업..

1편에서 다뤘던 문제를 다시 떠올려보자. 로그도 있고 메트릭도 있는데, 막상 장애가 나면 "어떤 요청이 어디서 느려졌는지"를 한 번에 설명하기가 어렵다.이 문제를 해결하기 위해 OpenTelemetry는 요청 단위 관측을 핵심 개념으로 삼는다. 그리고 그 중심에 있는 신호가 바로 Trace다.왜 요청 단위 관측이 중요한가메트릭은 전체를 요약한다. 예를 들어 p95 latency, error rate 같은 값은 시스템의 상태를 빠르게 감지하는 데 매우 유용하다.하지만 메트릭만으로는 다음 질문에 답하기 어렵다.느려진 요청은 모두 그런가, 일부만 그런가?특정 사용자-특정 기능에서만 발생한 문제인가?느려진 요청이 어떤 내부 호출 경로를 거쳤는가?이 질문들은 모두 "요청 하나"를 기준으로 시스템을 보고 싶다는 요..