Kafka lag evaluation

각 서비스의 role

Burrow : kafka 로부터 offset등의 데이터를 수집, API response 로 데이터 전달

Telegraf : Burrow 에 request 를 통해서 데이터를 받아, ES 에 적재 (index 설정 )

es: telegraf 로 부터 받은 데이터 적재
grafana : es의 데이터 조회 및 시각화

 

 

Grafana Data source 설정

데이터를 받아오기 위해 DATA source 설정

URL : 데이터가 적재된 ES의 주소
Index name : es의 index 이름 (RDB의 테이블 개념) Time field name : 시간정보가 있는 field (column 개념)

grafana 데이터 확인

Explorer → datasource : burrow_es_data → Metric : raw data (원래는 json 인것을 테이블 로 보여 줌 )

 

특정 토픽이름으로 쿼리하기 

tag.topic:”test” 로 쿼리하면 해당 데이터만 볼 수 있다. 

 

Burrow kafka 관련 데이터만 뽑기

measurement_name:burrow-* 

(measurement_name에 cpu mem 등 시스템 리소스 정보도 넘어온다 )

 

 

윈도우 크기에 따른 상태 변화 시간 

기본설정은 15이며 offset commit interval과 결합되어 만약 offset commit interval(consumer setting)이 30초이면 7.5 분 동안의 consumer group 상태를 평가한다.

 

ERR 테스트

consumer 프로세스 중지

2021-01-19 09:54:10

2021-01-19 10:01:20

약 7분 

윈도우 크기 15

오프셋 업데이트 30초

 

윈도우 완전히 넘어가는데 걸리는 시간 = 15 * 30초 = 450초 (7.5분)

 

 

Partition status 조건

• Partition status 조건
  OK : LAG <= 0 (윈도우에 0인 lag이 존재하면 상태는 OK 이다. )

전제조건: lag[0-15] != 0

• STOP : (consumer-offset[15].ts – consumer-offset[0].ts) < (now - consumer-offset[15].ts)
  • Offset 전체 수신 시간이 마지막 수신시간부터 현재까지 보다 작으면서
  • consumer-offset[15] 이 broker-offset 보다 작을 경우 (lag 이 0보다 큰 경우)

    

• REWIND : consumer-offset[15] < consumer-offset[14]
  • 컨슈머 오프셋은 시간이 지날 수록 커져야 정상이므로 감소하면 REWIND 상태를 띄워줌

    

• STALLED : consumer-offset[0-14] 이 전부 동일

  

• WARN : 윈도우 내에서 현재lag이 바로 이전 lag 보다 한번이라도 큰 적이 있는지
  • Lag[i] – lag[i-1] >0 (range (i, 15))

    

 

Consumer status 조건

ERROR : Partition Status Code가 ERR 보다 높을 경우 (STOP, STALL, REWIND)

그 이외에는 PARTITION STATUS 와 동일 (OK, WARN, NOTFOUND)

• OK = 1 
• NOT_FOUND = 2 
• WARN = 3
• ERR = 4
• STOP = 5 
• STALL = 6 
• REWIND = 00

status 종류

• NOTFOUND - Consumer group이 cluster에 존재하지 않는 경우
• OK - Consumer group, Partition 정상작동 중
• WARN - offset이 증가하면서 lag도 증가하는 경우(데이터가 증가하는데 consumer가 다소 따라가지 못할 경우)
• ERR - offset이 중지된 경우이지만 lag이 0이 아닌 경우
• STOP - offset commit이 일정시간 이상 중지된 경우
• STALL - offset이 commit되고 있지만 lag이 0이 아닌경우

 

status 평가 기준(컨슈머 랙 평가 룰)

슬라이딩 윈도우 -> 일정 시간 단위동안의 평가기준

 

예) 아래 기준이 슬라이딩 윈도우 기준인데 1.번의 “0이 존재하는지” 유무의 기준이 한개의 윈도우 기간 단위에 0이 있는지 이다. 디폴트가 10인데 이 경우 컨슈머의 셋팅 값 offset commit interval * 10 동안의 시간이다.

1. 0인 lag이 존재하면 상태는 'OK' 이다
2. consumer offset이 변경되지 않고, lag이 고정 혹은 증가하는 경우 consumer는 'ERROR' 이고, 해당 partition은 'STALLED' 이다.
3. consumer offset이 증가하지만 lag이 고정 혹은 증가하는 경우 consumer는 'WARNING'이다.
4. consumer offset의 가장 최근 시간과 현재시간 차이가 가장 최근 시간과 가장 오래된 오프셋 시간보다 클 경우 consumer는 'ERROR'이고, partition은 'STOPPED'이다.그러나 consumer offset과 broker offset이 동일하면 partition은 오류가 아니다.
5. lag이 -1인 경우 특수한 값이므로 broker의 offset이 존재하지 않음을 의미한다. 이는 정상적인 상태로 간주한다.

 

 

요약

offset 증가 -> GOOD

offset 유지 -> BAD

lag 증가 -> bad

log=0 -> GOOD

lag 감소 -> GOOD

 

 

예제1

위 상태를 살펴보면 lag이 동일하게 유지되거나 증가하는 모습을 볼 수 있지만 일부 lag이 0을 포함하므로 현재는 'OK' 상태이다.

만약 이후 6번의 추가 offset commit동안 lag이 유지(5)되거나 증가(5 이상)된다면 consumer는 'WARNING' 상태로 바뀔 것이다.

 

 

TEST 방법

→ 윈도우내 lag = 0 이 있다가 시간이 지나며 lag=0 인 구간이 사라지면서 burrow_partition.status 가 OK 에서 WARNING 으로 바뀌는 것을 확인해보자. 이를 위 해서 컨슈머가 모든 데이터를 소비하여 lag를 0으로 만든 후 추가 프로듀싱을 시작한다.

 

Burrow Query : measurement_name:burrow-*

확인할 필드 : burrow_group.status

1. ./kafka-producer-perf-test.sh --topic test --record-size 1000 --num-records 5000 --producer-props bootstrap.servers=n1:9092,n2:9092,n3: 9092 --throughput 100
2. ./kafka-consumer-perf-test.sh --topic test --show-detailed-stats --group test_group --broker-list n1:9092,n2:9092,n3:9092 --reporting- interval 500 --messages 5000
3. lag 이 0인 것을 확인, burrow_group.status OK이 것을 확인
4. ./kafka-producer-perf-test.sh --topic test --record-size 1000 --num-records 500000 --producer-props bootstrap.servers=n1:9092,n2:9092,n3:9092 --throughput 100
5. 약 7.5 분 후 "measurement_name:burrow_partition && tag.topic:test" 쿼리하여 burrow_partition.status = WARNING 으로 

 

 

query :measurement_name:burrow_group && tag.group:N18137

metric : max burrow_group.lag

interval : 10s

시작시간 : 약 09:33:10초경 lag 0→ 13163 으로 증가

꾸준히 증가하면서 burrow_group.partition_status가 OK→ WARN으로 변경

 

시작시간
2021-01-19 09:33:00

2021-01-19 09:40:10

 

 

예제2

위 상태를 살펴보면 offset이 유지되고 있으며 lag이 증가하므로 consumer는 'ERROR'상태이고 partition은 'STALLED'상태이다. Consumer가 offset을 commit를 시도하고 있지만 정상적으로 consuming 못하고 있다.
-> 룰 2번, 컨슈밍이 안되므로 오프셋이 안늘어나고, 프로듀싱은 계속 들어오므로 랙이 늘어나는 상황

 

예제3

위 상태를 살펴보면, offset은 증가되고 있고 lag도 꾸준히 증가하고 있다. Consumer는 consume을 지속적으로 하고 있으나 다소 지연되는 모습이 보이는데, 이 상태는 잘 consume되고 있지만 약간 뒤져쳐있다는 뜻이므로 'WARNING'상태이다.

-> offset 증가하고 있지만 lag도 증가 하고 있기 때문에 WARNING이다.

 

예제4

위 상태를 살펴보면, offset은 널뛰기하고 있음이 보인다. W1에 비해 W10이 더 높은 값이지만, 부분적으로 하락하는 부분도 있으므로 지금은 'OK'상태이다.

-> lag 감소가 일어난다는건 컨슈밍이 정상적으로 일어나고 있다는 뜻

예제5

위 상태를 측정시 시간이 T+1200이라면, partition은 'STOP'상태이며 consumer는 'ERROR'상태이다.
W10-W1 시간이 540초이지만 현재 저장된 오프셋과 측정시간의 차이가 660초이므로 이는 consumer가 commit offset을 중지했거나 실패 했음을 뜻한다.