본 문서는 Kafka Connect 클러스터를 운영할 때 보아야 할 메트릭·도구·표준 스택을 정리한다. sink 종류와 무관하게 통용되는 부분만 다루며, 외부 시스템(DB, ES 등) 내부 모니터링은 그 시스템 측 가이드 로 미룬다. 출처: Confluent — Kafka Connect Monitoring (JMX)

관련 문서:

• 개념·아키텍처·HA·자원: 1. Connect 개념
• DB sink 시나리오의 모니터링 보완(예: DB connection pool): 3. DB Sink 시나리오 Q&A

1. 모니터링이 답해야 할 질문#

Connect 운영자가 매일 답하고 싶은 것은 결국 다음 4 가지다:

각 질문 → 어떤 메트릭으로 답하는지를 §2 ~ §4 에서 풀어 둔다.

2. JMX 메트릭#

Connect Worker 는 JVM 이며 JMX 로 메트릭을 노출. 표준 운영 패턴은 JMX Exporter → Prometheus → Grafana.

2.1. Sink Connector 핵심 메트릭#

2.2. Source Connector 추가 메트릭 (참고)#

• source-record-poll-rate, source-record-write-rate
• poll-batch-avg-time-ms

→ 본 조직이 처음 도입할 때는 보통 Sink 가 우선. Source 는 CDC 등 도입 시 필요.

2.3. 임계값 기준점 (개인 정리)#

정확한 수치는 워크로드 의존. 첫 운영 시작 시 의심해 볼 만한 기준값.

3. Consumer Lag — 별도, 매우 중요#

Sink Worker 는 본질적으로 Kafka 컨슈머. 따라서 컨슈머 그룹 lag 으로 “외부 시스템 적재가 produce 속도를 못 따라가고 있나?” 를 본다.

JMX 의 sink-record-active-count 도 비슷한 신호를 주지만, Lag 은 broker 측에서 본 진실치 라서 별도 도구로도 함께 본다.

도구 (택 1):

→ 도구 선택은 환경 결정 후 — (미정)

4. 외부 시스템 측 모니터링은 별도#

Connect 의 JMX 만으로는 외부 시스템 내부 상태(connection 수·풀, 락 경합, 디스크 사용률, queue depth 등)를 볼 수 없다.

Connect 가 보여주는 것은 “외부 시스템에 batch 한 번 쓰는 데 N 초 걸렸다” 까지. 그 N 초의 내부 분해 는 외부 시스템 측 도구로 봐야 한다.

→ 외부 시스템 자체 exporter 와 함께 운영. sink 별 구체 가이드는 해당 시스템 docs 참조:

• DB sink 의 connection 풀 모니터링: 3. DB Sink 시나리오 Q&A §5
• Elasticsearch sink: cluster stats / hot threads — (미정, 도입 시 정리)
• S3 sink: S3 access log / multipart upload 실패율 — (미정)

5. 표준 모니터링 스택 (제안)#

Connect Worker (JMX)
    └→ Prometheus JMX Exporter (sidecar 또는 javaagent)
        └→ Prometheus
            └→ Grafana 대시보드
                └→ Alertmanager
                   ├ DLQ 발행 증가 알림
                   ├ consumer lag 임계 초과 알림
                   ├ put-batch-time-ms 임계 초과 알림
                   └ task FAILED 알림 (connector-status)

별도 트랙:
컨슈머 그룹 (broker)
    └→ Burrow / kafka-lag-exporter
        └→ Prometheus / Grafana

별도 트랙:
외부 시스템 자체 exporter
    └→ Prometheus
        └→ Grafana

→ Connect / Lag / 외부 시스템 — 세 트랙을 함께 봐야 장애 원인을 분리할 수 있음.

• 적재가 느림 + Connect put-batch-time 정상 + DB CPU 100% → DB 측 원인
• 적재가 느림 + Connect put-batch-time 정상 + DB 정상 → Worker 자원 부족
• 적재가 느림 + Connect put-batch-time 급증 + DB CPU 정상 → DB connection 경합·락 의심

6. JMX Exporter 운영 메모 (개인 정리)#

(개인 정리) — 운영 시 자주 꼬이는 부분.

• Javaagent vs sidecar: K8s 환경에서는 javaagent (Worker JVM 자체에 붙임) 가 단순. sidecar 는 별도 포트 expose 필요
• 메트릭 화이트리스트: JMX 가 노출하는 메트릭이 매우 많음 → 필요한 것만 lowercaseOutputName + 패턴 매치로 추리는 게 Prometheus storage 절약
• 태스크 단위 라벨: connector, task 라벨이 살아 있어야 어떤 connector 가 느린지 분리 가능. exporter rule 설계 시 신경

7. 알람 설계 원칙 (개인 정리)#

8. 참고 (출처)#

1차 출처#

• Confluent — Kafka Connect Monitoring (JMX)
• Apache Kafka 공식 — Connect Monitoring

도구#

• linkedin/Burrow
• seglo/kafka-lag-exporter
• prometheus/jmx_exporter