Realtime Compute for Apache Flink:Monitoring and log FAQ

Comment vérifier le type de service de surveillance utilisé par un espace de travail ?

Le type de service de surveillance est sélectionné lors de la création de l'espace de travail et ne peut pas être modifié ultérieurement. Pour vérifier le type utilisé par votre espace de travail, accédez à Operation Center > Job O&M et cliquez sur le nom d'une tâche. Si l'onglet Alert Configuration apparaît, l'espace de travail utilise le service Prometheus facturé à l'utilisation, qui fait partie d'Application Real-Time Monitoring Service (ARMS). Si cet onglet est absent, l'espace de travail utilise le service gratuit Cloud Monitor. Pour obtenir des instructions de configuration pour chaque type de service, consultez la rubrique Surveillance et alerte des tâches.

Quelles sont les limites des alertes Cloud Monitor par rapport à ARMS ?

Cloud Monitor présente trois limites par rapport à ARMS :

• La syntaxe d'analyse des requêtes n'est pas prise en charge.

• Les courbes au niveau de granularité des sous-tâches ne sont pas disponibles. Dans les scénarios comportant plusieurs sources et sous-tâches, cela rend difficile l'identification rapide des problèmes de latence après le regroupement.

• Les métriques issues de l'instrumentation personnalisée dans le code utilisateur ne peuvent pas être consultées, ce qui peut compliquer le dépannage.

Comment configurer ou ajouter un contact d'alerte ?

Lorsque vous utilisez les alertes de la console Cloud Monitor ou ARMS, ajoutez ou configurez les contacts dans la console correspondante. Pour plus de détails, consultez la rubrique Configurer la surveillance et les alertes.

Si votre espace de travail utilise ARMS et que vous configurez des alertes de métriques ou d'échec de tâche directement dans la console de développement Realtime Compute for Apache Flink, suivez les étapes ci-dessous pour ajouter ou configurer des contacts d'alerte.

1. Accédez à la page de configuration des alertes.

   1. Connectez-vous à la console de gestion Realtime Compute for Apache Flink. Dans la colonne Operation de l'espace de travail cible, cliquez sur Console.

   2. Sur la page Operation Center > Job O&M, cliquez sur le nom de la tâche cible.

   3. Cliquez sur l'onglet Alert Configuration.

2. Dans l'onglet Alert Rules, choisissez Add Rule > Custom Rule pour ouvrir le panneau de création de règle.

3. Configurez ou ajoutez un contact d'alerte.

   • Ajouter : Cliquez sur Notification Recipient Management à côté du paramètre Notification Recipient pour ajouter des contacts, des robots DingTalk, etc. Pour obtenir des informations sur la configuration des alertes pour les robots DingTalk, les webhooks et les robots Lark, consultez la section FAQ du guide d'alerte. Après avoir ajouté un contact, si vous utilisez des appels téléphoniques pour les alertes, assurez-vous que le numéro de téléphone du destinataire est vérifié. Sinon, les alertes ne seront pas délivrées. Si l'étiquette Unverified apparaît dans la colonne Phone pour le contact cible dans l'onglet Contacts, cliquez sur l'étiquette pour terminer la vérification.

   • Configurer : Pour le paramètre Notification Object, sélectionnez les contacts d'alerte souhaités. Si le contact ne figure pas dans la liste, ajoutez-le en suivant les étapes ci-dessus.

Comment désactiver le service Prometheus activé automatiquement ?

Si vous avez sélectionné le service Prometheus facturé à l'utilisation lors de la création de votre espace de travail, ARMS est automatiquement activé. Pour cesser de l'utiliser, désinstallez l'instance Prometheus depuis la console Prometheus.

Important

La désinstallation de l'instance Prometheus pour un espace de travail arrête la collecte des données de surveillance pour cet espace de travail et entraîne la perte des courbes de données de surveillance des tâches. En cas d'anomalie d'une tâche, vous ne pourrez ni identifier l'heure initiale de l'anomalie ni recevoir d'alertes de surveillance. Procédez avec prudence.

1. Connectez-vous à la console Prometheus.

2. Dans le volet de navigation de gauche, cliquez sur Instance List.

3. Dans la liste déroulante Tag Filtering, sélectionnez l'ID ou le nom de l'espace de travail cible.

4. Recherchez l'instance dont le Instance Type est défini sur Prometheus for Flink Serverless et cliquez sur Uninstall dans la colonne Operation.

5. Dans la boîte de dialogue, cliquez sur Confirm.

Comment identifier la tâche qui a déclenché une alerte ?

Les événements d'alerte contiennent à la fois un JobID et un Deployment ID. Étant donné que le JobID change après un basculement de tâche, utilisez le Deployment ID pour identifier la tâche spécifique qui a signalé une erreur.

Consultez le Deployment ID à l'un des emplacements suivants :

• Dans la console de développement Realtime Compute for Apache Flink, sur l'onglet Deployment Details, recherchez le Deployment ID dans la section Basic.

  

• Dans l'URL de la tâche.

  

Comment configurer la surveillance et les alertes pour les redémarrages de tâches Flink ?

La console de développement Realtime Compute for Apache Flink configure les règles d'alerte en fonction des métriques Flink. Par conséquent, après un basculement de tâche, les courbes de métriques ne s'affichent pas et les alertes ne peuvent pas être déclenchées. Pour alerter sur les redémarrages de tâches, configurez une règle personnalisée dans ARMS basée sur le taux de croissance instantané de la métrique flink_jobmanager_job_numRestarts. Cela permet d'alerter sur les événements de basculement du job manager (JM).

1. Connectez-vous à la console de gestion Realtime Compute for Apache Flink.

2. Dans la colonne Operation de l'espace de travail cible, cliquez sur More > Monitoring Indicator Configuration pour ouvrir la console ARMS.

3. Sur la page Alert Rules, cliquez sur Create Prometheus Alert Rule.

4. Définissez Detection Type sur Custom PromQL et sélectionnez l'instance d'alerte.

5. Saisissez une expression Prometheus Query Language (PromQL) personnalisée. Par exemple :

   irate(flink_jobmanager_job_numRestarts{jobId=~"$jobId",deploymentId=~"$deploymentId"}[1m])>0

   Cette expression interroge la métrique flink_jobmanager_job_numRestarts sur la dernière minute et déclenche une alerte si le taux de variation instantané est supérieur à 0.

6. Cliquez sur Finish.

Comment définir les paramètres de niveau de journalisation pour une classe unique ?

Configurez les paramètres de niveau de journalisation par classe dans Log Levels, et non dans Other Configuration. Par exemple, pour définir les niveaux de journalisation du connecteur Kafka, ajoutez les paramètres suivants à Log Levels :

• log4j.logger.org.apache.kafka.clients.consumer=trace (pour une table source)

• log4j.logger.org.apache.kafka.clients.producer=trace (pour une table sink)

Comment activer les paramètres de journal GC ?

Sur la page Operation Center > Job O&M, cliquez sur le nom de la tâche cible. Sur l'onglet Deployment Details, sous Parameters, ajoutez la configuration suivante à Other Configuration et enregistrez pour appliquer.

env.java.opts: >-
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/flink/log/gc.log
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=2 -XX:GCLogFileSize=50M

Échec du démarrage d'une tâche après configuration des journaux pour SLS

Après avoir configuré une tâche pour envoyer les journaux vers Simple Log Service (SLS), la tâche échoue avec l'erreur Job startup failed. Please retry. et le message suivant :

Unknown ApiException {exceptionType=com.ververica.platform.appmanager.controller.domain.TemplatesRenderException, exceptionMessage=Failed to render {userConfiguredLoggers={}, jobId=3fd090ea-81fc-4983-ace1-0e0e7b******, rootLoggerLogLevel=INFO, clusterName=f7dba7ec27****, deploymentId=41529785-ab12-405b-82a8-1b1d73******, namespace=flinktest-default, priorityClassName=flink-p5, deploymentName=test}}
029999 202312121531-8SHEUBJUJU

Cette erreur se produit lorsqu'une variable de modèle Twig — telle que namespace ou deploymentId — a été modifiée accidentellement lors de la configuration des journaux.

Pour corriger ce problème, reconfigurez les paramètres de journalisation en suivant la procédure décrite dans Configurer la sortie des journaux de tâche. Ne modifiez pas les variables Twig dans le modèle de configuration des journaux.

Comment afficher, rechercher et analyser les journaux opérationnels historiques de Flink ?

Realtime Compute for Apache Flink propose deux méthodes pour accéder aux journaux opérationnels historiques.

• Dans la console de développement : Sur l'onglet Deployment Details, la fonctionnalité Log Archiving est activée par défaut avec une période de rétention de 7 jours. Les 5 Mo les plus récents des journaux opérationnels sont conservés. Ajustez la Log Archive Retention Period selon vos besoins.

  

• Dans un stockage externe : Configurez les tâches pour envoyer les journaux vers Object Storage Service (OSS), SLS ou Kafka, et définissez le niveau de journalisation pour la sortie. Pour plus de détails, consultez la rubrique Configurer la sortie des journaux de tâche.

Comment résoudre le problème d'absence de sortie des journaux des méthodes non statiques vers SLS ?

En raison de la logique d'implémentation de l'appender de journal SLS, les journaux provenant de méthodes non statiques ne sont pas envoyés vers SLS.

Résolvez ce problème en déclarant votre logger en utilisant le modèle statique standard :

private static final Logger LOG = LoggerFactory.getLogger(xxx.class);

Les données sont écrites correctement, mais l'aperçu de l'état de la tâche Flink affiche 0 donnée. Que faire ?

Ce phénomène se produit lorsqu'une tâche ne comporte qu'un seul nœud, la source n'ayant que des sorties et le sink n'ayant que des entrées. Dans cette topologie, Flink n'affiche pas le volume de données dans le graphique de topologie.

Pour afficher le trafic de données dans le graphique de topologie, séparez les opérateurs source et sink en opérateurs indépendants. Ajoutez le paramètre suivant à Other Configuration sous Parameter Settings sur l'onglet Deployment Details :

pipeline.operator-chaining: 'false'

Accédez à Operation Center > Job O&M, cliquez sur le nom de la tâche, puis recherchez Other Configuration sous Parameter Settings sur l'onglet Deployment Details.

Que faire si une tâche DataStream ne présente aucun retard, mais que la courbe de sortie en affiche un ?

Si les métriques CurrentEmitEventTimeLag et CurrentFetchEventTimeLag affichent un retard d'environ 52 ans, la tâche utilise un connecteur Kafka communautaire plutôt que le connecteur intégré à Flink. Les connecteurs communautaires n'implémentent pas la logique de reporting des métriques pour ces courbes, ce qui entraîne des valeurs anormales.

Basculez vers la dépendance du connecteur intégré à Flink. Trouvez la version appropriée sur le dépôt Maven.

Que faire si une NullPointerException est levée dans les journaux du Task Manager (TM) d'une tâche DataStream sans trace de pile détaillée ?

La JVM omet les traces de pile pour les exceptions fréquemment levées afin d'optimiser les performances. Ajoutez l'indicateur suivant à Other Configuration sous Parameter Settings sur l'onglet Deployment Details pour désactiver ce comportement :

env.java.opts: "-XX:-OmitStackTraceInFastThrow"

Accédez à Operation Center > Job O&M, cliquez sur le nom de la tâche, puis recherchez Other Configuration sous Parameter Settings sur l'onglet Deployment Details.

La métrique currentFetchEventTimeLag affiche une valeur anormalement élevée après un redémarrage de tâche avec le connecteur Hologres

• Symptôme

  Après le redémarrage ou la reprise d'une tâche Flink utilisant le connecteur Hologres à partir d'un point de contrôle, la métrique currentFetchEventTimeLag atteint brièvement une valeur extrêmement élevée (plusieurs heures, voire plusieurs jours), puis revient progressivement à la normale.

• Cause

  La métrique currentFetchEventTimeLag est calculée comme suit : System.currentTimeMillis() - record.getBinlogTimestamp() / 1000. Cette métrique présente les caractéristiques suivantes :

  • Il s'agit d'une valeur instantanée qui n'est pas persistée avec les points de contrôle. Après un redémarrage de tâche, elle revient à sa valeur initiale de 0.

  • Elle n'est mise à jour que lorsque des enregistrements de données réels sont consommés. Les enregistrements de type heartbeat ne déclenchent pas de mise à jour.

  Après un redémarrage de tâche, le connecteur Hologres reprend la consommation du binlog à partir de la position du dernier point de contrôle. Des opérations internes à Hologres — telles que la compaction, les modifications de schéma et la maintenance des partitions — peuvent produire des enregistrements binlog historiques avec des horodatages antérieurs. Lorsque ces enregistrements historiques sont consommés, l'écart important entre l'heure système actuelle et l'horodatage de l'enregistrement provoque un pic de la métrique. La métrique revient à la normale une fois toutes les données historiques consommées et la tâche rattrapée sur les données en temps réel.

• Solution

  Cette anomalie de métrique est un comportement connu du connecteur Hologres lors des redémarrages de tâches et n'affecte pas l'exactitude du traitement des données. Vérifiez que l'ampleur du pic de la métrique correspond au temps d'inactivité de la tâche. La métrique revient à des niveaux normaux après que la tâche a fini de consommer les données historiques et rattrapé les données en temps réel.