[istio] istio 의 Access Log 활성화

2025. 8. 6. 02:01·Service Mesh/Istio 운영 특이사항

들어가기 앞서

파드를 재배포하며 Rolling Update를 수행하는 과정에서, APM 모니터링을 통해 일시적으로 응답 속도가 지연되는 현상을 확인하였다. 이 현상은 Istio proxy(Envoy)가 종료 중인 파드보다 먼저 종료되어, 이미 종료되었거나 종료 중인 파드로의 트래픽 처리가 제대로 이루어지지 않으면서 발생한 것으로 추정된다. 사이드카 프록시가 먼저 죽어 트래픽이 정상적으로 처리되지 못하고 내부에서 대기하다가 타임아웃되며, 이로 인해 백엔드 파드에서 500 오류가 발생하는 것으로 보인다. 정확한 원인 분석을 위해 Istio proxy의 Access Log를 확인하려 했으나, 로그가 비활성화되어 있어 이를 활성화하는 작업을 진행하고자 한다.

응답 속도 지연에 대한 상세 분석은 추후 다시 정리하여 포스팅할 예정이다.

Istio Proxy 액세스 로그 활성화

Istio에서 가장 간단한 형태의 로깅은 Envoy의 access log이다. Envoy 프록시는 접근 정보를 표준 출력(stdout) 으로 출력하며, 이는 kubectl logs 명령어를 통해 확인할 수 있다. 또한, demo 프로파일로 Istio를 설치하면 Egress Gateway와 Access Logging이 자동으로 활성화된다. (프로덕션 환경은 대부분 default profile 을 사용)

istio-ingressgateway의 YAML을 확인해보면, 이 파드는 istio-proxy 단일 컨테이너로 구성되어 있음을 알 수 있다. istio-ingressgateway는 기본적으로 외부 트래픽이 Mesh 내부로 들어오는 진입점(Entry Point) 역할을 수행하며, 단순히 첫 트래픽의 proxy를 통한 트래픽 라우팅을 위해 사용한다. 그렇기 때문에 istio proxy access log를 활성화하면, istio-ingressgateway도 istio-proxy 컨테이너를 기반으로 동작하기 때문에 함께 활성화된다.

방법1) Telemetry API 사용

Istio에서 access log를 활성화하는 방법은 몇 가지가 있으며, Telemetry API 사용을 권장한다. 다음과 같은 리소스를 생성하여 Access Logging을 활성화할 수 있다.

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-default                # 모든 메시(mesh)에 적용되는 기본 설정 이름
  namespace: istio-system          # 메시 전체 설정은 반드시 istio-system 네임스페이스에 위치해야 함
spec:
  accessLogging:
    - providers:
        - name: envoy              # 기본 envoy 로그 제공자 사용
  • 기본 제공되는 envoy 로그 제공자를 사용하고 있으며, 별도의 커스터마이징 없이 동작한다.
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: ns-telemetry               # 네임스페이스용 설정 이름 (자유롭게 지정)
  namespace: team-a                # 이 설정은 team-a 네임스페이스에만 적용됨
spec:
  accessLogging:
    - providers:
        - name: envoy              # envoy 로그 사용
  • Telemetry 리소스는 전체 메시(mesh) 뿐 아니라, 네임스페이스 단위, 워크로드 단위로도 적용 가능하다.
  • 네임스페이스 단위 적용 (예: team-a 네임스페이스에만 적용), 같은 네임스페이스 안의 모든 워크로드에 이 설정이 적용됨
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: payment-telemetry          # 특정 워크로드용 설정 이름
  namespace: team-a                # 대상 워크로드가 위치한 네임스페이스
spec:
  selector:
    matchLabels:
      app: payment                 # app=payment 라벨을 가진 워크로드에만 적용
  accessLogging:
    - providers:
        - name: envoy              # envoy 로그 사용
  • 특정 워크로드 단위 적용 (예: app=payment 라벨을 가진 워크로드만 대상)

이러한 방식으로 Mesh > Namespace > Workload 순으로 우선순위가 적용되며, 보다 구체적인 설정이 우선시된다. 예를 들어 app=payment에 대한 workload-level Telemetry가 있다면, 같은 네임스페이스에 존재하는 namespace-level Telemetry보다 우선 적용된다. 만약, 메시 전체(mesh-wide) 설정에서 access log를 켰는데, 네임스페이스 단위에서 로그 포맷을 다르게 지정했고, 워크로드 단위에서 로그를 완전히 끄도록 설정했다면, 워크로드 단위 설정이 가장 구체적이므로, 해당 워크로드에는 워크로드 단위 설정(즉, 로그 끄기)이 적용되고, 나머지 네임스페이스 내 다른 워크로드에는 네임스페이스 설정이 적용되며, 그 외에는 메시 전체 설정이 적용된다.

방법2) IstioOperator 설정(MeshConfig)

Istio를 IstioOperator를 통해 설치했다면, 다음 필드를 추가하여 로그를 활성화할 수 있다.

spec:
  meshConfig:
    accessLogFile: /dev/stdout
kubectl apply -f - <<EOF
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: istiocontrolplane
spec:
  profile: demo
  meshConfig:
    accessLogFile: /dev/stdout
  values:
    gateways:
      istio-ingressgateway:
        autoscaleEnabled: true
        type: ClusterIP
        serviceAnnotations:
          cloud.google.com/backend-config: '{"default": "istio-ingressgateway"}'
      istio-egressgateway:
        autoscaleEnabled: true
EOF

또는, 처음 설치 시 아래와 같이 명령어에 설정을 추가할 수도 있다.

istioctl install <기존 플래그> --set meshConfig.accessLogFile=/dev/stdout

만약 이도 아니라면, istio configMap 수정을 통해 설정할 수 있다. mesh.accessLogFile 설정의 값을 "/dev/stdout" 으로 설정

kubectl edit cm istio -n istio-system

apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout -> 로그 설정 추가
    defaultConfig:
      discoveryAddress: istiod.istio-system.svc:15012
      proxyMetadata: {}
      tracing:
        zipkin:
          address: zipkin.istio-system:9411
    enablePrometheusMerge: true
    rootNamespace: istio-system
    trustDomain: cluster.local
  meshNetworks: 'networks: {}'
...

선택적으로 다음 항목도 설정할 수 있다.

  • 로그 포맷: accessLogFormat
  • 인코딩 방식: accessLogEncoding (JSON 또는 TEXT)

관련 설정은 다음을 참고:

  • meshConfig.accessLogFile
  • meshConfig.accessLogEncoding
  • meshConfig.accessLogFormat

기본 로그 포맷

Access log 포맷(accessLogFormat) 을 명시하지 않으면 Istio는 다음과 같은 기본 포맷을 사용한다

[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS%
\"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\"
\"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER_RAW% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n

accessLogFile과 함께 accessLogFormat 값을 지정하면 로그 출력 형식을 설정할 수 있다.

spec:
  meshConfig:
    accessLogFile: /dev/stdout
    accessLogEncoding: JSON
    accessLogFormat: |
      {
        "start_time": "%START_TIME%",
        "method": "%REQ(:METHOD)%",
        "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
        "protocol": "%PROTOCOL%",
        "response_code": "%RESPONSE_CODE%",
        "duration": "%DURATION%",
        "upstream_host": "%UPSTREAM_HOST%"
      }

참고) 사용 가능한 로그 변수 

  • %START_TIME% – 요청 시작 시각
  • %REQ(:METHOD)% – HTTP 메서드(GET, POST 등)
  • %REQ(:PATH)% – 요청 경로
  • %RESPONSE_CODE% – 응답 코드 (200, 500 등)
  • %RESPONSE_FLAGS%, %DURATION%, %UPSTREAM_HOST% 등 다양한 항목 사용 가능

더 자세한 사항은 아래의 공식 문서를 확인하자

https://istio.io/latest/docs/tasks/observability/logs/access-log/

 

Envoy Access Logs

This task shows you how to configure Envoy proxies to print access logs to their standard output.

istio.io

Access Log 로그 레벨 설정

istio-proxy(Envoy)의 기본 로그 레벨은 info이다. 로그 레벨을 변경하는 방법은 임시 적용과 영구 적용 두 가지가 있으며, 일반적으로는 이슈 발생 시점에만 임시로 로그 레벨을 높여 확인하는 경우가 많다.

기동 중인 파드에 로그 레벨을 임시 적용하는 방법

파드에 로그 레벨을 임시 적용하면 즉시 반영되지만, 파드가 재시작되면 기본값(info)으로 되돌아간다. 

kubectl exec -it -n <namespace> <pod-name> -- \
  curl -X POST http://localhost:15000/logging?level=trace
  • Sidecar 컨테이너 내부의 관리용 포트(15000)를 통해 동적으로 설정. (실제 컨테이너 내부에 직접 접속해서 실행도 가능)
curl -X POST http://localhost:15000/logging
예시) curl -X POST http://localhost:15000/logging?level=debug
  • 위 명령을 실행하면 현재 로그 레벨을 조회할 수 있으며, ?level=<레벨>을 붙이면 임시 변경된다.

Deployment에 annotation을 설정하여 영구 적용하는 방법

파드가 재기동되어도 변경한 로그 레벨이 영구 반영됨

kubectl edit deploy <deployment-name> -n <namespace>

spec:
   ...(중략)...
   template:
      metadata:
          annotations:
               ...(중략)...
               sidecar.istio.io/agentLogLevel: info/trace/debug ...
  • Deployment에 sidecar.istio.io/agentLogLevel annotation을 추가
  • 수정 후 파드가 재생성되면 설정이 반영됨

Access Log 확인 명령어

kubectl logs -l app=<파드 레이블> -c istio-proxy

[2020-11-25T21:26:18.409Z] "GET /status/418 HTTP/1.1" 418 - via_upstream - "-" 0 135 4 4 "-" "curl/7.73.0-DEV" "84961386-6d84-929d-98bd-c5aee93b5c88" "httpbin:8000" "10.44.1.27:80" outbound|8000||httpbin.foo.svc.cluster.local 10.44.1.23:37652 10.0.45.184:8000 10.44.1.23:46520 - default
kubectl logs -f <pod-name> -c istio-proxy -n <namespace>
  • access log와 Envoy 자체 로그가 함께 출력되므로, 로그가 복잡하게 보일 수 있음.

'Service Mesh > Istio 운영 특이사항' 카테고리의 다른 글

[istio] Default Health Check Route and Port  (0) 2025.10.26
[istio] argo rollout + istio 를 통한 canary 배포 전략 도입  (0) 2025.10.26
[istio] istioOperator 커스텀  (0) 2025.08.20
[istio] istio proxy 의 Graceful Startup & Termination  (2) 2025.08.07
[Istio] NLB 의 Target Group 헬스 체크 실패  (0) 2025.04.30
'Service Mesh/Istio 운영 특이사항' 카테고리의 다른 글
  • [istio] argo rollout + istio 를 통한 canary 배포 전략 도입
  • [istio] istioOperator 커스텀
  • [istio] istio proxy 의 Graceful Startup & Termination
  • [Istio] NLB 의 Target Group 헬스 체크 실패
Hyukops
Hyukops
안녕하세요
  • Hyukops
    Hyukops 님의 Tech Blog
    Hyukops
    • 분류 전체보기 (141)
      • Introduction (1)
      • Kubernetes & EKS (43)
        • k8s in action (9)
        • k8s 공부 기록 (17)
        • k8s 운영 가이드 (10)
        • k8s 운영 특이사항 (7)
      • Service Mesh (29)
        • Istio 공부 기록 (20)
        • Istio 운영 특이사항 (9)
      • CICD (10)
        • argoCD 공부 기록 (6)
        • argoCD 운영 특이사항 (4)
      • Logging & Monitoring (5)
        • Prometheus 운영 특이사항 (0)
        • fluent bit 운영 특이사항 (5)
      • Infrastructure as Code (8)
        • terraform 공부 기록 (3)
        • terraform 운영 특이사항 (5)
      • AWS (40)
        • aws 공부 기록 (29)
        • 솔루션 사례 & 문제 해결 (11)
      • Database (5)
        • postgreSQL (5)
  • 태그

    fluent bit
    aws saa
    eks
    fluentbit
    Terraform
    Logging
    kubernetes
    canary
    MSK
    AWS
    Database
    prometheus
    PostgreSQL
    argocd
    k8s in action
    Istio
  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
Hyukops
[istio] istio 의 Access Log 활성화
상단으로

티스토리툴바