Surveillance du connecteur Kafka à l’aide des Java Management Extensions (JMX)

Cette rubrique décrit comment utiliser les Java Management Extensions (JMX) pour surveiller le connecteur Snowflake pour Kafka. Kafka Connect fournit des métriques JMX préconfigurées qui fournissent des informations sur le connecteur Kafka. Le connecteur Snowflake pour Kafka fournit plusieurs Managed Beans (MBeans) que vous pouvez utiliser pour ingérer des métriques sur l’environnement Kafka. Vous pouvez charger ces informations dans des outils tiers, notamment Prometheus et Grafana.

La fonction JMX est activée par défaut dans le connecteur. Pour désactiver JMX, définissez la propriété jmx sur false.

Important

Snowpipe prend en charge le connecteur Kafka version 1.6.0 et versions ultérieures.

Snowpipe Streaming prend en charge le connecteur Kafka version 2.1.0 et versions ultérieures.

Dans ce chapitre :

Configuration de JMX dans le connecteur Kafka

JMX est activé par défaut dans le connecteur Kafka de Snowflake. Pour activer JMX dans Kafka, effectuez ce qui suit :

  1. Activez JMX pour vous connecter à votre installation Kafka :

    • Pour établir des connexions JMX à une installation Kafka fonctionnant sur un serveur distant, définissez la variable d’environnement KAFKA_JMX_OPTS dans votre script de démarrage de Kafka Connect :

      export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote=true
    -Dcom.sun.management.jmxremote.authenticate=false
    -Dcom.sun.management.jmxremote.ssl=false
    -Djava.rmi.server.hostname=<ip_address>
    -Dcom.sun.management.jmxremote.port=<jmx_port>"
      Copy

      Où :

      • ip_address : spécifie l’adresse IP de votre installation Kafka Connect.

      • jmx_port : spécifie le port JMX sur lequel Kafka Connect écoute les connexions JMX.

    • Pour établir des connexions JMX à Kafka fonctionnant sur le même serveur, définissez la variable d’environnement JMX_PORT dans votre script de démarrage de Kafka :

      export JMX_PORT=<port_number>
      Copy

      Où port_number est le port JMX de votre installation Kafka.

  2. Redémarrez le connecteur Kafka.

Utilisation des Managed Beans du connecteur Kafka de Snowflake (MBeans)

JMX utilise MBeans pour représenter les objets de Kafka qu’il peut surveiller (par exemple, le nombre de threads, la charge du processeur, etc.) Le connecteur Kafka de Snowflake fournit des MBeans pour accéder aux objets gérés par le connecteur. Vous pouvez utiliser ces MBeans pour créer des tableaux de bord de surveillance.

Le format général du nom de l’objet MBean du connecteur Kafka est le suivant :

snowflake.kafka.connector:connector=connector_name,pipe=pipe_name,category=category_name,name=metric_name

Où :

  • connector=connector_name spécifie le nom du connecteur défini dans le fichier de configuration Kafka.

  • pipe=pipe_name spécifie l’objet Snowpipe utilisé pour ingérer les données. Le connecteur Kafka définit des objets Snowpipe pour chaque partition.

  • category=category_name spécifie la catégorie des MBean. Chaque catégorie contient un ensemble de métriques.

  • name=metric_name spécifie le nom de la métrique.

Les sections suivantes énumèrent les noms des catégories et des métriques fournis par le connecteur Kafka de Snowflake.

Catégorie : file-counts

Nom de la métrique

Type de données

Description

file-count-on-stage

long

Le nombre de fichiers actuellement sur une zone de préparation interne. Cette valeur est décrémentée après le début du processus de purge des fichiers. Cette propriété fournit une estimation du nombre de fichiers actuellement présents sur une zone de préparation interne.

file-count-on-ingestion

long

Le nombre de fichiers dans Snowpipe déterminé en appelant l”insertFiles API REST. Il y a actuellement une limitation de 5 000 pour les fichiers qui sont envoyés via une seule requête API REST. Il n’y a pas de relation univoque entre le nombre de fichiers et le nombre d’appels de l’API REST. Le nombre d’appels à l”insertFiles API REST peut être supérieur à cette valeur. La valeur de cette propriété est 0 s’il n’y a plus de fichiers à ingérer.

file-count-table-stage-ingestion-fail

long

Le nombre de fichiers de la zone de préparation de la table qui ont échoué à l’ingestion.

file-count-table-stage-broken-record

long

Le nombre de fichiers présents sur la zone de préparation de la table qui correspond à un décalage incorrect.

file-count-purged

long

Le nombre de fichiers purgés de la zone de préparation interne après que le statut d’ingestion a été déterminé.

Catégorie : offsets

Nom de la métrique

Type de données

Description

processed-offset

long

Un décalage se référant à l’enregistrement le plus récent envoyé dans le tampon en mémoire.

flushed-offset

long

Un décalage se référant à un enregistrement qui est évacué sur une zone de préparation interne après que le seuil de la mémoire tampon a été atteint. Le tampon peut atteindre son seuil par la durée, le nombre d’enregistrements ou la taille.

committed-offset

long

Un décalage se référant à un enregistrement qui a entraîné l’appel de l’API de pré-validation et qui a appelé l’API REST insertFiles de Snowpipe.

purged-offset

long

Un décalage se référant à un enregistrement qui est purgé de la zone de préparation interne. Ce nombre est la valeur du décalage le plus récent qui a été purgé de la zone de préparation interne.

Catégorie : buffer

Nom de la métrique

Type de données

Description

buffer-size-bytes

long

En fonction des seuils de la mémoire tampon, renvoie la taille de la mémoire tampon (en octets) avant qu’elle ne soit vidée vers une zone de préparation interne. Cette valeur peut être différente de la taille du fichier car les fichiers sont compressés lors de leur chargement dans une zone de préparation interne.

buffer-record-count

long

En fonction des seuils de la mémoire tampon, renvoie le nombre d’enregistrements Kafka mis en mémoire tampon avant que celle-ci ne soit vidée vers une zone de préparation interne.

Catégorie : latencies

Nom de la métrique

Type de données

Description

kafka-lag

long

La différence (en secondes) entre le moment où l’enregistrement est placé dans Kafka et le moment où l’enregistrement est récupéré dans Kafka Connect. Notez que cette valeur peut être nulle si la valeur n’a pas été définie dans un enregistrement.

commit-lag

long

La différence (en secondes) entre le moment où le fichier est téléchargé dans une zone de préparation interne et le moment où l”insertFiles API REST est appelée.

ingestion-lag

long

La différence (en secondes) entre le moment où un fichier est téléchargé vers une zone de préparation interne et le moment où le statut d’ingestion du fichier est signalé par le biais de l’API insertReport ou loadHistoryScan.
Langage: Français