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 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 instances dupliquées dans différentes zones pour assurer la tolérance aux pannes et redémarre automatiquement les agents qui échouent. Cependant, 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
  • Le nombre de partitions et d'instances répliquées
  • Configurations de sujet, 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é.

Surveiller la capacité des clusters

Pour éviter de surcharger un cluster, surveillez les signaux suivants. Créez des alertes pour être averti si elles se situent en dehors 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 en toute sécurité, nous vous recommandons d'avoir au moins 2*(segment.bytes) par partition et par agent. En pratique, les besoins réels en espace disque sont souvent considérablement inférieurs.

    Par défaut, un fichier de segment est fermé et déplacé vers un espace de 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 l'utilisation du disque à mesure que vous créez des 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 solutions suivantes :

Le tableau suivant présente les requêtes PromQL (Prometheus Query Language) 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 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}]
)
Taille de 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 diffuser correctement les requêtes des clients. Le nombre de partitions attribuées à un seul agent doit rester dans une limite d'environ 10 % du nombre moyen de partitions par agent. Recherchez les anomalies dans cette métrique.

Pour maintenir l'équilibre des partitions, 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 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

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 opérationnel, chaque partition d'un sujet possède le nombre total 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 inférieur au minimum. Si une partition comporte moins d'ISR synchronisés 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 de l'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 plusieurs 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 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
Nombre d'ISR inférieur au minimum requis 
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}]
  )
)

Surveiller le quota de demandes d'autorisation

Lorsqu'un client se connecte à un cluster, l'autorisation de la connexion est comptabilisée dans le quota Requêtes d'authentification de connexion au cluster par minute, par projet et par région. Tous les clusters d'un projet et d'une région partagent ce quota. S'il est dépassé, les nouvelles connexions client sont bloquées. Essayez de maintenir l'utilisation des quotas en dessous de 80 % et créez des alertes pour vous avertir si l'utilisation reste élevée.

Si l'utilisation du quota est élevée, envisagez les mesures d'atténuation suivantes :

  • Réduisez la fréquence à laquelle les clients créent de nouvelles connexions inutiles. Par exemple, configurez vos clients pour qu'ils utilisent un intervalle exponentiel entre les tentatives en cas d'erreurs de production et de consommation, consolidez les instances clientes le cas échéant et réutilisez les connexions existantes.

  • Demandez une augmentation de quota. Pour en savoir plus, consultez la page Quotas et limites.

Le tableau suivant présente une requête PromQL que vous pouvez utiliser pour surveiller les trois principales utilisations de quota de requêtes d'autorisation par projet et par région.

SignalRequête PromQL
Top 3 des utilisations de quota de requêtes d'autorisation par projet et par région 
topk(3,
  sum by (project_id, location) (
    rate(
      {
        "serviceruntime.googleapis.com/quota/rate/net_usage",
        monitored_resource="consumer_quota",
        service="managedkafka.googleapis.com",
        quota_metric="managedkafka.googleapis.com/cluster_authenticate_requests"
      }[${__interval}]
    )
  )
  / (
    min by (project_id, location) (
      min_over_time(
        {
          "serviceruntime.googleapis.com/quota/limit",
          monitored_resource="consumer_quota",
          service="managedkafka.googleapis.com",
          quota_metric="managedkafka.googleapis.com/cluster_authenticate_requests",
          limit_name="ClusterAuthPerMinutePerProjectPerRegion"
        }[${__interval}]
      )
    )
    / 60
  )
)

Étapes suivantes

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