Introdução às métricas do cliente Kafka

Com o Kafka, o monitoramento geralmente envolve várias métricas relacionadas a tópicos, partições, brokers e grupos de consumidores. As métricas padrão do Kafka incluem informações sobre rendimento, latência, replicação e uso de disco. Consulte a documentação do Kafka e as ferramentas de monitoramento relevantes para entender as métricas específicas disponíveis para sua versão do Kafka e como interpretá-las efetivamente.

Por que é importante monitorar clientes Kafka ?

Monitorar sua instância do Event Streams é crucial para assegurar a funcionalidade ideal e o funcionamento geral de seu pipeline de dados. O monitoramento de seus clientes Kafka ajuda a identificar sinais iniciais de falha do aplicativo, como alto uso de recursos, consumidores atrasados e gargalos. A identificação antecipada desses sinais de aviso permite uma resposta proativa a possíveis problemas que minimizam o tempo de inatividade e evitam qualquer interrupção das operações de negócios

Os clientes Kafka (produtores e consumidores) têm seu próprio conjunto de métricas para monitorar seu desempenho e funcionamento. Além disso, o serviço Event Streams suporta um rico conjunto de métricas produzidas pelo servidor. Para obter mais informações, consulte as métricas de serviço do Monitoramento Event Streams usando IBM Cloud Monitoring.

Métricas do cliente a serem monitoradas

Métricas do produtor

Métricas do produtor
Métrica Descrição
taxa de erro de registro Essa métrica mede o número médio por segundo de registros enviados que resultaram em erros. Um alto record-error-rate ou um aumento em record-error-rate pode indicar uma perda de dados ou dados não sendo processados conforme esperado. Todos esses efeitos podem comprometer a integridade dos dados que estão sendo processados e armazenados no Kafka. O monitoramento dessa métrica ajuda a assegurar que os dados enviados pelos produtores sejam registrados com precisão e confiabilidade em seus tópicos do Kafka.
request-latency-avg Essa é a latência média para cada solicitação de produção, em ms Um aumento na latência impacta o desempenho e pode sinalizar um problema Medir a métrica request-latency-avg pode ajudar a identificar gargalos em sua instância. Para muitos aplicativos, a baixa latência é crucial para assegurar uma experiência do usuário de alta qualidade e um aumento no request-latency-avg pode indicar que você está atingindo os limites de sua instância provisionado É possível corrigir o problema alterando as configurações do produtor, por exemplo, por meio do envio em lote ou do ajuste de escala de seu plano para otimizar o desempenho
taxa de bytes O número médio de bytes enviados por segundo para um tópico é uma medida de seu rendimento. Se você transmitir dados regularmente, uma queda no rendimento poderá indicar uma anormalidade em sua instância do Kafka O plano corporativo Event Streams é iniciado a partir de 150 MB por segundo divididos um a um entre o ingresso e o egresso e é importante saber quanto disso você está consumindo para um planejamento de capacidade efetivo. Não vá acima de dois terços do rendimento máximo, para considerar o possível impacto de ações operacionais, como atualizações internas ou modos de falha (por exemplo, a perda de uma zona de disponibilidade).

Métricas do consumidor.

Métricas de consumo
Métrica Descrição
fetch-rate fetch-tamanho-médio O número de solicitações de busca por segundo (fetch-rate) e o número médio de bytes buscados por solicitação (fetch-size-avg) são indicadores-chave para o desempenho de seus consumidores do Kafka. Um alto fetch-rate pode sinalizar ineficácia, especialmente em um pequeno número de mensagens, porque isso significa dados insuficientes, ou possivelmente nenhum dado está sendo recebido a cada vez O fetch-rate e o fetch-size-avg são afetados por três configurações: fetch.min.bytes, fetch.max.bytes e fetch.max.wait.ms. Ajuste essas configurações para atingir a latência geral desejada, enquanto minimiza o número de solicitações de busca e potencialmente a carga na CPU do broker. O monitoramento e a otimização de ambas as métricas asseguram que você esteja processando dados de forma eficiente para cargas de trabalho atuais e futuras.
commit-latency-avg Essa métrica mede o tempo médio entre um registro confirmado sendo enviado e a resposta de confirmação sendo recebida. Semelhante ao request-latency-avg como uma métrica de produtor, um commit-latency-avg estável significa que suas confirmações de deslocamento acontecem em tempo hábil. Uma latência de alta confirmação pode indicar problemas no consumidor que o impedem de confirmar deslocamentos rapidamente, o que afeta diretamente a confiabilidade do processamento de dados. Isso pode levar ao processamento duplicado de mensagens se um consumidor tiver que reiniciar e reprocessar mensagens de um deslocamento não confirmado anteriormente. Uma latência de confirmação alta também significa gastar mais tempo em operações administrativas do que o processamento de mensagem real Esse problema pode levar a listas não processadas de mensagens aguardando para serem processadas, especialmente em ambientes de alto volume.
bytes-taxa consumida Esta é uma métrica de busca do consumidor que mede o número médio de bytes consumidos por segundo.. Semelhante à métrica byte-rate como uma métrica de produtor, essa deve ser uma métrica estável e esperada.. Uma mudança repentina na tendência esperada do bytes-consumed-rate pode representar um problema com seus aplicativos.. Uma taxa baixa poderia ser um sinal de eficiência em buscas de dados ou recursos provisionados em excesso Uma taxa mais alta pode sobrecarregar a capacidade de processamento dos consumidores e, portanto, requerer ajuste de escala, criar mais consumidores para equilibrar a carga ou alterar configurações do consumidor, como tamanhos de busca.
rebalanceamento-taxa-por-hora O número de rebalanceamentos de grupo em que participaram por hora O rebalanceamento ocorre toda vez que há um novo consumidor ou quando um consumidor sai do grupo e causa um atraso no processamento Isso acontece porque as partições são redesignadas, o que torna os consumidores do Kafka menos eficientes se houver muitos rebalanceamentos por hora. Uma taxa de rebalanceamento mais alta por hora pode ser causada por configurações incorretas levando ao comportamento instável do consumidor. Esse ato de rebalanceamento poderia causar um aumento na latência e poderia resultar em travamento de aplicativos Assegure-se de que seus grupos de consumidores sejam estáveis rastreando um rebalance-rate-per-hour baixo e estável.