Surveiller la fiabilité des clusters Kafka

Ce document explique comment surveiller un cluster Managed Service pour Apache Kafka afin de garantir la fiabilité de vos charges de travail Kafka.

Présentation

La fiabilité est la capacité d'un système à fonctionner correctement et de manière cohérente dans le temps. Pour les charges de travail basées sur Kafka, la fiabilité englobe à la fois les clusters Kafka eux-mêmes et les applications clientes qui produisent et consomment des messages.

Managed Service pour Apache Kafka est conçu pour tolérer et récupérer de nombreuses défaillances courantes. Par exemple, le service place des instances répliquées dans différentes zones pour assurer la tolérance aux pannes et redémarre automatiquement les agents qui échouent. Toutefois, d'autres facteurs qui affectent la fiabilité échappent au contrôle direct du service, tels que :

  • Configuration du client
  • Charge sur le cluster, y compris la charge moyenne et les pics
  • Nombre de partitions et d'instances répliquées
  • Configurations de sujet, telles que la conservation des messages

Pour garantir des opérations fiables, il est important de surveiller le cluster pour ces paramètres opérationnels et de les maintenir dans les plages recommandées. Les sections suivantes décrivent certaines métriques clés importantes pour la fiabilité.

Surveiller la capacité du cluster

Pour éviter de surcharger un cluster, surveillez les signaux suivants. Créez des alertes pour vous avertir s'ils sortent de la plage recommandée pendant une période prolongée.

  • Utilisation du processeur : essayez de maintenir l'utilisation du processeur en dessous de 80% sur tous les agents.

  • Utilisation du disque de l'agent : assurez-vous que l'utilisation du disque de l'agent reste inférieure à 80%.

  • Taille du disque : pour commencer, nous vous recommandons d'avoir au moins 2*(segment.bytes) par partition et par agent. En pratique, les exigences réelles en matière de disque sont souvent considérablement inférieures.

    Par défaut, un fichier de segment est fermé et déplacé vers un stockage distant au bout de sept jours. Il est courant que la plupart des partitions reçoivent moins de segment.bytes de données au cours de cette période, ce qui signifie que la plupart des partitions utilisent moins de segment.bytes d'espace disque. Avant d'augmenter la taille du disque, surveillez son utilisation lorsque vous créez d'autres partitions sur le cluster.

  • Nombre de partitions : essayez de maintenir moins de 4 000 partitions par agent et moins de 100 000 partitions par cluster.

Si votre cluster manque de capacité, envisagez les mesures d'atténuation suivantes :

Le tableau suivant présente les requêtes Prometheus Query Language (PromQL) pour ces métriques que vous pouvez ajouter à un tableau de bord Cloud Monitoring personnalisé.

SignalRequête Promql
Utilisation du processeur 
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}]
)
Utilisation du disque de l'agent 
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}]
)
Taille du segment par partition 
# 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}]
)
Partitions par agent 
max by (resource_container, location, cluster_id, broker_index) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Partitions par cluster 
max by (resource_container, location, cluster_id) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)

Surveiller l'équilibre des partitions entre les agents

Une charge inégale peut empêcher un cluster Kafka de traiter correctement les requêtes client. Le nombre de partitions attribuées à un seul agent doit rester à environ 10% du nombre moyen de partitions par agent. Recherchez les valeurs aberrantes dans cette métrique.

Pour maintenir l'équilibre des partitions, envisagez d'activer le rééquilibrage automatique lors de la mise à l'échelle de votre cluster.

Le tableau suivant présente les requêtes PromQL que vous pouvez utiliser pour surveiller les déséquilibres de partition.

SignalRequête Promql
Nombre de partitions par agent 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Déséquilibre de partition 
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

Surveiller la réplication des partitions

La réplication des données est essentielle pour garantir la tolérance aux pannes de vos charges de travail. Dans un cluster sain, chaque partition d'un sujet comporte le nombre complet d' instances répliquées, en fonction du facteur de réplication configuré pour le sujet.

Utilisez les signaux suivants pour surveiller la réplication des partitions :

  • Nombre d'instances répliquées synchronisées (ISR) inférieur au minimum : si une partition comporte moins d'ISR synchronisées que le minimum configuré (min.insync.replicas), il existe un risque sérieux de perte de données et de disponibilité. En règle générale, cette situation est due à une capacité insuffisante sur un ou plusieurs agents, ou à des défaillances d'infrastructure.

  • Partitions sous-répliquées : une partition est sous-répliquée lorsque le nombre d'instances répliquées synchronisées est inférieur au facteur de réplication. Si une partition reste sous-répliquée pendant des dizaines de minutes, il peut y avoir un problème avec les agents, la capacité de stockage ou autre chose.

    Lors d'un redémarrage progressif, les agents deviennent indisponibles lors de leur redémarrage, ce qui entraîne une sous-réplication temporaire. Cette situation est normale et ne nécessite aucune intervention.

Le tableau suivant présente les requêtes PromQL que vous pouvez utiliser pour surveiller la réplication.

SignalRequête Promql
Nombre d'ISR inférieur au minimum 
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}]
  )
)
Sous-réplication 
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}]
  )
)

Étape suivante