Surveiller la fiabilité des clusters Kafka

Ce document explique comment surveiller un cluster Managed Service pour Apache Kafka afin d'assurer 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 au fil du 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 de nombreuses défaillances courantes et s'en remettre. Par exemple, le service place des répliques dans différentes zones pour la tolérance aux pannes et redémarre automatiquement les courtiers qui échouent. Toutefois, d'autres facteurs qui affectent la fiabilité ne sont pas directement contrôlés par le service, par exemple :

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

Pour garantir des opérations fiables, il est important de surveiller ces paramètres opérationnels du cluster 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 être averti si elles 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 brokers.

  • 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 courtier. En pratique, les exigences réelles en termes d'espace disque sont souvent considérablement inférieures.

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

  • Nombre de partitions : Essayez de maintenir moins de 4 000 partitions par courtier et moins de 100 000 partitions par cluster.

Si la capacité de votre cluster est faible, 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 du courtier 
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 courtiers

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

Pour maintenir des partitions équilibrées, envisagez d'activer le rééquilibrage automatique lors du scaling à la hausse dans 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 courtier 
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 des partitions 
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 de réplicas, 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és que le minimum configuré (min.insync.replicas), le risque de perte de données et de disponibilité est élevé. Cette situation est généralement due à une capacité insuffisante sur un ou plusieurs courtiers, ou à des défaillances d'infrastructure.

  • Partitions sous-répliquées : Une partition est sous-répliquée lorsque le nombre de répliques 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 courtiers, la capacité de stockage ou autre chose.

    Lors d'un redémarrage progressif, les courtiers deviennent indisponibles lorsqu'ils sont redémarrés, 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
Sous le nombre minimal d'ISR 
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}]
  )
)

Étapes suivantes

Apache Kafka® est une marque déposée d'Apache Software Foundation ou de ses sociétés affiliées aux États-Unis et/ou dans d'autres pays.