Monitorar a confiabilidade dos clusters do Kafka

Este documento descreve como monitorar um cluster do Serviço Gerenciado para Apache Kafka para garantir a confiabilidade das cargas de trabalho do Kafka.

Visão geral

Confiabilidade é a capacidade de um sistema de funcionar corretamente e de maneira consistente ao longo do tempo. Para cargas de trabalho baseadas no Kafka, a confiabilidade abrange os 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 muitas falhas comuns. Por exemplo, o serviço coloca réplicas em zonas diferentes 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 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 a sobrecarga de um cluster, monitore os seguintes indicadores. Crie alertas para notificar você se eles ficarem fora do intervalo recomendado por um período prolongado.

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

  • Utilização do disco do broker: verifique se a utilização do disco do broker permanece abaixo de 80%.

  • Tamanho do disco. Como um 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 sete 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 do disco à medida que você cria mais partições no cluster.

  • Contador 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 personalizado do Cloud Monitoring.

IndicadorConsulta do PromQL
Utilização de 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}]
)
Utilização 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 brokers

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 as partições balanceadas, considere ativar o rebalanceamento automático no escalonamento vertical do cluster.

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

IndicadorConsulta do PromQL
Contagens 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ção

A replicação de dados é fundamental para garantir que as 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ção:

  • Réplicas sincronizadas mínimas (ISRs, na sigla em inglês). Se uma partição tiver menos ISRs sincronizadas do que o mínimo configurado (min.insync.replicas), haverá um risco sério de perda de dados e disponibilidade. Normalmente, essa situação é causada por capacidade insuficiente em um ou mais brokers ou por falhas de infraestrutura.

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

    Durante uma reinicialização contínua, os brokers ficam indisponíveis à medida que são reiniciados, causando replicação insuficiente temporária. Essa situação é esperada e não requer intervenção.

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

IndicadorConsulta do PromQL
ISRs mínimas 
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}]
  )
)
Replicação insuficiente 
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