내장 명령어로 카프카 상태 모니터링 모범 사례

카프카 CLI 명령어를 사용하여 장애 발생 시 토픽 복제, 컨슈머 지연, 브로커 API 상태 및 기본 클러스터 상태를 확인합니다.

내장 명령어로 카프카 상태 모니터링 모범 사례

카프카의 내장 명령어는 기본적인 장애 질문에 가장 빠르게 답할 수 있는 방법입니다: 파티션에 리더가 있는지, 복제본이 동기화되었는지, 컨슈머가 뒤쳐지고 있는지 등. Prometheus, JMX 또는 관리형 모니터링 플랫폼을 대체하지는 않지만, 배스천 호스트나 관리 컨테이너에서 빠르게 확인하기에 탁월합니다.

아래 예제는 카프카 관리 명령어의 현재 클라이언트 경로인 --bootstrap-server를 사용합니다.

깔끔한 명령어 환경 설정

브로커 목록을 변수에 저장하여 모든 명령어를 반복 가능하게 만듭니다:

export KAFKA_HOME=/opt/kafka
export BOOTSTRAP_SERVER="kafka1:9092,kafka2:9092,kafka3:9092"
cd "$KAFKA_HOME/bin"

클러스터가 TLS 또는 SASL을 사용하는 경우, 클라이언트 설정을 속성 파일에 저장하고 --command-config로 전달합니다:

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --command-config /etc/kafka/admin-client.properties \
  --list

토픽 및 파티션 상태 확인

kafka-topics.sh --describe로 시작합니다. 정상적인 토픽은 각 파티션에 리더가 있어야 하고, 동기화된 복제본 목록이 예상 복제 팩터와 일치해야 합니다.

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --topic orders

다음 필드를 확인합니다:

  • Leader: none이 아니어야 합니다.
  • Replicas: 파티션에 할당된 브로커입니다.
  • Isr: 리더와 동기화된 복제본입니다.

Replicas에 세 개의 브로커가 있지만 Isr에 하나만 있다면, 토픽이 복제 부족 상태입니다. 이는 일반적으로 브로커 다운, 디스크 압박, 네트워크 문제 또는 따라잡지 못하는 복제본을 나타냅니다.

복제 부족 파티션 빠르게 찾기

클러스터 전체를 빠르게 확인해야 할 때 내장 필터를 사용합니다:

./kafka-topics.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --under-replicated-partitions

출력이 없으면 좋은 소식입니다. 출력이 있다면 조사가 필요하며, 특히 min.insync.replicas가 설정된 토픽의 경우 더욱 그렇습니다.

컨슈머 지연 모니터링

컨슈머 지연은 컨슈머 그룹이 생성된 레코드를 따라잡고 있는지 알려줍니다.

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --describe \
  --group payments-worker

중요한 열:

  • CURRENT-OFFSET: 그룹이 진행 상황을 커밋한 위치입니다.
  • LOG-END-OFFSET: 파티션의 최신 오프셋입니다.
  • LAG: 두 값의 차이입니다.
  • CONSUMER-ID, HOST, CLIENT-ID: 파티션을 소유한 컨슈머입니다.

짧은 스파이크는 배포나 트래픽 급증 시 정상일 수 있습니다. 지속적인 지연은 그룹이 주의를 필요로 함을 의미합니다: 느린 처리, 컨슈머 부족, 파티션 불균형, 다운스트림 종속성 지연 또는 브로커 측 페치 지연.

활성 컨슈머 그룹 목록

그룹 이름을 모를 경우 먼저 그룹을 나열합니다:

./kafka-consumer-groups.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER" \
  --list

그런 다음 영향을 받는 애플리케이션에 해당하는 그룹을 검사합니다.

브로커 API 연결 가능성 확인

kafka-broker-api-versions.sh는 클라이언트가 브로커에 도달하고 메타데이터/API 핸드셰이크를 완료할 수 있는지 확인하는 간단한 방법입니다.

./kafka-broker-api-versions.sh \
  --bootstrap-server "$BOOTSTRAP_SERVER"

이 명령어가 실패하면 DNS, 보안 그룹 또는 방화벽, TLS/SASL 설정, 그리고 명령어를 실행하는 위치에서 광고된 리스너 주소에 연결할 수 있는지 확인합니다.

장애 시 CLI 확인 사용

실용적인 트리지 흐름은 다음과 같습니다:

  1. kafka-broker-api-versions.sh를 실행하여 연결성을 확인합니다.
  2. kafka-topics.sh --describe --under-replicated-partitions를 실행하여 복제 상태를 확인합니다.
  3. 영향을 받는 토픽을 설명하고 리더와 ISR을 확인합니다.
  4. 영향을 받는 컨슈머 그룹을 설명하고 파티션별 지연을 확인합니다.
  5. 느린 파티션을 브로커, 디스크 및 애플리케이션 로그와 비교합니다.

결론

카프카의 내장 명령어는 클러스터 상태에 대한 신뢰할 수 있는 첫 번째 확인을 제공합니다. 관리 클라이언트 구성을 준비하고, --bootstrap-server를 사용하며, 리더, ISR, 복제 부족 파티션 및 컨슈머 지연에 집중하세요. CLI가 문제 위치를 보여주면, 더 깊은 브로커 메트릭과 로그를 해석하기가 훨씬 쉬워집니다.