카프카 모니터링하기

카프카 운영하기

토픽 작업

kafka-topics.sh 사용

• 새 토픽생성: —topic, —repolication-factor(레플리카 수), —partitions (파티션 수)
• 토픽 목록 조회: —list
• 토픽 상세 내역 조회: —describe
  • —under-replicated-partitions: 1개 이상의 레플리카가 리더와 동기화되지 않고 있는 모든 파티션
  • —at-min-isr-partitions: 레플리카 수가 인 싱크 레플리카 수의 최소값과 같은 모든 파티션
  • —under-min-isr-partitions: ISR 수가 쓰기 작업에 성공하기 위한 최소 레플리카 수에 미달하는 모든 파티션 , 이 파티션들은 읽기 전용
• 파티션 추가하기: —alter —topic my-topic —partitions N
• 파티션 개수 줄이기: 줄이는건 불가능, 토픽 삭제하고 다시 만들거나 새로운 버전의 토픽 생성해서 거기다 쓰기 트래픽 몰아줌
• 토픽 삭제하기: 클러스터 브로커의 delete.topic.enable 옵션이 true 로 설정되어 있어야 함
  • 토픽 삭제는 비동기적인 작업
  • 컨트롤러가 브로커에 삭제 작업 통지 후 브로커는 관련 파일을 디스크에서 지우게 됨

컨슈머 그룹

kafka-consumer-groups.sh 사용

• 컨슈머 그룹 목록 상세조회: —describe, —group [consumer_group_name]
• 컨슈머 그룹 삭제: 모든 컨슈머가 내려간 상태여야 함, —delete
• 오프셋 관리
  • 오프셋 내보내기: —export —group [group_name] —topic [topic_na,e] —reset-offsets —to-current —dry-run > offsetcs.csv
  • 오프셋 가져오기: —reset-offsets —group [group_name] —from-file offsets.csv —execute

동적 설정 변경

kafka-config.sh 사용, 변경 위해서 변경 사항을 파일로 지정해 —add-config-file 인자 사용 가능

동적으로 변경이 가능한 설정의 범주(entity-type) 4가지: topic, broker, user, client

• 토픽 설정 기본값

재정의 가능한 토픽 설정값 목록 (—alter —entity-type topics —entity-name [topic_name] —add-config [topic-config]=[topic-config-value]

https://docs.confluent.io/platform/current/installation/configuration/topic-configs.html

• 클라이언트, 사용자 설정 기본값

consumer_bytes_rate, producer_bytes_rate (하나의 클라이언트 ID 가 하나의 브로커에서 읽거나 / 쓸 수 있는 메시지의 양), controller_mutation_rates (컨트롤러 변경률), request_percentage

• 브로커 설정 기본값 재정의

min.isync.replicas : 프로듀서 ack 설정값이 all 로 잡혀 있을 때 쓰기가 이루어져야 하는 레플리카 수 최소값

unclean.leader.election.enable: 데이터 유실이 발생하는 레플리카를 리더로 선출

max.connections 브로커에 연결할 수 있는 최대 연결 수

• 재정의된 설정 상세 조회

—describe —entity-type topics —entity-name [topic_name]

쓰기 작업과 읽기 작업

• 프로듀서: kafka-console-producer.sh 사용
  • 어떤 카프카 클러스터에 연결할지(—bootstrap-server), 클러스터 어느 토픽에 쓸 지(—topic) 인수 설정
  • 설정 옵션 사용하기: —producer-config {config_file} 또는 —producer-property key=value 사용
    • —batch-size: 하나의 배치로 전달되어야 할 메시지의 수
    • —timeout: 메시지 배치를 쓰기 전에 기다리는 최대 시간
    • —compression-codec: 압축 코덱
    • —sync: 동기적으로 메시지 씀
• 컨슈머: kafka-console-consumer.sh 사용
  • 어떤 카프카 클러스터에 연결할지(—bootstrap-server), 클러스터 어느 토픽에 읽을 지(—topic) , 토픽 이름과 매칭되는 정규식 (—whitelist)인수 설정
  • 설정 옵션 사용하기: —consumer.config 또는 —consumer-property key=value
    • —formatter: 메시지를 바이트에서 문자열로 변환하기 위해 사용되는 메시지 포매터
    • from-beggining: 가장 오래된 오프셋부터 메시지 읽어옴
  • 오프셋 토픽 읽어오기: 컨슈머 그룹별로 커밋된 오프셋 확인
    • __consumer_offsets 내부 토픽 읽음: —topic __consumer_offsets —from-beggining ..

파티션 관리

전체 카프카 클러스터에 대해 부하를 고르게 분산하기 위해서는 리더 레플리카를 전체 브로커에 걸쳐 균형있게 분산해야 함

자동 리더 밸런싱 기능이 꺼져 있을 경우 처음 리더 레플리카였던 브로커가 크래시 후 살아나면 다른 레플리카가 리더가 되게 되는데, 이 경우 균형이 잘 맞지 않을 수 있음

• 선호 레플리카 선출

선호 레플리카 선출을 실행시켜 부하를 고르게 분산함

kafka-leader-elections.sh 사용해서 선호 레플리카(토픽 처음 생성되었을 때 리더 레플리카였던 레플리카) 선출 실행

• 파티션 레플리카 변경: 파티션 레플리카 할당을 수동으로 변경해주고 싶을 때 : kafka-reassign.partitions.sh 사용
  • —topics-to-move-json-file [json-file-name] —broker-list [to-move-broker-list]
  • —reassignment-json-file [reassignment-json-file-name\
  클러스터 컨트롤러는 각 파티션의 레플리카 목록에 새로운 레플리카를 추가하여 재할당 작업을 실행하고 복제 작업 완료되면 복제 팩터를 원상 복구시켜 오래 된 레플리카를 레플리카에서 제거
• JSON 파일에 레플리카 목록에 브로커 ID 목록을 추가로 넣어주는 식으로 복제 팩터 변경 가능

로그 세그먼트 덤프 뜨기

파티션의 로그 세그먼트를 열어볼 때 사용 : kafka-dump-log.sh

인덱스 파일은 로그 세그먼트 안에 저장되어 있는 메시지 찾을 때 사용. 이 파일이 오염되지 않았는지 검증하는 옵션도 있음

• —print-data-log 옵션 추가하여 실제 탑재된 내용물 정보 출력 가능
• —index-sanity-check: 인덱스 파일이 사용 가능한 상태인지 체크
• —verify-index-only: 메시지 데이터와 일치하지 않는 인덱스 항목 검사

레플리카 검증

클러스터 전체에서 토픽 파티션의 레플리카들이 서로 동일한지 확인: kafka-replica-verification.sh 사용

모든 레플리카로부터 메시지 읽어온 후 주어진 파티션의 최대 랙 값을 출력

카프카 모니터링 하기

지표값들은 JMX 인터페이스를 통해 사용할 수 있다

카프카 브로커 지표

불완전 복제 파티션

kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

해당 브로커가 리더 레플리카를 잡고 있는 파티션 중 팔로워 레플리카가 따라오지 못하는 파티션의 수

단일 브로커 문제인지, 클러스터 전체 연관된 문제인지 파악할 것

kafka-topics.sh 툴 + —under-replicated 사용해서 공통으로 나타나는 브로커 찾아보기 ..

• 클러스터 수준 문제: 브로커로부터 파티션 수, 리더 파티션 수, 바이트 인입/유출, 메시지 인입 수 모니터링해보고 각 브로커 간 균형이 맞는지 체크 .. 균형이 맞지 않을 경우 선호 파티션 선출 실행하거나 부하 많은 브로커의 파티션을 적은 브로커로 재할당함.. 또는 브로컼에 들어오는 요청이 처리 가능한 용량을 넘어가는 경우 발생할 수 있음
• 호스트 수준 문제: 몇 개의 브로커에 국한된 문제일 경우, 디스크 장애와 같은 하드웨어 문제일 수 있고 네트워킹 문제일 수도 있음 ..

브로커 지표

• 활성 컨트롤러 수: 특정 브로커가 현재 클러스터 컨트롤러 역할 맡고 있는지 나타낸ㅁ
• 컨트롤러 큐 크기: 컨트롤러에서 브로커의 처리를 기다리고 있는 요청 수, 계속 증가하는 상태라면 뭔가 문제가 있는 것. 컨트롤러 역할 하는 브로커 끄고 컨트롤러를 다른 브로커로 옮겨야 함
• 요청 핸들러 유휴 비율: 카프카에는 네트워크 스레드 풀 / 요청 핸들러 스레드 풀을 사용, 이 요청 핸들러가 작동중이지 않은 시간 비율 나타냄. 이 값이 낮을 경우 부하가 많이 걸린 것. 요청 핸들러 스레드 수는 시스템 프로세서 수와 동일하게 설정하는 것이 좋음
• 토픽 바이트 인입: 브로커가 프로듀서 클라이언트로부터 얼마나 많은 메시지 트래픽을 받는지에 대한 측정값
• 전 토픽 바이트 유출: 컨슈머가 메시지를 읽는 속도, 레플리카에 발생하는 트래픽 역시 포함하기 때문에 컨슈머 클라이언트가 없더라도 유출 바이트가 있을 수 있음
• 전 토픽 메시지 인입: 초당 들어오는 메시지 수, 메시지 유출 수가 없는 이유는 컨슈머가 메시지를 읽을 때 브로커는 메시지 배치를 넘겨주기 때문, 이 배치에 몇 개의 메시지가 들어있는지는 브로커가 확인하지 않음
• 오프라인 파티션 수: 클러스터 컨트롤러 역할을 맡고 있는 브로커에게만 제공, 현재 리더가 없는 파티션의 갯수를 보여줌

토픽과 파티션별 지표

토픽별 지표도 브로커 지표와 매우 유사

초당 바이트 인입 및 유출, 초당 실패한 읽기 및 쓰기 요청 갯수, 초당 인입 메시지 수 등을 제공

파티션별 지표의 로그 세그먼트 수 지표는 디스크에 저장된 파티션의 로그 세그먼트 파일 수 보여줌,

파티션 크기 지표는 파티션에 대해 현재 저장된 데이터 양을 바이트 단위로 보여줌

JVM 지표

CollectionCount : GC 사이클 수

CollectionTime : GC 사이클에 소요된 시간을 밀리초 단윌

MaxFileDescriptorCount,: 최대 File Descriptor 수

OpenFileDescriptorCount : 현재 열려 있는 FD 수 (모든 로그 세그먼트와 네트워크 연결별로 FD가 열리게 됨)

저장 공간이 부족할 수 있으므로 디스크 공간과 inode 사용량 모니터링

클라이언트 모니터링

프로듀서 지표

• 프로듀서 종합 지표
  • record-error-rate : 이 값이 0보다 크다면 메시지 누수가 발생하고 있음, 경보값 설정할 것
  • request-latency-avg : 브로커가 쓰기 요청을 받을 때까지 걸린 평균 시간
  • outgoing-byte-rate : 전송되는 메시지의 절대 크기를 초당 바이트 형태로 나타냄
  • record-send-rate: 초당 전송되는 메시지 수의 크기
  • request-rate : 브로커로 전달되는 쓰기 요청의 수를 초 단위로 나타냄
  • request-size-avg : 브로커로 보내지는 쓰기 요청의 평균 크기를 바이트 단위로 나타냄
  • batch-size-avg : 메시지 배치의 평균 크기를 바이트 단위로 나타냄
  • record-size-avg: 레코드의 평균 크기를 바이트 단위로 나타냄
  • record-queue-time-avg : 메시지를 전송한 뒤 실제로 카프카에 쓰여지기 전까지 프로듀서에서 대기하는 평균 시간 (batch.size, linger.ms 를 튜닝할 때 도움됨)
• 브로커별, 토픽별 지표

브로커별 프로듀서에서 중요한 지표는 request-latency-avg , 이 지표는 특정 브로커 연결에 문제가 있음을 알 수 있음

토픽별 지표는 record-send-rate, record-error-rate 를 이용해서 어느 토픽에 메시지 누수가 발생하는지 알 수 있고 byte-rate 지표는 주어진 토픽에 대해 초당 몇 바이트의 메시지가 전송되었는지 보여줌

컨슈머 지표

• 읽기 매니저 지표
  • fetch-latency-avg : 브로커로 읽기 요청을 보내는데 걸리는 시간. 이 지표는 fetch.min.bytes 와 fetch.max.wait.ms 의 영향을 받기 때문에 값이 일정치 않을 수 있음
  • bytes-consumed-rate, records-consumed-rate : 클라이언트의 읽기 트래픽을 초당 바이트 수 혹은 초당 메시지 수 형태로 보여줌
  • fetch-late : 컨슈머가 보내는 초당 읽기 요청 수
  • fetch-size-avg : 읽기 요청의 평균 크기를 바이트 수로 나타냄
  • records-per-request-avg : 각 읽기 요청의 결과로 주어진 메시지 수의 평균값 보여줌
• 브로커 별, 토픽별 지표
  • 읽기 매니저에 의해 제공되는 bytes-consumed-rate, records-consumed-rate 를 브로커별로 세분화해서 incoming-byte-rate, request-rate 지표 제공
• 컨슈머 코디네이터 지표
  • sync-time-avg : 동기화 작업에 들어간 평균 시간을 밀리초 단위로 나타냄
  • sync-rate : 초당 그룹 동기화 수를 보여줌
• 코디네이터 관련 작업으로 인해 컨슈머 그룹 동기화 때문에 작업이 중단될 수 있음, 이 시간에 대한 메트릭 제공

쿼터

브로커가 클라이언트가 주어진 쿼터를 초과했다면 클라이언트로 갈 응답을 늦춤으로써 클라이언트 속도를 감소시킴

이 쓰로틀링 시간을 보여주는 지표를 모니터링

랙 모니터링

컨슈머 랙: 프로듀서가 특정 파티션에 마지막으로 쓴 메시지 ↔ 컨슈머가 마지막으로 읽고 처리한 메시지 간의 처리

컨슈머가 얼마나 뒤쳐져 있는지 나타냄

Burrow 를 사용하자 → 컨슈머 그룹의 랙 정보를 보여줌