[카프카인액션] 9장. 관리 : 도구와 로깅

9.1 관리 클라이언트

9.1.1 AdminClient를 사용한 코드 관리 

• 카프카 쉘 스크립트 통해 빠른 접근이나 일회성 작업이 좋지만, 자바 AdminClient 통해 자동화를 제공할 수 있다

 

9.1.2 kcat 

• 전체 Kafka 도구를 설치할 필요 없이 가볍게 사용 가능

 

9.1.3 컨플루언트 REST 프록시 API 

• 경우에 따라 선호도나 사용 편의성으로 인해 REST API 방식을 선호할 수 있다. 
• 또한 포트에 엄격한 방화벽 규칙 가진 회사의 경우 더 많은 포트를 열때 주의가 필요할 수 있다.
  • 이 때 한 가지 좋은 선택지는 REST 프록시 API를 사용하는 것이다.

 

9.2 카프카를 systemd 서비스로 실행하기 

• systemd는 시스템 전반에 걸쳐 구성 요소를 초기화하고 유지 관리하는 역할을 담당한다.
• 주키퍼와 카프카를 정의하는 일반적인 방법 중 하나가 systemd에서 사용하는 유닛 파일이다. 
• kafka를 systemd 서비스로 등록하면, 시스템 부팅 시 자동 실행되거나 systemctl 명령어로 쉽게 관리할 수 있다.

 

9.3 로깅 

 

9.3.1 카프카 애플리케이션 로그 

• 기본적으로 서버 로그는 새 로그가 생성될 때 디렉터리에 계속 추가되며, 로그는 제거되지 않는다. 
  
  • maxfilesize 는 새 로그 파일을 생성할 시기를 결정하기 위한 파일 크기 정의
  • maxbackupindex는 보관할 과거 파일 갯수를 설정하는 것 

log4j.appender.kafkaAppender.MaxFileSize=500KB
log4j.appender.kafkaAppender.MaxBackupIndex=10

 

• 로그 어펜더의 패턴
  • kafkaAppender - server.log
  • stateChangeAppender - state-change.log
  • requestAppender - kafa-request.log
  • cleanerAppender - log-cleaner.log
  • controllerAppender - controller.log
  • authorizerAppender - kafka-authorizer.log

 

 

9.3.2 주키퍼 로그 

• 로컬 주키퍼 노드 설정을 따랐다면 이 값은 config/zookeeper.properties 파일에서 설정할 수 있다. 
  • autopurge.purgeInerval : 제거 작업이 트리거되는 간격(시간), 클린업이 발생하려면 0보다 높게 설정해야 한다.
  • autopurge.snapRetainCount : 최근 스냅샷의 dataDir 및 dataLogDir 위치의 관련 트랜잭션 로그가 포함된다. 숫자를 초과하면 이전 로그 파일이 삭제된다. 필요에 따라 더 많거나 적게 유지하기를 원할 수 있다. 
  • snapCount : 주키퍼는 트랜잭션을 트랜잭션 로드에 기록한다. 이 값을 설정하면 하나의 파일에 기록되는 트랜잭션의 양이 결정된다. 총 파일 크기에 문제가 있는 경우 이 숫자를 기본값 보다 작게 설정해야 할 수 있다. 

 

 

요약

• 카프카와 함께 제공되는 셸 스크립트 외에도 토픽 생성과 같은 중요한 작업에 대한 API 접근을 제공하는 관리 클라이언트도 있다. 
• kcat이나 컨플루언트 REST 프록시 API와 같은 도구를 사용하면 개발자가 클러스터와 상호 작용할 수 있다. 
• 카프카는 핵심에서 클라이언트 데이터에 대한 로그를 사용하기도 하지만, 여전히 유지 관리해야 하는 브로커 작업과 관련된 다양한 로그가 있다. 필요한 경우 문제 해결을 위한 세부 정보를 제공하기 위해 이러한 로그 관리 문제를 해결해야 한다. 
• 애드버타이즈도 리스너를 이해하면 처음에는 클라이언트 연결에 대해 일관되지 않는 것처럼 보이는 동작을 설명하는데 도움이 될 수 있다. 
• 카프카는 메트릭에 JMX를 사용한다. 브로커뿐만 아니라 클라이언트 매트릭도 볼 수 있다.