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élai de consommation peuvent vous indiquer si les applications clientes rencontrent des problèmes de fiabilité. Ces problèmes peuvent être dus à la configuration du client, à une distribution 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 brokers (brokers actifs) et les écarts par rapport aux opérations normales, tels que les pics de latence.

Débit

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

  • Taux de messages, par broker et par sujet.
  • Débit en octets, par broker et par sujet.
  • Taux de requêtes. Un client mal configuré peut inonder les brokers avec un taux élevé 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 sujets. 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. Isolez les problèmes sur des brokers spécifiques.

Taux d'erreur des requêtes

La topic_error_count métrique suit le nombre de requêtes d'extraction et de production ayant échoué côté serveur. Cependant, 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 dans un sujet, sans que l'erreur n'apparaisse dans cette métrique.

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

Pour cette raison, vous devez également surveiller les erreurs côté client, y compris les erreurs de délai avant expiration des requêtes.

Délai de consommation

Le délai de consommation mesure le retard d'un client consommateur par rapport à un décalage particulier. L'agrégation de cette métrique par sujet, partition et broker est utile pour déterminer si le délai est dû à des brokers ou des partitions spécifiques.

Envisagez de créer une alerte basée sur le délai maximal pour le sous-ensemble de sujets essentiels à votre charge de travail.

Requêtes de tableau de bord personnalisé

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 du langage Prometheus Query (PromQL) que vous pouvez utiliser pour surveiller l'état du client.

SignalRequête Promql
Débit : taux de messages par broker 
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 broker 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 broker 
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 des requêtes 
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 : cinq premières 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

Parfois, 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, les 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 produire plus de messages que le nombre de threads alloué ne peut en envoyer. Bien que le débit puisse être cohérent, un backlog croissant de requêtes expire avant de pouvoir être envoyé.

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

Les clients Java exposent de nombreuses métriques via Java Management Extensions (JMX). Pour en savoir plus, consultez la section Surveillance de la documentation Apache Kafka. Si possible, donnez la priorité à 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}")

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

Stratégies d'atténuation

Si vous rencontrez des problèmes dans vos applications clientes, envisagez les stratégies d'atténuation suivantes :

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

  • Si le taux de demandes semble anormalement élevé, vérifiez si le client envoie un grand nombre de petites requêtes. 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 de flux.

  • Un délai excessif pour tous les sujets ou partitions d'un cluster peut indiquer que le cluster est surchargé et doit être mis à l'échelle.

  • Un délai excessif pour tous les sujets ou partitions d'un broker peut indiquer que le broker est surchargé. Essayez d'améliorer la distribution des clés ou de réattribuer des partitions à différents brokers.

Étape suivante