Monitorar a confiabilidade dos clusters do Kafka

Neste documento, descrevemos como monitorar um cluster do Serviço gerenciado para Apache Kafka para garantir a confiabilidade das suas cargas de trabalho do Kafka.

Visão geral

Confiabilidade é a capacidade de um sistema funcionar corretamente e de forma consistente ao longo do tempo. Para cargas de trabalho baseadas no Kafka, a confiabilidade abrange os próprios clusters do Kafka e os aplicativos cliente que produzem e consomem mensagens.

O Serviço Gerenciado para Apache Kafka foi projetado para tolerar e se recuperar de muitos erros comuns. Por exemplo, o serviço coloca réplicas em diferentes zonas para tolerância a falhas e reinicia automaticamente os brokers com falha. No entanto, outros fatores que afetam a confiabilidade estão fora do controle direto do serviço, como:

  • Configuração do cliente
  • Carga no cluster, incluindo carga média e picos
  • O número de partições e réplicas
  • Configurações de tópico, como retenção de mensagens

Para ter operações confiáveis, é importante monitorar o cluster para esses parâmetros operacionais e mantê-los dentro dos intervalos recomendados. As seções a seguir descrevem algumas métricas importantes para a confiabilidade.

Monitorar a capacidade do cluster

Para evitar sobrecarregar um cluster, monitore os seguintes indicadores. Crie alertas para receber notificações se eles ficarem fora do intervalo recomendado por um longo período.

  • Uso da CPU. Tente manter a utilização da CPU abaixo de 80% em todos os agentes.

  • Uso do disco do broker: verifique se o uso do disco do broker permanece abaixo de 80%.

  • Tamanho do disco. Como ponto de partida seguro, recomendamos ter pelo menos 2*(segment.bytes) por partição por broker. Na prática, os requisitos reais de disco costumam ser consideravelmente menores.

    Por padrão, um arquivo de segmento é fechado e movido para o armazenamento remoto após 7 dias. É comum que a maioria das partições receba menos de segment.bytes de dados durante esse período, o que significa que a maioria das partições usa menos de segment.bytes de espaço em disco. Antes de aumentar o tamanho do disco, monitore a utilização dele à medida que você cria mais partições no cluster.

  • Contagem de partições. Tente manter menos de 4.000 partições por broker e menos de 100.000 partições por cluster.

Se o cluster estiver com pouca capacidade, considere as seguintes mitigações:

A tabela a seguir mostra consultas da linguagem de consulta do Prometheus (PromQL) para essas métricas que podem ser adicionadas a um painel do Cloud Monitoring personalizado.

SinalConsulta PromQL
Uso da CPU 
rate(
  {
    "managedkafka.googleapis.com/cpu/core_usage_time",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/cpu/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
Uso do disco do broker 
max_over_time(
  {
    "managedkafka.googleapis.com/disk/used_bytes",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
Tamanho do segmento por partição 
# Assumes that segment files are 225 MiB. Check your cluster configuration.
2*225*(1024*1024) * max_over_time(
  {
    "managedkafka.googleapis.com/partitions",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
Partições por broker 
max by (resource_container, location, cluster_id, broker_index) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Partições por cluster 
max by (resource_container, location, cluster_id) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)

Monitorar o balanceamento de partições entre agentes

Uma carga desigual pode impedir que um cluster do Kafka atenda às solicitações do cliente corretamente. O número de partições atribuídas a um único broker precisa ficar dentro de cerca de 10% da contagem média de partições por broker. Procure outliers nessa métrica.

Para manter partições equilibradas, considere ativar o rebalanceamento automático no escalonamento vertical no cluster.

A tabela a seguir mostra consultas do PromQL que podem ser usadas para monitorar desequilíbrios de partição.

SinalConsulta PromQL
Contagem de partições por broker 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Desequilíbrio de partição 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
/ on (resource_container, location, cluster_id)
  group_left avg by (resource_container, location, cluster_id) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
) - 1

Monitorar a replicação de partições

A replicação de dados é fundamental para garantir que suas cargas de trabalho sejam tolerantes a falhas. Em um cluster íntegro, cada partição em um tópico tem o número total de réplicas, com base no fator de replicação configurado do tópico.

Use os seguintes indicadores para monitorar a replicação de partições:

  • Abaixo do número mínimo de réplicas sincronizadas (ISRs). Se uma partição tiver menos ISRs sincronizadas do que o mínimo configurado (min.insync.replicas), haverá um risco grave de perda de dados e disponibilidade. Normalmente, isso acontece devido à capacidade insuficiente em um ou mais brokers ou a falhas de infraestrutura.

  • Partições sub-replicadas. Uma partição está sub-replicada quando o número de réplicas sincronizadas fica abaixo do fator de replicação. Se uma partição permanecer com poucas réplicas por dezenas de minutos, pode haver um problema com os brokers, a capacidade de armazenamento ou algo mais.

    Durante uma reinicialização gradual, os agentes ficam indisponíveis à medida que são reiniciados, causando uma subreplicação temporária. Essa situação é esperada e não exige intervenção.

A tabela a seguir mostra consultas do PromQL que podem ser usadas para monitorar a replicação.

SinalConsulta PromQL
Abaixo do mínimo de ISRs 
max by (
  resource_container,
  location,
  cluster_id
) (
  max_over_time(
    {
      "managedkafka.googleapis.com/broker/under_min_isr_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Em replicação 
max by (
  resource_container,
  location,
  cluster_id
) (
  min_over_time(
    {
      "managedkafka.googleapis.com/broker/under_replicated_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[10m:${__interval}]
  )
)

A seguir

Apache Kafka® é uma marca registrada da The Apache Software Foundation ou afiliadas nos Estados Unidos e/ou em outros países.