HTTP 접근 로깅
HTTP 접근 로깅 (HTTP Access Logging)
Linkerd 프록시에서 프록시를 지나는 모든 HTTP 요청을 기록하는 접근 로그를 생성하도록 설정하는 방법을 알려드려요. config.linkerd.io/access-log 주석으로 활성화하고 apache 또는 json 형식 중 선택할 수 있습니다.
본문
Linkerd 프록시는 프록시를 지나는 모든 HTTP 요청을 기록하는 HTTP 접근 로그를 생성하도록 구성할 수 있습니다.
config.linkerd.io/access-log 주석은 프록시 HTTP 접근 로깅을 활성화하는 데 사용됩니다. 이 주석을 네임스페이스나 워크로드에 추가하면 프록시 인젝터가 프록시 컨테이너에 접근 로깅을 구성하는 환경 변수를 설정합니다.
HTTP 접근 로깅은 접근 로깅이 없는 프록시에 비해 성능 영향이 있으므로 기본적으로 비활성화되어 있습니다. 접근 로깅을 활성화하면 부하가 걸릴 때 tail latency와 CPU 소비가 증가할 수 있어요. 이 성능 비용의 심각도는 프록시되는 트래픽에 따라 달라질 수 있고, 일부 환경에서는 감수할 수 있을 정도일 수도 있습니다.
Note
프록시의 HTTP 접근 로그는 별도로 구성되는 프록시 디버그 로깅과는 다릅니다. 프록시의 디버그 로깅 구성에 대한 자세한 내용은 프록시 로그 레벨 수정 문서를 참고하세요.
접근 로그 형식
config.linkerd.io/access-log 주석의 값은 HTTP 접근 로그 항목의 형식을 결정하며, "apache" 또는 "json" 중 하나일 수 있습니다.
config.linkerd.io/access-log: "apache" 주석을 설정하면 프록시가 Apache Common Log Format으로 HTTP 접근 로그를 내보냅니다. 예를 들면:
`10.42.0.63:51160 traffic.booksapp.serviceaccount.identity.linkerd.cluster.local - [2022-08-23T20:28:20.071809491Z] "GET http://webapp:7000/ HTTP/2.0" 200
10.42.0.63:51160 traffic.booksapp.serviceaccount.identity.linkerd.cluster.local - [2022-08-23T20:28:20.187706137Z] "POST http://webapp:7000/authors HTTP/2.0" 303
10.42.0.63:51160 traffic.booksapp.serviceaccount.identity.linkerd.cluster.local - [2022-08-23T20:28:20.301798187Z] "GET http://webapp:7000/authors/104 HTTP/2.0" 200
10.42.0.63:51160 traffic.booksapp.serviceaccount.identity.linkerd.cluster.local - [2022-08-23T20:28:20.409177224Z] "POST http://webapp:7000/books HTTP/2.0" 303
10.42.0.1:43682 - - [2022-08-23T20:28:23.049685223Z] "GET /ping HTTP/1.1" 200
`
config.linkerd.io/access-log: json 주석을 설정하면 프록시가 JSON 형식으로 접근 로그를 내보냅니다. 예를 들면:
`{"client.addr":"10.42.0.70:32996","client.id":"traffic.booksapp.serviceaccount.identity.linkerd.cluster.local","host":"webapp:7000","method":"GET","processing_ns":"39826","request_bytes":"","response_bytes":"19627","status":200,"timestamp":"2022-08-23T20:33:42.321746212Z","total_ns":"14441135","trace_id":"","uri":"http://webapp:7000/","user_agent":"Go-http-client/1.1","version":"HTTP/2.0"}
{"client.addr":"10.42.0.70:32996","client.id":"traffic.booksapp.serviceaccount.identity.linkerd.cluster.local","host":"webapp:7000","method":"POST","processing_ns":"30036","request_bytes":"33","response_bytes":"0","status":303,"timestamp":"2022-08-23T20:33:42.436964052Z","total_ns":"14122403","trace_id":"","uri":"http://webapp:7000/authors","user_agent":"Go-http-client/1.1","version":"HTTP/2.0"}
{"client.addr":"10.42.0.70:32996","client.id":"traffic.booksapp.serviceaccount.identity.linkerd.cluster.local","host":"webapp:7000","method":"GET","processing_ns":"38664","request_bytes":"","response_bytes":"2350","status":200,"timestamp":"2022-08-23T20:33:42.551768300Z","total_ns":"6998222","trace_id":"","uri":"http://webapp:7000/authors/105","user_agent":"Go-http-client/1.1","version":"HTTP/2.0"}
{"client.addr":"10.42.0.70:32996","client.id":"traffic.booksapp.serviceaccount.identity.linkerd.cluster.local","host":"webapp:7000","method":"POST","processing_ns":"42492","request_bytes":"46","response_bytes":"0","status":303,"timestamp":"2022-08-23T20:33:42.659401621Z","total_ns":"9274163","trace_id":"","uri":"http://webapp:7000/books","user_agent":"Go-http-client/1.1","version":"HTTP/2.0"}
{"client.addr":"10.42.0.1:56300","client.id":"-","host":"10.42.0.69:7000","method":"GET","processing_ns":"35848","request_bytes":"","response_bytes":"4","status":200,"timestamp":"2022-08-23T20:33:49.254262428Z","total_ns":"1416066","trace_id":"","uri":"/ping","user_agent":"kube-probe/1.24","version":"HTTP/1.1"}
`
접근 로그 소비하기
HTTP 접근 로그는 프록시 컨테이너의 stderr 스트림에 기록되는 반면, 프록시의 표준 디버그 로깅은 프록시 컨테이너의 stdout 스트림에 기록됩니다. 현재 kubectl logs 명령은 컨테이너의 stdout과 stderr 스트림 둘 다 항상 출력합니다. 하지만 KEP 3289가 kubectl logs 명령에서 컨테이너의 stdout 또는 stderr를 분리하는 지원을 추가할 예정입니다.
더 알아보기 (Learn more)
- 프록시 로그 레벨 수정 (Modifying the proxy log level)
- KEP 3289