Apache Kafka se destaca como um armazenamento de eventos de código aberto e plataforma de processamento de fluxo amplamente reconhecido. Ele evoluiu para o padrão de fato para streaming de dados, já que mais de 80% das empresas Fortune 500 o utilizam. Todos os principais provedores de nuvem fornecem serviços gerenciados de streaming de dados para atender a essa demanda crescente.
Uma das principais vantagens de optar pelos serviços gerenciados do Kafka é a delegação de responsabilidade pelas métricas operacionais e de corretagem, permitindo que os usuários se concentrem apenas nas métricas específicas das aplicações. Neste artigo, o Gerente de Produto Uche Nwankwo fornece orientação sobre um conjunto de métricas de produtores e consumidores que os clientes devem monitorar para obter o desempenho ideal.
Com o Kafka, o monitoramento normalmente envolve diversas métricas relacionadas a tópicos, partições, corretores e grupos de consumidores. As métricas padrão do Kafka incluem informações sobre taxa de transferência, latência, replicação e uso de disco. Consulte a documentação do Kafka e as ferramentas de monitoramento relevantes para compreender as métricas específicas disponíveis para sua versão do Kafka e como interpretá-las de forma eficaz.
Por que é importante monitorar os clientes Kafka?
Monitorar sua instância do IBM® Event Streams for IBM Cloud® é crucial para garantir a funcionalidade ideal e o funcionamento geral do seu pipeline de dados. Monitorar seus clientes Kafka ajuda a identificar sinais precoces de falha no aplicativo, como alto uso de recursos, consumidores atrasados e gargalos. A identificação precoce desses sinais de alerta permite uma resposta proativa a possíveis problemas que minimizam o tempo de inatividade e evitam qualquer interrupção nas operações comerciais.
Os clientes Kafka (produtores e consumidores) têm seu próprio conjunto de métricas para monitorar seu desempenho e saúde. Além disso, o serviço Event Streams oferece suporte a um rico conjunto de métricas produzidas pelo servidor. Para obter mais informações, consulte Monitorando métricas do Event Streams usando o IBM Cloud Monitoring.
Métricas do cliente para monitorar
Métricas do produtor
MetricDescriptionRecord-error-rateEssa métrica mede o número médio por segundo de registros enviados que resultaram em erros. Uma alta (ou um aumento) na taxa de erros de registro pode indicar uma perda de dados ou que os dados não estão sendo processados conforme o esperado. Todos esses efeitos podem comprometer a integridade dos dados que você está processando e armazenando no Kafka. O monitoramento dessa métrica ajuda a garantir que os dados enviados pelos produtores sejam registrados de maneira precisa e confiável em seus tópicos Kafka.Request-latency-avgEsta é a latência média para cada solicitação de produção em ms. Um aumento na latência afeta 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 garantir uma experiência de usuário de alta qualidade e um aumento na média de latência de solicitação pode indicar que você está atingindo os limites da sua instância provisionada. Você pode corrigir o problema alterando as configurações do produtor, por exemplo, agrupando em lote ou dimensionando 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 sua taxa de transferência. Se você transmitir dados regularmente, uma queda na taxa de transferência poderá indicar uma anomalia na sua instância do Kafka. O plano Event Streams Enterprise começa com 150 MB por segundo divididos individualmente entre entrada e saída, e é importante saber quanto disso você está consumindo para um planejamento de capacidade eficaz. Não ultrapasse dois terços do rendimento máximo, para ter em conta 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).
Role para ver a tabela completa
Tabela 1. Métricas do Produtor
Métricas do consumidor
MetricDescriptionFetch-ratefetch-size-avgO número de solicitações de busca por segundo (taxa de busca) e o número médio de bytes buscados por solicitação (tamanho de busca média) são indicadores-chave do desempenho de seus consumidores Kafka. Uma taxa de busca alta pode sinalizar ineficiência, especialmente em um pequeno número de mensagens, pois significa que dados insuficientes (possivelmente nenhum) estão sendo recebidos a cada vez. A taxa de busca e a média de tamanho de busca são afetadas 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 e, ao mesmo tempo, minimizar o número de solicitações de busca e, potencialmente, a carga na CPU do corretor. Monitorar e otimizar ambas as métricas garante que você esteja processando dados com eficiência para cargas de trabalho atuais e futuras.Commit-latency-avgEssa métrica mede o tempo médio entre o envio de um registro confirmado e o recebimento da resposta de confirmação. Semelhante à request-latency-avg como métrica do produtor, um commit-latency-avg estável significa que seus commits de compensação acontecem em tempo hábil. Uma latência de confirmação alta pode indicar problemas no consumidor que o impedem de cometer compensações rapidamente, o que impacta diretamente a confiabilidade do processamento de dados. Isso poderá levar ao processamento duplicado de mensagens se um consumidor precisar reiniciar e reprocessar mensagens de um deslocamento não confirmado anteriormente. Uma latência de alta confirmação também significa gastar mais tempo em operações administrativas do que no processamento real de mensagens. Esse problema pode levar a atrasos de mensagens aguardando processamento, especialmente em ambientes de alto volume.Taxa de bytes consumidosEsta é uma métrica de busca do consumidor que mede o número médio de bytes consumidos por segundo. Semelhante à taxa de bytes como métrica do produtor, esta deve ser uma métrica estável e esperada. Uma mudança repentina na tendência esperada da taxa de bytes consumidos pode representar um problema com seus aplicativos. Uma taxa baixa pode ser um sinal de eficiência na busca de dados ou de recursos superprovisionados. Uma taxa mais alta pode sobrecarregar a capacidade de processamento dos consumidores e, portanto, exigir escalonamento, criando mais consumidores para equilibrar a carga ou alterar as configurações do consumidor, como tamanhos de busca. Taxa de rebalanceamento por horaO número de rebalanceamentos de grupo participados por hora. O reequilíbrio ocorre sempre que há um novo consumidor ou quando um consumidor sai do grupo e causa atraso no processamento. Isso acontece porque as partições são reatribuídas, tornando os consumidores Kafka menos eficientes se houver muitos rebalanceamentos por hora. Uma taxa de reequilíbrio mais alta por hora pode ser causada por configurações incorretas que levam a um comportamento instável do consumidor. Esse ato de reequilíbrio pode causar um aumento na latência e resultar na falha dos aplicativos. Garanta que seus grupos de consumidores estejam estáveis monitorando uma taxa de rebalanceamento por hora baixa e estável.
Role para ver a tabela completa
Tabela 2. Métricas do consumidor
As métricas devem abranger uma ampla variedade de aplicações e casos de uso. Os Event Streams no IBM Cloud fornecem um rico conjunto de métricas que estão documentadas aqui e fornecerão insights úteis adicionais dependendo do domínio do seu aplicativo. Dê o próximo passo. Saiba mais sobre Event Streams para IBM Cloud.
Qual é o próximo?
Agora você tem conhecimento sobre os clientes Kafka essenciais para monitorar. Você está convidado a colocar esses pontos em prática e experimentar a oferta Kafka totalmente gerenciada na IBM Cloud. Para quaisquer desafios de configuração, consulte o Guia de primeiros passos e as Perguntas frequentes.
Saiba mais sobre o Kafka e seus casos de uso Provisione uma instância do Event Streams no IBM Cloud
Esse artigo foi útil?
SimNão
Gerente de produto, fluxos de eventos na IBM Cloud
