관찰성(Observability) — Istio 텔레메트리로 서비스 들여다보기

Istio는 메시 안에서 오가는 모든 서비스 통신에 대해 상세한 텔레메트리를 생성해요. 이 텔레메트리가 곧 서비스 동작의 관찰성(observability) 을 만들어 주고, 운영자는 서비스 개발자에게 추가 부담을 주지 않으면서 장애 원인을 찾고, 유지보수하고, 최적화할 수 있어요. 기본 아이디어는 간단해요. 프록시가 지나가는 트래픽을 이미 다 보고 있으니, 그 정보를 메트릭·트레이스·로그 세 가지로 정리해 주는 거죠.

출처: Observability — Istio 공식 문서

Istio가 만드는 텔레메트리

서비스 메시 관찰성을 위해 Istio는 다음 세 종류의 텔레메트리를 생성해요.

메트릭(Metrics): 모니터링의 "골든 시그널" 네 가지(지연, 트래픽, 에러, 포화)를 바탕으로 서비스 메트릭을 만들고, 메시 컨트롤 플레인에 대한 상세 메트릭과 기본 대시보드도 제공해요.
분산 트레이스(Distributed Traces): 서비스마다 트레이스 스팬을 생성해 메시 안의 호출 흐름과 서비스 의존성을 이해하게 해줘요.
액세스 로그(Access Logs): 요청이 서비스로 흘러들어올 때 소스·대상 메타데이터를 포함한 전체 기록을 생성해, 개별 워크로드 인스턴스 수준까지 감사할 수 있게 해줘요.

메트릭

메트릭은 동작을 집계해서 이해하는 방법이에요. Istio는 메시 안으로 들어오고, 나가고, 메시 안에서 오가는 모든 서비스 트래픽에 대해 메트릭을 생성해요. 이 메트릭은 트래픽 총량, 에러율, 요청 응답 시간 같은 동작 정보를 담아요.

메시 안의 서비스뿐 아니라 메시 자체의 동작도 봐야 해요. Istio 컴포넌트도 자신의 내부 동작에 대한 메트릭을 내보내서 컨트롤 플레인의 건강 상태와 기능에 대한 인사이트를 제공해요.

프록시 레벨 메트릭

Istio의 메트릭 수집은 사이드카 프록시(Envoy)에서 시작돼요. 각 프록시는 프록시를 지나가는 모든 트래픽(인바운드·아웃바운드 모두)에 대한 풍부한 메트릭을 생성하고, 프록시 자체의 설정·건강 정보 같은 관리 기능 통계도 제공해요.

Envoy 생성 메트릭은 리스너·클러스터 같은 Envoy 리소스 단위로 메시를 모니터링하게 해줘요. 그래서 메시 서비스와 Envoy 리소스 사이의 연결을 이해해야 Envoy 메트릭을 제대로 읽을 수 있어요.

Istio는 각 워크로드 인스턴스에서 생성·수집할 Envoy 메트릭을 고를 수 있게 해줘요. 기본적으로는 메트릭 백엔드를 압도하지 않고 수집 CPU 오버헤드를 줄이도록 Envoy 통계 중 작은 일부만 켜요. 필요하면 수집하는 프록시 메트릭을 쉽게 늘려 네트워킹 동작을 타깃 디버깅할 수 있어요.

프록시 레벨 메트릭 예시:

envoy_cluster_internal_upstream_rq{response_code_class="2xx",cluster_name="xds-grpc"} 7163

envoy_cluster_upstream_rq_completed{cluster_name="xds-grpc"} 7164

envoy_cluster_ssl_connection_error{cluster_name="xds-grpc"} 0

envoy_cluster_lb_subsets_removed{cluster_name="xds-grpc"} 0

envoy_cluster_internal_upstream_rq{response_code="503",cluster_name="xds-grpc"} 1

서비스 레벨 메트릭

프록시 레벨 메트릭에 더해 Istio는 서비스 통신을 모니터링하기 위한 서비스 중심 메트릭도 제공해요. 이 메트릭은 지연, 트래픽, 에러, 포화라는 네 가지 기본 모니터링 니즈를 다루고, 이를 바탕으로 한 기본 대시보드도 함께 제공돼요.

표준 Istio 메트릭은 기본적으로 Prometheus로 내보내져요. 서비스 레벨 메트릭은 완전히 선택 사항이라, 필요에 따라 생성·수집을 꺼도 돼요.

서비스 레벨 메트릭 예시:

istio_requests_total{
  connection_security_policy="mutual_tls",
  destination_app="details",
  destination_canonical_service="details",
  destination_canonical_revision="v1",
  destination_principal="cluster.local/ns/default/sa/default",
  destination_service="details.default.svc.cluster.local",
  destination_service_name="details",
  destination_service_namespace="default",
  destination_version="v1",
  destination_workload="details-v1",
  destination_workload_namespace="default",
  reporter="destination",
  request_protocol="http",
  response_code="200",
  response_flags="-",
  source_app="productpage",
  source_canonical_service="productpage",
  source_canonical_revision="v1",
  source_principal="cluster.local/ns/default/sa/default",
  source_version="v1",
  source_workload="productpage-v1",
  source_workload_namespace="default"
} 214

컨트롤 플레인 메트릭

Istio 컨트롤 플레인도 자기 모니터링용 메트릭 모음을 제공해요. 이 메트릭은 메시 안의 서비스와는 별개로 Istio 자체의 동작을 모니터링할 수 있게 해줘요. 유지되는 메트릭에 대한 자세한 내용은 pilot-discovery 레퍼런스를 참고해요.

분산 트레이스

분산 트레이스는 요청이 메시를 흐르는 동안 개별 요청을 따라가며 동작을 이해하는 방법이에요. 트레이스는 운영자가 서비스 의존성과 서비스 메시 안의 지연 원인을 파악하게 도와줘요.

Istio는 Envoy 프록시를 통해 분산 트레이스를 지원해요. 프록시가 프록시하는 애플리케이션을 대신해 트레이스 스팬을 자동 생성하며, 애플리케이션은 적절한 요청 컨텍스트만 전달해 주면 돼요.

Zipkin, Jaeger, 그리고 OpenTelemetry를 지원하는 많은 도구와 서비스가 트레이싱 백엔드로 쓰여요. 운영자는 트레이스 생성 샘플링 비율(요청당 트레이싱 데이터를 얼마나 만들지)을 제어해서 메시에서 만들어지는 트레이싱 데이터의 양과 비율을 조절할 수 있어요. 자세한 내용은 분산 트레이싱 FAQ에서 볼 수 있어요.

액세스 로그

액세스 로그는 개별 워크로드 인스턴스의 관점에서 동작을 이해하는 방법이에요. Istio는 설정 가능한 여러 형식으로 서비스 트래픽에 대한 액세스 로그를 생성해, 로깅의 방법·내용·시점·장소를 운영자가 모두 제어할 수 있게 해줘요. 자세한 내용은 Envoy 액세스 로그 얻기를 참고해요.

Istio 액세스 로그 예시:

[2019-03-06T09:31:27.360Z] "GET /status/418 HTTP/1.1" 418 - "-" 0 135 5 2 "-" "curl/7.60.0" "d209e46f-9ed5-9b61-bbdd-43e22662702a" "httpbin:8000" "127.0.0.1:80" inbound|8000|http|httpbin.default.svc.cluster.local - 172.30.146.73:80 172.30.146.82:38618 outbound_.8000_._.httpbin.default.svc.cluster.local

관찰성(Observability) — Istio 텔레메트리로 서비스 들여다보기