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é échappent au contrôle direct du 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 sujets, telles que la conservation des messages

Pour garantir un fonctionnement fiable, 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é.

Capacité du cluster

Pour éviter de surcharger un cluster, surveillez les signaux suivants. Créez des alertes pour vous avertir 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%.

  • 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}]
  )
)

Déséquilibre des partitions

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 courtier doit rester dans les 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 up 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

Réplication des partitions

La réplication des données est essentielle pour garantir que vos charges de travail sont tolérantes aux pannes. Dans un cluster sain, chaque partition d'un sujet comporte le nombre total 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 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 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 de RS 
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