이 문서에서는 Managed Service for Apache Kafka 클러스터에서 데이터를 생성하거나 소비하는 클라이언트의 상태를 모니터링하는 방법을 설명합니다.
전반적인 안정성 전략의 일환으로 클라이언트 애플리케이션을 모니터링하는 것이 중요합니다. 처리량, 오류율, 소비자 지연과 같은 측정항목은 클라이언트 애플리케이션에 안정성 문제가 있는지 여부를 알려줄 수 있습니다. 클라이언트 구성, 파티션 간 키의 불균등한 분포 또는 특정 파티션에만 영향을 미치는 클러스터 문제로 인해 문제가 발생할 수 있습니다.
서버 측 측정항목
클라이언트 동작을 직접 모니터링하는 것이 유용하지만 서버 측 측정항목은 추가 계측이 필요하지 않으며 안정성에 영향을 미치는 클라이언트 측 문제를 감지하는 데 도움이 될 수 있습니다.
서버 측 측정항목은 브로커 간 부하 불균형 (핫 브로커)과 지연 시간 급증과 같은 정상 작업의 편차를 감지하는 데 특히 유용합니다.
처리량
다음 처리량 측정항목을 모니터링하고 예상 처리량과 비교합니다.
- 브로커 및 주제별 메시지 속도
- 바이트 속도(브로커 및 주제별)
- 요청 비율 잘못 구성된 클라이언트는 작은 요청 (요청당 0~1,000바이트)을 높은 비율로 브로커에 과도하게 전송하여 처리량을 줄일 수 있습니다.
- 요청 지연 시간 프로듀서 요청 지연 시간이 급증하면 부하가 불균형하거나 클라이언트 구성에 문제가 있을 수 있습니다.
Kafka는 주제별 및 클러스터별 처리량 측정항목을 제공합니다. 이러한 측정항목은 모든 주제에 대해 집계될 때 항상 동일한 값을 갖지 않습니다. 대략적인 모니터링 및 알림에는 집계된 측정항목을 사용하고 처리량 문제를 해결할 때는 주제별 측정항목을 확인합니다. 문제를 특정 브로커로 격리합니다.
요청 오류율
topic_error_count 측정항목은 서버 측에서 실패한 가져오기 및 생성 요청 수를 추적합니다. 하지만 일부 오류 클래스는 이 측정항목에 반영되지 않습니다. 예를 들면 다음과 같습니다.
승인 설정이 잘못 구성되면 이 측정항목에 오류가 표시되지 않고 클라이언트가 주제에 게시하지 못할 수 있습니다.
클러스터 장애로 인해 브로커가 요청에 전혀 응답하지 못할 수 있습니다.
따라서 요청 시간 초과 오류를 포함하여 클라이언트 측의 오류도 모니터링해야 합니다.
소비자 지연
소비자 지연은 소비자 클라이언트가 특정 오프셋에서 얼마나 뒤처져 있는지를 측정합니다. 이 측정항목을 주제, 파티션, 브로커별로 집계하면 지연이 특정 브로커 또는 파티션으로 인한 것인지 확인하는 데 유용합니다.
워크로드에 중요한 주제 하위 집합의 최대 지연 시간을 기준으로 알림을 만드는 것이 좋습니다.
커스텀 대시보드 쿼리
이러한 신호를 모니터링하려면 커스텀 대시보드와 알림을 만드는 것이 좋습니다. 다음 표에는 클라이언트 상태를 모니터링하는 데 사용할 수 있는 Prometheus Query Language (PromQL) 쿼리가 나와 있습니다.
| 신호 | PromQL 쿼리 |
|---|---|
| 처리량: 브로커당 메시지 비율 | sum by (resource_container, location, cluster_id, broker_index) ( rate( { "managedkafka.googleapis.com/message_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| 처리량: 가장 큰 5개 주제의 주제별 브로커당 메시지 속도 | topk(5, sum by (resource_container, location, cluster_id, broker_index, topic_id) ( rate( { "managedkafka.googleapis.com/message_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) ) |
| 처리량: 주제 및 브로커당 대역폭 | sum by (resource_container, location, cluster_id, broker_index, topic_id) ( rate( { "managedkafka.googleapis.com/byte_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| 요청 비율 | sum by (resource_container, location, cluster_id, request) ( rate( { "managedkafka.googleapis.com/request_count", monitored_resource="managedkafka.googleapis.com/Cluster", "request"="Produce" }[${__interval}] ) ) |
| 요청 비율, 클러스터 총계 | sum by (resource_container, location, cluster_id, request) ( rate( { "managedkafka.googleapis.com/topic_request_count", monitored_resource="managedkafka.googleapis.com/Topic", "request"="Produce" }[${__interval}] ) ) |
| 요청 지연 시간 | sum by (resource_container, location, cluster_id, broker_index, request) ( avg_over_time( { "managedkafka.googleapis.com/request_latencies", monitored_resource="managedkafka.googleapis.com/Cluster", "percentile"="95", "request"="Produce" }[${__interval}] ) ) |
| 요청 오류 수 | sum by (resource_container, location, cluster_id, broker_index, request) ( rate( { "managedkafka.googleapis.com/topic_error_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| 소비자 지연: 오프셋 지연별 상위 5개 파티션 | topk(5, max by (resource_container, location, cluster_id, topic_id, partition_index) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
| 소비자 지연: 오프셋 지연별 상위 5개 소비자 그룹 | topk(5, max by (resource_container, location, cluster_id, consumer_group_id) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
클라이언트 측 측정항목
클라이언트 문제가 서버 측정항목에 표시되지 않는 경우도 있습니다. 예를 들면 다음과 같습니다.
인증 또는 네트워킹이 잘못 구성된 경우 메시지가 클라이언트의 내부 큐에 누적될 수 있습니다. 요청이 타임아웃되면 메시지가 다시 큐에 추가되고 재시도됩니다.
흐름 제어가 잘못 구성되면 클라이언트가 할당된 스레드 수보다 더 많은 메시지를 생성할 수 있습니다. 처리량은 일정할 수 있지만 요청 백로그가 증가하면 전송되기 전에 만료됩니다.
클라이언트가 Compute Engine, Google Kubernetes Engine 또는 Cloud Run에서 실행되는 경우 Cloud Monitoring의 로그 기반 측정항목을 사용하여 로그에서 높은 오류율을 감지할 수 있습니다. 하지만 일부 Kafka 클라이언트는 더 높은 로그 수준을 구성하지 않는 한 재시도가 길어지는 예외를 숨깁니다. 따라서 요청 지연 시간 증가도 모니터링해야 합니다.
Java 클라이언트는 Java 관리 확장 프로그램 (JMX)을 통해 많은 측정항목을 노출합니다. 자세한 내용은 Apache Kafka 문서의 모니터링을 참조하세요. 가능하면 다음 측정항목을 보고하도록 클라이언트를 계측하는 데 우선순위를 두세요.
- 요청 오류율(
kafka.producer:type=producer-metrics,client-id="{client-id}") - 요청 평균 지연 시간(
kafka.producer:type=producer-metrics,client-id="{client-id}")
가능하면 이러한 측정항목을 모니터링 솔루션으로 전송합니다. 클라이언트 인스턴스를 실행하는 머신의 JMX 포트에 연결할 수 있으면 이러한 측정항목을 대화형으로 읽을 수도 있습니다.
완화 조치
클라이언트 애플리케이션에 문제가 표시되면 다음 완화 조치를 고려하세요.
브로커 간의 불균형한 부하 (핫 브로커)를 찾습니다. 클러스터에서 자동 리밸런싱이 사용 설정되어 있는지 확인합니다.
요청 비율이 비정상적으로 높은 경우 클라이언트가 작은 요청을 많이 전송하는지 확인합니다. 프로듀서에서
max.request.size및batch.size구성을 확인합니다.인증, 네트워킹, 흐름 제어에 대한 클라이언트 구성을 확인합니다.
클러스터의 모든 주제 또는 파티션에서 지연이 과도하게 발생하면 클러스터가 과부하 상태이므로 확장해야 함을 나타낼 수 있습니다.
브로커의 모든 주제 또는 파티션에서 과도한 지연이 발생하면 브로커가 과부하 상태임을 나타낼 수 있습니다. 키 배포를 개선하거나 다른 브로커에 파티션을 재할당해 보세요.