Kafka 심화) 카프카 모니터링 하기

클러스터 문제 진단하기

활성 컨트롤러 수나 컨트롤러 큐 크기와 같은 지표를 모니터링 함으로써 뭔가 문제가 발생했을 때 간단히 알아차릴수 있다. 

 

불완전 복제 파티션 다루기

해당 브로커가 리더 레플리카를 잡고 있는 파티션 중 팔로워 레플리카가 따라오지 못하고 있는 파티션의 수를 나타낸다. 다수의 브로커가 일정한 수의 불완전 복제 파티션을 가지고 있다는 것은 보통 클러스터의 브로커중 하나가 내려가 있다는 것을 의미하는 경우가 많다. 

가장 먼저 해야 할 일은 문제가 단일 브로커에 국한된 것인지 아니면 클러스터 전체에 연관된 것인지를 확인하는 것이다 때로는 이것이 쉽지 않은 문제일 수 있다. 만약 다음 예와 같이 불완전 복제 파티션들이 한 브로커에 몰려 있다면 해당 브로커가 문제일 가능성이 높다. 에러 메시지를 보면 다른 브로커가 해당 브로커로부터 메시지를 복제하는데 문제가 있음을 알 수 있다.

 

클러스터 수준 문제

대게 클러스터 문제는 다음 둘중 하나의 유형에 속한다.

- 부하 불균형

- 자원 고갈

 

첫번재 문제는 가장 찾기 쉽지만, 해결 하는 것은 상당히 복잡할 수 있다. 

- 파티션의 개수

- 리더 파티션의 수

- 전 토픽에 있어서의 초당 들어오는 메시지

- 전 토픽에 있어서의 초당 들어오는 바이트

- 전 토픽에 있어서의 초당 나가는 바이트

 

클러스터에서 흔히 볼 수 있는 또 다른 문제는 브로커에 들어오는 요청이 처리 가능한 용량을 넘어 가는 경우다. 

- CPU사용률

- 인바운드 네트워크 속도

- 아웃바운드 네트워크 속도

- 평균 디스크 대기 시간

- 디스크 평균 활용률

 

전 토픽 바이트 인입률은 클러스터 사용량을 보여주는 좋은 가이드 라인이 된다.

 

호스트 수준 문제

하드웨어가 제공하는 기능을 사용해서 하드웨어 상태를 모해야 할 것이다. 

 

브로커 지표

- 활성 컨트롤러 수 : 이 지표는 특정 브로커가 현재 클러스터의 컨트롤러 역할을 맡고 있는지를 나타낸다.

- 컨트롤러의 큐 크기 : 현재 컨트롤러에서 브로커의 처리를 기다리고 있는 요청의 수를 가리킨다.

- 요청 핸들러 유휴 비율 : 카프카는 모든 클라이언트 요청을 처리하기 위해 네트워크, 스레드 풀과 요청 핸들러 스레드 풀, 두개의 스레드 풀을 사용한다. 

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

- 전 토픽 바이트 유출 : 전 토픽 바이트 유출 속도는 트래픽의 전체적인 성장세를 보여주는 또 다른 지표다.

- 전 토픽 메시지 인입 : 메시지 인입 속도는 메시지 크기와 무관하게 초당 들어오는 메시지 수를 보여준다. 

- 파티션 수 : 이는 브로커에 할당된 파티션의 전체 갯수로 자주 변하지는 않는다. 

- 리더 수 : 브로커가 현재 리더를 맡고 있는 파티션의 갯수를 보여준다. 이 지푯값은 모든 브로커에 걸쳐 균동해야 한다. 

- 오프라인 파티션 : 불완전 복제 파티션 수와 마찬가지로 오프라인 파티션 수는 모니터링에 있어서 매우 중요한 지표다. 현재 리더가 없는 파티션의 갯수를 보여준다. 

- 읽기 요청지표 : 초당 요청 지표는 속도 지표이며, 주어진 시간 단위에 걸쳐 수신되어 처리된 해당 타입 요청의 전체 갯수를 가리킨다. 

 

토픽과 파티션별 지표

- 토픽별 지표 : 모든 토픽별 지표의 측정값은 앞에서 설명한 브로커 지표와 매우 비슷하다. 사실, 유일한 차이점은 토픽 이름을 지정해야 한다는 점이며, 지푯값 역시 지정된 토픽에 국한도니 값만을 내놓는다. 

- 파티션별 지표 : 지속적으로 사용하는 걸 기준으로 보자면 파티션별 지표는 토픽별 지표에 비해 덜 유용한 편이다. 몇몇 제한된 상황에서는 유용하게 사용될 수 있다. 특히 파티션 크기 지표는 해당 파티션에 대한 현재 디스크에 저장도니 데이터의 양을 바이트 단위로 보여준다. 따라서 이 값들을 합산하면 하나의 토픽에 저장된 데이터의 양을 알 수 있는데, 이는 카프카를 각각의 클라이언트에 할당할 때 들어갈 자원의 양을 계산하는데 유용할 수 있다. 

 

 

로깅 

kafka.server.ClientQuotaManager 로거다. 이 로거는 프로듀서 혹은 컨슈머 쿼터 작업에 관련된 메시지를 보여주기 위해 사용된다. 로그 압착 스레드의 상태에 관한 정보를 로깅하는 것 역시 도움이 된다. kafka.log.LogCleaner, kafka.log.Cleaner, kafka.log.LogCleanerManager 로거를 Debug 레벨로 활성화함으로써 이 스레드에 대한 상태 정보가 찍히게 할 수 있다. 카프카에서 문제를 디버깅할대 유용한 로거 역시 있다. 그러한 로거 중 하나가 kafka.request.logger다. 이 로거는 Debug또는 Trace 레벨로 켜 놓으면 되는데, 브로커로 들어오는 모든 요청에 대한 정보를 기록한다. 

 

프로듀서 종합 지표

우선 record-error-rate 속성은 반드시 경보 설정을 해 놓아야 한다. 이 지표는 언제나 0이어야 하며, 만약 그보다 크다면 프로듀서가 브로커로 메시지를 보내는 와중에 누수가 발생하고 있음을 의미한다. 프로듀서는 백오프backoff 를 해가면서 사전 설정된 수만큼 재시로를 하게 되어 있는데, 만약 재시도 수가 고갈되면 메시지는 폐기된다. 

 

경보를 설정해 놔야 하는다른 지표는 request-latency-avg 이다. 이것은 브로커가 쓰기 요청을 받을 때까지 걸린 평균 시간이다. 

 

브로커별, 토픽별 지표

브로커별 프로듀서 지표에서 가장 중요한 지표는 request-latency-avg이다. 이 지표는 거의 변화가 없지만, 특정 브로커로의 연결에 문제가 있을 경우 알 수 있다. outgoing-byte-rate나 request-latency-avg와 같은 다른 속성은 브로커가 리더를 맡고 있는 파티션이 무엇이냐에 따라 달라지는 경향이 있다. 

 

컨슈머 지표

읽기 매니저 지표 : 컨슈머 클라이언트에서는 중요한 지표들이 읽기 매니저 빈에 들어있기 때문에 컨슈머 종합 지표 빈은 상대적으로 덜 유용하다. 읽기 매니저의 경우 모니터링 말고 경보 설정에 모두 사용할 수 있는 속성에 하나 있는데, 바로 fetch-latency-avg이다. 프로듀서 클라이언트의 request-latency-avg와 마찬가지로 이 지표는 브로커로 읽기 요청을 보내는데 걸리는 시간을 보여준다. 다만 이 지표에 경보 설정을 걸어 놓는 것은 문제가 있는데, 지연은 컨슈머 설정 중 fetch.min.bytes와 fetch.max.wait.ms의 영향을 받기 때문이다. 컨슈머 클라이언트가 얼마나 많은 메시지 트래픽을 처리중인지를 알려면 bytes-comsumed-rate 혹은 records-consumed=rate, 가능하면 두 지표를 다 보는것이 좋다. 이 지표들은 클라이언트 인스턴스의 읽기 트래픽을 초당 바이트 수 혹은 초당 메시지 수 형태로 보여준다. 

브로커별, 토픽별 지표 : 컨슈머 클라이언트 역시 브로커 연결이나 읽는 토픽에 각각에 대한 지표를 제공한다. request-latency-avg 속성은 읽고 있는 토픽의 메시지 트래픽에 따라 제한적으로 유용하다. incoming-byte-rate와 reqeust-rate 지표는 읽기 매니저에 의해 제공되는 bytes-consumed-rate, records-consumed-rate 지표를 각각 브로커별 초당 바이트와 브로커별 초당 요청수로 세분화한 것이다. 토픽별 지표는 1개 이상의 토픽에서 읽어오고 있을 때 유용하다. 너무 많은 토픽으로부터 읽을 경우 이 지표들은 알아보기가 어렵다. 만약 이 값들을 수집하고 싶다면 가장 중요한 지표는 bytes-consumed-rate, records-consumed-rate, fetch-size-avg다. bytes-consumed-rate 는 특정 포틱에서 읽은 초당 바이트 수 , records-consumed-rate는 초당 메시지 수 , fetch-size-avg는 해당 토픽에 대한 읽기 요청의 평균 크기를 보여준다. 

그룹 코디에니터는 동기화 작업에 들어간  평균 시간을 sync-time-avg 지표 속성을 통해 밀리초 단위로 보여준다. 초당 그룹 동기화 수를 보여주는 sync-rate 속성 역시 도움이 된다. 컨슈머 그룹이 안정적일 경우 이값은 대부분의 시간 동안 0이다. 

 

랙 모니터링

카프카 컨슈머에 있어서 가장 중요하게 모니터링되어야 하는 것은 컨슈머 랙이다. 선호되는 방법은 브로커의 파티션 상태와 컨슈머 상태를 둘다 지켜봄으로써 마지막으로 쓰여진 메시지 오프셋과 컨슈머 그룹이 파티션에 대해 마지막으로 커밋한 오프셋을 추적하는 외부 프로세스를 두는 것이다.