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 du consommateur 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 du client, 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 agents (agents 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 agent et par sujet.
  • Débit en octets, par agent et par sujet.
  • Taux de demandes. Un client mal configuré peut inonder les agents 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 du 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 liés à des agents 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. 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 un sujet, sans que l'erreur n'apparaisse dans cette métrique.

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

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

Délai de consommation

Le décalage du client mesure l'écart entre un client consommateur et un décalage particulier. L'agrégation de cette métrique par sujet, 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élai maximal pour le sous-ensemble de sujets essentiels à votre charge de travail.

Requêtes de tableau de bord personnalisées

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

SignalRequête PromQL
Débit : taux de messages par agent 
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 agent et par sujet, pour les cinq sujets les plus volumineux 
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 du consommateur : 5 principales partitions par délai d'offset 
topk(5,
  max by (resource_container, location, cluster_id, topic_id, partition_index) (
    max_over_time(
      {
        "managedkafka.googleapis.com/offset_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup"
      }[${__interval}]
    )
  )
)
Retard du consommateur : 5 principaux groupes de consommateurs par retard d'offset 
topk(5,
  max by (resource_container, location, cluster_id, consumer_group_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/offset_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup"
      }[${__interval}]
    )
  )
)

Métriques côté client

Il arrive que les problèmes côté client n'apparaissent pas dans les métriques côté 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és ne 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 des 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 les extensions de gestion Java (JMX). Pour en savoir plus, consultez la section Surveillance dans la documentation Apache Kafka. Si possible, priorisez 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 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 solutions suivantes :

  • Recherchez une charge déséquilibrée entre les agents (agents surchargés). 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 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 de flux.

  • Un décalage excessif sur l'ensemble des thèmes ou des 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 agent peut indiquer que l'agent est surchargé. Essayez d'améliorer la distribution des clés ou de réattribuer des partitions à différents agents.

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