Kafka Trouble-Shooting

⚪ CheckList

1. 어떤 일이 발생하였나
   • 정확하게 어떤 현상이 발생했는지 파악이 필요하다.
   • 예를 들자면 Broker가 다운 되었다, Replica가 Leader를 따라잡지 못한다.
   • 주요 확인 사항은 발생 시간, 발생 직전의 상황, 근본 원인이 있다
2. 원인 파악
   • 모니터링 실시(프로세스가 그대로 살아있다면 과부하 신호일 수 있음)
   • ssh 접속이 가능한가(클러스터의 노드에 문제가 생긴 것일 수 있음)
   • 로그 확인(log4j.properties 파일을 찾아 확인)

일반적인 시나리오

1. TLS 암호화: CPU 자원이 모자라서 암호화 속도가 느린경우가 있음(OS 수준의 문제)
2. NW : broken pipe가 Broker에 감지되면 네트워크에 문제가 있다는 것을 의미
3. Unable to resolve hostname : DNS에 문제가 있음을 의미
4. ZK 와 Broker 간의 Timeout : ZK 측에서 디스크 액세스 속도가 빠르지 않거나(fsync error) ZK Ensemble이 Kafka 외의 다른 서비스와 공유된다는 것을 의미할 수 있음
5. VM의 공유 리소스를 놓고 경쟁하기 때문에 전체 시스템이 일시 중지되어 실패하는 경우가 있음
   • 격리된 리소스를 VM에 고정
6. Docker의 경우 리소스 제한으로 OOM이 발생
7. Open File 제한 : Linux 커널 파라미터 조정으로 OS 수준에서 조절

주요 메트릭

• kafka-specific Metric
  • TotalTimeMs, BytesInPerSec, BytesOutPerSec, kafka.server.type=SessionExpireListener,name=ZookeeperExpiresPerSec
• Host Metrics
  • Page Cache Reads Ratio(, Disk Usage, CPU Usage, Network bytes Sent/Recieved

추가 설명

• Page Cache : Ram에서 저장하는 캐시 (kafka의 매시 처리 방식)
• Buffer Cache :

⚪ Monitoring

• 기본적으로 JMX Metric을 노출하지만 원격으로는 노출X
  • 하려면 관련 옵션을 사용하여 Broker 시작
  • 예로는 Grafana, Graphite, CloudWatch 등에서 그래프로 표시
  • GUI 툴로는 jconsole이 있을 수 있고 CLI로는 jmxterm을 사용할 수 있다.

Zoookeeper

• Four Letter Words라는 제한된 명령 세트에 응답
  • stat, srvr, cons 및 mntr이 많이 사용된다
• 하드웨어 고려사항
  • Zookeeper 쿼럼의 각 멤버를 위한 전용 서버(서로 다른 Rack에 구성 권장)
  • dataLogDir에 의해 지정된 트랜잭션 로그 디렌터리용 전용 디스크
    • 3개의 전용 드라이브(루트 파일 시스템, 스냅샷, 트랜잭션 로그)로 프로비저닝
    • 스냅샷 및 트랜잭션 로그를 SSD에 저장하는 것을 권장
  • swapiness를 최소화(스왑 메모리 활용 수준)
  • 물리 메모리(통산 8gb 이상)
• service-level 고려사항
  • 충분한 Heap Memory(GB 모니터링)
  • 쿼럼당 5개의 zookeeper 구성(공식에 따라 3노드는 단일 서버의 장애만 handle 가능)
  • 고정된 ip(변경되면 모든 클라이언트 재시작해야함)

Broker

• JMX Metric은 파라미터를 통해서 뽑아올 수 있음
  • 초당 Request 개수
  • 메시지가 얼마나 처리되는지 등의 메트릭을 뽑을 수 있음
• 주요 관찰 대상 : 보통 60%가 넘으면 alert를 주로 한다.
  • CPU
  • Memory
  • Disk Space
  • Disk IO
  • Network IO
  • Open File Handles
• Producer 관련 메트릭, consumer 관련 메트릭도 포함되어 있다.
  • 자세한 것은 실습으로 알아보자

Trouble Shooting

예시 시나리오

• TLS: 암호화를 하다보면 OS 수준의(CPU 부족 등)의 문제가 있을 확률이 크다.
• Network: borken pipe(네트워크 끊어짐) Broker 로그를 확인한다.
  • unable to resolve hostname: DNS 문제
• ZK와 Broker 간의 Timeout : ZK의 DISK 액세스 속도가 느리거나 ZK Ensemble이 다른 서비스와 공유되고 있을 때
  • fsync error took x amount time which is ...
• JVM OOM : JVM Heap Memory가 부족
• VM : 공유 리소스를 놓고 경쟁하다 전체 시스템이 다운 되는 현상도 발생 (Broker에 로그 없을 수도 있음)
  • 격리된 리소스를 VM에 고정
• open file 제한 : OS 혹은 서비스에서 한번에 열 수 있는 파일 디스크립터의 수의 제한으로 Broker, ZK, Kafka Connect에서 발생할 수 있음

주요 고려사항

• Kafka Metric : TotalTimeMs, BytesInPerSec, SessionExpireListener, ZookeeperExpiresPerSec
• Host Metric : Page Cache Rades Ratio, Disk Usage, CPU Usage, Network Bytes Sent / Received
• GC Metrics : GarbageCollector, G1 Young | Old,
• 주요 Broker File
  • recovery-point-offset-checkpoint: 디스크 플러시 Offset
  • cleaner-offset-checkpoint : Cleaner가 청소한 Compacted Topics의 Offset
  • repliaction-offset-checkpoint : 마지막 커밋 Offset
  • log-start-offset-checkpoint : 각 Topic Partition의 First Offset
  • leader-epoch-checkpoint : 각 partition들이 replication에 전파한 message에 대한 epoch값
• broker의 Liveness
  • 정기적 메타데이터 업데이트 수신을 위해 Active Session을 유지
  • Follower는 Leader를 복제해야 하며 복사 정도가 너무 뒤쳐져서는 안됨

추가 설명

Active Session이란 클러스터 구성에 따라

1. Kraft : 주기적 하트비트 컨트롤러에 전송하여 Active Session 유지
2. Zookeeper : ZK 세션 초기화 시 Broker가 생성하는 임시 노드의 존재를 통해 간접적으로 결정
   • 설정된 시간 안에 ZK에 하트비트를 보내지 못하면 노드 삭제

Follower가 너무 뒤쳐지면 이 Follower을 ISR에서 제거할 수 있음

Controller : 클러스터의 두뇌역할을 하는 클러스터 중 하나의 Broker