[쿠버네티스 네트워크 9/10] Kiali·Jaeger·OpenTelemetry로 요청의 경로와 지연 읽기

Об этом предложении

이 글에서 다룰 주제 Kiali·Prometheus·Jaeger의 역할과 수집·조회 경로 ServiceMonitor·PodMonitor, Istio 메트릭과 오류율·지연 쿼리 Trace·Span·Context propagation·Sampling, 관측 데이터가 비는 이유 주요 단어 · Kiali · Jaeger v2 · OpenTelemetry · OTLP · RED · p95 · Trace ID · Sampling 선수 지식과 목표 — Service와 Istio의 데이터 평면을 이해했다면, 이번에는 “어느 연결에서 문제가 시작되었는가”를 관측 신호로 좁힌다. 읽고 나면 서비스 지도·메트릭·트레이스를 서로 다른 근거로 해석할 수 있다. 서점 화면이 느리다는 알림이 왔다. productpage Pod의 CPU는 정상이다. 이 정보만으로 productpage가 정상이라고 결론 낼 수 있을까? reviews의 응답을 기다리거나, ratings 호출을 여러 번 재시도하거나, 연결 풀에서 순서를 기다릴 수도 있다. CPU 한 개의 그래프로는 요청이 지나간 경로를 알 수 없다. 1. 관측 지도: 요청과 관측 데이터는 다른 길로 이동한다 앞선 전체도와 같은 배치에서 관측 대상을 강조한 개념도다. 애플리케이션 요청이 Kiali나 Jaeger를 거쳐 전달되는 것은 아니다. Observability — 외부로 내보낸 신호를 통해 시스템 내부에서 무엇이 일어났는지 질문하고 설명하는 능력이다. Kiali는 서비스 메시의 연결 관계와 상태를 보는 콘솔이다. Prometheus의 메트릭과 Kubernetes·Istio 설정을 함께 해석한다. Jaeger는 분산 요청의 트레이스를 저장·조회하는 도구다. Grafana는 메트릭 등 여러 데이터 소스를 조회하는 대시보드로 연결할 수 있다. Kiali 자체를 메트릭 저장소로 생각하면 “Kiali가 비었으니 요청이 없었다”는 잘못된 결론에 도달한다. Kiali 아키텍처 화살표는 범례에 적힌 요청·전송 방향이다. Prometheus가 메트릭 endpoint를 조회하는 것과 앱이 트레이스를 보내는 것을 구분한다. Kiali 화면의 연결이 비었다면 먼저 조회 Namespace와 시간 구간을 확인한다. 그 구간에 트래픽을 발생시켰는지, Istio 메트릭이 수집되는지, Prometheus endpoint에 Kiali가 접근할 수 있는지 순서대로 본다. “선이 없다”는 관찰에는 요청 없음과 수집 실패라는 서로 다른 가능성이 포함된다. 1.1 제품 로고는 역할을 찾는 표식이다 이 시리즈의 제품별 표식이다. 같은 로고를 썼다는 이유만으로 동일 프로세스나 필수 구성요소라는 뜻은 아니다. 아래 그림에서는 수집·저장·조회 화살표를 따라 실제 역할을 구분한다. Kubernetes 리소스 아이콘과 제품 로고도 서로 다른 의미로 사용한다. 2. 메트릭: 어떤 신호를 어느 위치에서 계산하는가 RED — 요청량(Rate), 오류(Errors), 지연(Duration)을 함께 보는 서비스 관측 관점이다. Istio HTTP 메트릭 중 istio_requests_total 은 요청 수 counter이고, istio_request_duration_milliseconds 는 요청 지연 분포다. source 와 destination reporter는 관측한 프록시 위치를 나타낸다. 두 reporter를 구분 없이 더하면 같은 호출을 중복 집계할 수 있다. TLS가 해독되지 않는 통과 트래픽이나 L4만 관측하는 구간에서는 같은 HTTP 지표가 나오리라고 가정하면 안 된다. Istio 표준 메트릭 다음은 Prometheus가 Istio HTTP 메트릭을 수집 중일 때 사용하는 미실행 쿼리 예제 다. 대상은 bookshop Namespace의 reviews Service로 들어온 요청이고 reporter는 수신 측으로 고정한다. Bookinfo처럼 Deployment가 버전별로 나뉘면 destination_workload 는 reviews-v1 , reviews-v2 등이 될 수 있으므로 Service 이름과 workload 이름을 혼동하지 않는다. 다음처럼 실제 라벨 조합부터 조회하고, 아래 식의 Service 이름이 수집값과 맞는지 확인한다. count by (destination_service_name, destination_service_namespace, destination_workload) ( istio_requests_total{ reporter="destination", destination_workload_namespace="bookshop" } ) 이 탐색식의 값은 요청 수가 아니라 해당 라벨 조합의 시계열 개수다. 목적은 이름 확인이다. 버전별 Service를 별도로 사용한다면 실제 Service 이름에 맞춰 필터를 바꾼다. sum(rate(istio_requests_total{ reporter="destination", destination_service_namespace="bookshop", destination_service_name="reviews" }[5m])) 결과는 최근 5분 표본으로 계산한 평균 요청/초 다. counter의 누적값을 그대로 그리면 재시작과 시간 경과가 섞이므로 rate 를 먼저 계산한 뒤 합친다. 그래프를 30분 구간·30초 step으로 표시하면 각 점은 그 시점의 직전 5분을 요약한 값이다. 순간 최대 요청량과 같은 뜻은 아니다. HTTP 5xx 비율은 같은 조건의 전체 요청률을 분모로 사용한다. 100 * sum(rate(istio_requests_total{ reporter="destination", destination_service_namespace="bookshop", destination_service_name="reviews", response_code=~"5.." }[5m])) / sum(rate(istio_requests_total{ reporter="destination", destination_service_namespace="bookshop", destination_service_name="reviews" }[5m])) 결과 단위는 %. 설명용 가정으로 초당 200개 중 4개가 5xx라면 2%다. 이는 실측이 아니다. 요청이 전혀 없으면 분모가 0이거나 시계열이 없을 수 있다. 전체 요청이 있어도 5xx 시계열이 아직 생성되지 않았다면 분자가 비어 식 전체가 빈 결과일 수 있다. 이런 경우 전체 요청의 수집이 확인된 구간에 한해서만 오류 0으로 해석하거나 보정한다. 이를 무조건 0% 성공으로 채우지 않는다. 트래픽 부재·수집 실패·표본 부족을 구분해야 한다. 또한 수신 프록시에 도달하기 전에 실패한 연결은 이 분모에 안 들어갈 수 있어, 호출자와 게이트웨이 지표도 함께 본다. gRPC는 별도 주의가 필요하다. HTTP 상태가 200이어도 gRPC status가 실패일 수 있다. 위 쿼리는 HTTP 5xx 질문에 답하며 모든 업무 실패율을 대표하지 않는다. 업무 오류·gRPC 상태 기준은 서비스의 성공 정의에 맞게 따로 설계한다. 3. p95: 평균이 숨기는 느린 요청을 읽기 classic histogram이 노출된 환경에서는 다음처럼 95번째 백분위수를 추정한다. histogram_quantile( 0.95, sum by (le) ( rate(istio_request_duration_milliseconds_bucket{ reporter="destination", destination_service_namespace="bookshop", destination_service_name="reviews" }[5m]) ) ) 단위는 메트릭 이름 그대로 밀리초 다. le 는 bucket 상한을 나타내므로 집계에서 보존한다. workload별 결과가 필요하면 sum by (le, destination_workload) 처럼 목적에 맞는 그룹도 남긴다. 현재 식은 지정한 reviews Service의 버전들을 합친 지연 분포를 계산한다. p95가 800ms라는 값은 관측 분포상 약 95%가 그보다 빠르다는 의미이지 모든 요청이 800ms 걸렸다는 뜻이 아니다. histogram bucket 경계에 따른 추정 오차도 있다. Pod별 p95를 평균내는 계산은 전체 요청의 p95와 다르다. native histogram을 사용하면 식과 저장 형태가 달라질 수 있으므로 이 예제는 _bucket 이 있는 classic histogram에 한정한다. Prometheus histogram 함수 실무에서는 p95 하나만으로 배포를 판단하기보다 요청량·오류율·p99·버전별 분포를 같이 본다. 예를 들어 표본 10개인 v2와 표본 10만 개인 v1의 p95를 같은 확신으로 비교할 수 없다. 비교 구간의 부하와 요청 종류가 바뀌면 지연 변화의 원인도 달라진다. 4. ServiceMonitor·PodMonitor: 대상을 찾는 선언과 수집 결과 구분 ServiceMonitor / PodMonitor — Prometheus Operator가 읽어 수집 대상을 구성하는 CRD다. 전자는 Service의 라벨을, 후자는 Pod의 라벨을 기준으로 대상을 찾는다. 선택은 보통 두 번 일어난다. Prometheus 리소스가 Monitor 객체를 고르고, 그 Monitor가 Service 또는 Pod를 고른다. 그래서 ServiceMonitor 파일을 만들었는데 Targets에 나타나지 않는다면 serviceMonitorSelector , serviceMonitorNamespaceSelector , Monitor의 대상 selector와 Namespace 범위를 차례로 확인한다. ServiceMonitor endpoint의 port 는 일반적으로 Service 포트의 이름 이다. 앱 컨테이너 포트 숫자나 라벨과 혼동하지 않는다. Prometheus Operator 시작 안내 또한 애플리케이션 메트릭, Envoy 데이터 평면 메트릭, istiod 제어 평면 메트릭은 관측 대상이 다르다. istiod만 잘 수집한다고 reviews의 HTTP 오류율이 생기지 않는다. sidecar의 메트릭 병합 기능을 사용하는지, 프록시 endpoint를 직접 scrape하는지에 따라 포트와 경로도 달라진다. 기존 수집 설정과 새 Monitor를 중복 적용하면 중복 시계열·부하가 생길 수 있다. Istio Prometheus 통합 “Targets가 UP”은 수집 endpoint 응답 성공이라는 좁은 사실이다. 필요한 istio_requests_total 이 존재하고 시간 구간에 샘플이 들어오는지까지 확인해야 원하는 관측이 완성된다. 5. Trace와 Span: 느린 한 요청을 분해하기 Trace — 하나의 작업이 여러 서비스를 거치는 흐름을 연결한 기록이다. Span 은 그 안의 개별 작업 구간으로 시작·종료 시각과 속성을 가진다. 가상의 trace가 다음처럼 보인다고 하자. productpage의 전체 처리는 900ms, reviews 호출은 820ms, 그 안의 ratings 호출은 700ms다. 이 세 시간을 더해 2,420ms라고 해석하면 안 된다. 부모 span은 자식이 실행된 시간을 포함할 수 있기 때문이다. 병렬 호출이 있다면 단순 합이 아니라 전체 완료를 늦춘 경로를 살펴야 한다. 이 경우 ratings가 유력한 조사 대상이지만 “ratings CPU가 원인”이라는 결론까지는 나오지 않는다. ratings 내부 DB 호출, 연결 대기, 스레드 대기처럼 더 세부적인 span이나 로그·프로파일이 필요하다. 네트워크 프록시가 만든 span만으로 함수 내부의 시간을 모두 설명할 수는 없다. 동일 trace의 관계를 이어 주는 것은 시간의 근접성이 아니라 전파된 context다. 프록시가 서로 다른 앱의 업무 인과관계를 자동 추론하지 않는다. Istio 프록시는 span을 보낼 수 있지만, 애플리케이션은 incoming request와 그로 인해 발생한 outgoing request 사이에 context를 전달해야 한다. 설정한 전파 형식에 맞게 W3C의 traceparent · tracestate 또는 B3 헤더와 SDK instrumentation을 확인한다. Istio가 요구하는 x-request-id 전파도 확인하되, 이 값만 전달하는 것으로 trace context 전파를 대신할 수는 없다. 중간 서비스가 새 Trace ID를 만들면 화면에 여러 개의 끊어진 trace가 나타날 수 있다. Istio 추적 개요 , OpenTelemetry context propagation 6. Jaeger v2: 옛 Agent 그림과 현재 수집 경로 구분 Jaeger v2는 OpenTelemetry Collector 프레임워크를 기반으로 한다. collector는 span을 받고 저장하며, query는 저장된 trace를 UI와 API로 조회한다. all-in-one은 역할을 한 프로세스에 모은 배포 형태다. all-in-one이라는 이름과 메모리 저장은 같은 개념이 아니다. 개발용 메모리 저장 구성을 쓰면 재시작 시 데이터가 사라질 수 있으므로 운영의 보존 기간·저장 용량·복구 요구에 맞는 저장소 구성이 필요하다. Jaeger v2 아키텍처 구성 예를 말로 읽으면 앱/프록시 → OTLP 수신 → 처리 → 저장 → query 조회 다. OTLP gRPC와 HTTP는 다른 전송 방식이며 흔히 각각 4317과 4318을 쓰지만, Service의 실제 노출 포트를 확인해야 한다. 16686 같은 UI 포트로 span을 보내는 것은 목적지가 잘못된 것이다. Jaeger API 별도의 OpenTelemetry Collector는 여러 신호를 모으거나 공통 속성 추가·필터링·샘플링을 집중할 때 유용하다. Jaeger 앞에 반드시 추가해야 하는 필수 부품은 아니다. Kafka 버퍼도 모든 배포의 필수 단계가 아니라 순간 유입량과 저장소 처리량 사이를 완충할 필요가 있을 때 검토한다. 구성요소를 늘리면 그만큼 대기·유실·재시도·저장 공간을 관측해야 할 곳도 늘어난다. 구버전 강의의 Jaeger Agent·Thrift·환경변수 설정을 현재 v2 설정에 그대로 섞지 않는다. 제품 버전과 함께 사용 중인 receiver·exporter·storage 설정을 확인한다. Kiali에서 Jaeger를 연결할 때도 ingestion endpoint가 아니라 해당 연동이 요구하는 query endpoint와 API 지원 을 확인한다. Jaeger 구성 , Kiali Jaeger 연동 7. Sampling: trace가 없다는 사실의 해석 Sampling — 모든 요청의 trace를 저장하는 대신 정책에 따라 일부를 선택하는 과정이다. Head sampling은 요청 초기에 선택한다. 비용을 줄이기 쉽지만 뒤늦게 발생할 오류를 미리 알 수 없다. Tail sampling은 여러 span을 받은 뒤 결과를 보고 고를 수 있어 느린 요청이나 오류 보존에 유리하지만 버퍼 메모리·판정 대기·동일 trace의 span을 모으는 설계가 필요하다. OpenTelemetry sampling 설명용으로 독립적인 1% 확률 샘플링을 가정하면, 요청 100개 중 정확히 하나가 남는다고 보장되지 않는다. 희귀 장애는 샘플에서 빠질 수 있다. 그러므로 오류율 메트릭은 상승했지만 Jaeger에 사례가 없다고 오류가 없었다고 결론 내리지 않는다. trace가 비는 이유는 sampling만이 아니다. exporter endpoint·TLS·권한 문제, Collector drop, queue 포화, 저장소 장애, 잘못된 시간 범위와 서비스명도 확인한다. “앱이 span을 생성했다 → Collector가 받았다 → exporter가 전송했다 → 저장됐다 → query가 조회했다”를 단계별로 검증한다. 8. 하나의 장애를 세 화면으로 좁히기 가상의 상황은 “reviews v2를 배포한 뒤 화면 지연 상승”이다. Kiali에서는 어느 edge와 버전에 오류가 집중되는지 본다. 메트릭에서는 같은 시간·workload·reporter로 요청량과 오류율, 지연을 비교한다. Jaeger에서는 해당 구간의 느린 trace를 선택해 reviews 자체 처리와 ratings 대기를 구분한다. 여기서 reviews v2의 ratings client가 context를 전달하지 않으면 가장 필요한 호출이 trace에서 끊겨 보일 수 있다. 이는 네트워크 장애가 아니라 관측 계측의 누락일 수도 있다. 데이터가 뒷받침하는 범위 안에서 가설을 세우고, 다음 확인 명령을 선택한다. 10편에서는 이 관측을 DNS·TCP·Service·Gateway·메시 정책의 진단 순서와 연결한다. 도구를 설치했다는 사실보다 중요한 것은 각 화면이 답할 수 있는 질문과 답할 수 없는 질문을 아는 것이다. 자료·예제 기준 — 2026-10-04에 링크한 공식 문서의 역할·메트릭·설정 의미를 확인했다. Jaeger는 v2 구조를 설명한다. PromQL은 공식 지표·문법 기반·실제 데이터 미실행 예제이며 수치는 설명용이다. 기존 Observability 시리즈 와 함께 읽으면 신호별 역할을 복습할 수 있다. 쿠버네티스 네트워크 10편 시리즈 TCP/IP부터 CNI까지, Pod가 통신하는 원리 Service·EndpointSlice·DNS Ingress와 Gateway API, 외부 진입과 연결 NetworkPolicy와 연결 허용 설계 Istio 구조: Sidecar·Ambient·CNI 카나리·재시도·서킷 브레이커 mTLS·JWT·인증과 인가 TLS와 cert-manager의 발급·갱신 Kiali·Jaeger·OpenTelemetry DNS부터 TLS까지 장애 진단 그림과 아이콘 출처 · 도식은 이 시리즈를 위해 직접 제작했다. Kubernetes 리소스 아이콘은 Kubernetes Icons Set (Kubernetes Authors / contributors, CC BY 4.0 )의 원본을 비율대로 축소해 배치했다. 제품 로고는 CNCF Artwork 와 Kiali 공식 자산 을 식별 목적으로 사용했다. 각 이름과 로고의 상표권은 해당 권리자에게 있으며, 공식 후원이나 인증을 뜻하지 않는다. 확인일: 2026-10-04.