Métriques - Realtime Compute for Apache Flink - Centre de documentation Alibaba Cloud

Cette rubrique décrit les métriques de Flink managé.

Notes

Écarts de données entre CloudMonitor et la console Flink

Différences dans les dimensions affichées La console Flink utilise des requêtes PromQL pour afficher uniquement la latence maximale. Dans les scénarios de calcul en temps réel, la latence moyenne peut masquer des problèmes graves tels qu'un déséquilibre de charge ou des blocages sur une seule partition. Par conséquent, seule la latence maximale fournit des informations opérationnelles pertinentes.
Écarts de valeurs CloudMonitor utilise un mécanisme de pré-agrégation pour calculer les métriques. La valeur « maximale » dans CloudMonitor peut différer légèrement de la valeur en temps réel dans la console Flink en raison de différences dans les fenêtres d'agrégation, les horodatages d'échantillonnage ou la logique de calcul. Pour le dépannage, utilisez les données de la console Flink comme référence fiable.

Latence des données et configuration du watermark

Logique de calcul de la latence La métrique de surveillance actuelle Emit Delay est calculée en fonction de l'heure de l'événement, selon la formule suivante :

Délai = Heure système actuelle - Champ d'heure logique dans l'enregistrement de données (par exemple, PriceData.time)

Cela signifie que la métrique reflète la fraîcheur des données, et non la vitesse de traitement du système. Cette métrique est élevée lorsque les données source sont anciennes ou lorsque le système suspend sa sortie pour aligner les watermarks.
Recommandations

Scénario 1 : Votre logique métier repose sur les watermarks pour garantir l'exactitude, mais les données source sont anciennes
- Situations typiques :
  - La livraison des données en amont est intrinsèquement retardée (par exemple, signalement lent des événements).
  - Vous effectuez un remplissage rétroactif pour traiter les données d'une journée précédente.
  - La logique métier nécessite des watermarks pour gérer les événements hors ordre, ils ne peuvent donc pas être désactivés.
- Phénomène : Les alertes de surveillance indiquent une latence élevée, mais le groupe de consommateurs Kafka n'affiche aucun retard (lag ≈ 0) et la charge CPU est faible.
- Recommandations :
  1. Ignorez cette métrique de latence : Dans ce cas, un délai élevé est attendu car il reflète l'ancienneté des données. Il n'indique pas une défaillance du système.
  2. Basculez vers une autre métrique : Surveillez plutôt le retard du consommateur Kafka. Si le retard du consommateur n'augmente pas continuellement, le système dispose d'une capacité de traitement suffisante et ne nécessite aucune intervention.
Scénario 2 : Vous exigez une faible latence et pouvez tolérer des événements légèrement hors ordre ou une perte de données
- Situations typiques :
  - Pour des applications telles que les tableaux de bord grand écran ou le contrôle des risques en temps réel, l'attente induite par le watermark ralentit la sortie.
  - La logique métier se soucie davantage du moment où les données sont reçues (heure de traitement) que de l'horodatage contenu dans l'enregistrement de données (heure de l'événement).
- Phénomène : Le flux de données est en temps réel, mais parce que le watermark est configuré avec une grande fenêtre de tolérance (par exemple, une autorisation de retard de 10 secondes), la sortie est retardée de 10 secondes.
- Recommandations :
  1. Supprimez ou désactivez les watermarks : Basculez vers l'utilisation de l'heure de traitement pour les calculs, ou définissez le seuil d'attente du watermark à 0.
  2. Résultat attendu : La métrique de latence diminuera considérablement, se rapprochant du temps de traitement réel. Les données sont traitées dès leur arrivée, sans attendre l'alignement.

Caractéristiques des métriques

Les métriques reflètent uniquement l'état actuel d'un composant et sont insuffisantes pour déterminer la cause racine d'un problème. Pour un diagnostic complet, utilisez toujours le moniteur de contre-pression de l'interface utilisateur Flink et d'autres outils.

1. Contre-pression de l'opérateur

Symptôme : Les opérateurs en aval ne peuvent pas traiter les données assez rapidement, ce qui pousse la source à réduire son taux d'émission.

Comment identifier : Utilisez le moniteur de contre-pression de l'interface utilisateur Flink pour identifier ce problème.
Caractéristiques des métriques :
- sourceIdleTime augmente périodiquement.
- currentFetchEventTimeLag et currentEmitEventTimeLag augmentent continuellement.
- Cas extrême : Si un opérateur est complètement bloqué, sourceIdleTime augmentera continuellement.

2. Goulot d'étranglement des performances de la source

Symptôme : La source lit à sa vitesse maximale mais ne peut pas satisfaire les demandes de traitement des données.

Comment identifier : Aucune contre-pression n'est détectée dans la tâche.
Caractéristiques des métriques :
- sourceIdleTime reste à une valeur très faible (indiquant que la source fonctionne à pleine capacité).
- currentFetchEventTimeLag et currentEmitEventTimeLag sont similaires et restent élevés.

3. Déséquilibre de charge ou partitions vides

Symptôme : La distribution des données est inégale entre les partitions Kafka en amont, ou certaines partitions sont vides.

Comment identifier : Comparez les métriques entre différentes sous-tâches source.
Caractéristiques des métriques :
- Le sourceIdleTime d'une sous-tâche source spécifique est significativement plus élevé que celui des autres, indiquant que cette instance parallèle est inactive.

4. Latence des données

Symptôme : La latence globale de la tâche est élevée. Vous devez déterminer si le goulot d'étranglement provient de la source ou d'un système externe.

Comment identifier : Analysez conjointement le temps d'inactivité, la différence entre les métriques de retard et la taille de la file d'attente.
Caractéristiques des métriques :
- **sourceIdleTime élevé : Cela indique que la source est inactive, ce qui signifie généralement que le taux de production de données du système externe** est faible, et non que Flink traite lentement.
- Analyse de la différence de retard : Comparez la différence entre currentEmitEventTimeLag et currentFetchEventTimeLag. Cette différence représente le temps passé par les données au sein de l'opérateur source :
  - Faible différence (valeurs de métriques proches) : Cela indique une capacité de récupération insuffisante. Le goulot d'étranglement est généralement la bande passante des E/S réseau ou un parallélisme source insuffisant.
  - Forte différence : Cela indique une capacité de traitement insuffisante. Le goulot d'étranglement est généralement une analyse inefficace des données ou une contre-pression des opérateurs en aval.
- **pendingRecords (si pris en charge par le connecteur) : Cette métrique reflète directement la file d'attente externe**. Une valeur plus élevée indique une accumulation de données plus sévère dans le système externe.

Aperçu

Métrique	Description	Détails	Unité	Connecteurs pris en charge
Nombre de redémarrages	Le nombre de fois où le déploiement a redémarré après une erreur.	Le nombre de fois où le déploiement a redémarré en raison d'une erreur. Cette métrique exclut les redémarrages causés par un basculement JobManager (JM). Utilisez cette métrique pour surveiller la disponibilité et l'état du déploiement.	Compte	S.O.
Retard actuel de l'heure d'émission de l'événement	La latence de traitement des données.	Une valeur élevée indique une latence dans la récupération ou le traitement des données.	millisecondes (ms)	Kafka ApsaraMQ for RocketMQ Simple Log Service DataHub Postgres Change Data Capture (CDC) Hologres (Binlog Source)
Retard actuel de l'heure de récupération de l'événement	La latence de récupération des données depuis le système en amont.	Une valeur élevée indique une latence de récupération des données. Vérifiez vos E/S réseau et les systèmes en amont. La comparaison de cette métrique avec `currentEmitEventTimeLag` vous aide à analyser la capacité de traitement de la source. La différence entre les deux représente le temps passé par les données dans l'opérateur source. Si les deux retards sont très proches, cela suggère que la source n'a pas une capacité suffisante pour extraire les données du système externe, probablement en raison des E/S réseau ou des limitations de parallélisme. Un écart important entre les deux retards suggère que la capacité de traitement du déploiement est insuffisante, ce qui entraîne une accumulation de données dans l'opérateur source. Sur la page des détails du déploiement, accédez à l'onglet Status et utilisez la page BackPressure pour localiser le sommet problématique. Ensuite, accédez à la page Thread Dump pour analyser la pile et identifier le goulot d'étranglement.	millisecondes (ms)	Kafka ApsaraMQ for RocketMQ Simple Log Service DataHub Postgres Change Data Capture (CDC) Hologres (Binlog Source)
numRecordsIn	Le nombre total d'enregistrements reçus par tous les opérateurs.	Si la valeur `numRecordsIn` d'un opérateur spécifique n'augmente pas pendant une longue période, cela peut indiquer un problème avec le flux de données en amont. Vérifiez la source et les opérateurs en amont.	Compte	Tous les connecteurs intégrés.
numRecordsOut	Le nombre total d'enregistrements émis.	Si la valeur `numRecordsOut` d'un opérateur spécifique n'augmente pas pendant une longue période, cela peut indiquer une erreur dans la logique du code du déploiement qui entraîne la suppression d'enregistrements. Examinez la logique du code.	Compte	Tous les connecteurs intégrés.
numRecordsInOfSource	Le nombre d'enregistrements ingérés par l'opérateur source.	Utilisez cette métrique pour surveiller l'entrée de données depuis la source en amont.	Compte	Kafka MaxCompute Incremental MaxCompute ApsaraMQ for RocketMQ Simple Log Service DataHub Elasticsearch Hologres
numRecordsOutOfSink	Le nombre total d'enregistrements émis par l'opérateur sink.	Utilisez cette métrique pour surveiller la sortie de données vers le sink en aval.	Compte	Kafka Simple Log Service DataHub Hologres ApsaraDB for HBase Tablestore ApsaraDB for Redis
numRecordsInPerSecond	Le nombre d'enregistrements ingérés par seconde sur l'ensemble du flux de données.	Utilisez cette métrique pour surveiller la vitesse de traitement de l'ensemble du flux de données. Par exemple, vous pouvez utiliser `numRecordsInPerSecond` pour observer si la vitesse de traitement globale atteint les niveaux attendus et comment les performances varient avec différentes charges d'entrée.	enregistrements/seconde	Tous les connecteurs intégrés.
numRecordsOutPerSecond	Le nombre d'enregistrements émis par seconde sur l'ensemble du flux de données.	Utilisez cette métrique pour mesurer la vitesse de sortie de l'ensemble du flux de données. Par exemple, vous pouvez utiliser `numRecordsOutPerSecond` pour observer si la vitesse de sortie globale répond à vos attentes et comment les performances changent sous différentes charges de sortie.	enregistrements/seconde	Tous les connecteurs.
numRecordsInOfSourcePerSecond (IN RPS)	Le nombre d'enregistrements ingérés par seconde par chaque source.	Utilisez cette métrique pour mesurer le taux de génération d'enregistrements de chaque source. Par exemple, dans un flux de données avec plusieurs sources, vous pouvez utiliser cette métrique pour comprendre le taux d'ingestion de chaque source et ajuster le flux de données pour de meilleures performances. Cette métrique est également utile pour la surveillance et les alertes. Une valeur de 0 indique que le système en amont a cessé de produire des données ou que la consommation est bloquée, ce qui empêche la sortie. Vérifiez que la source en amont produit toujours des données.	enregistrements/seconde	Kafka MaxCompute Incremental MaxCompute ApsaraMQ for RocketMQ Simple Log Service DataHub Elasticsearch Hologres
numRecordsOutOfSinkPerSecond (OUT RPS)	Le nombre d'enregistrements émis par seconde par chaque sink.	Utilisez cette métrique pour mesurer le taux de sortie de chaque sink. Par exemple, dans un flux de données avec plusieurs sinks, vous pouvez utiliser cette métrique pour comprendre la vitesse de sortie de chaque sink et ajuster le flux de données pour de meilleures performances. Cette métrique est utile pour la surveillance et les alertes. Une valeur de 0 suggère une possible erreur dans la logique du code du déploiement qui filtre toutes les données. Examinez la logique du code.	enregistrements/seconde	Kafka MaxCompute Incremental MaxCompute Simple Log Service DataHub Hologres ApsaraDB for HBase Tablestore ApsaraDB for Redis
pendingRecords	Le nombre d'enregistrements dans le système externe que l'opérateur source n'a pas encore extraits.	Cette métrique affiche le nombre d'enregistrements dans le système externe que l'opérateur source n'a pas encore extraits.	Compte	Kafka Elasticsearch
sourceIdleTime	La durée pendant laquelle l'opérateur source est inactif.	Cette métrique indique si la source est inactive. Une valeur élevée suggère que le taux de production de données dans le système externe est faible.	millisecondes (ms)	Kafka ApsaraMQ for RocketMQ Postgres Change Data Capture (CDC) Hologres (Binlog Source)
busyTimePerSecond	La quantité de temps pendant laquelle une tâche est occupée chaque seconde.	Le nombre de millisecondes par seconde pendant lesquelles un thread de tâche est occupé à traiter des données. La valeur varie de 0 à 1 000. Une valeur plus élevée indique que la tâche subit une charge plus lourde. Utilisez cette métrique pour identifier les goulots d'étranglement de performance, évaluer l'utilisation des ressources et guider le réglage automatique.	millisecondes (ms)	S.O.

Points de contrôle

Métrique

Description

Détails

Unité

Nombre de points de contrôle

Le nombre total de points de contrôle.

Fournit un aperçu de l'état des points de contrôle pour vous aider à configurer des alertes.

Compte

lastCheckpointDuration

La durée du point de contrôle le plus récent.

Une longue durée ou un délai d'expiration peut être causé par une taille d'état importante, des problèmes réseau temporaires, des barrières non alignées ou une contre-pression.

millisecondes (ms)

lastCheckpointSize

La taille du point de contrôle le plus récent.

Indique la taille du dernier point de contrôle téléchargé. Utilisez cette métrique pour analyser les performances lorsqu'un goulot d'étranglement se produit.

Octets

État

Remarque

Les métriques d'état de latence sont désactivées par défaut. Pour utiliser ces métriques, définissez state.backend.latency-track.keyed-state-enabled: true dans les configurations Flink supplémentaires. L'activation de ces métriques peut affecter les performances d'exécution de votre déploiement.

Metric	Description	Description	Unit	Supported version
State Clear Latency	The maximum latency of a single state clear operation.	Use this metric to monitor the performance of state clear operations.	nanoseconds (ns)	Realtime Compute for Apache Flink that uses Ververica Runtime (VVR) 4.0.0 or later.
ValueState Latency	The maximum latency of a single ValueState access operation.	Use this metric to monitor the performance of ValueState access.	nanoseconds (ns)
AggregatingState Latency	The maximum latency of a single AggregatingState access operation.	Use this metric to monitor the performance of AggregatingState access.	nanoseconds (ns)
ReducingState Latency	The maximum latency of a single ReducingState access operation.	Use this metric to monitor the performance of ReducingState access.	nanoseconds (ns)
MapState Latency	The maximum latency of a single MapState access operation.	Use this metric to monitor the performance of MapState access.	nanoseconds (ns)
ListState Latency	The maximum latency of a single ListState access operation.	Use this metric to monitor the performance of ListState access.	nanoseconds (ns)
SortedMapState Latency	The maximum latency of a single SortedMapState access operation.	Use this metric to monitor the performance of SortedMapState access.	nanoseconds (ns)
State Size	The size of the state data.	Utilisez cette métrique pour : Identifier les goulets d'étranglement actuels ou potentiels au niveau des nœuds. Vérifier que la configuration du délai d'expiration (TTL) fonctionne comme prévu.	Octets	Realtime Compute for Apache Flink utilisant Ververica Runtime (VVR) 4.0.12 ou version ultérieure.
State File Size	La taille du fichier de données d'état.	Cette métrique permet de : Surveiller l'espace disque local consommé par les données d'état et prendre des mesures en cas d'utilisation élevée. Déterminer si des données d'état excessivement volumineuses entraînent un manque d'espace disque local.	Octets	Realtime Compute for Apache Flink utilisant Ververica Runtime (VVR) 4.0.13 ou version ultérieure.

I/O

Metric	Description	Details	Unit	Supported connectors
numBytesIn	Le nombre total d'octets en entrée.	Utilisez cette métrique pour surveiller le débit d'entrée depuis la source et suivre le trafic du déploiement.	Octets	Kafka MaxCompute Incremental MaxCompute ApsaraMQ for RocketMQ
numBytesInPerSecond	Le nombre total d'octets en entrée par seconde.	Utilisez cette métrique pour surveiller le taux d'entrée depuis la source et suivre le trafic du déploiement.	Octets/s	Kafka MaxCompute Incremental MaxCompute ApsaraMQ for RocketMQ
numBytesOut	Le nombre total d'octets en sortie.	Utilisez cette métrique pour surveiller le débit de sortie vers le puits (sink) et suivre le trafic du déploiement.	Octets	Kafka ApsaraMQ for RocketMQ DataHub ApsaraDB for HBase
numBytesOutPerSecond	Le nombre total d'octets en sortie par seconde.	Utilisez cette métrique pour surveiller le taux de sortie vers le puits (sink) et suivre le trafic du déploiement.	Octets/s	Kafka ApsaraMQ for RocketMQ DataHub ApsaraDB for HBase
Task numRecords I/O	Le nombre total d'enregistrements reçus et émis par chaque sous-tâche.	Utilisez cette métrique pour identifier les goulets d'étranglement d'E/S potentiels.	Enregistrements	Kafka MaxCompute Incremental MaxCompute Simple Log Service DataHub Elasticsearch Hologres ApsaraDB for HBase Tablestore ApsaraDB for Redis
Task numRecords I/O PerSecond	Le nombre total d'enregistrements reçus et émis par chaque sous-tâche par seconde.	Utilisez cette métrique pour identifier les goulets d'étranglement d'E/S et évaluer leur gravité en fonction du taux de traitement.	Enregistrements/s	Kafka MaxCompute Incremental MaxCompute Simple Log Service DataHub Elasticsearch Hologres ApsaraDB for HBase Tablestore ApsaraDB for Redis
currentSendTime	Le temps nécessaire à chaque sous-tâche pour envoyer le dernier enregistrement au puits (sink).	Une valeur élevée pour cette métrique indique que la sortie de la sous-tâche est trop lente.	Millisecondes (ms)	Kafka MaxCompute Incremental MaxCompute ApsaraMQ for RocketMQ Simple Log Service DataHub Hologres Remarque Prise en charge des modes JDBC et RPC. Le mode BHClient n'est pas pris en charge. ApsaraDB for HBase Tablestore ApsaraDB for Redis

Watermark

Metric	Description	Usage	Unit	Supported connector
Task InputWatermark	L'heure à laquelle chaque tâche reçoit le dernier watermark.	Utilisez cette métrique pour surveiller la progression des données arrivant sur un TaskManager.	S.O.	Non spécifique au connecteur.
watermarkLag	La différence entre l'heure murale et l'heure d'événement du watermark.	Utilisez cette métrique pour déterminer la latence de traitement au niveau de la sous-tâche.	ms	Kafka ApsaraMQ for RocketMQ Simple Log Service DataHub Hologres (source binlog)

CPU

Metric	Description	Description	Unit
JobManager CPU usage	L'utilisation du CPU d'un JobManager.	Cette métrique affiche le pourcentage de tranches de temps CPU utilisées par Flink. Une valeur de 100 % signifie qu'un cœur de processeur est entièrement utilisé, tandis que 400 % indique que quatre cœurs sont saturés. Si cette valeur dépasse constamment 100 %, le JobManager est limité par le CPU. Une charge élevée associée à une faible utilisation du CPU peut indiquer un nombre excessif de processus en état de sommeil ininterrompu en raison d'opérations de lecture et d'écriture fréquentes. Remarque Cette métrique est disponible uniquement pour Realtime Compute for Apache Flink VVR 6.0.6 et versions ultérieures.	S.O.
TaskManager CPU usage	L'utilisation du CPU d'un TaskManager.	Cette métrique affiche le pourcentage de tranches de temps CPU utilisées par Flink. Une valeur de 100 % signifie qu'un cœur de processeur est entièrement utilisé, tandis que 400 % indique que quatre cœurs sont saturés. Si cette valeur dépasse constamment 100 %, le TaskManager est limité par le CPU. Une charge élevée associée à une faible utilisation du CPU peut indiquer un nombre excessif de processus en état de sommeil ininterrompu en raison d'opérations de lecture et d'écriture fréquentes.	S.O.

Memory

Metric

Description

Unit

JM heap memory

La mémoire heap du JobManager.

Suit les variations de la mémoire heap du JobManager.

Octets

JM non-heap memory

La mémoire non-heap du JobManager.

Suit les variations de la mémoire non-heap du JobManager.

Octets

TM heap memory

La mémoire heap du TaskManager.

Suit les variations de la mémoire heap du TaskManager.

Octets

TM non-heap memory

La mémoire non-heap du TaskManager.

Suit les variations de la mémoire non-heap du TaskManager.

Octets

TM Mem (RSS)

La taille de l'ensemble résident (RSS) du processus TaskManager, telle que rapportée par le système d'exploitation.

Surveille l'utilisation totale de la mémoire physique du processus TaskManager.

Octets

JVM

Metric

Description

Details

Unit

JM Threads

Le nombre de threads du JobManager.

Un nombre excessif de threads du JobManager peut consommer trop de mémoire, réduisant ainsi la stabilité des tâches.

Nombre

TM Threads

Le nombre de threads du TaskManager.

Un nombre excessif de threads du TaskManager peut consommer trop de mémoire, réduisant ainsi la stabilité des tâches.

Nombre

JM GC Count

Le nombre d'événements de garbage collection (GC) pour le JobManager.

Des événements de garbage collection fréquents peuvent consommer une quantité excessive de mémoire et dégrader les performances des tâches. Utilisez cette métrique pour diagnostiquer les échecs au niveau des tâches.

Nombre

JM GC Time

La durée de chaque événement de garbage collection pour le JobManager.

De longues pauses de garbage collection peuvent consommer une quantité excessive de mémoire et dégrader les performances des tâches. Utilisez cette métrique pour diagnostiquer les échecs au niveau des tâches.

Millisecondes (ms)

TM GC Count

Le nombre d'événements de garbage collection pour le TaskManager.

Nombre

TM GC Time

La durée de chaque événement de garbage collection pour le TaskManager.

Millisecondes (ms)

JM ClassLoader

Le nombre total de classes chargées ou déchargées par la JVM du JobManager depuis son démarrage.

Un volume élevé de chargement et de déchargement de classes dans la JVM du JobManager peut consommer une quantité excessive de mémoire et dégrader les performances des tâches.

S.O.

TM ClassLoader

Le nombre total de classes chargées ou déchargées par la JVM du TaskManager depuis son démarrage.

Un volume élevé de chargement et de déchargement de classes dans la JVM du TaskManager peut consommer une quantité excessive de mémoire et dégrader les performances des tâches.

S.O.

MySQL connector

Métrique	Description	Unité	Scénario	Version prise en charge
isSnapshotting	Indique si le job se trouve dans la phase de snapshot (valeur = 1).	S/O	Vérifiez si le job est dans la phase de snapshot.	Realtime Compute for Apache Flink versions 8.0.9 et ultérieures.
isBinlogReading	Indique si le job se trouve dans la phase incrémentale (valeur = 1).	S/O	Vérifiez si le job est dans la phase incrémentale.
Nombre de tables restantes	Le nombre de tables en attente de traitement pendant la phase de snapshot.	Nombre	Vérifiez le nombre de tables non traitées.
Nombre de tables ayant fait l'objet d'un snapshot	Le nombre de tables traitées pendant la phase de snapshot.	Nombre	Vérifiez le nombre de tables traitées.
Nombre de SnapshotSplits restants	Le nombre de splits en attente de traitement pendant la phase de snapshot.	Nombre	Vérifiez le nombre de splits non traités.
Nombre de SnapshotSplits traités	Le nombre de splits traités pendant la phase de snapshot.	Nombre	Vérifiez le nombre de splits traités.
currentFetchEventTimeLag	La latence entre la création d'un événement dans la base de données et sa lecture par le connecteur.	ms	Vérifiez la latence de lecture des binlogs depuis la base de données.
currentReadTimestampMs	L'horodatage du dernier enregistrement de données lu.	ms	Vérifiez l'horodatage du dernier enregistrement de données lu.
numRecordsIn	Le nombre total d'enregistrements de données lus.	Nombre	Vérifiez le nombre total d'enregistrements de données lus.
numSnapshotRecords	Le nombre d'enregistrements de données traités pendant la phase de snapshot.	Nombre	Vérifiez le nombre d'enregistrements de données traités pendant la phase de snapshot.
numRecordsInPerTable	Le nombre d'enregistrements de données lus à partir de chaque table.	Nombre	Vérifiez le nombre d'enregistrements de données lus à partir de chaque table.
numSnapshotRecordsPerTable	Le nombre d'enregistrements de données traités pour chaque table pendant la phase de snapshot.	Nombre	Vérifiez le nombre d'enregistrements de données traités pour chaque table pendant la phase de snapshot.

Connecteur - Kafka

Métrique	Description	Unité	Scénario	Version prise en charge
commitsSucceeded	Le nombre total de validations d'offset réussies.	Nombre	Vérifie que les validations d'offset aboutissent.	Realtime Compute for Apache Flink VVR 8.0.9 ou version ultérieure.
commitsFailed	Le nombre total de validations d'offset échouées.	Nombre	Identifie les problèmes liés aux validations d'offset.
Taux de récupération (Fetch Rate)	Le nombre moyen de requêtes de récupération par seconde.	Nombre/s	Utilisez cette métrique pour surveiller le taux de récupération des données et identifier d'éventuels problèmes de latence.
Latence moyenne de récupération (Fetch Latency Avg)	La latence moyenne des opérations de récupération.	Millisecondes	Une valeur élevée peut indiquer un goulot d'étranglement réseau ou un broker Kafka lent.
Taille moyenne de récupération (Fetch Size Avg)	Le nombre moyen d'octets par requête de récupération.	Octets	Utilisez cette métrique pour analyser le débit et l'efficacité de la récupération des données.
Moyenne d'enregistrements par requête (Avg Records In Per-Request)	Le nombre moyen d'enregistrements par requête de récupération.	Nombre	Utilisez cette métrique pour analyser l'efficacité du regroupement des enregistrements dans les requêtes de récupération.
currentSendTime	L'horodatage event-time du dernier enregistrement traité par le connecteur.	S/O	Utilisez cette métrique pour surveiller la progression de la consommation.
batchSizeAvg	Le nombre moyen d'octets par lot.	Octets	Utilisez cette métrique pour analyser la latence et le débit d'écriture des données.
requestLatencyAvg	La latence moyenne des requêtes d'écriture de données.	Millisecondes	Utilisez cette métrique pour évaluer les performances d'écriture des données.
requestsInFlight	Le nombre de requêtes d'écriture de données actuellement en cours.	S/O	Une valeur élevée peut indiquer un goulot d'étranglement au niveau du système de destination (sink).
recordsPerRequestAvg	Le nombre moyen d'enregistrements dans chaque requête d'écriture de données.	Nombre	Utilisez cette métrique pour évaluer l'efficacité du regroupement et le débit d'écriture des données.
recordSizeAvg	La taille moyenne des enregistrements en octets.	Octets	Utilisez cette métrique pour analyser le débit et l'efficacité de l'écriture des données.

Connecteur Paimon

Métrique	Description	Unité	Scénario	Version prise en charge
Nombre de writers	Le nombre d'`instance writer`s actifs.	Nombre	Un nombre élevé de writers peut dégrader les performances d'écriture et augmenter la consommation de mémoire. Si cette valeur est élevée, vérifiez si vos paramètres de nombre de `bucket`s et de `clé de partition` sont appropriés.	Realtime Compute for Apache Flink VVR 8.0.9 ou version ultérieure.
Taux d'occupation maximal des threads de compaction	Le taux d'occupation maximal des threads de `compaction`.	Ratio	Cette métrique reflète la pression de `compaction`. Une valeur proche de 100 % indique que la compaction constitue un goulot d'étranglement, ce qui peut ralentir l'écriture des données.
Taux d'occupation moyen des threads de compaction	Le taux d'occupation moyen des threads de `compaction`.	Ratio	Cette métrique reflète la pression moyenne de `compaction` sur tous les buckets. Une valeur élevée suggère que les performances globales de compaction sont lentes.
Nombre maximal de fichiers de niveau 0	Le nombre maximal de fichiers de niveau 0.	Nombre	Pour une `table à clé primaire`, un nombre élevé de fichiers de niveau 0 (petits fichiers) indique que la `compaction` ne suit pas le rythme d'écriture.
Nombre moyen de fichiers de niveau 0	Le nombre moyen de fichiers de niveau 0.	Nombre	Pour une `table à clé primaire`, un nombre moyen élevé de fichiers de niveau 0 (petits fichiers) indique que la `compaction` globale ne suit pas le rythme d'écriture.
Durée de la dernière validation	La durée de la dernière validation.	Millisecondes	Si la durée est excessivement longue, vérifiez si les données sont écrites simultanément dans trop de `bucket`s.
Nombre de partitions validées lors de la dernière commit	Le nombre de `partition`s écrites lors de la dernière validation.	Nombre	Un nombre élevé de partitions dans une seule validation peut dégrader les performances d'écriture et augmenter la consommation de mémoire. Vérifiez si vos paramètres de nombre de `bucket`s ou de `clé de partition` sont appropriés.
Nombre de buckets validés lors de la dernière commit	Le nombre de `bucket`s écrits lors de la dernière validation.	Nombre	Un nombre élevé de buckets dans une seule validation peut dégrader les performances d'écriture et augmenter la consommation de mémoire. Vérifiez si vos paramètres de nombre de `bucket`s ou de `clé de partition` sont appropriés.
Mémoire tampon d'écriture utilisée	La quantité de mémoire tampon d'écriture utilisée.	Octets	Ce buffer consomme de la `mémoire heap Java` sur tous les `TaskManager`s. Une valeur persistamment élevée peut entraîner une erreur d'épuisement de la mémoire (OOM).
Mémoire tampon d'écriture totale	La quantité totale de mémoire tampon d'écriture allouée.	Octets	Ce buffer consomme de la `mémoire heap Java` sur tous les `TaskManager`s. Définir cette valeur trop haut peut épuiser la mémoire disponible et entraîner une erreur d'épuisement de la mémoire (OOM).

Ingestion des données

Métrique	Description	Unité	Scénario	Version prise en charge
isSnapshotting	Indique si le job se trouve dans la phase de snapshot. Une valeur de 1 signifie que le job est dans cette phase.	S/O	Détermine la phase de traitement actuelle du job.	Realtime Compute for Apache Flink VVR 8.0.9 ou version ultérieure.
isBinlogReading	Indique si le job se trouve dans la phase incrémentale. Une valeur de 1 signifie que le job est dans cette phase.	S/O	Détermine la phase de traitement actuelle du job.
Nombre de tables restantes	Le nombre de tables en attente de traitement pendant la phase de snapshot.	Tables	Surveille la file d'attente des tables pour le traitement des snapshots.
Nombre de tables ayant fait l'objet d'un snapshot	Le nombre de tables traitées pendant la phase de snapshot.	Tables	Surveille le nombre de snapshots de tables terminés.
Nombre de SnapshotSplits restants	Le nombre de splits en attente de traitement pendant la phase de snapshot.	Splits	Surveille la file d'attente des splits de données pour le traitement des snapshots.
Nombre de SnapshotSplits traités	Le nombre de splits traités pendant la phase de snapshot.	Splits	Surveille le nombre de splits de données terminés issus de la phase de snapshot.
currentFetchEventTimeLag	La latence entre la création d'un événement dans la base de données et sa lecture par le connecteur.	ms	Mesure la latence d'ingestion des données à partir du journal binaire de la base de données.
currentReadTimestampMs	L'horodatage du dernier enregistrement de données lu.	ms	Identifie le point temporel du dernier enregistrement ingéré.
numRecordsIn	Le nombre total d'enregistrements de données lus.	Enregistrements	Suit le nombre total d'enregistrements de données lus par la source.
numRecordsInPerTable	Le nombre d'enregistrements de données lus à partir de chaque table.	Enregistrements	Suit le nombre total d'enregistrements de données lus à partir de chaque table.
numSnapshotRecords	Le nombre d'enregistrements de données traités pendant la phase de snapshot.	Enregistrements	Surveille le nombre total d'enregistrements traités pendant la phase de snapshot.
numSnapshotRecordsPerTable	Le nombre d'enregistrements de données traités pour chaque table pendant la phase de snapshot.	Enregistrements	Surveille le nombre d'enregistrements traités par table pendant la phase de snapshot.