メトリクスは二度数えられ、ラベルはお金がかかる

한 줄 요약

사이드카는 요청마다 표준 지표(istio_requests_total·istio_request_duration_milliseconds 등)를 올리고 접근 로그를 남긴다. Telemetry API 는 그것을 네임스페이스·워크로드 단위로 고치는 장치다 — 라벨을 더하고(tagOverrides), 빼고(REMOVE), 지표를 끄고(disabled), 로그를 조건으로 거른다(filter).

왜 이게 필요했나

메시의 약속 가운데 하나는 '코드를 고치지 않고도 모든 서비스의 요청 수·오류율·지연을 같은 모양으로 본다' 는 것이다. 사이드카가 모든 요청을 지나가므로 가능하다. 그런데 그대로 두면 두 가지 문제가 생긴다.

첫째, 비용이다. 표준 지표는 출발지·목적지·응답 코드·프로토콜 같은 라벨을 여럿 달고, 지연 히스토그램은 버킷마다 시계열이 생긴다. 서비스가 수백 개면 Prometheus 가 먼저 버거워진다. 둘째, 모자람이다. '어느 고객(tenant)의 요청인가' 처럼 업무에 필요한 차원은 표준 라벨에 없다.

Telemetry API 는 이 둘을 설정 하나로 다룬다. 메시 전체(istio-system), 네임스페이스, 워크로드 셀렉터 순으로 좁혀 적용할 수 있다.

어떻게 동작하나

지표는 두 번 세어진다. 사이드카 모드에서 요청 하나는 보내는 쪽 사이드카(reporter="source")와 받는 쪽 사이드카(reporter="destination")가 각각 센다. 둘 다 메시 안이면 같은 수가 두 번 쌓이므로, 합계를 낼 때는 reporter 를 하나로 고정해야 한다. 받는 쪽 기준(destination)이 보통 '서비스가 받은 요청' 에 가깝다.

Prometheus 는 긁어 간다. 배포판의 Prometheus 애드온은 파드 애너테이션을 보고 사이드카의 병합된 지표 포트를 주기적으로(이 설정은 15초) 긁는다. 그래서 요청을 보내고 한 주기쯤 뒤에 질의 결과에 나타난다. 사이드카가 지금 들고 있는 값은 pilot-agent request GET stats/prometheus 로 곧바로 볼 수 있다.

Telemetry 로 고치는 것

설정	하는 일
tagOverrides: {tenant: {value: "request.headers['x-tenant']"}}	요청 속성으로 새 라벨을 만든다
tagOverrides: {request_protocol: {operation: REMOVE}}	표준 라벨을 뺀다
match: {metric: REQUEST_DURATION}, disabled: true	그 지표를 만들지 않는다
accessLogging: [{filter: {expression: "response.code >= 400"}}]	조건에 맞는 요청만 로그를 남긴다

라벨 값이 끝없이 늘어나는 것(사용자 id·요청 id)을 라벨로 만들면 시계열이 폭발한다. 라벨을 더할 때는 값의 가짓수를 먼저 생각한다. 그리고 카운터는 지워지지 않으므로, 설정을 바꾼 효과는 새로 생기는 시계열에서만 보인다.

PromQL 로 비율을 낸다. 오류율은 sum(5xx) / sum(전체) 다. 운영 대시보드는 rate(…[5m]) 로 최근 창의 비율을 보지만, 요청이 적은 실험에서는 카운터끼리 나눠도 된다. 두 경우 모두 분자와 분모가 같은 reporter·같은 목적지를 가리켜야 한다.

현장에서 만나는 모습

"대시보드의 요청 수가 로드밸런서보다 두 배입니다." reporter 를 거르지 않고 더했다.

"tenant 라벨을 붙였더니 Prometheus 메모리가 뛰었습니다." 고객이 수만이었다. 라벨이 아니라 로그나 트레이스로 봐야 할 차원이다.

"접근 로그를 줄였더니 장애 분석이 어려워졌습니다." 오류만 남기면 '정상이던 요청이 언제부터 느려졌나' 를 볼 수 없다. 조건식에 지연(response.duration)을 함께 넣는 경우가 많다.

공식 문서: Telemetry API · Customizing Istio Metrics · Istio Standard Metrics · Envoy Access Logs · Prometheus addon

다음 실습에서 할 것

배포판의 Prometheus 애드온이 함께 올라간 메시에서 요청을 흘려 istio_requests_total 을 HTTP API 로 묻고, 같은 요청이 source·destination 으로 두 번 세어지는 것을 본다. Telemetry API 로 tenant 라벨을 더하고, 쓰지 않는 라벨을 빼고, 지연 지표를 끄고, 접근 로그를 오류만 남기게 거른 뒤, 마지막으로 오류율을 PromQL 한 줄로 낸다.