※ 트래픽이 많은 MSA 환경에서 istio-proxy 로그 레벨을 높이거나 access log를 쌓을 경우 너무 많은 디스크가 사용되기 때문에 기본적으로는 info level에 access 로그는 off로 구성될 수 있다.
허나 실무 서비스 이슈 발생 시 디버깅 용도로 로그레벨 및 access log를 설정하여 봐야하는 경우가 있다.
이번 글에서는 MSA 환경에서 MSA간 문제 발생 시, istio를 통한 디버깅 방법을 적어보려고 한다.
● 서비스 이슈 발생 시 로그 보는 방법
: 기본적으로 이슈 발생 시, 아래 명령어로 컨테이너 로그를 볼 수 있다.
| $ kubectl logs -f [pod-name] -n [namespace-name] -c [container-name] |
※ 멀티컨테이너 구성 시에 -c 옵션을 통해 특정 컨테이너 로그만 볼 수 있다.
● access log 설정
: istio config map 수정을 통해 설정할 수 있으며 약 1분뒤에 반영된다.
istio-ingressgateway와 app의 istio-proxy에 모두 반영되며 Pod 재기동은 필요 없다.
$ kubectl edit cm istio -n istio-system |
※ accessLogFile: /dev/stdout 라인을 추가하면 access 로그가 enable 된다.
- cli를 통해 istio-proxy의 access 로그를 확인한다.
$ kubectl logs -f ratings-v1-5967f59c58-7w7xd -n default -c istio-proxy |
※ URI, HTTP Code, inbound/outbound 정도 등의 출력정보를 확인할 수 있다.
● 로그 레벨 설정
: istio-proxy의 로그레벨은 default로 info 이다. 로그 레벨을 변경하는 방법은 임시적용과 영구적용 두 가지가 있다. 보통 이슈 발생 시점에만 로그레벨을 높혀서 보기 때문에 임시방법을 사용한다.
i) 기동 중인 Pod에 Istio-Sidecar(istio-proxy) 임시로 즉시 레벨 적용하는 방법
- 재기동 시 default로 돌아간다.
$ kubectl exec -it -n <namespace> <pod-name> exec -- curl -X POST http://localhost:15000/logging?level=trace |
※ 실제 컨테이너 안에 들어가서 curl로 실행해도 된다.
$ curl -X POST localhost:15000/logging 까지만 명령하면 현재 로그레벨을 확인할 수 있으며, ?level=[loglevel]로 명령하면 로그레벨을 임시로 변경하게된다.
ii) Deployment의 annotation 설정에 로그레벨을 영구적용하는 방법
- Pod를 재기동할 때 반영되며 다시 기동되어도 로그 레벨이 적용된다.
| $ kubectl edit deploy <deployment-name> -n <namespace-name> spec: ...(중략)... template: metadata: annotations: ...(중략)... sidecar.istio.io/agentLogLevel: info/trace/debug ... |
※ sidecar.istio.io/agentLogLevel: trace 라인을 추가하여 재기동하면 반영된다.
- cli를 통해 istio-proxy의 로그를 확인한다.
$ kubectl logs -f ratings-v1-5967f59c58-7w7xd -c istio-proxy |
※ 다만, access log와 istio 로그가 같이 찍히기 때문에 보기가 어려울 수 있다.