Monitorar aplicativos cliente do Kafka

Este documento descreve como monitorar a integridade dos clientes que produzem ou consomem dados no cluster do Serviço Gerenciado para Apache Kafka.

É importante monitorar os aplicativos cliente como parte da sua estratégia geral de confiabilidade. Métricas como capacidade, taxas de erro e atraso do consumidor podem indicar se os aplicativos cliente estão apresentando problemas de confiabilidade. Os problemas podem ser causados pela configuração do cliente, distribuição desigual de chaves entre partições ou problemas de cluster que afetam apenas uma partição específica.

Métricas do lado do servidor

Embora seja útil monitorar o comportamento do cliente diretamente, as métricas do lado do servidor não exigem instrumentação adicional e podem ajudar a detectar problemas do lado do cliente que afetam a confiabilidade.

As métricas do lado do servidor são especialmente úteis para detectar desequilíbrios de carga entre agentes (agentes ativos) e desvios em operações normais, como picos de latência.

Capacidade de processamento

Monitore as seguintes métricas de capacidade de processamento e compare-as com a capacidade de processamento esperada:

  • Taxa de mensagens, por agente e por tópico.
  • Taxa de bytes, por agente e por tópico.
  • Taxas de solicitação. Um cliente mal configurado pode inundar os agentes com uma alta taxa de solicitações pequenas (0 a 1.000 bytes por solicitação), reduzindo a capacidade.
  • Latência da solicitação. Picos na latência da solicitação do produtor podem indicar carga desequilibrada ou um problema com a configuração do cliente.

O Kafka oferece métricas de capacidade por tópico e para o cluster. Essas métricas nem sempre têm os mesmos valores quando agregadas para todos os tópicos. Use uma métrica agregada para monitoramento e alertas de alto nível e consulte as métricas por tópico ao solucionar problemas de capacidade de processamento. Isole problemas em agentes específicos.

Taxas de erro de solicitação

A métrica topic_error_count acompanha o número de solicitações de busca e produção com falha no lado do servidor. No entanto, algumas classes de erro não são refletidas nessa métrica. Exemplo:

  • Configurações de autorização mal configuradas podem impedir que um cliente produza um tópico, sem que o erro apareça nessa métrica.

  • Falhas de cluster podem impedir que um agente responda a solicitações.

Por esse motivo, também é necessário monitorar erros no lado do cliente, incluindo erros de tempo limite de solicitação.

Atraso do consumidor

O atraso do consumidor mede o quão atrasado um cliente consumidor está em relação a um deslocamento específico. A agregação dessa métrica por tópico, partição e agente é útil para determinar se o atraso é devido a agentes ou partições específicos.

Considere criar um alerta com base no atraso máximo no subconjunto de tópicos que são essenciais para sua carga de trabalho.

Consultas de painel personalizado

Recomendamos criar painéis e alertas personalizados para monitorar esses indicadores. A tabela a seguir mostra consultas da linguagem de consulta do Prometheus (PromQL, na sigla em inglês) que podem ser usadas para monitorar a integridade do cliente.

SinalConsulta PromQL
Capacidade: taxas de mensagens por agente 
sum by (resource_container, location, cluster_id, broker_index) (
  rate(
    {
      "managedkafka.googleapis.com/message_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Capacidade: taxas de mensagens por agente por tópico, para os cinco maiores tópicos 
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}]
    )
  )
)
Capacidade: largura de banda por tópico e agente 
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}]
  )
)
Taxa de solicitação 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/request_count",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "request"="Produce"
    }[${__interval}]
  )
)
Taxa de solicitação, totais do cluster 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_request_count",
      monitored_resource="managedkafka.googleapis.com/Topic",
      "request"="Produce"
    }[${__interval}]
  )
)
Latência da solicitação 
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}]
  )
)
Contagens de erros de solicitação 
sum by (resource_container, location, cluster_id, broker_index, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_error_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Atraso do consumidor: as cinco principais partições por atraso do consumidor 
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}]
    )
  )
)

Métricas do lado do cliente

Às vezes, problemas do cliente não aparecem nas métricas do servidor. Exemplo:

  • Se a autenticação ou a rede estiverem mal configuradas, as mensagens poderão se acumular nas filas internas do cliente. À medida que as solicitações expiram, as mensagens são reenfileiradas e repetidas.

  • Se o controle de fluxo estiver mal configurado, um cliente poderá produzir mais mensagens do que o número alocado de linhas de execução pode enviar. Embora a capacidade de processamento possa ser consistente, um backlog crescente de solicitações expira antes de poder ser enviado.

Se os clientes forem executados no Compute Engine, no Google Kubernetes Engine ou no Cloud Run, você poderá usar métricas baseadas em registros no Cloud Monitoring para detectar altas taxas de erro nos registros. No entanto, alguns clientes do Kafka ocultam exceções que levam a novas tentativas prolongadas, a menos que você configure níveis de registro mais altos. Portanto, também é necessário monitorar o aumento das latências de solicitação.

Os clientes Java expõem muitas métricas por meio das extensões de gerenciamento do Java (JMX, na sigla em inglês). Para mais informações, consulte Monitoramento na documentação do Apache Kafka. Se possível, priorize a instrumentação dos clientes para informar as seguintes métricas:

  • Taxas de erro de solicitação (kafka.producer:type=producer-metrics,client-id="{client-id}")
  • Latência média da solicitação (kafka.producer:type=producer-metrics,client-id="{client-id}")

Envie essas métricas para uma solução de monitoramento, se possível. Se você puder se conectar às portas JMX nas máquinas que executam as instâncias do cliente, também poderá ler essas métricas de forma interativa.

Mitigações

Se você encontrar problemas nos aplicativos cliente, considere as seguintes mitigações:

  • Procure carga desequilibrada entre agentes (agentes ativos). Verifique se o rebalanceamento automático está ativado no cluster.

  • Se a taxa de solicitação parecer muito alta, verifique se o cliente está enviando um grande número de solicitações pequenas. Verifique as configurações max.request.size e batch.size no produtor.

  • Verifique as configurações do cliente para autenticação, rede e controle de fluxo.

  • O atraso excessivo em todos os tópicos ou partições em um cluster pode indicar que o cluster está sobrecarregado e precisa ser escalonado.

  • O atraso excessivo em todos os tópicos ou partições em um agente pode indicar que o agente está sobrecarregado. Tente melhorar a distribuição de chaves ou reatribuir partições a agentes diferentes.

A seguir