[Kafka 운영] Request log 살펴보기

들어가며

 

중앙에 위치하는 카프카 브로커 (출처 : https://engineering.linkedin.com/blog/2016/04/kafka-ecosystem-at-linkedin)

 

 카프카는 아키텍처 중앙에 위치하여 다양한 클라이언트들의 요청을 받습니다. 그렇기 때문에 간혹 클라이언트에서 잘못된 요청을 보내는 경우가 발생할 수 있습니다. 예를 들면, 스키마가 정의되지 않은 토픽에 대해 프로듀서가 기존과 다른 임의의 메시지 포맷으로 보내게 된다면 컨슈머는 이 메시지를 처리하지 못하게 됩니다. 이와 같이 잘못된 요청이 발생하게 되면 어떤 클라이언트에서 보낸 요청인지 확인할 필요가 있습니다. 그리고 다행히도 카프카는 브로커가 받는 요청에 대해 별도의 로그 파일로 저장할 수 있습니다. 

 이번 글은 카프카 브로커가 받은 요청에 대해 저장하는 로그인 request log에 대해 살펴봅니다. 이 글 내용은 카프카 한국 사용자 모임에서 진행한 제4회 버츄얼 밋업 내용에서 영감을 받아 작성했습니다. 

Request log 설정하기

 request log는 기본적으로 INFO 레벨에 대한 로그를 저장하고 있으며, 기본적으로 ${kafka.logs.dir}/kafka-request.log 파일에 저장됩니다. 하지만 INFO 레벨에선 자세한 내용을 알 수 없으므로 관련 로거인 kafka.request.logger의 로깅 레벨을 DEBUG로 내릴 필요가 있습니다. 브로커의 로깅 레벨 변경은 런타임 중에도 가능하며, 아래와 같이 요청하면 됩니다. 

• 카프카와 함께 제공되는 kafka-configs.sh 스크립트 명령어를 사용합니다.
• entity-name 은 로깅 레벨을 변경할 브로커 id입니다. 

 위 명령어를 입력하면 kafka-request.log 파일이 생성되고, 방금 전에 설정 변경을 요청했던 것에 대한 로그가 저장된 것을 확인할 수 있습니다.

tail 명령어로 로그 파일 확인

 

Request log 내용 살펴보기

 위 스크린샷을 보면 상당히 많은 내용이 로그로 남는 것을 알 수 있는데, 한번 나눠서 살펴보겠습니다.

 위에서 보는 것과 같이 로그 내용은 크게 세 부분으로 나눠 볼 수 있습니다.

• API 요청 정보
• 브로커 응답 정보
• 클라이언트 연결 및 처리 정보

 이 중 특히 눈에 띄는 부분은 클라이언트의 연결 및 처리 정보를 통해 어떤 클라이언트에서 어떤 요청이 전달되었는지 확인할 수 있다는 것입니다. 그럼 설정 변경 외의 다른 요청에 대한 로그도 간단히 살펴보겠습니다.

요청 별 로그

 요청에 따라 저장되는 로그를 간단하게 살펴봅니다. 참고로 아래 내용 중 대문자 알파벳은 로그의 apiKey에 대응하는 것입니다.

토픽 생성

• 최종적으로 CREATE_TOPICS 요청을 통해 토픽이 생성되는 것을 알 수 있다.

메시지 프로듀싱

• 프로듀서가 연결되면서 METADATA 요청으로 카프카 클러스터에 대한 메타데이터를 가져가는 것을 알 수 있다.
• PRODCUE 요청으로 프로듀서가 메시지를 발행하는 것을 알 수 있다.

메시지 컨슈밍

• 컨슈머가 연결되면서 JOIN_GROUP 과 SYNC_GROUP을 통해 컨슈머 그룹을 구성하는 것을 알 수 있다.
• 컨슈머가 연결되면 오프셋 정보를 가져오고(OFFST_FETCH, LIST_OFFSETS), 지속적인 메시지 FETCH 요청과 헬스 체크를 위해 HEARTBEAT 요청을 하는 것을 알 수 있다.
• 컨슈머가 종료되면 LEAVE_GROUP 요청을 통해 컨슈머 그룹을 이탈하고 FETCxH 요청으로 종료 되는 것을 알 수 있다.

마무리

 위에서 살펴본 것처럼 간단한 로깅 레벨 변경으로 현재 브로커에 들어오고 있는 요청에 대해 더욱 자세히 알 수 있었습니다. 이는 가시성이 좋지 않은 카프카 운영 환경을 보완하기에 매우 좋은 요소입니다. 참고로 아직 저도 실제 운영 환경에 적용해보지는 못했지만 테스트해보며 고려하고 있습니다. 테스트 과정에서의 내용은 별도의 포스팅을 정리하도록 하겠습니다. 0