Chapter 13. 카프카 모니터링하기

Chapter 13 카프카 모니터링하기

13.1 지표 기초

13.1.1 지표는 어디에 있는가?

카프카의 모든 지표값은 자바 관리 확장(JMX) 인터페이스를 통해 사용할 수 있다. 외부 모니터링 입장에서 이를 사용하는 가장 쉬운 방법은 해당 모니터링 시스템에서 제공하는 메트릭 수집 에이전트를 가져다 카프카 프로세스에 붙이는 것.

비 애플리케이션 지표
- 모든 지표의 출처가 카프카인 것은 x
- 카프카 브로커 모니터링 지표는 아래 5가지가 있다.
- 애플리케이션 지표
- 로그
- 인프라스트럭처 지표
- 특수 클라이언트 지표
- 일반 클라이언트 지표

13.1.2 어떤 지표가 필요한가?

어느 지표가 중요하느냐의 문제? 케이스 바이 케이스다.

브로커 내부를 개발하는 사람이 필요로 하는 지표는 카프카를 설치하고 운영하는 사이트 신뢰성 엔지니어가 필요로 하는 지표와는 크게 다를 것.

경보냐 디버깅이냐?
- 문제 발생시 경보를 보낼 것이냐, 문제를 디버깅할 것이냐에 답변은 둘 중 어느쪽에 속하는지를 알아둬야 수집 후 서로 다르게 처리 가능하다.
- 경보를 보내기 위한 지표는 짧은 시간 간격, 즉 문제에 대응하는 데 걸리는 시간보다 그리 길지 않은 경우에서 유용
- 사용자에게 영향을 미치지 않는 문제인지 아닌지 명확한 목표를 설정해야한다.
- 디버깅이 주 목적인 데이터는 일정 시간 동안 존재하는 문제의 원인을 자주 진단해야 안다든가, 뭔가 복잡한 문제여서 깊이 봐야 한다든가 하는 이유 때문에 굳이 모니터링 시스템에 들이부을 필요는 없다.
자동화가 목적인지, 사람이 볼 것인지?
- 지표는 누가 사용할 것인지가 중요하다.
- 자동화가 목적인면 어차피 컴퓨터가 처리할 것이기 때문에 대량의 메트릭을 사용해서 아주 세세한 부분까지 대량의 데이터를 수집해도 상관없다.
- 사람이 봐야할 지표를 대상으로 수집하면 오히려 지표에 압사당할 수 있다.
  - 측정된 지표값에 따라 경보를 설정할 때 매우 중요하다.(경보 피로감에 빠질 수 있다.)

13.1.3 애플리케이션 상태 검사

카프카로부터 어떠한 지표를 수집하던 간에 상태 검사를 통해 애플리케이션 프로세스가 살아있는지의 여부를 모니터링 할 수 있어야 한다.

방법
- 브로커가 살아있는지의 여부를 알려 주는 외부 프로세스를 사용 (상태 검사)
- (만료된 지표) 카프카 브로커에서 들어와야 하는 지표가 들어오지 않을 때 경보를 보낸다.
방법중 마지막에 있는 방법이 잘 작동하더라도 브로커 장애인지 모니터링 시스템 그 자체에 장애인지 구분하기 어렵다.

13.2 서비스 수준 목표

모니터링에서 다뤄야할 중요한 부분 중 하나는 서비스 수준 목표(SLO)이다.

클라이언트와 제공되어야 할 인프라스트럭처 서비스의 수준에 대해 이야기하는 수단

13.2.1 서비스 수준 정의

카프카에 있어서의 SLO를 논하기 전 사용되는 용어를 먼저 짚고 가자.

서비스 수준 지표(Service-Level Indicator)
- 서비스 신뢰성의 여러 측면 중 하나를 가리키는 지표
- 전체 이벤트에 대한 성공적인 이벤트의 비율로 측정되는 것이 최선
- 웹 서버 예시 2xx, 3xx or 4xx 응답을 받은 요청의 비율
서비스 수준 목표 or 서비스 수준 한계 (Service-Level Threshold)
- SLI에 목표값을 결합한 것
- 보통 99.9%와 같이 비율로 표현하는 경우가 많은데 꼭 그럴 필요는 없다.
- SLO는 측정되는 시간 간격 역시 포함해야 한다.
- 예를 들어서 7일간 웹 서버에 대한 요청 중 99%가 2xx, 3xx or 4xx 응답을 받아야 한다
서비스 수준 협약 (Service-Level agreement)
- 서비스 제공자와 클라이언트 사이의 계약으로, 측정 방식, 보고 방식, 자원을 받을 수 있는 방법
- SLA를 준수하지 못했을 때 서비스 제공자가 져야 하는 책임이 명시된 여러 개의 SLO를 포함
- 만약 서비스 제공자가 SLO 수준의 작동을 제공하지 못할 경우 해당 기간에 대한 모든 비용을 환불
SLO를 SLA라 부르는 것은 매우 흔한 일
SLO를 정해 놓으면 클라이언트 입장에서는 카프카가 어떻게 작동할 것인지에 대해 덜 가정할 수 있어 SLO가 항상 안 정해지는 것은 아님.

13.2.2 좋은 서비스 수준 지표를 위해서는 어떠한 지푯값을 써야 하는가?

일반적으로 SLI에 연관된 지표는 카프카 브로커 외부에 있는 어디간에서 수집되어야 한다.

SLO는 사용자의 만족 여부를 가리켜야 하고, 주관적인 것인 만큼 측정할 수 없기 때문이다. 따라서 SLI를 기준으로 볼 때 인프라스트럭처 지표는 사용해도 괜찮고, 특수 클라이언트 지표는 좋은 수준이며, 일반 클라이언트 지표는 아마도 가장 좋은 지표일 것이다.

요청 / 응답 혹은 데이터 저장 시스템에 흔히 쓰이곤 하는 SLI 종류
- 지연(latency) : 응답이 얼마나 빨리 리턴되는가?
- 질 (quality) : 응답의 내용이 적절한가?
- 보안 (security) : 요청과 응답이 적절히 보호되는가? 권한이나 암호화 측면에서도?
- 처리량 (throughput) : 클라이언트가 충분한 속도로 데이터를 발을 수 있는가?
중요 : SLI가 SLO의 문턱값 아래 실제 측정값을 근거로 정하는 게 좋다는 점을 명심
중요 : 각 이벤트는 SLO 문턱값 아래에 있는지 개별적으로 확인할 수 있어야 함
위 중요를 기준으로 변위치(quantile) 지푯값은 좋은 SLI가 못 된다.
- 변위치 지푯값은 전체 이벤트의 90%가 주어진 값 아래에 있다 와 같은 것을 알려 줄 뿐 그 값을 제어 할 수 있게 해주는 건 아니기 때문이다.
- 하지만 수집된 값을 구간별로 분류하는 것 (10ms 이하, 10~15ms, 50~100ms, 등등)은 SLO를 정할 때 요긴하게 사용

13.2.3 경보에 SLO를 사용하기

SLO는 주된 경보로 설정되어 있어야 한다.

SLO는 사용자의 관점에서 문제를 기술하는 것이고, 운영하는 사람 입장에서는 가장 먼저 고려해야 하기 때문에 그렇다.

SLO는 장기간 (1주일이라던가)을 기준으로 할 때 가장 좋음
- 경영진이나 고객 측에 적당한 형식으로 보고해야 하기 때문이고, SLO 경보가 울릴 때쯤이면 이미 늦는다.
- 조기에 경고가 가도록 뭔가 파생된 값을 사용하는 경우도 있지만, SLO를 경보에 사용하는 가장 좋은 방법은 소진율을 보는것이다.
- 소진율을 활용하는 방법에 대해서는 Betsy Beyer 등이 쓴 <사이트 신뢰성 엔지니어링>과 <사이트 신뢰성 워크북>을 참고.

13.3 카프카 브로커 지표

대부분 카프카의 개발자들이 특정한 이슈, 나중에 디버깅에 사용할 목적으로 만든 저수준 지표.

브로커의 거의 모든 작동에 관한 정보를 제공하는 지표도 있지만, 가장 일반적으로 사용되는 것들은 평소 카프카를 싱핼하는데 필요한 정보를 제공.

13.3.1 클러스터 문제 진단하기

카프카 클러스터에 문제가 있을 경우, 크게 3가지 종류가 있다.

단일 브로커에서 발생하는 문제

과적재된 클러스터에서 발생하는 문제

컨트롤러 문제

하드웨어나 운영체제 수준에서 발생하는 문제를 제외한다면, 대부분의 문제는 카프카 클러스터 안에서 요청이 몰려서 발생
카프카는 언제나 클러스터 안의 데이터를 브로커 사이에 최대한 고르게 분포시키려고 하지만, 그 데이터에 접근하는 클라이언트가 고르게 분포되지는 않는다. 또한 요청이 몰리는 파티션과 같은 이슈를 찾아 주는 것도 아니다.
따라서 외부 툴을 사용해서 클러스터의 균형을 항상 유지하는 것을 강력히 권장
- 크루즈 컨트롤 (https://github.com/linkedin/cruise-control)이 있는데 이 애플리케이션은 클러스터를 계속 모니터링하고 있다가 그 안의 파티션을 리밸런싱해준다.
클러스터 과적재 역시 쉽게 알아볼 수 있는 문제
- 클러스터 균형이 잡혀 있는데 다수의 브로커가 요청에 대해 높은 지연을 가지거나 요청 핸들러 풀의 유휴 비율이 높다면, 브로커가 처리할 수 있는 트래픽의 한계에 다다른 것이다.
- 클라이언트가 요청 패턴을 바꿔서 문제가 발생했는지 찾아볼 수 있겠지만, 설령 그렇다 해도 클라이언트 쪽을 바꾸는 것이 거의 불가능할 때도 있다.
- 해당 문제의 해법은 클러스터에 걸리는 부하를 줄이든, 브로커 수를 늘리든지 둥 중 하나다.
카프카 클러스터의 컨트롤러에 발생한 문제는 훨씬 더 진단하기 어렵고, 심지어 카프카 그 자체의 버그인 경우도 많다.
- 해당 이슈들은 브로커 메타데이터 동기화가 끊어진다든가, 브로커는 멀쩡해 보이는데 거기 있는 레플리카는 오프라인 상태라던가, 토픽 생성과 같은 기능이 제대로 작동하지 않는 다든가 하는 식으로 나타난다.
- 만약 문제 원인을 열심히 찾다가 이상하면 컨트롤러가 무너가 오작동해서 그랬을 가능성이 높다.

13.3.2 불완전 복제 파티션 다루기

카프카 모니터링에 있어서 가장 자주 쓰이는 지표 중 하나는 불완전 복제 파티션이다.

해당 측정값은 클러스터에 속한 브로커 단위로 집계, 해당 브로커가 리더 레플리카를 잡고 있는 파티션 중 팔로워 레플리카가 따라오지 못하고 있는 파티션의 수를 나타낸다.

이 지표는 브로커 정지에서부터 자원 고갈에 이르기까지, 카프카 클러스터에서 발생하는 많은 문제에 대한 통찰력을 준다.

지표와 관련된 불완전 복제 파티션
- JMX MBean : kafka.server:type=ReplicaManager, name=UnderReplicatedPartitions
- 값의 범위 : 0 이상 Integer
다수의 브로커가 일정한 수의 불완전 복제 파티션을 가지고 있다는 것은 보통 클러스터의 브로커 중 하나가 내려가 있다는 것을 의미
- 해당 브로커에서 무슨 일이 있었는지 살펴본 뒤 문제를 해결해야 하는데 하드웨어 장애인 경우가 많지만, 운영체제 혹은 자바 이슈 때문일 수도 있다.
불완전 복제 파티션의 수가 오르락 내리락 하거나, 수는 일정한데 내려간 브로커가 없다면 클러스터의 서능 문제가 원인이다.
- 불완전 복제 파티션들이 한 브로커에 몰려 있다면 해당 브로커 문제일 가능성이 높다
- 불완전 복제 파티션이 여러 브로커에 걸쳐 나타난다면 클러스터 문제일 수도 있지만, 여전히 특정 브로커 문제일 가능성도 있다.
- Kafka-topics.sh 툴을 샤용해서 확인

클러스터 수준 문제

부하 불균형 : 가장 찾기 쉽지만 해결하는 것은 상당히 복잡하다.
- 문제 진단을 하기 위해서는 클러스터의 브로커들로부터 다음과 같은 메트릭을 확인해봐야 한다.
- 파티션의 개수
- 리더 파티션 수
- 전 토픽에 있어서의 초당 들어오는 메시지
- 전 토픽에 있어서의 초당 들어오는 바이트
- 전 토픽에 있어서의 초당 나가는 바이트
- 해당 문제에 대해서 카프카 브로커를 재할당 해야한다면 kafka-reassign-partitions.sh 툴을 사용해서 할 수 있다.
자원 고갈
클러스터에서 흔히 볼 수 있는 또 다른 문제
- CPU 사용률
- 인바운드 네트워크 속도
- 아웃바운드 네트워크 속도
- 평균 디스크 대기 시간
- 디스크 평균 활용률
많은 경우 위 자원 중 어느 하나라도 고갈되면 불완전 복제 파티션이 발생

카프카 브로커 지표에 신경 쓰는 한, 전 토픽 바이트 인입률은 클러스터 사용량을 보여주는 좋은 가이드라인이다.

호스트 수준 문제

만약 카프카의 성능 문제가 클러스터 전체가 아닌 한두 개의 브로커에 국한되어 있다면, 해당 서버가 나머지 서버와 무엇이 다른지 봐야한다.
- 하드웨어 장애
- 네트워킹
- 다른 프로세스와의 충돌
- 로컬 구성의 차이
카프카에 성능 저하를 초래하는 더 흔한 유형의 하드웨어 장애는 디스크 장애
- 메시지를 저장하기 위한 용도로 디스크를 사용하기 때문에, 프로듀서 서능은 디스크에 쓴 애용을 커밋하는 속도에 직결
- 여기에 편차가 생기면 프로듀서와 레플리카에 성능 문제가 발생
- 브로커 혹은 시스템의 설정 변경이 문제가 될 수도 있으니 참고

13.3.3 브로커 지표

활성 컨트롤러 수
- 해당 지표는 특정 브로커가 현재 클러스터의 컨트롤러 역할을 맡고 있는지를 나타냄
- 0 또는 1일 될 수 있는데, 1이면 현재 브로커가 컨트롤러인 것
- 만약 클러스터 안에 컨트롤러 브로커가 없을 겨웅 클러스터는 토픽이나 파티션 생성 혹은 브로커 장애 발생과 같이 상태 변경이 생길 때 제대로 대응 할 수 없을 것.
- 클러스터 안의 모든 브로커를 재시작해주는 것도 방법이다.
컨트롤러 큐 크기
- 현재 컨트롤러에서 브로커의 처리를 기다리고 있는 요청의 수를 가르킨다.
- 브로커의 요청이 들어오고 관리 작업이 수행됨에 따라 오르락내리락 할 수 있고 순간적으로 뛸 수도 있지만, 계속해서 증가하거나 높아진 상태로 유지된다면 문제가 발생한 것이다.
- 문제 해결 방법 : 현재 컨트롤러 역할을 하고있는 브로커를 끔으로써 컨트롤러를 다른 브로커로 옮겨야 한다.
요청 핸들러 유휴 비율
- 네트워크 스레드 풀과 요청 핸들러 스레드 풀, 두 개의 스레드 풀을 사용한다.
- 네트워크 스레드가 당장 고갈되더라도 우려할 만한 것은 못된다, 다만 요청 핸들러 스레드는 메시지를 디스크에 쓰거나 읽어 오는 것을 포함한 클라이언트 요청 그 자체의 처리를 담당한다.
- 브로커에 더 많은 부하가 걸릴수록 이 스레드 풀에는 막대한 영향이 미친다.
요청 핸들러 유휴 비율 지표는 요청 핸들러가 작동 중이지 않은 시간 비율을 가린킨다.

이 값이 낮을수록 브로커에 부하가 많이 걸려 있다는 의미.
- 요청 핸드럴 스레드의 수는 시스템의 프로세서 수와 같게 설정해야 한다.
- 카프카 0.10 이전까지 요청 핸들러는 모든 입력 메시지 배치를 재압축하는 일까지 전부 다 수행했는데 버전 0.10부터 메시지 배체이 상대적인 오프셋을 할당할 수 있도록 하는 새로운 메시지 형식이 도입, 이에 따라 새로운 프로듀서가 메시지 배치를 전송하기 전 상대적인 오프셋을 할당하게 됨으로써 브로커는 메시지 배치를 재압축 단계를 생략 가능하다.
전 토픽 바이트 인입

초당 바이트로 나타내어지는 전 토픽 바이트 인입 속도는 브로커가 프로듀서 클라이언트로부터 얼마나 많은 메시지 트래픽을 받는지에 대한 측정값으로 유용

언제 확장해야 하는지, 트래픽이 어떻게 증가함에 따라 필요한 다른 작업을 언제 해야하는지를 결정할때 유용, 클러스터의 어느 브로커가 다른 브로커보다 더 많은 트래픽을 받고 있는지 측정할 때도 유용

7개의 지표 속석 중 첫 두개는 측정값은 아니다.
- EventType : 모든 지표의 단위, Byte
- RateUnit : 속도 지표의 시간적 기준, second
- OneMinuteRate : 지난 1분간의 평균
- FiveMinuteRate : 지난 5분간의 평균
- FifteenMnuteRate : 지난 15분간의 평균
- MeanRate : 브로커가 시작된 이후의 평균
전 토픽 바이트 유출

전 토픽 바이트 유출 속도는 트래픽의 전체적인 성장세를 보여주는 또 다른 지표.
- 컨슈머가 메세지를 읽는 속도를 보여준다.
전 토픽 메시지 인입

메시지 인입 속도는 메시지 크기와 무관하게 초당 들어오는 메시지 수를 보여준다.
- 프로듀서 트래픽 만큼이나 트래픽의 성장을 보여주는 지표로서 유용
- 브로커 간의 불균형도 볼 수 있기 때문에 유지 작업이 필요할 경우 알려 줄 수도 있다.
파티션 수

브로커에 할당된 파티션의 전체 개수, 브로커에 저장된 모든 레플리카를 포함한다.
- 자동 토픽 생성 기능이 켜져 있는 클러스터라면 이 값을 모니터링 하는 것이 중요해진다.
리더 수

리더 수 지표는 브로커가 현재 리더를 맡고 있는 파티션의 개수를 보여준다.
- 클러스터 안의 모든 브로커에 결쳐 균등해야 하니 참고.
- 정기적으로 확인하고 가능하면 경보도 걸어 놓은 것이 좋다.
오프라인 파티션

불완전 복제 파티션 수와 마찬가지로 오프라인 파티션 수는 모니터링에 있어서 매우 중요한 지표.

이 측정 값은 클러스터 컨트롤러 역할을 맡고 있는 브로커에서만 제공되는데, 현재 리더가 없는 파티션의 개수를 보여준다.
- 리더가 없는 파티션은 크게 두가지 이유로 나뉜다.
  - 레플리카를 보유하고 있는 모든 브로커가 다운
  - 저장된 메시지 개수가 모자란 탓에 리더 역할을 맡을 수 있는 인-싱크 레플리카가 없을 때
- 오프라인 파티션은 프로듀서 클라이언트에 메시지 유실이나 애플리케이션에서의 백프레셔와 같은 문제를 야기 함으로 즉시 해결해야 한다.
요청 지표

카프카 프로토콜에는 많은 요청이 있는데 각 요청이 어떻게 수행되고 있는지에 대한 지표 역시 제공된다. 책 : 401페이지 확인
- 요청 지표는 속도 지표이고, 주어진 시간 단위에 걸쳐 수신되어 처리된 해당 타입 요청의 전체 개수를 가린킨다.
- 그렇다면 모니터링 할때는?
  - 시간 지표의 경우 경고 문턱값 설정이 어려울 수 있는데 백분의 측정값에 대한 문턱값을 나름대로 정해서 경고를 걸어서 사용하라고 한다...

13.3.4 토픽과 파티션별 지표

토픽별 지표

모든 토픽별 지표의 측정값은 앞에서 설명한 브로커 지표와 매우 비슷

유일한 차이점은 토픽 이름을 지정해야 한다는 점..
- 토픽 수가 많아도 경보 설정을 해야한다.
  - 카프카 사용량을 확인하고, 디버깅 할 수 있게 해 준다는 점에서 유용하기 때문.
파티션별 지표
지속적 사용 기준으로 보면 파티션별 지표는 토픽별 지표에 비해 덜 유용하다.

몇몇 제한된 상황에서는 유용하다.
- 해당 파티션에 대해 현재 디스크에 저장된 데이터의 양을 바이트 단위로 보여주는데 이를 합산하면 하나의 토픽에 저장된 데이터의 양을 알 수 있다.

13.3.5 JVM 모니터링

JVM을 포함한 모든 서버의 표준적인 측정값도 모니터링 해야한다.

브로커의 성능을 발목잡을 수 있는 가비지 수집 증가와 같은 상황에 대해 경고해 줄 수 있다는 점에서 유용할 것

가비지 수집
- GC의 맥락에서 Old, Full은 같은 의미이다.
- 두 메트릭 각각에 대해 눈여겨봐야 할 속성은
  - CollectionCount, CollectionTime 이다.
- GC 사이클의 횟수와 단위 시간당 GC에 소요된 시간을 보여 줄 때 사용
자바 운영체제 모니터링
JVM은 java.lang:type=OperationgSystem 빈을 통해서 운영체제에 대한 일부 정보를 제공할 수 있다.

이 정보는 제한적이기 때문에 브로커를 돌리고 있는 시스템에 대해 알아야 하는 모든 정보를 제공해주지는 않는다.

여기서 수집되는 속성 중 운영체제에서는 수집하기 어련운 두개가 있는데
- MaxFileDescriptorCount, OpenFileDescriptorCount 이다.
모든 로그 세그먼트와 네트워크 연결별로 FD가 열리기 때문에 OpenFileDescriptorCount 값을 빠르게 늘어 날 수 있다.

13.3.6 운영체제 모니터링

운영체제 정보중 CPU 사용, 메모리 사용, 디스크 사용, 디스크 I/O, 네트워크 사용을 눈여겨 봐야한다.

CPU 사용에 대해서는 시스템 부하 평균 정도는 살펴봐야 한다.
카프카 브로커는 요청을 처리하기 위해 CPU자원을 많이 사용한다.
- 카프카를 모니터링할때 CPU 활용율을 추적 관리하는 것은 중요하다.
브로커에 네트워크 사용량 역시 모니터링 하길 추천.
- 단순히 초장 비트 단위로 나타내어지는 인입, 유출 네트워크 트래픽 양을 보면 된다.

13.3.7 로깅

kafka.controller : 컨트롤러에 대한 메세지를 제공하기 위해 사용 : Level = INFO
kafka.server.ClientQuotaManager : 프로듀서 혹은 컨슈머 쿼터 작업에 관련된 메세지를 보여주기 위해 사용, 주 브로커 로그 파일에는 포함되지 않도록 하는 것이 좋음 : Level = INFO
kafka.log.LogCleaner, kafka.log.Cleaner, kafka.log.CleanerManager : 스레드에 대한 상태 정보가 찍히게 할 수 있음, 압착되는 각 파티션 크기나 메시지 수 등에 대한 정보를 포함 : Level = DEBUG
kafka.request.logger : 브로커로 들어오는 모든 요청에 대한 정보를 기록, 디버깅 할 때 가장 유용 : Level = DEBUG, TRACE

13.4 클라이언트 모니터링

13.4.1 프로듀서 지표

모든 프로듀서 지표는 빈 이름에 프로듀서 클라이언트의 클라이언트 ID를 갖는다.

이름 : JMX MBean

프로듀선 전반 : kafka.producer:type=producer-metrics, client-id=CLIENTID

브로커별 : kafka.producer:type=producer-node-metrics, client-id=CLIENTID, nodeid=node-BROKERID

토픽별 : kafka.producer:type=producer-topic-metrics, client-id=CLIENTID, topic=TOPICNAME

프로듀서 종합 지표

메시지 배치 크기에서부터 메모리 버퍼 활용에 이르기까지 모든 것들을 나타내는 속성을 제공
- record-error-rate 속성은 반드시 경보 설정을 해 놓아야 한다.
  - 언제나 0이어야 하며, 만약 그보다 크다면 프로듀서가 브로커로 메시지를 보내는 와중에 누수가 발생하고 있음을 의미한다.
- request-latency-avg 속성은 반드시 경보 설정을 해 놓아야 한다.
  - 브로커가 쓰기 요청을 받을 때까지 걸린 평균 시간이다.
  - 정상 작동 상태에서 이 지표의 기준값을 찾고 기준값 보다 높은 값을 문턱값으로 설정한다.
- 애플리케이션 대시보드에 표시해 놓으면 좋은 지표
  - Record-send-rate : 트래픽을 초당 전송되는 메시지 수의 크기로 제공
  - Outgoing-byte-rate : 전송되는 메시지의 절대 크기를 초당 바이트 형태로 제공
  - request-rate : 브로커고 전달되는 쓰기 요청의 수를 초 단위로 제공
- 메시지, 요청, 배치의 크기를 나타내는 지표
  - Request-size-avg metric : 브로커로 보내지는 쓰기 요청의 평균 크기를 바이트 단위로 제공
  - batch-size-avg : 메시지 배치의 평균 크기를 바이트 단위로 제공
  - record-size-avg : 레코드의 평균 크기를 바이트 단위로 제공, 하나의 토픽에서만 쓰는 프로듀서의 경우 유용한 지표이다.
  - Records-per-request-avg : 쓰기 요청에 포함된 메시지의 평균 개수를 제공
- 권장하는 프로듀서 종합 지표 속성
  - record-queue-time-avg : 애플리케이션이 메시지를 전송한 뒤 실제로 카프카에 쓰여지기 전까지 프로듀서에서 대기하는 평균시간.
  - batch.size 설정에 지정된 크기를 갖는 배치가 메시지로 채워질 때
  - 마지막 배치가 전송된 이래 linger.ms 설정에 지정된 시간이 경과될 떄
  - 애플리케이션의 지연 요구 조건을 만족시키도록 튜닝할 때 도움.
브로커별, 토픽별 지표

지속적으로 살펴볼 만한 것은 아니다..
- 그나마? 가장 중요한 지표
  - Request-latency-avg : 거의 변화가 없지만 특정 브로커로의 연결에 문제가 있을 경우 알 수 있다.

13.4.2 컨슈머 지표

단순히 메시지를 브로커로 쏘아 보내는 것보다 좀 더 복잡한 만큼 다뤄야 할 지표도 조금 더 많다.

읽기 매니저 지표
- 읽기 매니저 빈은 바이트, 요청, 레코드에 대한 지표를 갖는다.
- 유용하지만 경보를 설정하기엔 그리 유용하지 않다.
- 경보 설정에 모두 사용할 수 있는 속성
  - Fetch-latency-avg : 브로커로 읽기 요청을 보내는 데 걸리는 시간을 제공
  - 정기적으로 많은 메시지가 들어 있는 토픽을 읽을 경우 이 지표는 살펴볼 만한 가치가 있다.
브로커별 토픽별 지표
- 메시지 읽기 과정에서 발생하는 문제점을 디버깅하는 데 유용하나 매일 살펴볼 필요는 없다.
  - Request-latency-avg : 읽고 있는 토픽의 메시지 트래픽에 따라 제한적으로 유용
  - Incoming-byte-rate, request-rate : 읽기 매니저에 의해 제공되는 bytes-consumed-rate, records-consumed-rate 지표를 각각 브로커별 초당 바이트와 브로커별 초당 요청 수로 세분화한 것
  - 컨슈머가 특정 브로커에 연결할 때 발생하는 문제를 식별할 때 사용하면 도움이 된다.
컨슈머 코디네이터 지표

그룹 멤버 합류, 그룹 멤버십을 유지하기 위해 브로커로 하트비트 메시지를 보내는 것이 여기로 들어간다.

몇개의 지표만 장기적으로 보면된다.
- Sync-time-avg : 동기화 작업에 들어간 평균 시간을 밀리초 단위로 보여준다.
- sync-rate : 초당 그룹 동기화 수를 보여준다.
- Commit-latency-avg : 오프셋 커밋에 걸린 평균 시간을 보여준다.
  - 프로듀서에서 요청 지연을 모니터링하는 것과 마찬가지로 이 값을 모니터링해야 한다.
- assigned-partitions : 특정 컨슈머 클라이언트에게 할당된 파티션의 개수
  - 같은 그룹의 다른 컨슈머 클라이언트와 비교했을 때 컨슈머 그룹 전체에서 부하가 고르게 분배되었는지를 확인할 수 있어 유용하다.
  - 메트릭을 수집하면 유용

13.4.3 쿼터

하나의 클라이언트가 전체 클러스터를 독차지하는 것을 방지하기 위해 클라이언트 요청을 스로틀링 하는 기능을 가지고 있다.

이는 프로듀셔, 컨슈머 양쪽 다 설정 가능한데, 각 클라이언트 ID에서부터 각 브로커까지 허용된 트래픽 형태로 표시된다.

기본적으로 활성화 되어있지 않다.
하지만 아래에 지표들을 모니터링하는 것이 안전하다.
- 컨슈머 : bean kafka.consumer:type=consumer-fetch-manager-metrics, client-id=CLINETID, attribute fetch-throttle-time-avg
- 프로듀서 : bean kafka.producer:type=producer-metrics,client-id=CLIENTID, attribute produce throttle-time-avg

13.5 랙 모니터링

컨슈머에 있어서 가장 중요하게 모니터링 되어야 하는 것은 컨슈머 랙이다.

컨슈머 랙은 메시지의 수로 측정되는데, 정확한 정의는 프로듀서가 특정 파티션에 마지막으로 쓴 메시지와 컨슈머가 마지막으로 읽고 처리한 메시지 사이의 차이다.

컨슈머 랙 지표는 외부 모니터링을 사용하는 것이 클라이너트 자체적으로 제공하는 것보다 훨씬 나은 경우 중 하나이다.
가장 지연이 심한 하나의 파티션만 나타내기 때문에 컨슈머가 얼마만큼 뒤처져 있는지 정확하게 보여주지 않는다.
읽기 요청이 나갈 때마다 지푯값이 계산되기 때문에 컨슈머가 정상 작동하고 있어야 한다는 전제도 필요하다.
컨슈머에 문제가 생기거나 오프라인 상태가 되면 이 지표는 부정확하거나, 아예 사용 불능이 될 수도 있다.

랙 모니터링 선호 방법

브로커의 파티션 상태와 컨슈머 상태를 둘 다 지켜봄으로써 마지막으로 쓰여진 메시지 오프셋과 컨슈머 그룹이 파티션에 대해 마지막으로 커밋한 오프셋을 추적하는 외부 프로세스를 두는 것.
- 컨슈머 자체의 상태와는 상관없이 갱신될 수 있는 객관적인 관점을 제공
12장에서 컨슈머 그룹 정보, 커밋된 오프셋, 랙을 볼 수 있는 명령줄 유틸리티에 대해 소개했지만 이런 식으로 랙을 모니터링하는 것은 그 자체로 문제가 있다.
컨슈머 그룹을 모니터링할때 발생하는 복잡성을 줄이는 방법 중 하나는 버로우를 사용하는 것.
- 버로우 : 링크드인에서 개발된 컨슈머 상태 모니터링용 오픈소스 애플리케이션으로, 클러스터 내 모든 컨슈머 그룹의 랙 정보를 가져온 뒤 각 그룹이 제대로 작동하고 있는지, 뒤쳐지고 있는지, 일시 중지되거나 완전히 중지되었는지를 계산해서 보여준다.
- 컨슈머 그룹이 메시지를 처리하는 동안 진척 상황을 모니터링함으로써 문턱값 없이도 작동한다.
- 자세한 정보 : https://engineering.linkedin.com/apache-kafka/burrow-kafka-consumer-monitoring-reinvented
- 버로우를 사용하는 것은 단일, 다중 클러스터 환경에서도 모든 컨슈머를 모니터링하기 쉬운 방법이 될 수 있고, 이미 사용중인 모니터링 및 경보 시스템과 연동하기도 쉽다.
만약 마땅한 다른 대안이 없다면, 컨슈며 클라이언트의 records-lag-max 지표가 컨슈머 상태에 대해 부분적인 관점이라도 제공
하지만 burrow와 같은 모니터링 시스템을 사용하는 것을 강력하게 권장!!!!

13.6 종단 모니터링

카프카 클러스터의 작동 상태에 대한 클라이언트의 관점을 제공

컨슈머와 프로듀서 클라이언트는 카프카 클러스터에 뭔가 문제가 있음을 나타낼 수 있는 지표를 가지고 있지만, 이것은 지연의 증가 원인이 무엇인지, 즉 클라이언트 탓인지, 네트워크 탓인지, 아니면 카프카 자체의 문제 때문인지를 알려 주지는 않는다. 뿐만 아니라 이 지표를 사용해서 클러스터가 제대로 작동하는지의 여부를 판단한다면 카프카 클러스터를 운영하는 책임을 지고 있는 경우에도 모든 클라이언트 역시 모니터링해야 한다.

정말로 확인해야 할 것들
- 카프카 클러스터에 메시지를 쓸 수 있는가?
- 카프카 클러스터에서 메시지를 읽어 올 수 있는가?
확인 하려면 트래픽을 밀어 넣어봐야 하는데 이것은 합리적이지 않아 수행하는 툴이 있다.

툴 이름 : Xinfra Monitor
- 링크드인의 카프카 팀에서 오픈소스로 공개한 이 툴은 클러스터의 모든 브로커에 걸쳐 있는 토픽에 계속해서 데이터를 쓰고 읽음으로써 브로커별 모니터링을 수행한다.
- 이것은 쓰기 읽기 뿐만 아니라 지연까지도 측정가능하다.
컨슈머 랙 모니터링과 마찬가지로 카프카 브로커는 클라이언트가 클러스터를 문제없이 사용할 수 있는지의 여부를 알려줄 수 없어 외부 모니터링 사용을 적극 권장한다.

hlab-books / kafka-the-definitive-guide

Chapter 13. 카프카 모니터링하기 #14

Chapter 13 카프카 모니터링하기

13.1 지표 기초

13.1.1 지표는 어디에 있는가?

13.1.2 어떤 지표가 필요한가?

13.1.3 애플리케이션 상태 검사

13.2 서비스 수준 목표

13.2.1 서비스 수준 정의

13.2.2 좋은 서비스 수준 지표를 위해서는 어떠한 지푯값을 써야 하는가?

13.2.3 경보에 SLO를 사용하기

13.3 카프카 브로커 지표

13.3.1 클러스터 문제 진단하기

13.3.2 불완전 복제 파티션 다루기

13.3.3 브로커 지표

13.3.4 토픽과 파티션별 지표

13.3.5 JVM 모니터링

13.3.6 운영체제 모니터링

13.3.7 로깅

13.4 클라이언트 모니터링

13.4.1 프로듀서 지표

13.4.2 컨슈머 지표

13.4.3 쿼터

13.5 랙 모니터링

13.6 종단 모니터링

소감

소감

소감

소감