数两次，按标签付费

목표

Prometheus 애드온이 올라간 진짜 메시에서 표준 지표를 PromQL 로 묻고, Telemetry API 로 라벨을 더하고·빼고·지표를 끄고·접근 로그를 걸러 그 효과를 사이드카의 지표와 로그에서 확인한다.

왜 중요한가

메시의 관측은 공짜처럼 보이지만 라벨 하나, 히스토그램 하나가 시계열 수를 곱으로 늘린다. 반대로 업무에 필요한 차원은 표준 라벨에 없다. 무엇을 더하고 무엇을 버릴지 정하는 장치가 Telemetry API 이고, 그 효과는 설정이 아니라 실제로 쌓이는 지표와 로그로 확인해야 한다.

단계

1. kubectl apply -f /opt/fixtures/istlab/telemetry-app.yaml 로 재료를 올리고 준비될 때까지 기다리세요. client 에서 http://web/ 을 10번, http://web/broken 을 3번 부른 뒤, Prometheus(서비스 istio-system/prometheus, 포트 9090)에 sum by (response_code) (istio_requests_total{reporter="destination",destination_workload="web",destination_workload_namespace="shop"}) 를 물어 그 응답 JSON 을 그대로 /root/istlab-telemetry/01-prom.json 에 저장하세요. 스크레이프 주기가 15초라, 두 코드가 모두 보일 때까지 기다렸다가 저장합니다.
2. Prometheus 에서 destination_workload="web" 이고 response_code="503" 인 istio_requests_total 을 reporter 별로 합해 /root/istlab-telemetry/02-reporters.txt 에 source_503=·destination_503= 두 줄로 적으세요.
3. /root/istlab-telemetry/telemetry.yaml 에 네임스페이스 shop 의 Telemetry shop-telemetry 를 적어 적용하세요 — metrics 의 provider prometheus, override 는 REQUEST_COUNT·CLIENT_AND_SERVER 에 tagOverrides 로 tenant 를 request.headers['x-tenant'] 로 더합니다. 적용 뒤 x-tenant: acme 를 붙여 세 번 부르고, Prometheus 에 sum by (tenant) (istio_requests_total{tenant="acme"}) 를 물은 응답을 /root/istlab-telemetry/03-tenant.json 에 저장하세요.
4. /root/istlab-telemetry/telemetry.yaml 의 같은 override 의 tagOverrides 에 request_protocol: {operation: REMOVE} 를 더해 다시 적용하세요. 적용 뒤 x-tenant: beta 로 부른 요청의 새 시계열에는 request_protocol 라벨이 없어야 합니다.
5. /root/istlab-telemetry/telemetry.yaml 에 override 를 하나 더 두어 REQUEST_DURATION(CLIENT_AND_SERVER)을 disabled: true 로 끄고 다시 적용하세요. 적용 뒤 요청을 보내도 client 사이드카의 istio_request_duration_milliseconds_count 합이 늘지 않아야 합니다(istio_requests_total 은 계속 늘어야 합니다).
6. /root/istlab-telemetry/telemetry.yaml 에 accessLogging 을 더해 다시 적용하세요 — provider envoy, filter.expression: "response.code >= 400". 적용 뒤 client 의 200 요청은 client 사이드카 접근 로그에 남지 않고, /broken(503) 요청만 남아야 합니다.
7. /root/istlab-telemetry/07-error-ratio.promql 에 web 이 받은(reporter destination) 요청 가운데 5xx 의 비율을 돌려주는 PromQL 을 적고, 그 질의를 Prometheus 에 물어 나온 값을 /root/istlab-telemetry/07-ratio.txt 에 ratio= 로 적으세요.
8. /root/istlab-telemetry/08-report.md 에 다섯 줄 — requests_503_destination=(2단계 destination_503), counted_twice=(2단계에서 source 와 destination 이 같은 수를 세었으면 yes), tenant_label=(3단계에서 붙은 tenant 값), duration_counting=(지금 duration 지표가 늘고 있으면 yes), logged_only_errors=(6단계 결과면 yes) — 을 적고 그 아래 배운 것을 네 줄 이상 적으세요.

참고

• 이 VM 은 준비에 3~5분 걸립니다. Prometheus 는 istio-system/prometheus(9090)에 떠 있습니다 — kubectl -n istio-system get svc prometheus -o jsonpath='{.spec.clusterIP}' 로 주소를 얻습니다.
• Prometheus 는 15초마다 긁습니다. 질의 결과가 비었으면 조금 기다렸다가 다시 물으세요.
• 사이드카가 지금 들고 있는 지표는 kubectl -n shop exec client -c istio-proxy -- pilot-agent request GET stats/prometheus 로 곧바로 볼 수 있습니다.
• Telemetry 는 같은 파일(telemetry.yaml)에 단계마다 더해 가며 다시 적용합니다.
• 흔한 실수 — 카운터가 사라지기를 기다리는 것. 이미 쌓인 시계열은 남고, 설정 변경은 새로 생기는 시계열에서만 보입니다.

요청을 흘리고 Prometheus 에 묻는다

kubectl apply -f /opt/fixtures/istlab/telemetry-app.yaml 로 재료를 올리고 준비될 때까지 기다리세요. client 에서 http://web/ 을 10번, http://web/broken 을 3번 부른 뒤, Prometheus(서비스 istio-system/prometheus, 포트 9090)에 sum by (response_code) (istio_requests_total{reporter="destination",destination_workload="web",destination_workload_namespace="shop"}) 를 물어 그 응답 JSON 을 그대로 /root/istlab-telemetry/01-prom.json 에 저장하세요. 스크레이프 주기가 15초라, 두 코드가 모두 보일 때까지 기다렸다가 저장합니다.

사이드카는 요청마다 istio_requests_total 같은 표준 지표를 올리고, Prometheus 는 파드의 애너테이션을 보고 사이드카의 15020 포트를 긁어 갑니다. 그래서 요청을 보낸 즉시 보이지 않고 한 주기쯤 늦게 보입니다. 질의는 curl -s http://<ClusterIP>:9090/api/v1/query --data-urlencode 'query=…' 처럼 HTTP API 로 합니다.

요청 하나를 누가 세나 — reporter

Prometheus 에서 destination_workload="web" 이고 response_code="503" 인 istio_requests_total 을 reporter 별로 합해 /root/istlab-telemetry/02-reporters.txt 에 source_503=·destination_503= 두 줄로 적으세요.

사이드카 모드에서는 요청 하나를 보내는 쪽(source) 사이드카와 받는 쪽(destination) 사이드카가 따로 셉니다. 두 값이 같게 나오는 것이 정상이고, 대시보드에서 reporter 를 거르지 않고 더하면 요청 수가 두 배로 보입니다. 받는 쪽이 메시 밖이면 source 쪽만, 보내는 쪽이 메시 밖이면 destination 쪽만 남는다는 것도 기억해 두세요.

지표에 우리 라벨을 붙인다 — tagOverrides

/root/istlab-telemetry/telemetry.yaml 에 네임스페이스 shop 의 Telemetry shop-telemetry 를 적어 적용하세요 — metrics 의 provider prometheus, override 는 REQUEST_COUNT·CLIENT_AND_SERVER 에 tagOverrides 로 tenant 를 request.headers['x-tenant'] 로 더합니다. 적용 뒤 x-tenant: acme 를 붙여 세 번 부르고, Prometheus 에 sum by (tenant) (istio_requests_total{tenant="acme"}) 를 물은 응답을 /root/istlab-telemetry/03-tenant.json 에 저장하세요.

Telemetry API 는 사이드카의 지표 설정을 네임스페이스(또는 워크로드) 단위로 고칩니다. tagOverrides 의 값은 요청 속성 표현식이라 헤더·경로 같은 요청 정보를 라벨로 만들 수 있습니다. 다만 라벨 값이 끝없이 늘어나는 것(사용자 id 같은 것)을 라벨로 만들면 시계열이 폭발하니 조심하세요. 사이드카가 붙인 것은 kubectl -n shop exec client -c istio-proxy -- pilot-agent request GET stats/prometheus 로 곧바로 볼 수 있고, Prometheus 에는 한 주기쯤 뒤에 보입니다.

쓰지 않는 라벨을 뺀다

/root/istlab-telemetry/telemetry.yaml 의 같은 override 의 tagOverrides 에 request_protocol: {operation: REMOVE} 를 더해 다시 적용하세요. 적용 뒤 x-tenant: beta 로 부른 요청의 새 시계열에는 request_protocol 라벨이 없어야 합니다.

라벨 하나가 늘 같은 값(http)이라도 모든 시계열에 붙어 저장 공간을 먹습니다. 쓰지 않는 표준 라벨은 빼는 것이 카디널리티를 줄이는 가장 싼 방법입니다. 이미 만들어진 시계열은 카운터라 지워지지 않고 남으므로, 새로 생기는 시계열(새 tenant 값)로 확인하세요.

쓰지 않는 지표는 끈다

/root/istlab-telemetry/telemetry.yaml 에 override 를 하나 더 두어 REQUEST_DURATION(CLIENT_AND_SERVER)을 disabled: true 로 끄고 다시 적용하세요. 적용 뒤 요청을 보내도 client 사이드카의 istio_request_duration_milliseconds_count 합이 늘지 않아야 합니다(istio_requests_total 은 계속 늘어야 합니다).

지연 히스토그램은 버킷마다 시계열이 생겨 표준 지표 중 가장 무겁습니다. 게이트웨이에서만 보고 사이드카에서는 끄는 식의 선택을 Telemetry API 로 할 수 있습니다. 끈다고 옛 값이 사라지지는 않으므로 '늘지 않는다' 로 확인합니다 — 요청 전후로 합을 두 번 재어 비교하세요.

오류만 접근 로그에 남긴다

/root/istlab-telemetry/telemetry.yaml 에 accessLogging 을 더해 다시 적용하세요 — provider envoy, filter.expression: "response.code >= 400". 적용 뒤 client 의 200 요청은 client 사이드카 접근 로그에 남지 않고, /broken(503) 요청만 남아야 합니다.

이 메시는 설치 때 meshConfig 로 모든 접근 로그를 켜 두었습니다. Telemetry 의 accessLogging 은 그것을 네임스페이스 단위로 덮어써, 조건식(CEL)에 맞는 요청만 남기게 할 수 있습니다. 성공 요청까지 전부 남기면 로그 비용이 요청 수에 비례해 늘기 때문에, 운영에서는 오류와 느린 요청만 남기는 경우가 많습니다. 요청 id 를 붙여 보내고 kubectl -n shop logs client -c istio-proxy 에서 찾으세요.

오류율을 PromQL 한 줄로

/root/istlab-telemetry/07-error-ratio.promql 에 web 이 받은(reporter destination) 요청 가운데 5xx 의 비율을 돌려주는 PromQL 을 적고, 그 질의를 Prometheus 에 물어 나온 값을 /root/istlab-telemetry/07-ratio.txt 에 ratio= 로 적으세요.

비율은 sum(5xx 카운터) / sum(전체 카운터) 입니다. reporter 를 하나로 고정하지 않으면 한 요청이 두 번 세어진 것끼리 나누게 되고, 메시 밖에서 온 요청이 있으면 분모와 분자가 서로 다른 것을 세게 됩니다. 운영 대시보드라면 rate(…[5m]) 로 최근 비율을 보겠지만, 이 실습의 요청은 몇 번뿐이라 카운터 자체로 나눕니다. 질의 파일의 줄바꿈은 --data-urlencode "query=$(cat 파일)" 로 보내면 그대로 됩니다.

무엇을 세고 무엇을 버렸는지 적는다

/root/istlab-telemetry/08-report.md 에 다섯 줄 — requests_503_destination=(2단계 destination_503), counted_twice=(2단계에서 source 와 destination 이 같은 수를 세었으면 yes), tenant_label=(3단계에서 붙은 tenant 값), duration_counting=(지금 duration 지표가 늘고 있으면 yes), logged_only_errors=(6단계 결과면 yes) — 을 적고 그 아래 배운 것을 네 줄 이상 적으세요.

설명 줄에는 '라벨을 더할 때의 비용(카디널리티)' 과 'reporter 를 거르지 않은 합계가 왜 틀리는가' 를 자기 말로 적어 두세요.