[Istio 가이드 ep.28] 4부 모니터링 #4 | Envoy Proxy 로그 분석 및 트러블슈팅 실습

🔹 개요

이번 글에서는 Istio에서 Envoy Proxy 로그를 분석하는 방법과 트러블슈팅을 수행하는 방법을 살펴보겠습니다.
Istio는 서비스 메시 내부에서 Envoy 프록시를 활용하여 트래픽을 관리하며,
Envoy 로그를 분석하면 네트워크 문제, 요청 지연, 오류 발생 원인을 신속하게 파악할 수 있습니다.

이 글에서는 Envoy Proxy의 주요 로그 유형, 로그 분석 방법, 실전 트러블슈팅 예제를 설명하겠습니다.

---

🔹 1. Envoy Proxy 로그란?

✅ 1.1 Envoy Proxy란?

Envoy Proxy는 Istio에서 트래픽을 제어하고 모니터링하는 서비스 프록시입니다.
각 Pod에 Sidecar 형태로 배포되며, 모든 네트워크 트래픽이 Envoy를 통해 전달됩니다.

Envoy Proxy의 역할

• 서비스 간 트래픽 라우팅 및 부하 분산
• mTLS를 통한 보안 및 암호화 적용
• 트래픽 로그 및 메트릭 수집
• 네트워크 오류 감지 및 트러블슈팅 지원

💡 Istio에서 네트워크 트러블슈팅을 수행하려면 Envoy 로그를 분석하는 것이 필수적입니다.

---

✅ 1.2 Envoy Proxy 로그 유형

Envoy Proxy는 다음과 같은 유형의 로그를 제공합니다.

로그 유형	설명
Access Log	서비스 요청 및 응답 로그 (HTTP, gRPC, TCP 요청 정보)
Admin Log	Envoy 관리 인터페이스에서 제공하는 내부 로그
Error Log	요청 실패 및 네트워크 오류 발생 시 기록되는 로그
Trace Log	요청 경로 및 서비스 호출 흐름 추적 (Jaeger, Zipkin 연동 가능)

💡 Access Log와 Error Log를 분석하면 네트워크 트래픽 상태 및 오류 원인을 파악할 수 있습니다.

---

🔹 2. Envoy Proxy 로그 분석 방법

✅ 2.1 Envoy Access Log 설정 확인

Istio에서 Envoy Access Log가 활성화되었는지 확인하려면 다음 명령어를 실행합니다.

kubectl get configmap istio -n istio-system -o yaml | grep accessLogFile

 

출력 예제:

accessLogFile: "/dev/stdout"

💡 Access Log가 /dev/stdout으로 설정되어 있으면, kubectl logs 명령어로 로그를 확인할 수 있습니다.

---

✅ 2.2 특정 Pod의 Envoy Proxy 로그 확인

Envoy Proxy 로그를 확인하려면, 해당 Pod의 Sidecar 컨테이너 로그를 조회해야 합니다.

kubectl logs <pod-name> -c istio-proxy -n <namespace>

 

예제:

kubectl logs my-app-pod -c istio-proxy -n default

 

출력 예제:

[2024-03-16T12:34:56.123Z] "GET /api/data HTTP/1.1" 200 - upstream_service_time=20ms
[2024-03-16T12:35:02.456Z] "POST /api/login HTTP/1.1" 401 - upstream_service_time=10ms

💡 응답 코드(200, 401) 및 서비스 응답 시간(upstream_service_time)을 분석하여 성능 문제를 파악할 수 있습니다.

---

✅ 2.3 Envoy Proxy Admin 인터페이스 활용하기

Envoy Proxy의 상태 및 설정을 확인하려면 Admin API를 사용할 수 있습니다.

① 특정 Pod의 Envoy Admin API에 접근

kubectl port-forward <pod-name> -n <namespace> 15000:15000

웹 브라우저에서 http://localhost:15000 에 접속하면 Envoy의 관리 페이지를 확인할 수 있습니다.

② Envoy의 현재 설정 확인

curl http://localhost:15000/config_dump

③ Envoy의 활성 라우트 정보 조회

curl http://localhost:15000/routes

💡 Admin API를 활용하면 Envoy Proxy의 네트워크 설정 및 라우팅 상태를 상세히 분석할 수 있습니다.

---

🔹 3. Envoy Proxy 트러블슈팅 실습

✅ 3.1 트래픽이 특정 서비스로 전달되지 않는 경우

🛠️ 해결 방법: Envoy의 라우팅 설정을 확인하고, DestinationRule이 올바르게 설정되었는지 점검해야 합니다.

① 특정 서비스로 트래픽이 전달되는지 확인

kubectl logs <pod-name> -c istio-proxy -n <namespace> | grep "GET /api/data"

② DestinationRule이 올바르게 설정되었는지 확인

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

💡 DestinationRule에서 tls.mode: ISTIO_MUTUAL이 설정되지 않으면, mTLS 활성화된 서비스 간 통신이 차단될 수 있습니다.

---

✅ 3.2 특정 요청이 503(Service Unavailable) 오류를 반환하는 경우

🛠️ 해결 방법: Envoy Proxy 로그를 확인하고, 백엔드 서비스가 정상적으로 실행 중인지 점검해야 합니다.

① 503 오류 로그 확인

kubectl logs <pod-name> -c istio-proxy -n <namespace> | grep "503"

 

출력 예제:

[2024-03-16T12:40:00.789Z] "GET /api/data HTTP/1.1" 503 - upstream_reset_before_response_started{connection_termination}

② 백엔드 서비스 상태 확인

kubectl get pods -n default

💡 503 오류는 일반적으로 백엔드 서비스가 비정상 상태이거나, DestinationRule 설정이 올바르지 않을 때 발생합니다.

---

✅ 3.3 서비스 간 요청 지연 시간이 비정상적으로 긴 경우

🛠️ 해결 방법: Envoy Proxy의 upstream_service_time 값을 분석하여 지연 원인을 찾습니다.

① 응답 시간이 긴 요청 필터링

kubectl logs <pod-name> -c istio-proxy -n <namespace> | grep "upstream_service_time"

 

출력 예제:

[2024-03-16T12:50:00.123Z] "GET /api/orders HTTP/1.1" 200 - upstream_service_time=1500ms

💡 upstream_service_time=1500ms → 백엔드 서비스의 응답 시간이 1.5초로, 성능 최적화 필요

---

📌 결론

• Envoy Proxy 로그를 분석하면 서비스 메시 내부 트래픽 흐름 및 성능 문제를 파악할 수 있습니다.
• Access Log를 통해 HTTP 요청 상태, 응답 코드 및 지연 시간을 분석할 수 있습니다.
• Envoy Admin API를 활용하면 네트워크 설정 및 라우팅 문제를 진단할 수 있습니다.
• 503 오류, 트래픽 누락, 성능 저하 등의 문제는 Envoy 로그 및 Istio 리소스 설정을 점검하여 해결할 수 있습니다.