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 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é.

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%.

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

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 agent doit rester à environ 10% du nombre moyen de partitions par agent. Recherchez les valeurs aberrantes dans cette métrique.

Pour maintenir des partitions équilibrées, 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 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 la tolérance aux pannes de vos charges de travail. Dans un cluster sain, chaque partition d'un sujet comporte le nombre total d' instances répliquées, en fonction du facteur de réplication configuré du 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