Ssoon

[6주차] 데이터 플레인 문제 해결 : Envoy 원격 분석을 사용하여 애플리케이션 이해 본문

Istio Hands-on Study [1기]

[6주차] 데이터 플레인 문제 해결 : Envoy 원격 분석을 사용하여 애플리케이션 이해

구구달스 2025. 4. 22. 10:31

📊 Envoy Telemetry로 애플리케이션 이해하기


🛠️ Grafana로 실패한 요청 비율 확인하기

  • Envoy proxy는 서비스의 메트릭을 저장해 오류율을 분석할 수 있게 해줍니다. 이를 가장 쉽게 확인하는 방법은 Grafana 대시보드를 사용하는 것입니다. Grafana는 Prometheus와 함께 설치되며, Istio의 기본 대시보드를 제공해 빠르게 서비스 상태를 파악할 수 있습니다.

트래픽 생성

  • 분석을 시작하기 위해 먼저 트래픽을 생성합니다. 이전에 사용했던 것과 동일한 명령어를 실행하세요:
$ for in in {1..9999}; do curl http://catalog.istioinaction.io:30000/items -w "\nStatus Code %{http_code}\n"; sleep 1; done

 

Grafana 대시보드 열기

  • 브라우저에서 http://localhost:30002에 접속한 후, 아래 자격 증명으로 로그인하세요:
  • Username: admin
  • Password: prom-operator

Istio Service Dashboard 탐색

  • Grafana에 로그인한 후, Istio Service Dashboard로 이동합니다. 여기서 catalog.istioinaction.svc.cluster.local 서비스를 필터링하고 General 패널을 확인하세요. Client Success Rate (Non-5xx Responses) 다이어그램을 보면 성공률을 확인할 수 있습니다.

Grafana의 Istio Service Dashboard에서
Client Success Rate를 확인해 서비스의 실패율을 파악하세요.


🔍 클라이언트와 서버 성공률 비교

  • Grafana에서 확인한 성공률을 분석해보면, 클라이언트와 서버의 성공률이 다르게 나타납니다. 이를 통해 문제의 원인을 더 깊이 이해할 수 있습니다.

서버 성공률 확인

  • Server Success Rate 다이어그램을 보면 서버는 100% 성공률을 보고합니다. 이는 Envoy proxy가 클라이언트가 연결을 종료한 요청(downstream terminated requests)에 대해 응답 코드 0을 기록하기 때문입니다.
    코드 0은 5xx 오류로 간주되지 않으므로 실패율에 포함되지 않습니다.

클라이언트 성공률과 상태 코드

  • 반면, 클라이언트는 동일한 요청에 대해 상태 코드 504(Gateway Timeout)를 기록합니다. 이는 클라이언트가 서버의 응답이 너무 느리다고 판단해 연결을 종료했음을 나타냅니다. 따라서 클라이언트의 실패율에는 이 요청이 포함됩니다.

분석 결과

  • 클라이언트가 보고한 실패율(20~30%)이 실제 상황을 더 정확히 반영합니다. 이는 즉각적인 조치가 필요한 심각한 문제입니다. 하지만 Grafana는 catalog 서비스 뒤에 있는 모든 워크로드의 성공률을 보여주므로, 문제가 있는 특정 인스턴스를 찾으려면 더 자세한 분석이 필요합니다.

클라이언트의 실패율(20~30%)이 정확하며,
특정 인스턴스 문제를 찾기 위해 추가 분석이 필요합니다.


📌 핵심 요약

  • 트래픽 생성: curl 명령어로 트래픽을 생성해 서비스 상태를 확인
  • Grafana 접속: Prometheus 포트 포워딩으로 Grafana에 접속하고, Istio Service Dashboard에서 catalog 서비스를 분석
  • 성공률 확인: Client Success Rate에서 약 30%의 요청이 실패했음을 확인
  • 클라이언트 vs 서버: 서버는 100% 성공률을 보고하지만, 클라이언트는 504 상태 코드를 기록해 실제 실패율을 반영
  • 다음 단계: 20~30%의 실패율은 심각하며, 문제 인스턴스를 찾기 위해 더 자세한 분석이 필요

🔍 Prometheus로 문제 Pod 분석하기

  • Prometheus를 활용해 Grafana 대시보드에서 확인하기 어려운 세부 메트릭을 쿼리하는 방법을 설명합니다.
  • 특정 Pod의 실패율(failure rate)을 분석해 문제가 있는 애플리케이션을 찾아내는 과정 을 설명합니다.

🛠️ Prometheus 대시보드 열기

  • Grafana 대시보드가 전체적인 성공률은 보여주지만, 특정 Pod의 문제를 파악하려면 더 세부적인 데이터가 필요합니다. 이를 위해 Prometheus를 직접 쿼리해 각 Pod의 실패율을 확인합니다.

Prometheus 접속

  • 브라우저에서 http://localhost:30001에 접속합니다.

📊 Pod별 실패율 쿼리하기

  • 우리는 특정 조건을 만족하는 메트릭을 쿼리해 문제가 있는 Pod를 찾아낼 것입니다. 쿼리는 아래 조건을 기반으로 작성됩니다:
    • Destination에서 보고된 요청
    • Destination service가 catalog.istioinaction.svc.cluster.local인 요청
    • Response flag가 DC(downstream connection termination)인 요청

Prometheus 쿼리

  • Prometheus 쿼리 창에 아래 쿼리를 입력하세요:
sort_desc( # 가장 높은 값부터 내림차순 정렬
  sum( # irate 값들을 집계
    irate( #  요청 수 초당 증가율
      istio_requests_total {
        reporter="destination",   # 서버(destination) 측에서 보고한 메트릭만 필터링
        destination_service=~"catalog.istioinaction.svc.cluster.local",   # catalog 가 서버(destination)측인 메트릭만 필터링
        response_flags="DC"       # DC (다운스트림 커넥션 종료)로 끝난 메트릭만 필터링
      }[5m]
    )
  )by(response_code, pod, version) # 응답 코드(response_code), 대상 pod, 버전(version) 별로 분리 => sum.. 합산
)

쿼리 설명

  • reporter="destination": Destination(서버 측)에서 보고된 메트릭만 필터링합니다.
  • destination_service=~"catalog...": catalog 서비스로 향하는 요청만 선택합니다.
  • response_flags="DC": 클라이언트가 연결을 종료한(downstream connection termination) 요청을 필터링합니다.
  • irate(...[5m]): 지난 5분 동안의 요청 비율을 계산합니다.
  • sort_desc: 결과를 내림차순으로 정렬해 실패율이 높은 Pod를 쉽게 확인합니다.
  • by (response_code, kubernetes_pod_name, version): 응답 코드, Pod 이름, 버전별로 결과를 그룹화합니다.

결과 확인

  • 쿼리를 실행한 후, Graph 뷰로 이동하면 실패율이 시각적으로 표시됩니다.
    그래프를 보면 version-v2 워크로드 중 단 하나의 Pod만 실패를 보고하고 있음을 알 수 있습니다.

  • 이 결과는 version-v2 전체가 문제가 아니라 특정 Pod에 문제가 있음을 시사합니다.
  • 퀴리를 조금 수정해서 확인 : 여러 개 파드 중 catalog v2 만 응답 코드 0 기록 확인

Prometheus 쿼리로 Pod별 실패율을 확인해 문제 Pod를 특정합니다.


📈 추가 메트릭과 디버깅 팁

  • Istio의 표준 메트릭으로 충분한 정보를 얻지 못했다면, 커스텀 메트릭을 추가할 수 있습니다. 또한, Prometheus client libraries를 사용해 애플리케이션에 원하는 메트릭을 추가로 기록할 수 있습니다.

📌 핵심 요약

  • Pod별 쿼리: istio_requests_total 메트릭을 쿼리해 catalog 서비스의 실패율을 Pod 단위로 분석
  • 문제 Pod 특정: 그래프에서 version-v2의 특정 Pod만 실패를 보고함을 확인
  • 추가 디버깅: Istio 표준 메트릭이 부족하면 커스텀 메트릭이나 Prometheus client libraries를 활용

 

Comments