Kafka 클라이언트 애플리케이션 모니터링

이 문서에서는 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, broker_index, topic_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/consumer_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartition"
      }[${__interval}]
    )
  )
)

클라이언트 측 측정항목

클라이언트 문제가 서버 측정항목에 표시되지 않는 경우도 있습니다. 예를 들면 다음과 같습니다.

  • 인증 또는 네트워킹이 잘못 구성되면 메시지가 클라이언트의 내부 대기열에 누적될 수 있습니다. 요청 시간이 초과되면 메시지가 다시 대기열에 추가되고 다시 시도됩니다.

  • 흐름 제어가 잘못 구성되면 클라이언트가 할당된 스레드 수보다 더 많은 메시지를 생성할 수 있습니다. 처리량은 일정할 수 있지만 전송되기 전에 만료되는 요청 백로그가 증가합니다.

클라이언트가 Compute Engine, Google Kubernetes Engine 또는 Cloud Run에서 실행되는 경우 Cloud Monitoring의 로그 기반 측정항목을 사용하여 로그의 높은 오류율을 감지할 수 있습니다. 하지만 더 높은 로그 수준을 구성하지 않으면 일부 Kafka 클라이언트에서 재시도를 길게 만드는 예외를 숨깁니다. 따라서 요청 지연 시간 증가도 모니터링해야 합니다.

Java 클라이언트는 Java 관리 확장 프로그램 (JMX)을 통해 많은 측정항목을 노출합니다. 자세한 내용은 Apache Kafka 문서의 Monitoring을 참고하세요. 가능하다면 클라이언트가 다음 측정항목을 보고하도록 계측하는 것을 우선시하세요.

  • 요청 오류율 (kafka.producer:type=producer-metrics,client-id="{client-id}")
  • 요청 평균 지연 시간(kafka.producer:type=producer-metrics,client-id="{client-id}")

가능하면 이러한 측정항목을 모니터링 솔루션으로 전송하세요. 클라이언트 인스턴스를 실행하는 머신의 JMX 포트에 연결할 수 있는 경우 이러한 측정항목을 대화형으로 읽을 수도 있습니다.

완화 조치

클라이언트 애플리케이션에 문제가 있는 경우 다음 완화 방법을 고려하세요.

  • 브로커 간 불균형한 부하 (핫 브로커)를 찾습니다. 클러스터에서 자동 리밸런싱이 사용 설정되어 있는지 확인합니다.

  • 요청 비율이 비정상적으로 높은 경우 클라이언트가 작은 요청을 많이 보내고 있는지 확인합니다. 프로듀서에서 max.request.size 및 batch.size 구성을 확인합니다.

  • 인증, 네트워킹, 흐름 제어를 위한 클라이언트 구성을 확인합니다.

  • 클러스터의 모든 주제 또는 파티션에서 지연이 과도하게 발생하면 클러스터가 과부하 상태이므로 확장해야 할 수 있습니다.

  • 브로커의 모든 주제 또는 파티션에서 과도한 지연이 발생하면 브로커가 과부하되었음을 나타낼 수 있습니다. 키 배포를 개선하거나 파티션을 다른 브로커에 재할당해 보세요.

다음 단계