Observability

이 도메인이 묻는 것

핵심 개념 요약 — 4대 지표부터

Kafka 브로커는 JMX로 메트릭을 노출합니다. 수백 개가 있지만 대시보드 최상단에는 네 개만 두면 됩니다. 나머지는 이 네 개가 움직인 뒤에 봅니다.

URP와 UnderMinIsr — 헷갈리면 조치가 반대로 갑니다

브로커 · 복제 메트릭

컨트롤러 · 메타데이터 메트릭

컨슈머 lag 측정 3방법

같은 lag을 세 경로로 볼 수 있고, 세 경로가 보는 것이 미묘하게 다릅니다. 이 차이가 시험 문항이 됩니다.

필수 CLI 명령어

# 파티션별 CURRENT-OFFSET / LOG-END-OFFSET / LAG
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group order-workers

# 활성 멤버와 각 멤버가 가진 파티션 수
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
    --describe --group order-workers --members

# 멤버별 실제 할당 파티션까지
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
    --describe --group order-workers --members --verbose

# 그룹 상태 요약: 코디네이터 / 할당 전략 / STATE / 멤버 수
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
    --describe --group order-workers --state

# 리더 · 에폭 · HighWatermark · MaxFollowerLag · voter/observer
bin/kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --status

# 노드별 LogEndOffset / Lag / LastFetchTimestamp / LastCaughtUpTimestamp / Status
bin/kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --replication

# Isr 가 Replicas 보다 짧은 파티션을 눈으로 찾습니다
bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe

# 그룹 종류를 통합 조회 (Consumer / Share / Streams)
bin/kafka-groups.sh --bootstrap-server localhost:9092 --list

# 특정 로거만 DEBUG 로 (조사 후 반드시 원복)
bin/kafka-configs.sh --bootstrap-server localhost:9092 --broker-logger 0 \
    --alter --add-config kafka.server.ReplicaManager=DEBUG

# 현재 로거 레벨 확인
bin/kafka-configs.sh --bootstrap-server localhost:9092 --broker-logger 0 --describe

반드시 외워야 할 값 — 임계값과 관련 설정

장애 시나리오와 대응

시나리오 1 — 컨슈머가 죽었는데 lag 알림이 오지 않았다

1. 알림이 records-lag-max(컨슈머 발행 메트릭) 하나에만 걸려 있는지 확인합니다.
2. 컨슈머가 죽으면 그 메트릭도 사라집니다. 값이 커지는 게 아니라 없어지는 것입니다.
3. 즉시 조치: kafka-consumer-groups.sh --describe --group으로 현재 lag을 확인합니다.
4. 구조 개선: 메트릭 부재 자체(no data)에 알림을 걸고, 동시에 브로커에서 커밋 오프셋 기준 lag을 주기적으로 수집합니다.
5. 그룹의 활성 멤버 수(--members)에도 알림을 걸면 "컨슈머가 사라진 것"을 직접 감지할 수 있습니다.

시나리오 2 — 모든 요청 지연이 동시에 나빠졌다

1. RequestHandlerAvgIdlePercent를 봅니다. 0.3 미만이면 처리 스레드가 포화입니다.
2. RequestQueueTimeMs가 커졌는지 확인합니다. 큐 대기가 지연의 대부분이면 스레드 부족이 확정입니다.
3. NetworkProcessorAvgIdlePercent도 함께 봅니다. 이쪽이 낮으면 네트워크 스레드가 원인입니다.
4. 원인 트래픽을 특정합니다 — 쿼터 메트릭으로 사용자·클라이언트별 사용량을 봅니다.
5. 단기 조치는 num.io.threads 상향(cluster-wide라 재시작 불필요), 중기 조치는 쿼터 부여입니다.

시나리오 3 — ActiveControllerCount 합계가 0이 되었다

1. 즉시 kafka-metadata-quorum.sh --bootstrap-controller ... describe --status를 실행합니다.
2. 리더가 없다면 쿼럼 과반이 살아 있는지 확인합니다. 과반을 잃으면 리더가 뽑히지 않습니다.
3. 기존 파티션의 읽기·쓰기는 한동안 계속되지만 메타데이터 변경은 전부 실패합니다. 이 점을 관계자에게 먼저 알립니다.
4. 컨트롤러 노드 간 네트워크를 확인합니다. controller.quorum.fetch.timeout.ms(기본 2000)를 넘기면 선거가 반복됩니다.
5. MetadataErrorCount가 올라 있으면 메타데이터 손상 가능성이 있으므로, 노드를 다시 포맷하기 전에 describe --replication으로 과반의 데이터 보유를 확인합니다.

시나리오 4 — URP가 0으로 돌아오지 않는다

1. 어느 브로커·파티션인지 kafka-topics.sh --describe로 좁힙니다.
2. ReplicaFetcherManager MaxLag가 커지는 추세인지 봅니다. 커지면 복제가 뒤처지는 중입니다.
3. 남아 있는 스로틀을 확인합니다. 재할당 후 --verify를 생략했다면 여기서 걸립니다.
4. IsrShrinksPerSec/IsrExpandsPerSec가 반복되면 특정 브로커의 디스크·네트워크를 봅니다.
5. num.replica.fetchers(기본 1)를 올려 팔로워 fetch 병렬성을 확보합니다.

자주 나오는 함정

관련 케이스 스터디

• 케이스 2 · 컨슈머가 무한 리밸런스 루프에 빠졌다 — 그룹 상태 판독
• 케이스 6 · RF=3인데 브로커 1대 죽자 유실됐다 — ISR 메트릭으로 사전 감지

메트릭 전체 목록은 JMX 메트릭 치트시트, 운영 배경은 11장 운영 기초, lag 모니터링 실습은 예제 10에 있습니다. 이 지표들을 실제 조치로 잇는 방법은 Troubleshooting에서 다룹니다.

미니 퀴즈

메트릭 이름과 정상값 매칭이 중심입니다.

공식 문서 출처

• Monitoring — 4대 지표와 정상값, ISR 메트릭 3종, UncleanLeaderElectionsPerSec, RequestHandlerAvgIdlePercent/NetworkProcessorAvgIdlePercent의 0.3 기준, records-lag-max가 컨슈머 발행임, 컨트롤러 메트릭, TotalTimeMs 분해
• Basic Kafka Operations — kafka-consumer-groups.sh --describe 출력, --members/--state, 새 컨슈머 프로토콜의 DESCRIBE 권한 요구
• KRaft — kafka-metadata-quorum.sh describe --status/--replication
• Broker Configs — num.io.threads, num.network.threads, num.replica.fetchers, queued.max.requests 기본값과 갱신 모드