이전 포스팅(https://blog.voidmainvoid.net/243)에서 Burrow가 나오게된 배경에 대해 알아보았다.
이 포스팅에서는 burrow가 lag의 상태에 따라 상태를 정의하는 방법에 대해 알아보자.
Consumer Lag Evaluation Rules
Burrow에 있는 consumer group의 상태는 group이 consume하고 있는 각 partitin에 대한 offset의 규칙에 따라 결정된다. 분리된 threshold를 정하지 않더라도 이 kafka consumer들이 '정상'적으로 작동중인지, '비정상'적으로 작동중인지 판단 할 수 있다. consumer group이 consume하는 모든 파티션에 대해 평가를 함으로서 consumer group이 정상적으로 consume을 하고 있음을 판단 할 수 있다.
Evaluation Window
Burrow의 storage는 in-memory에 partition등 정보들이 저장되는데, 슬라이딩 윈도우길이와 consumer group이 consume하는 partition의 offset을 지정할 수 있다. 기본설정은 10이며 offset commit interval과 결합되어 만약 offset commit interval(consumer setting)이 60초이면 10분 동안의 consumer group 상태를 평가한다.
슬라이딩 윈도우란?
일정 buffer을 가진 data 묶음을 추가, 제거하는 자료구조이다. 대표적인 사용처로서 TCP sliding window가 있다.
Evaluation Rules
아래와 같은 평가규칙을 가지고 consumer group의 상태를 평가한다. (아래는 모두 슬라이딩 윈도우에 존재하는 값에 기반한다.)
- 0인 lag이 존재하면 상태는 'OK' 이다
- consumer offset이 변경되지 않고, lag이 고정 혹은 증가하는 경우 consumer는 'ERROR' 이고, 해당 partition은 'STALLED' 이다.
- consumer offset이 증가하지만 lag이 고정 혹은 증가하는 경우 consumer는 'WARNING'이다.
- consumer offset의 가장 최근 시간과 현재시간 차이가 가장 최근 시간과 가장 오래된 오프셋 시간보다 클 경우 consumer는 'ERROR'이고, partition은 'STOPPED'이다.
그러나 consumer offset과 broker offset이 동일하면 partition은 오류가 아니다. - lag이 -1인 경우 특수한 값이므로 broker의 offset이 존재하지 않음을 의미한다. 이는 정상적인 상태로 간주한다.
Burrow의 http endpoint를 통해 consumer status와 partition status를 조회 할 수 있다.
참고 url : https://blog.voidmainvoid.net/245#consumer-group-lag
Evaluation 예제들
아래 예제들은 Burrow에 저장된 슬라이딩 윈도우의 값(offset, lag, timestamp)들을 나타낸다. offset, lag은 해당 시간에 측정된 값이고 timestamp는 임의의 시간에 더해진 초(second)이다.
예제1
W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | |
Offset | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 | 90 | 100 |
Lag | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 3 | 5 | 5 |
Timestamp | T | T+60 | T+120 | T+180 | T+240 | T+300 | T+360 | T+420 | T+480 | T+540 |
위 상태를 살펴보면 lag이 동일하게 유지되거나 증가하는 모습을 볼 수 있지만 일부 lag이 0을 포함하므로 현재는 'OK' 상태이다.
만약 이후 6번의 추가 offset commit동안 lag이 유지(5)되거나 증가(5 이상)된다면 consumer는 'WARNING' 상태로 바뀔 것이다.
예제2
W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | |
Offset | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
Lag | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 2 | 3 | 3 |
Timestamp | T | T+60 | T+120 | T+180 | T+240 | T+300 | T+360 | T+420 | T+480 | T+540 |
위 상태를 살펴보면 offset이 유지되고 있으며 lag이 증가하므로 consumer는 'ERROR'상태이고 partition은 'STALLED'상태이다.
Consumer가 offset을 commit를 시도하고 있지만 정상적으로 consuming 못하고 있다.
예제3
W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | |
Offset | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 | 90 | 100 |
Lag | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 2 | 3 | 3 |
Timestamp | T | T+60 | T+120 | T+180 | T+240 | T+300 | T+360 | T+420 | T+480 | T+540 |
위 상태를 살펴보면, offset은 증가되고 있고 lag도 꾸준히 증가하고 있다. Consumer는 consume을 지속적으로 하고 있으나 다소 지연되는 모습이 보이는데, 이 상태는 잘 consume되고 있지만 약간 뒤져쳐있다는 뜻이므로 'WARNING'상태이다.
예제4
W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | |
Offset | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 | 90 | 100 |
Lag | 5 | 3 | 5 | 2 | 1 | 1 | 2 | 1 | 4 | 6 |
Timestamp | T | T+60 | T+120 | T+180 | T+240 | T+300 | T+360 | T+420 | T+480 | T+540 |
위 상태를 살펴보면, offset은 널뛰기하고 있음이 보인다. W1에 비해 W10이 더 높은 값이지만, 부분적으로 하락하는 부분도 있으므로 지금은 'OK'상태이다.
예제5
W1 | W2 | W3 | W4 | W5 | W6 | W7 | W8 | W9 | W10 | |
Offset | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 | 90 | 100 |
Lag | 5 | 3 | 5 | 2 | 1 | 1 | 2 | 1 | 4 | 6 |
Timestamp | T | T+60 | T+120 | T+180 | T+240 | T+300 | T+360 | T+420 | T+480 | T+540 |
위 상태를 측정시 시간이 T+1200이라면, partition은 'STOP'상태이며 consumer는 'ERROR'상태이다.
W10-W1 시간이 540초이지만 현재 저장된 오프셋과 측정시간의 차이가 660초이므로 이는 consumer가 commit offset을 중지했거나 실패 했음을 뜻한다.
원문 : https://github.com/linkedin/Burrow/wiki/Consumer-Lag-Evaluation-Rules
'빅데이터 > Kafka' 카테고리의 다른 글
enable.auto.commit 일 때 Kafka consumer close() method 동작분석 (0) | 2019.09.02 |
---|---|
[confluent]Kafka에 대한 상식 퀴즈 14개 (0) | 2019.08.30 |
Kafka burrow http endpoint 정리 (270) | 2019.08.02 |
Burrow - kafka consumer의 지연(lag)을 모니터링할 수 있는 효과적인 opensource tool (249) | 2019.08.02 |
KSQL - Streaming SQL for Apache Kafka 개요 - readme 설명 번역 (265) | 2019.07.07 |
Kafka broker와 java client의 버젼 하위호환성 정리 (390) | 2019.02.14 |