Neste documento, descrevemos 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 informar se os aplicativos clientes estão enfrentando problemas de confiabilidade. Os problemas podem ser causados por 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 brokers (brokers ativos) e desvios nas operações normais, como picos de latência.
Capacidade
Monitore as seguintes métricas de capacidade e compare-as com a capacidade esperada:
- Taxa de mensagens, por corretor e por tópico.
- Taxa de bytes, por broker e por tópico.
- Taxas de solicitação. Um cliente mal configurado pode inundar os brokers com uma alta taxa de solicitações pequenas (0 a 1.000 bytes por solicitação), reduzindo a capacidade.
- Latência de solicitação. Picos na latência de solicitação do produtor podem indicar carga desequilibrada ou um problema com a configuração do cliente.
O Kafka oferece métricas de capacidade de processamento por tópico e para o cluster. Essas métricas nem sempre têm os mesmos valores quando agregadas para todos os temas. Use uma métrica agregada para monitoramento e alertas de alto nível e analise as métricas por tópico ao resolver problemas de capacidade. Isolar problemas em corretores específicos.
Taxas de erro de solicitação
A métrica topic_error_count rastreia 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 incorretas podem impedir que um cliente produza para um tópico sem que o erro apareça nessa métrica.
Falhas no cluster podem impedir que um broker responda a solicitações.
Por isso, também é importante monitorar erros no lado do cliente, incluindo erros de tempo limite de solicitação.
Tempo de conversão
O atraso do consumidor mede o quanto um cliente consumidor está atrasado em relação a um determinado deslocamento. A agregação dessa métrica por tópico, partição e broker é útil para determinar se o atraso é devido a brokers ou partições específicas.
Considere criar um alerta com base no atraso máximo no subconjunto de tópicos críticos para sua carga de trabalho.
Consultas personalizadas do painel
Recomendamos criar painéis e alertas personalizados para monitorar esses indicadores. A tabela a seguir mostra consultas da linguagem de consulta do Prometheus (PromQL) que podem ser usadas para monitorar a integridade do cliente.
| Sinal | Consulta PromQL |
|---|---|
| Capacidade de processamento: taxas de mensagens por broker | 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 broker e 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 de processamento: 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}] ) ) |
| Contagem 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, os problemas do cliente não aparecem nas métricas do servidor. Por exemplo:
Se a autenticação ou a rede estiverem configuradas incorretamente, as mensagens poderão se acumular nas filas internas do cliente. Quando 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 taxa de transferência possa ser consistente, um backlog crescente de solicitações expira antes de ser enviado.
Se os clientes forem executados no Compute Engine, no Google Kubernetes Engine ou no Cloud Run, use métricas com base em registros no Cloud Monitoring para detectar altas taxas de erros 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 Monitoring na documentação do Apache Kafka. Se possível, priorize a instrumentação dos seus clientes para informar as seguintes métricas:
- Taxas de erros 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ê conseguir se conectar às portas JMX nas máquinas que executam as instâncias de 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 os 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 de
max.request.sizeebatch.sizeno produtor.Verifique as configurações do cliente para autenticação, rede e controle de fluxo.
Um atraso excessivo em todos os tópicos ou partições de um cluster pode indicar que ele está sobrecarregado e precisa ser escalonado.
Um atraso excessivo em todos os tópicos ou partições em um agente pode indicar que ele está sobrecarregado. Tente melhorar a distribuição de chaves ou reatribuir partições a diferentes brokers.
A seguir
- Monitorar clusters do Kafka
- Monitorar a confiabilidade dos clusters do Kafka
- Criar e gerenciar painéis personalizados