백엔드 데이터 인프라 100편 — Kafka Monitoring (JMX 메트릭 30가지)

이 글은 백엔드 데이터 인프라 시리즈 130편 중 100편이에요. 99편 에서 운영 도구를 잡았다면, 이번 100편은 Kafka 운영의 절반 — Monitoring. JMX(Java 모니터링 표준 인터페이스) 메트릭 30가지 + Prometheus/Grafana 통합 + 알람 임계값을 정리합니다.

Kafka Monitoring이 어렵게 느껴지는 이유

Kafka 가 수백 가지 JMX 메트릭을 노출합니다. 어디서 시작해야 하고 어느 게 정말 중요한지가 흐려요.

첫째, 메트릭 이름이 복잡합니다. kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions 같은 JMX naming 그대로 노출되거든요.

둘째, broker / producer / consumer 메트릭이 분리되어 있어요. 각 영역마다 별도 메트릭을 봐야 합니다.

셋째, 알람 임계값 가이드가 부족합니다. 얼마면 위험인지 가 환경마다 달라요.

이 글에서 영역별 30가지 + 알람 임계값 + 통합 도구를 짚어볼게요.

모니터링 4단계

Kafka 프로세스 (JMX 노출)
  ↓
JMX Exporter (메트릭 수집)
  ↓
Prometheus (시계열 저장)
  ↓
Grafana (시각화·알람)

업계 표준 stack 입니다. 또는 Datadog·New Relic·CloudWatch 같은 SaaS(서비스형 소프트웨어) 도 같은 자리를 채워요.

1. Broker 메트릭 — 핵심 15가지

Replication 건강

UnderReplicatedPartitions

kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

ISR(In-Sync Replicas, 동기화된 복제본 집합) 가 replication factor 보다 적은 partition 수예요. 가장 중요한 메트릭입니다.

• 정상 = 0
• 지속적으로 > 0 = broker 문제 (네트워크·디스크·CPU)
• 알람 — 5분 이상 > 0

UnderMinIsrPartitionCount

kafka.cluster:type=Partition,name=UnderMinIsr,topic=...,partition=...

ISR 가 min.insync.replicas 보다 적은 partition 이에요. 쓰기 실패가 임박한 상태입니다.

• 알람 — > 0 발생 즉시

OfflinePartitionsCount

kafka.controller:type=KafkaController,name=OfflinePartitionsCount

Leader 가 없는 partition 수입니다. 심각한 장애 신호예요.

• 알람 — > 0 발생 즉시

ActiveControllerCount

kafka.controller:type=KafkaController,name=ActiveControllerCount

Active controller 수는 정확히 1 이어야 해요.

• 0 = controller 없음 (장애)
• > 1 = split-brain (매우 심각)

Throughput

MessagesInPerSec

kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec

초당 들어오는 메시지 수입니다 (broker 전체 또는 topic 별).

BytesInPerSec · BytesOutPerSec

kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec

초당 네트워크 트래픽이에요. capacity 계획·이상 감지 에 씁니다.

BytesRejectedPerSec

kafka.server:type=BrokerTopicMetrics,name=BytesRejectedPerSec

거부된 메시지 (크기 초과·인증 실패 등) 인데, 0 이 아니면 경고 로 봐야 해요.

FailedProduceRequestsPerSec · FailedFetchRequestsPerSec

kafka.server:type=BrokerTopicMetrics,name=FailedProduceRequestsPerSec
kafka.server:type=BrokerTopicMetrics,name=FailedFetchRequestsPerSec

실패 요청이에요. >1% 면 경고 구간으로 잡습니다.

Request Latency

RequestQueueTimeMs · LocalTimeMs · RemoteTimeMs · ResponseQueueTimeMs · ResponseSendTimeMs

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce
kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchConsumer
kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchFollower

요청별 latency breakdown 입니다. p99(99번째 백분위 응답 시간) 가 폭증 하면 디스크 또는 네트워크 부담 을 의심합니다.

Network·IO Threads

NetworkProcessorAvgIdlePercent

kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent

Network thread idle 비율이에요 (0~1).

• < 0.3 = 부하 큼, num.network.threads 늘림 검토

RequestHandlerAvgIdlePercent

kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent

IO thread idle 비율입니다.

• < 0.3 = num.io.threads 늘림

디스크

LogFlushRateAndTimeMs

kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs

Log flush 빈도와 시간이에요.

LogStartOffset · LogEndOffset

kafka.log:type=Log,name=LogStartOffset,topic=...,partition=...
kafka.log:type=Log,name=LogEndOffset,topic=...,partition=...

Topic 의 시작·끝 offset 입니다. Consumer lag 계산용 으로 써요.

JVM·OS

JVM(Java 가상 머신) JMX 표준은 이렇습니다:

• HeapMemoryUsage — JVM heap 사용
• GcCollectionCount · GcCollectionTime — GC(Garbage Collection, 메모리 회수) 빈도·시간
• OpenFileDescriptorCount — open file 수 (디스크 segment 영향)

GC 시간이 1초를 넘으면 심각 합니다 (consumer rebalance 위험).

2. Producer 메트릭 — 7가지

kafka.producer:type=producer-metrics,client-id=<id>

record-send-rate

초당 메시지 수예요.

record-error-rate · record-retry-rate

초당 에러와 재시도입니다. 지속적으로 > 0 면 broker 문제예요.

batch-size-avg

평균 batch 크기. 작으면 효율이 떨어집니다.

compression-rate-avg

압축 효율이에요 (원본/압축 비율).

request-latency-avg · request-latency-max

요청 latency. max 가 폭증 하면 broker·네트워크 문제로 봐야 해요.

buffer-available-bytes

Producer buffer 여유예요. 0 에 가까우면 send() 가 blocking 될 위험이 있습니다.

outgoing-byte-rate

초당 outgoing 바이트입니다.

3. Consumer 메트릭 — 8가지

kafka.consumer:type=consumer-metrics,client-id=<id>
kafka.consumer:type=consumer-fetch-manager-metrics,client-id=<id>
kafka.consumer:type=consumer-coordinator-metrics,client-id=<id>

Lag — 가장 중요

records-lag-max

kafka.consumer:type=consumer-fetch-manager-metrics,client-id=<id>,topic=<topic>,partition=<p>

해당 partition 의 lag 입니다. 가장 중요한 consumer 메트릭 이에요.

• 0~수백 = 정상
• 수천~수만 = 처리 느림
• 수십만 이상 = 심각, consumer 늘리기 + partition 늘리기

records-lag-avg

평균 lag 예요.

Fetch

fetch-rate · fetch-size-avg

Fetch 횟수와 평균 크기. batch 효율 을 봅니다.

bytes-consumed-rate · records-consumed-rate

초당 처리량이에요.

Coordinator

commit-rate · commit-latency-avg

Commit 빈도와 latency 입니다.

heartbeat-rate · heartbeat-response-time-max

Heartbeat 동작이에요.

assigned-partitions

이 consumer 가 받은 partition 수입니다.

Rebalance

rebalance-rate-per-hour · rebalance-latency-avg

Rebalance 빈도와 시간이에요.

• 시간당 > 1 = 너무 잦음 → session.timeout·heartbeat 조정 또는 Static Membership(consumer 식별 고정 기능)

4. JMX 활성화

환경변수

export JMX_PORT=9999
$ kafka-server-start.sh config/server.properties

기본은 port 9999, no auth 입니다 (운영 환경은 보안 추가).

운영 환경 — 보안

export KAFKA_OPTS="-Dcom.sun.management.jmxremote=true \
                    -Dcom.sun.management.jmxremote.port=9999 \
                    -Dcom.sun.management.jmxremote.authenticate=true \
                    -Dcom.sun.management.jmxremote.ssl=true \
                    -Dcom.sun.management.jmxremote.password.file=/etc/kafka/jmx.password"

5. Prometheus 통합

JMX Exporter

Java agent 로 JMX 를 Prometheus(시계열 메트릭 저장소) 형식으로 변환해줍니다.

$ wget jmx_prometheus_javaagent-0.20.0.jar
$ cp jmx_prometheus_javaagent-0.20.0.jar /opt/kafka/libs/

# server.properties 환경변수
export KAFKA_OPTS="-javaagent:/opt/kafka/libs/jmx_prometheus_javaagent-0.20.0.jar=7071:/etc/kafka/jmx-exporter.yml"

jmx-exporter.yml 설정

lowercaseOutputName: true
rules:
- pattern: kafka.server<type=ReplicaManager, name=UnderReplicatedPartitions><>Value
  name: kafka_server_replicamanager_underreplicatedpartitions
  type: GAUGE
- pattern: kafka.server<type=BrokerTopicMetrics, name=MessagesInPerSec, topic=(.+)><>OneMinuteRate
  name: kafka_server_brokertopicmetrics_messagesinpersec
  type: GAUGE
  labels:
    topic: "$1"
# ... 더 많은 rule

Confluent·Linkedin 의 준비된 yml 가 공개되어 있어요 (검색).

Prometheus scrape

# prometheus.yml
scrape_configs:
  - job_name: 'kafka'
    static_configs:
      - targets: ['broker-1:7071', 'broker-2:7071', 'broker-3:7071']

Grafana 대시보드

Grafana(시각화·대시보드 도구) 는 Kafka Cluster Overview 같은 공개 대시보드 를 임포트해서 시작하면 빨라요.

표시 메트릭:

• 클러스터 throughput
• Partition health (under-replicated·offline)
• Request latency (p50·p99)
• Network·IO thread idle
• JVM heap·GC

6. 알람 임계값 가이드

7. 자주 보는 운영 시나리오

시나리오 1: Consumer lag 폭증

확인:

1. consumer records-lag-max 어느 그룹·partition?
2. Broker BytesInPerSec (producer 증가?)
3. Broker RequestHandlerAvgIdlePercent (CPU 부족?)
4. Consumer records-consumed-rate (처리 속도?)

대응:

• Consumer 늘리기
• Partition 늘리기 (consumer 한계가 partition)
• Processing 최적화

시나리오 2: UnderReplicated 발생

확인:

1. 어느 broker 가 ISR 에서 빠짐?
2. 그 broker 의 RequestHandlerAvgIdlePercent · 디스크 I/O · 네트워크?
3. replica.lag.time.max.ms 임계 확인

대응:

• 느린 broker 디버깅 (디스크·네트워크·GC)
• 일시적이면 회복 대기
• 지속되면 reassign 검토

시나리오 3: 높은 GC pause

확인:

1. JVM heap 사용 (HeapMemoryUsage)
2. GC 빈도·시간
3. Topic 수·partition 수 (메모리 영향)

대응:

• Heap 크기 늘림 (단, OS pagecache 줄어듦 trade-off)
• G1GC tuning
• Broker 더 추가 (분산)

한계·실무 함정

1. JMX port 보안 누락

운영 환경에는 자격증명 + SSL 이 필수예요. 누락하면 외부에서 cluster 조작이 가능 해집니다.

2. JMX Exporter 메트릭 카디널리티 폭증

Topic·partition·client 별로 모든 메트릭을 노출 하면 Prometheus 에 부담이 가요. 필요한 것만 whitelist 로 잡아야 합니다.

3. 알람 too noisy

5분 평균 이나 지속 시간 조건 을 걸어서 false positive 를 줄입니다.

4. Consumer lag 의 정의

lag 은 LOG-END-OFFSET - CURRENT-OFFSET 이에요. 어느 시점 인지 명확히 잡고, throughput 메트릭과 함께 봐야 정확합니다.

5. 단일 broker 알람만

3 broker cluster 라면 모든 broker 메트릭을 종합 해서 봐야 해요. 한 broker 만 보면 전체 그림이 안 잡힙니다.

시험 직전 한 번 더 — Kafka Monitoring 함정 압축 노트

• JMX 메트릭 = Kafka 의 표준 노출 방식
• 표준 stack = JMX → JMX Exporter → Prometheus → Grafana
• Broker 핵심 15가지 영역
• Replication = UnderReplicatedPartitions (0이어야) · UnderMinIsrPartitionCount (즉시 알람) · OfflinePartitionsCount (즉시) · ActiveControllerCount (1이어야)
• Throughput = MessagesInPerSec·BytesInPerSec·BytesOutPerSec·BytesRejectedPerSec·FailedProduceRequestsPerSec
• Latency = RequestMetrics TotalTimeMs per request type (Produce·FetchConsumer·FetchFollower)
• Threads = NetworkProcessorAvgIdlePercent (>0.3)·RequestHandlerAvgIdlePercent (>0.3)
• Disk = LogFlushRateAndTimeMs·LogStartOffset·LogEndOffset
• JVM = HeapMemoryUsage·GcCollectionCount·GcCollectionTime·OpenFileDescriptorCount
• GC pause > 1초 = 심각
• Producer 7가지 = record-send-rate·record-error-rate·batch-size-avg·compression-rate-avg·request-latency-avg·buffer-available-bytes·outgoing-byte-rate
• Consumer 8가지 = records-lag-max (가장 중요)·records-lag-avg·fetch-rate·records-consumed-rate·commit-latency·heartbeat·assigned-partitions·rebalance-rate-per-hour
• records-lag-max = consumer 모니터링의 핵심
• Rebalance > 시간당 1 = 너무 잦음 → Static Membership
• JMX 활성화 = JMX_PORT=9999 환경변수
• 운영 환경 = JMX 보안 (인증·SSL) 필수
• JMX Exporter = Java agent, jmx-exporter.yml 로 변환 규칙
• 공개 대시보드 = Grafana 7589 등
• 알람 임계값 — UnderReplicated 5분·UnderMinIsr 즉시·OfflinePartitions 즉시·Lag 10000~100000
• 자주 시나리오 = Consumer lag 폭증·UnderReplicated·GC pause
• 함정 — JMX port 보안 누락
• 함정 — 메트릭 카디널리티 폭증 (whitelist)
• 함정 — 알람 too noisy (지속 시간 조건)
• 함정 — 단일 broker 만 모니터링 (cluster 종합)

공식 문서: Kafka Monitoring 에서 모든 메트릭의 자세한 사양을 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 95편 — Kafka Topic 설정 (Retention · Compression · Cleanup)
• 96편 — Kafka Producer 설정 20가지 (Batching · Retries · Idempotence)
• 97편 — Kafka Consumer 설정 25가지 (Group · Commit · Fetch)
• 98편 — Kafka Admin Client 설정 (간결 정리)
• 99편 — Kafka 운영 기본 (Topic·Partition·Reassign·Rolling Restart)

다음 글:

• 101편 — Kafka Multi-tenancy (Quota · Naming · ACL 분리)
• 102편 — Kafka 다중 데이터센터 (Stretched · Local + Mirror)
• 103편 — Kafka Geo-Replication (MirrorMaker 2)
• 104편 — Kafka Hardware · OS (CPU·메모리·디스크·튜닝)
• 105편 — Kafka KRaft (Zookeeper 의 후속 · Quorum 운영)