Application Observability

이 도메인이 묻는 것

출제 형태는 대체로 "이 증상일 때 무엇을 먼저 보는가"입니다. 메트릭 이름을 정확히 아는지 묻는 matching 문항도 흔합니다. 브로커 쪽 메트릭도 일부 나오지만, 개발자가 자기 애플리케이션을 진단하기 위해 보는 범위에 한정됩니다. 참고 챕터는 11장 운영 기초의 모니터링 절과 5장 Consumer 심화입니다.

핵심 개념 (1) 클라이언트 메트릭

Kafka 클라이언트는 JMX로 메트릭을 노출합니다. MBean 이름은 kafka.producer:type=producer-metrics,client-id={id} 형태이고, 같은 값을 KafkaProducer.metrics() / KafkaConsumer.metrics()로 코드에서도 읽을 수 있습니다. client.id를 지정하지 않으면 자동 생성된 이름이 붙어 대시보드에서 구분이 안 됩니다. 서비스명 기반으로 반드시 지정하세요.

핵심 개념 (2) consumer lag 측정 3가지 방법

lag = high watermark − committed offset입니다. LEO에서 빼는 것이 아닙니다(LEO와 high watermark 사이는 아직 복제가 끝나지 않아 컨슈머가 읽을 수 없는 구간입니다). 재는 방법이 세 가지이고, 각각 다른 것을 보여 줍니다.

$ bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
    --describe --group billing-worker

TOPIC      PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG      CONSUMER-ID       HOST         CLIENT-ID
payments   0          854144          855809          1665     consumer1-3fc8…   /10.0.1.21   consumer1
payments   1          460537          803290          342753   consumer1-3fc8…   /10.0.1.21   consumer1
payments   2          243655          398812          155157   -                 -            -

핵심 개념 (3) 개발자가 알아야 할 브로커 메트릭

브로커 운영은 CCAAK 범위이지만, "내 애플리케이션이 느린 게 아니라 클러스터가 아픈 것"을 구분하려면 아래 정도는 알아야 합니다.

핵심 개념 (4) Connect 관측 — 로그를 어디서 찾는가

이 절이 이 도메인에서 가장 자주 틀리는 지점입니다. Connect 워커는 각 노드의 로컬 파일에 로그를 남깁니다. REST API는 클러스터 전체를 보여 주지만, 로그는 그렇지 않습니다.

1. GET /connectors/{name}/status로 실패한 태스크와 trace를 확인합니다. 응답의 각 태스크에는 worker_id(호스트:포트)가 들어 있습니다.
2. 그 worker_id가 가리키는 노드의 로그를 봅니다. 다른 워커의 로그에는 그 태스크의 스택트레이스가 없습니다. 워커가 완전히 죽었다면 죽은 노드의 파일을 직접 열어야 합니다.
3. 필요하면 런타임에 로그 레벨을 올립니다. 재시작 없이 PUT /admin/loggers/{logger}로 변경할 수 있습니다.
4. 중앙 집계를 미리 준비합니다. 워커 로그를 중앙 로그 시스템으로 보내는 log appender를 추가하고, 커넥터별로 로그를 분리해 두면 사후 조사가 가능해집니다.

# 1) 어느 태스크가 어느 워커에서 죽었는지
curl -s http://connect-1:8083/connectors/orders-sink/status

# 2) 런타임 로그 레벨 상향 (재시작 불필요)
curl -s -X PUT -H "Content-Type: application/json" \
  --data '{"level":"DEBUG"}' \
  http://connect-2:8083/admin/loggers/org.apache.kafka.connect.runtime.WorkerSinkTask

# 3) 현재 설정된 로거 확인
curl -s http://connect-2:8083/admin/loggers

# 4) 조사 후 원래 레벨로 되돌린다
curl -s -X PUT -H "Content-Type: application/json" \
  --data '{"level":"INFO"}' \
  http://connect-2:8083/admin/loggers/org.apache.kafka.connect.runtime.WorkerSinkTask

핵심 개념 (5) Streams 애플리케이션 관측

Streams는 내부적으로 컨슈머·프로듀서를 쓰므로 위의 클라이언트 메트릭도 함께 노출됩니다. Streams의 lag은 결국 내부 컨슈머의 records-lag-max이며, kafka-consumer-groups --group {application.id}로도 볼 수 있습니다.

핵심 개념 (6) 수집 파이프라인과 알림 임계값

JMX는 로컬 프로세스의 메트릭을 노출하는 인터페이스일 뿐입니다. 대시보드를 만들려면 세 단계가 필요합니다.

1. 노출 — JVM에 JMX_PORT(또는 JMX Exporter 에이전트)를 붙여 메트릭을 꺼낼 수 있게 합니다.
2. 수집 — 익스포터가 JMX를 주기적으로 읽어 시계열 형식으로 변환하고, 수집기가 스크레이프합니다.
3. 시각화·알림 — 대시보드에 올리고 규칙으로 알림을 만듭니다.

Kafka 자체에는 metric.reporters 설정이 있어 커스텀 리포터를 붙일 수도 있습니다. 중요한 것은 클라이언트 메트릭은 클라이언트 프로세스에서 꺼내야 한다는 점입니다 — 브로커를 감시해도 컨슈머의 poll 간격은 볼 수 없습니다.

반드시 외워야 할 설정값

자주 나오는 함정

함정 1 — 클라이언트 JMX lag vs 커밋 기반 lag

함정 2 — 하트비트 지표 vs poll 지표

함정 3 — UnderReplicatedPartitions vs UnderMinIsrPartitionCount

함정 4 — Connect 로그 위치 vs 상태 API

함정 5 — 태스크가 살아 있는 것 vs 데이터가 온전한 것

함정 6 — 메트릭의 소속을 바꿔 놓은 선택지

진단 읽기 문제 대비

스니펫 1 — 이 지표 조합의 진단

assigned-partitions            = 4
records-lag-max                = 1_240_000
poll-idle-ratio-avg            = 0.02
time-between-poll-max          = 268_000   (ms)
rebalance-rate-per-hour        = 0
commit-rate                    = 0.19      (/s)

스니펫 2 — 왜 알림이 울리지 않았는가

14:02  컨슈머 파드 3개 중 3개가 OOMKilled
14:03  대시보드의 records-lag-max 패널이 "No data"
14:03  lag 알림 규칙: records-lag-max > 100000 → 발동 안 함
15:40  하위 DB에 데이터가 없다는 제보로 인지

스니펫 3 — 이 status 응답에서 다음 행동

{
  "name": "orders-sink",
  "connector": { "state": "RUNNING", "worker_id": "connect-1:8083" },
  "tasks": [
    { "id": 0, "state": "RUNNING", "worker_id": "connect-1:8083" },
    { "id": 1, "state": "FAILED",  "worker_id": "connect-3:8083",
      "trace": "org.apache.kafka.connect.errors.DataException: Failed to deserialize..." },
    { "id": 2, "state": "RUNNING", "worker_id": "connect-2:8083" }
  ]
}

이어서 볼 곳

• 11장 · 운영 기초 메트릭 파이프라인, 알림 임계값, 성능 튜닝의 전체 설명. 기본개념
• 예제 10 · 컨슈머 Lag 모니터링 동작하는 lag 수집·대시보드 구성. 실무 예제
• 메트릭 치트시트 MBean 이름 · 정상 범위 · 조치 전체 표. 빠른참조
• 트러블슈팅 치트시트 증상 → 확인 명령 → 원인 후보 결정 트리. 빠른참조
• 케이스 2 · 무한 리밸런스 루프 메트릭으로 미리 잡을 수 있었던 장애. 실수 케이스
• 케이스 5 · 파티션 1000개가 더 느림 파티션 증설이 지표에 어떻게 나타나는가. 실수 케이스

도메인 미니 퀴즈

공식 문서 출처

• Monitoring — 브로커·컨트롤러 MBean 이름과 정상 값, 클라이언트 메트릭 목록
• Consumer Monitoring — records-lag-max, time-between-poll-avg, poll-idle-ratio-avg, assigned-partitions, 리밸런스 메트릭
• Producer Monitoring — record-error-rate, record-retry-rate, record-queue-time-avg
• Connect Monitoring — 워커·태스크·에러 메트릭
• Kafka Streams Monitoring — thread/task/processor-node/state MBean
• Connect Administration — 상태 API, PUT /admin/loggers/{name} 런타임 로그 레벨 변경
• Managing Consumer Groups — kafka-consumer-groups --describe 출력 형식