|| OpenTelemetry + ClickHouse 로 APM 스캐터 차트 만들기 (1) — 수집과 저장
글. 박준희(Kuiper) / 숙박플랫폼개선TF팀
1. 들어가며
안녕하세요.
여기어때 숙박플랫폼개선TF팀 박준희(카이퍼)입니다.
APM 도구를 써보신 분이라면 이런 화면을 보신 적이 있으실 겁니다. 가로축은 시간, 세로축은 응답시간, 그리고 요청 하나하나가 점으로 흩뿌려지는 산점도. 이 시리즈가 끝나면 아래 화면을 직접 만들게 됩니다.
이 화면이 유용한 이유는 단순합니다. 평균과 백분위는 개별 요청을 지웁니다. 평균 응답시간 그래프가 평탄해도 그 안에서 일부 요청만 10초씩 걸리고 있을 수 있고, P99 가 정상이어도 그 바깥에서 무슨 일이 벌어지는지는 보이지 않습니다. 스캐터 차트는 개별 요청을 지우지 않기 때문에, 집계 지표가 감추는 패턴이 눈에 그대로 남습니다.
문제는 이 화면이 대개 상용 APM 제품에 묶여 있다는 점입니다. 여기어때는 이미 OpenTelemetry 로 트레이스를 수집하고 Grafana 로 관측하고 있습니다. 그렇다면 같은 데이터로, 집계 지표가 감추는 패턴을 요청 하나하나 단위로 보는 화면을 직접 만들 수 있지 않을까요?
이 글은 그 질문에 답해본 기록입니다. 두 편으로 나눠 싣습니다.
(1편) 수집과 저장 — OpenTelemetry Collector 로 span 을 받아 ClickHouse 에 쌓기까지. 이 글입니다
(2편) 화면 만들기 — Grafana 커스텀 패널 플러그인으로 스캐터 차트를 그리기
전체 구성
애플리케이션 (OTel Agent/SDK)
|
v
OpenTelemetry Collector <- 수집 대상 선정 (6장)
|
v
ClickHouse <- 스키마 설계 (7장), Materialized View 변환 (8장)
otel_traces (raw) -- Materialized View --> transactions (조회용)
|
v
Grafana 커스텀 패널 <- 2편검증 범위를 먼저 밝힙니다
이 글의 내용은 로컬 단일 노드 환경(및 3-Keeper / 2-Shard x 2-Replica 클러스터 구성)에서 파이프라인 전 구간을 구성하고 합성 트래픽으로 검증한 기록입니다. 운영 트래픽 적용은 별도 단계이며, 본문의 용량·성능 수치는 각각 로컬 실측 / 추정치 / 공식 문서 로 출처를 구분해 표기했습니다.
1편은 다음을 다룹니다.
스캐터 차트가 집계 지표 대비 무엇을 더 보여주는가
ClickHouse 는 무엇이고 왜 이런 조회에 빠른가
기존 트레이싱 파이프라인을 건드리지 않고 분기하는 방법
어떤 span 을 남기고 어떤 span 을 버릴 것인가
컬럼 타입·정렬 키·파티션·TTL·인덱스를 어떻게 고를 것인가
2. 스캐터 차트가 보여주는 것2.1 집계 지표의 사각지대
평균 응답시간 — 이상치가 평균에 묻혀 감지되지 않습니다
P95 / P99 — 백분위 바깥의 극단적 지연은 표현되지 않습니다
에러율 — 성공했지만 느린 응답은 잡히지 않습니다
세 지표 모두 “개별 요청을 하나의 숫자로 접는” 연산입니다. 접는 순간 분포의 모양이 사라집니다. 스캐터 차트는 접지 않기 때문에 모양이 남습니다.
2.2 점 하나가 무엇인지부터 정하기
용어를 하나 짚고 가겠습니다. span 은 트레이스를 구성하는 작업 단위 하나입니다. HTTP 요청 처리, DB 쿼리, 외부 API 호출 같은 작업 각각이 시작 시각·소요 시간(duration)·성격(SpanKind)·속성을 가진 기록 하나로 남는데, 그 기록이 span 입니다. 요청 하나의 전체 여정(트레이스)은 이런 span 여러 개가 부모-자식으로 엮인 트리입니다.
여기서 첫 설계 결정이 나옵니다. 점 하나를 무엇으로 볼 것인가.
요청(트랜잭션) 하나 = 점 하나로 하면 화면은 깔끔하지만, 느려진 원인이 내부 DB 호출인지 외부 API 호출인지 구분되지 않습니다
span 하나 = 점 하나로 하면 요청 하나가 여러 점으로 찍힙니다. 대신 진입 요청과 하위 호출을 나눠 볼 수 있습니다
저는 후자를


