세 신호는 대체재가 아니라 조사 순서다

한 줄 요약

트레이스는 '어디'에 답하고, 메트릭은 '언제와 얼마나', 로그는 '왜'에 답한다. 그래서 조사 순서는 고정이다 — 메트릭 → 트레이스 → 로그.

왜 이게 필요했나

장애가 나면 사람들은 대개 로그부터 연다. 그리고 30분 뒤에도 여전히 로그를 읽고 있다. 로그는 가장 자세하지만 가장 비싸고, 무엇을 찾아야 할지 모르는 상태에서 열면 그냥 텍스트의 바다다.

메트릭이 먼저인 이유는 세 가지다. 값이 싸고, 항상 켜져 있고, 카디널리티가 낮다. 이 셋을 동시에 만족하기 때문에 메트릭은 알림의 근거가 될 수 있는 유일한 신호다. 트레이스는 샘플링되므로 "지금 이 순간 나빠지고 있다"를 보장하지 못하고, 로그는 양이 많아 실시간 집계 비용이 감당되지 않는다.

세 신호는 서로를 대체하지 않는다. 서로를 이어 주는 세 개의 다리가 있을 뿐이다. 메트릭에서 트레이스로는 exemplar 로 건너가고, 트레이스에서 로그로는 trace_id 필드로, 로그에서 다시 메트릭으로는 event 필드로 돌아온다. 이 다리가 없으면 세 도구를 다 사 놓고도 조사는 여전히 사람의 직감에 의존한다.

어떻게 동작하나

메트릭에서 진짜 결정은 타입 선택이다. 타입 선택은 취향이 아니다. 잘못 고르면 나중에 하고 싶은 계산이 원리적으로 불가능해진다.

• Counter: 단조 증가하고 재시작하면 0 이 된다. 값 자체는 의미가 없고 rate 로 봐야 의미가 생긴다.
• Gauge: 오르내린다. 현재 상태를 나타낸다.
• Histogram: 버킷 카운터의 집합. 분위수를 알고 싶은 값에 쓴다.
• Summary: 인스턴스 안에서 이미 백분위를 계산해 내보낸다. 그래서 여러 인스턴스를 합칠 방법이 없다. 서비스 수준 지표로는 쓸 수 없다.

왜 지연 시간에 게이지가 안 되는지는 산수로 확인된다. 스크레이프 간격이 15초이고 초당 요청이 500건이면, 게이지로는 7,500건 중 1건의 값만 저장된다. 나머지는 존재한 적도 없는 것이 된다. 이 시계열로는 p99 를 구할 수 없고 나중에 다시 처리해도 복원되지 않는다.

현장에서 만나는 모습

배포 직후마다 트래픽이 줄어든 것처럼 보이는 대시보드를 종종 만난다. 원인은 거의 항상 같다. rate 를 sum 바깥에 걸어 둔 것이다. 카운터 리셋 보정은 개별 시계열 단위로만 정확하다. 파드 하나가 재시작하면 합산된 뒤에는 리셋으로 인식되지 않는다. 올바른 형태는 sum(rate(x[5m])) by (route) 이고, rate(sum(x)[5m:]) 는 틀렸다.

또 하나는 조용한 오답이다. histogram_quantile 에서 by (le) 를 빼면 에러 없이 틀린 숫자를 반환한다. 아무도 예외를 보지 않으니 그 패널은 몇 달씩 대시보드에 남는다.

다음 실습에서 할 것

실습 환경에는 진짜 프로메테우스 서버가 12시간치 데이터를 담은 채로 떠 있다. 오류가 치솟는 구간이 두 번, 지연의 꼬리만 튀는 구간이 한 번, 그리고 꾸준히 줄어드는 디스크가 들어 있다.

쿼리를 파일에 적기만 하는 것이 아니라 promq 로 직접 던지고 돌아온 숫자를 읽는다. 여러분이 쓴 쿼리가 그 세 사건을 찾아내는지가 정답 여부를 알려 준다 — PromQL 이 어려운 이유는 문법이 아니라, 틀린 쿼리도 오류 없이 그럴듯한 숫자를 돌려주기 때문이다.