19.4. 문제 해결을 위해 Kafka#159 메트릭 분석

균형 잡힌 Kafka 클러스터는 최적의 성능을 위해 중요합니다. 분산된 클러스터에서 파티션과 리더는 모든 브로커에 균등하게 분배되며 I/O 메트릭은 이를 반영합니다. 메트릭을 사용하는 것 외에도 kafka-topics.sh 툴을 사용하여 복제되지 않은 파티션 목록을 가져오고 문제가 있는 브로커를 식별할 수 있습니다. 복제되지 않은 파티션의 수가 변동하거나 많은 브로커가 높은 요청 대기 시간을 표시하는 경우 일반적으로 조사가 필요한 클러스터의 성능 문제를 나타냅니다. 반면 클러스터의 많은 브로커가 보고한 비복제 파티션의 안정적인 수는 일반적으로 클러스터의 브로커 중 하나가 오프라인임을 나타냅니다.

kafka-topics.sh 툴의 describe --under-replicated-partitions 옵션을 사용하여 현재 클러스터에 복제된 파티션에 대한 정보를 표시합니다. 이러한 파티션은 구성된 복제 인수보다 적은 복제본입니다.

출력이 비어 있으면 Kafka 클러스터에 복제되지 않은 파티션이 없습니다. 그렇지 않으면 출력에 동기화 중이거나 사용할 수 없는 복제본이 표시됩니다.

다음 예제에서는 각 파티션에 대해 3개의 복제본 중 2개만 동기화되고 ISR(동기화 복제본)에서 복제본이 누락되어 있습니다.

bin/kafka-topics.sh --bootstrap-server :9092 --describe --under-replicated-partitions

Topic: topic-1 Partition: 0 Leader: 4 Replicas: 4,2,3 Isr: 4,3
Topic: topic-1 Partition: 1 Leader: 3 Replicas: 2,3,4 Isr: 3,4
Topic: topic-1 Partition: 2 Leader: 3 Replicas: 3,4,2 Isr: 3,4

다음은 I/O 및 비복제된 파티션을 확인하는 몇 가지 메트릭입니다.

kafka.server:type=ReplicaManager,name=PartitionCount 1
kafka.server:type=ReplicaManager,name=LeaderCount 2
kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec 3
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec 4
kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions 5
kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount 6

주제 구성이 고가용성으로 설정된 경우 주제 구성이 3개 이상이고, 최소 개수의 in-sync 복제본이 복제 요소보다 1보다 작으면 복제되지 않은 파티션을 계속 사용할 수 있습니다. 반대로 최소 ISR 미만의 파티션은 가용성을 줄였습니다. kafka.server:type=ReplicaManager,name=UnderMinIsr CryostatCount 메트릭과 kafka-topics.sh 툴의 under-min-isr-partitions 옵션을 사용하여 이러한 항목을 모니터링할 수 있습니다.

클러스터 메트릭의 급증은 브로커 문제를 나타낼 수 있으며, 이는 종종 스토리지 장치의 속도 저하 또는 실패 또는 다른 프로세스의 중단과 관련된 경우가 많습니다. 운영 체제 또는 하드웨어 수준에서 문제가 없는 경우 Kafka 클러스터의 로드의 불균형이 발생할 수 있으며 일부 파티션에서는 동일한 Kafka 주제의 다른 항목과 비교하여 과도한 트래픽을 수신할 수 있습니다.

Kafka 클러스터에서 성능 문제를 예측하려면 RequestHandlerAvgIdlePercent 메트릭을 모니터링하는 것이 좋습니다. RequestHandlerAvgIdlePercent 는 클러스터가 작동하는 방식을 잘 나타내는 전체 지표를 제공합니다. 이 메트릭의 값은 0에서 1 사이입니다. Cryostat 아래의 값은 스레드가 시간 중 30%를 사용 중이고 성능이 저하되기 시작하는 것을 나타냅니다. 값이 50% 아래로 떨어지면 특히 클러스터를 확장하거나 재조정해야 하는 경우 문제가 발생할 수 있습니다. 30 %에서 클러스터는 거의 사용할 수 없습니다.

또 다른 유용한 메트릭은 kafka.network:type=Processor,name=IdlePercent 입니다. 이 메트릭은 Kafka 클러스터의 네트워크 프로세서가 유휴 상태인 범위(%)를 모니터링하는 데 사용할 수 있습니다. 메트릭은 프로세서가 초과되었는지 또는 활용도가 낮은지 여부를 식별하는 데 도움이 됩니다.

최적의 성능을 보장하기 위해 num.io.threads 속성을 하이퍼 스레드 프로세서를 포함하여 시스템의 프로세서 수와 동일하게 설정합니다. 클러스터가 균형을 유지하지만 단일 클라이언트가 요청 패턴을 변경하여 문제를 유발하는 경우 클러스터의 부하를 줄이거나 브로커 수를 늘리십시오.

단일 브로커의 단일 디스크 오류가 전체 클러스터의 성능에 심각한 영향을 미칠 수 있다는 점에 유의해야합니다. 생산자 클라이언트는 주제의 파티션을 유도하는 모든 브로커에 연결하고 해당 파티션이 전체 클러스터에 균등하게 분배되므로 성능이 좋지 않은 브로커는 요청을 생성하고 생산자의 백 압력을 유발하여 모든 브로커에 대한 요청을 느리게합니다. RAID(Redundant Array of Inexpensive Disks) 스토리지 구성으로 여러 물리적 디스크 드라이브를 단일 논리 단위로 결합하면 이 문제를 방지할 수 있습니다.

다음은 Kafka 클러스터의 성능을 확인하는 몇 가지 메트릭입니다.

kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent 1
# attributes: OneMinuteRate, FifteenMinuteRate
kafka.server:type=socket-server-metrics,listener=([-.\w]+),networkProcessor=([\d]+) 2
# attributes: connection-creation-rate
kafka.network:type=RequestChannel,name=RequestQueueSize 3
kafka.network:type=RequestChannel,name=ResponseQueueSize 4
kafka.network:type=Processor,name=IdlePercent,networkProcessor=([-.\w]+) 5
kafka.server:type=KafkaServer,name=TotalDiskReadBytes 6
kafka.server:type=KafkaServer,name=TotalDiskWriteBytes 7

Kafka 컨트롤러는 브로커 등록, 파티션 재할당, 주제 관리와 같은 클러스터의 전체 상태를 관리합니다. Kafka 클러스터에서 컨트롤러의 문제는 진단하기가 어렵고 Kafka 자체의 버그 범주에 속하는 경우가 많습니다. 컨트롤러 문제는 브로커 메타데이터가 동기화되지 않거나, 브로커가 미세한 것처럼 보이는 경우 오프라인 복제본 또는 주제 생성이 올바르게 발생하지 않는 항목에 대한 작업으로 표시될 수 있습니다.

컨트롤러를 모니터링하는 방법은 많지 않지만 활성 컨트롤러 수와 컨트롤러 대기열 크기를 모니터링할 수 있습니다. 이러한 메트릭을 모니터링하면 문제가 있는 경우 높은 수준의 표시기가 제공됩니다. 큐 크기의 급증이 예상되지만 이 값이 지속적으로 증가하거나 높은 값을 유지하고 떨어지지 않는 경우 컨트롤러가 중단될 수 있음을 나타냅니다. 이 문제가 발생하면 컨트롤러를 다른 브로커로 이동할 수 있으므로 현재 컨트롤러 인 브로커를 종료해야합니다.

다음은 Kafka 컨트롤러의 성능을 확인하는 몇 가지 메트릭입니다.

kafka.controller:type=KafkaController,name=ActiveControllerCount 1
kafka.controller:type=KafkaController,name=OfflinePartitionsCount 2
kafka.controller:type=ControllerEventManager,name=EventQueueSize 3

RequestHandlerAvgIdlePercent 메트릭을 사용하여 요청이 느린지 확인할 수 있습니다. 또한 요청 메트릭은 지연 및 기타 문제가 발생하는 특정 요청을 식별할 수 있습니다.

Kafka 요청을 효과적으로 모니터링하려면 다음 두 가지 주요 지표인 count 및 99번째 백분위 대기 시간을 수집하는 것이 중요합니다.

count 메트릭은 특정 시간 간격 내에서 처리된 요청 수를 나타냅니다. Kafka 클러스터에서 처리하는 요청 볼륨에 대한 인사이트를 제공하고 트래픽의 급증 또는 감소를 식별하는 데 도움이 됩니다.

99번째 백분위 대기 시간 메트릭은 요청 대기 시간을 측정하며, 이는 요청을 처리하는 데 걸리는 시간입니다. 이는 요청의 99 %가 처리되는 기간을 나타냅니다. 그러나 나머지 1%의 요청에 대한 정확한 지속 기간에 대한 정보는 제공하지 않습니다. 즉, 99번째 백분위 대기 시간 메트릭은 요청의 99 %가 특정 기간 내에 처리되고 나머지 1 %는 더 오래 걸릴 수 있지만 나머지 1 %의 정확한 기간은 알려져 있지 않습니다. 99번째 백분위 수를 선택하는 것은 주로 대부분의 요청에 중점을 두고 결과를 스케일 수 있는 아웃리저를 제외하는 것입니다.

이 메트릭은 대부분의 요청과 관련된 성능 문제 및 병목 현상을 식별하는 데 특히 유용하지만 적은 요청만으로 경험되는 최대 대기 시간을 완전히 파악하지는 않습니다.

count 및 99번째 백분위 대기 시간 지표를 모두 수집하고 분석하면 Kafka 클러스터의 전반적인 성능 및 상태를 이해하고 처리 중인 요청의 대기 시간을 파악할 수 있습니다.

다음은 Kafka 요청의 성능을 확인하는 몇 가지 메트릭입니다.

# requests: EndTxn, Fetch, FetchConsumer, FetchFollower, FindCoordinator, Heartbeat, InitProducerId,
# JoinGroup, LeaderAndIsr, LeaveGroup, Metadata, Produce, SyncGroup, UpdateMetadata 1
kafka.network:type=RequestMetrics,name=RequestsPerSec,request=([\w]+) 2
kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request=([\w]+) 3
kafka.network:type=RequestMetrics,name=TotalTimeMs,request=([\w]+) 4
kafka.network:type=RequestMetrics,name=LocalTimeMs,request=([\w]+) 5
kafka.network:type=RequestMetrics,name=RemoteTimeMs,request=([\w]+) 6
kafka.network:type=RequestMetrics,name=ThrottleTimeMs,request=([\w]+) 7
kafka.network:type=RequestMetrics,name=ResponseQueueTimeMs,request=([\w]+) 8
kafka.network:type=RequestMetrics,name=ResponseSendTimeMs,request=([\w]+) 9
# attributes: Count, 99thPercentile 10

클라이언트 메트릭을 분석하면 브로커에 연결된 Kafka 클라이언트(프로덕터 및 소비자)의 성능을 모니터링할 수 있습니다. 이렇게 하면 소비자가 소비자 그룹, 높은 요청 실패 속도 또는 빈번한 연결 해제와 같이 브로커 로그에 강조 표시된 문제를 식별하는 데 도움이 될 수 있습니다.

다음은 Kafka 클라이언트의 성능을 확인하는 몇 가지 메트릭입니다.

kafka.consumer:type=consumer-metrics,client-id=([-.\w]+) 1
# attributes: time-between-poll-avg, time-between-poll-max
kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\w]+) 2
# attributes: heartbeat-response-time-max, heartbeat-rate, join-time-max, join-rate, rebalance-rate-per-hour
kafka.producer:type=producer-metrics,client-id=([-.\w]+) 3
# attributes: buffer-available-bytes, bufferpool-wait-time, request-latency-max, requests-in-flight
# attributes: txn-init-time-ns-total, txn-begin-time-ns-total, txn-send-offsets-time-ns-total, txn-commit-time-ns-total, txn-abort-time-ns-total
# attributes: record-error-total, record-queue-time-avg, record-queue-time-max, record-retry-rate, record-retry-total, record-send-rate, record-send-total

주제 및 파티션에 대한 메트릭은 Kafka 클러스터의 문제를 진단하는 데도 유용할 수 있습니다. 또한 클라이언트 메트릭을 수집할 수 없는 경우 특정 클라이언트의 문제를 디버깅하는 데 사용할 수도 있습니다.

다음은 특정 주제 및 파티션의 성능을 확인하는 몇 가지 메트릭입니다.

#Topic metrics
kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=([-.\w]+) 1
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec,topic=([-.\w]+) 2
kafka.server:type=BrokerTopicMetrics,name=FailedFetchRequestsPerSec,topic=([-.\w]+) 3
kafka.server:type=BrokerTopicMetrics,name=FailedProduceRequestsPerSec,topic=([-.\w]+) 4
kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec,topic=([-.\w]+) 5
kafka.server:type=BrokerTopicMetrics,name=TotalFetchRequestsPerSec,topic=([-.\w]+) 6
kafka.server:type=BrokerTopicMetrics,name=TotalProduceRequestsPerSec,topic=([-.\w]+) 7
#Partition metrics
kafka.log:type=Log,name=Size,topic=([-.\w]+),partition=([\d]+)) 8
kafka.log:type=Log,name=NumLogSegments,topic=([-.\w]+),partition=([\d]+)) 9
kafka.log:type=Log,name=LogEndOffset,topic=([-.\w]+),partition=([\d]+)) 10
kafka.log:type=Log,name=LogStartOffset,topic=([-.\w]+),partition=([\d]+)) 11