Surveiller les applications clientes Kafka

Ce document explique comment surveiller l'état des clients qui produisent ou consomment des données dans votre cluster Managed Service pour Apache Kafka.

Il est important de surveiller les applications clientes dans le cadre de votre stratégie globale de fiabilité. Les métriques telles que le débit, les taux d'erreur et le décalage des consommateurs peuvent vous indiquer si les applications clientes rencontrent des problèmes de fiabilité. Les problèmes peuvent être dus à la configuration du client, à une répartition inégale des clés entre les partitions ou à des problèmes de cluster qui n'affectent qu'une partition spécifique.

Métriques côté serveur

Bien qu'il soit utile de surveiller directement le comportement des clients, les métriques côté serveur ne nécessitent aucune instrumentation supplémentaire et peuvent vous aider à détecter les problèmes côté client qui affectent la fiabilité.

Les métriques côté serveur sont particulièrement utiles pour détecter les déséquilibres de charge entre les courtiers (courtiers actifs) et les écarts dans les opérations normales, tels que les pics de latence.

Débit

Surveillez les métriques de débit suivantes et comparez-les à votre débit attendu :

  • Taux de messages, par courtier et par sujet.
  • Débit en octets, par agent et par thème.
  • Taux de demandes. Un client mal configuré peut inonder les courtiers avec un grand nombre de petites requêtes (0 à 1 000 octets par requête), ce qui réduit le débit.
  • Latence des requêtes. Les pics de latence des requêtes de producteur peuvent indiquer une charge déséquilibrée ou un problème de configuration du client.

Kafka propose des métriques de débit par sujet et pour le cluster. Ces métriques n'ont pas toujours les mêmes valeurs lorsqu'elles sont agrégées pour tous les thèmes. Utilisez une métrique agrégée pour la surveillance et les alertes de haut niveau, et examinez les métriques par sujet lorsque vous résolvez des problèmes de débit. Isoler les problèmes pour des courtiers spécifiques

Taux d'erreur des requêtes

La métrique topic_error_count suit le nombre de requêtes de récupération et de production ayant échoué côté serveur. Toutefois, certaines classes d'erreurs ne sont pas reflétées dans cette métrique. Exemple :

  • Des paramètres d'autorisation mal configurés peuvent empêcher un client de produire un sujet, sans que l'erreur n'apparaisse dans cette métrique.

  • Les défaillances de cluster peuvent empêcher un courtier de répondre aux requêtes.

C'est pourquoi vous devez également surveiller les erreurs côté client, y compris les erreurs d'expiration du délai de requête.

Délai avant conversion

Le décalage du consommateur mesure le retard d'un client consommateur par rapport à un décalage spécifique. L'agrégation de cette métrique par thème, partition et agent est utile pour déterminer si le décalage est dû à des agents ou des partitions spécifiques.

Envisagez de créer une alerte basée sur le décalage maximal pour le sous-ensemble de thèmes critiques pour votre charge de travail.

Requêtes personnalisées pour les tableaux de bord

Nous vous recommandons de créer des tableaux de bord et des alertes personnalisés pour surveiller ces signaux. Le tableau suivant présente les requêtes Prometheus Query Language (PromQL) que vous pouvez utiliser pour surveiller l'état du client.

SignalRequête PromQL
Débit : taux de messages par courtier 
sum by (resource_container, location, cluster_id, broker_index) (
  rate(
    {
      "managedkafka.googleapis.com/message_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Débit : taux de messages par courtier et par sujet, pour les cinq sujets les plus importants 
topk(5,
  sum by (resource_container, location, cluster_id, broker_index, topic_id) (
    rate(
      {
        "managedkafka.googleapis.com/message_in_count",
        monitored_resource="managedkafka.googleapis.com/Topic"
      }[${__interval}]
    )
  )
)
Débit : bande passante par sujet et par agent 
sum by (resource_container, location, cluster_id, broker_index, topic_id) (
  rate(
    {
      "managedkafka.googleapis.com/byte_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Taux de requêtes 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/request_count",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "request"="Produce"
    }[${__interval}]
  )
)
Taux de demandes, totaux du cluster 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_request_count",
      monitored_resource="managedkafka.googleapis.com/Topic",
      "request"="Produce"
    }[${__interval}]
  )
)
Latence de la requête 
sum by (resource_container, location, cluster_id, broker_index, request) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/request_latencies",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "percentile"="95",
      "request"="Produce"
    }[${__interval}]
  )
)
Nombre d'erreurs de requête 
sum by (resource_container, location, cluster_id, broker_index, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_error_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Délai de consommation : 5 principales partitions par délai de consommation 
topk(5,
  max by (resource_container, location, cluster_id, broker_index, topic_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/consumer_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartition"
      }[${__interval}]
    )
  )
)

Métriques côté client

Il arrive que les problèmes liés au client n'apparaissent pas dans les métriques du serveur. Exemple :

  • Si l'authentification ou la mise en réseau sont mal configurées, des messages peuvent s'accumuler dans les files d'attente internes du client. Lorsque les requêtes expirent, les messages sont remis en file d'attente et réessayés.

  • Si le contrôle de flux est mal configuré, un client peut générer plus de messages que le nombre de threads alloué peut en envoyer. Bien que le débit puisse être constant, un nombre croissant de requêtes en attente expirent avant de pouvoir être envoyées.

Si vos clients s'exécutent sur Compute Engine, Google Kubernetes Engine ou Cloud Run, vous pouvez utiliser des métriques basées sur les journaux dans Cloud Monitoring pour détecter les taux d'erreur élevés dans les journaux. Toutefois, certains clients Kafka masquent les exceptions qui entraînent des tentatives prolongées, sauf si vous configurez des niveaux de journalisation plus élevés. Vous devez donc également surveiller l'augmentation de la latence des requêtes.

Les clients Java exposent de nombreuses métriques via les extensions de gestion Java (JMX). Pour en savoir plus, consultez la section Surveillance dans la documentation Apache Kafka. Si possible, privilégiez l'instrumentation de vos clients pour qu'ils signalent les métriques suivantes :

  • Taux d'erreur des requêtes (kafka.producer:type=producer-metrics,client-id="{client-id}")
  • Latence moyenne des requêtes (kafka.producer:type=producer-metrics,client-id="{client-id}")

Si possible, envoyez ces métriques à une solution de surveillance. Si vous pouvez vous connecter aux ports JMX des machines qui exécutent les instances clientes, vous pouvez également lire ces métriques de manière interactive.

Mesures d'atténuation

Si vous rencontrez des problèmes dans vos applications clientes, envisagez les atténuations suivantes :

  • Recherchez une charge déséquilibrée entre les courtiers (courtiers actifs). Assurez-vous que le rééquilibrage automatique est activé dans votre cluster.

  • Si le taux de demandes semble inhabituellement élevé, vérifiez si le client envoie un grand nombre de petites demandes. Vérifiez les configurations max.request.size et batch.size sur le producteur.

  • Vérifiez les configurations du client pour l'authentification, la mise en réseau et le contrôle du flux.

  • Une latence excessive pour tous les thèmes ou partitions d'un cluster peut indiquer que le cluster est surchargé et qu'il doit être mis à l'échelle.

  • Un décalage excessif sur tous les sujets ou partitions d'un courtier peut indiquer que celui-ci est surchargé. Essayez d'améliorer la distribution des clés ou de réattribuer des partitions à différents courtiers.

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