조용한 개발 노트

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 이전..