Surveillance et alertes NiFi avec exemples pratiques

Introduction

Surveiller efficacement Apache NiFi signifie suivre la santé des flux de données, l'utilisation des ressources système et l'état des composants pour détecter les problèmes avant qu'ils n'impactent les pipelines de production. NiFi fournit des capacités de surveillance intégrées via son API, des tâches de reporting et l'intégration avec des systèmes externes comme Prometheus, Grafana et des outils d'alerte.

Ce guide se concentre sur la surveillance et les alertes pratiques et actionnables pour NiFi. Vous apprendrez à :

Collecter les métriques clés de NiFi (métriques de flux, de processeur, de connexion, de JVM et système)
Exposer les métriques à Prometheus et les visualiser dans Grafana
Configurer des règles d'alerte et des canaux de notification (email, Slack, PagerDuty)
Diagnostiquer les modes de défaillance courants et en récupérer
Construire une liste de contrôle opérationnelle pour la surveillance quotidienne

Tous les exemples supposent une installation NiFi standard (version 1.13+), avec des commandes adaptables à votre environnement. Remplacez les espaces réservés comme {NIFI_HOST}, {PORT}, {PROCESSOR_ID} par vos valeurs réelles.

Inventaire de version et d'environnement

Avant de configurer la surveillance, vous devez savoir exactement ce que vous exécutez. Utilisez les commandes en lecture seule suivantes pour collecter les informations de version, de configuration et d'état.

Vérifier la version de NiFi et les informations de build

curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/system-diagnostics | jq '.systemDiagnostics.aggregateSnapshot.versionInfo'

Exemple de sortie attendue :

{
  "niFiVersion": "1.16.3",
  "buildTag": "nifi-1.16.3-RC1",
  "buildTimestamp": "03/29/2022 13:47:50 UTC",
  "javaVendor": "Oracle Corporation",
  "javaVersion": "1.8.0_311"
}

Si la commande échoue avec une erreur de certificat, utilisez curl -k uniquement si vous comprenez et acceptez les implications de sécurité. En production, utilisez des trust stores appropriés.

Identifier la topologie du cluster

Pour voir les nœuds du cluster et leur statut :

curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/controller/cluster | jq '.cluster.nodes[] | {nodeId, address, status}'

Exemple de sortie attendue :

{
  "nodeId": "node-1",
  "address": "nifi1.example.com:8443",
  "status": "CONNECTED"
}
{
  "nodeId": "node-2",
  "address": "nifi2.example.com:8443",
  "status": "CONNECTED"
}

Liste de contrôle des prérequis

Accès à l'API REST de NiFi (HTTPS généralement activé)
jq installé pour l'analyse JSON (sudo apt install jq ou brew install jq)
Accès réseau à tous les nœuds NiFi si en cluster
Permissions en lecture seule (ou un utilisateur avec accès view)

Observation en lecture seule : diagnostics système

curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/system-diagnostics | jq '.systemDiagnostics.aggregateSnapshot'

Cela renvoie une multitude de métriques système : utilisation du tas, utilisation non-tas, charge moyenne, utilisation du disque, etc. Capturez cette référence avant d'apporter des modifications.

Capturer l'état actuel pour le contrôle des changements

Enregistrez toujours l'état actuel avant tout changement. Par exemple, pour lister toutes les tâches de reporting :

curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/controller/reporting-tasks | jq '.reportingTasks[] | {id, name, state, type}'

Sortie attendue :

{
  "id": "reporting-task-1",
  "name": "AmbariReportingTask",
  "state": "RUNNING",
  "type": "org.apache.nifi.reporting.ambari.AmbariReportingTask"
}

Chemin de configuration sûr

La configuration de surveillance de NiFi implique l'activation de tâches de reporting qui envoient des métriques à des systèmes externes. Cette section couvre la manière la plus sûre d'activer les métriques Prometheus, qui est la base de nombreux tableaux de bord et alertes.

Activer la tâche de reporting Prometheus

La classe de tâche de reporting Prometheus est org.apache.nifi.reporting.prometheus.PrometheusReportingTask. Elle est incluse dans NiFi 1.8+.

Identifier le type de tâche de reporting

Créer la tâche de reporting via l'API (ou utilisez l'interface utilisateur) :

curl -k -X POST https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/controller/reporting-tasks \
  -H 'Content-Type: application/json' \
  -d '{
    "revision": {"version": 0},
    "component": {
      "name": "PrometheusReportingTask",
      "type": "org.apache.nifi.reporting.prometheus.PrometheusReportingTask",
      "properties": {
        "prometheus-reporting-task-metrics-endpoint-port": "9092",
        "prometheus-reporting-task-metrics-endpoint-path": "/metrics"
      }
    }
  }'

Remarque : Les noms exacts des propriétés peuvent varier selon la version. Consultez la documentation officielle de NiFi pour votre version. Dans NiFi 1.16, les propriétés sont :

prometheus-reporting-task-metrics-endpoint-port
prometheus-reporting-task-metrics-endpoint-path

Après la création, obtenez l'ID de la tâche et démarrez-la :

Démarrer la tâche de reporting

# Obtenir l'ID de la tâche
TASK_ID=$(curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/controller/reporting-tasks | jq -r '.reportingTasks[] | select(.name=="PrometheusReportingTask") | .id')

# Démarrer la tâche
curl -k -X PUT https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/reporting-tasks/$TASK_ID \
  -H 'Content-Type: application/json' \
  -d '{
    "revision": {"version": 1},
    "state": "RUNNING"
  }'

Accédez au point de terminaison Prometheus depuis votre serveur de surveillance :

Vérifier le point de terminaison

curl http://{NIFI_HOST}:9092/metrics | head -20

La sortie attendue inclut des métriques comme :

nifi_amount_flowfiles_received{instance="...",} 0.0
nifi_amount_flowfiles_sent{instance="...",} 0.0
nifi_amount_flowfiles_queued{instance="...",} 10.0
nifi_jvm_heap_used{instance="...",} 3.2E8

Rayon d'impact et sécurité

Le point de terminaison Prometheus n'est pas authentifié par défaut. Liez-le à une interface réseau privée ou protégez-le avec un proxy inverse.
Modifier les configurations des tâches de reporting peut provoquer des interruptions de métriques ; faites-le pendant une fenêtre de maintenance si possible.
Gardez toujours une sauvegarde de la configuration de flux NiFi (flow.xml.gz) avant des modifications majeures.

Chemin de récupération

Si la tâche de reporting ne démarre pas :

Vérifiez les journaux dans {NIFI_HOME}/logs/nifi-app.log pour les erreurs.
Vérifiez que le port configuré n'est pas déjà utilisé.
Si nécessaire, arrêtez et désactivez la tâche, puis recréez-la avec les bonnes propriétés.

Vérification et diagnostics

Après avoir configuré la surveillance, vérifiez que les métriques circulent et que les tableaux de bord sont alimentés. Cette section montre des commandes de diagnostic et ce qu'il faut rechercher.

Vérifier le scraping Prometheus

Dans votre serveur Prometheus, vérifiez la santé des cibles :

curl http://{PROMETHEUS_HOST}:9090/api/v1/targets | jq '.data.activeTargets[] | {scrapeUrl, health, lastError}'

Sortie attendue :

{
  "scrapeUrl": "http://nifi1.example.com:9092/metrics",
  "health": "up",
  "lastError": ""
}

Si la santé est down, vérifiez la connectivité réseau, les règles de pare-feu et l'état de la tâche de reporting NiFi.

Interroger des métriques spécifiques

Pour voir les flowfiles en file d'attente pour une connexion :

curl -s 'http://{PROMETHEUS_HOST}:9090/api/v1/query?query=nifi_amount_flowfiles_queued' | jq '.data.result[] | {instance: .metric.instance, value: .value[1]}'

Commandes de diagnostic pour la santé de NiFi

Vérifiez la santé globale du système via l'API NiFi :

curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/system-diagnostics | jq '.systemDiagnostics.aggregateSnapshot | {totalQueued: .totalQueued, totalNonLoopingFlowFiles: .totalNonLoopingFlowFiles, heapUsed: .heapUsed, heapUtilization: .heapUtilization}'

Exemple de sortie :

{
  "totalQueued": 1205,
  "totalNonLoopingFlowFiles": "1205",
  "heapUsed": "350 MB",
  "heapUtilization": "70%"
}

Surveillez ces tendances au fil du temps. Un nombre de files d'attente en augmentation constante ou une utilisation du tas proche de 90% indique un problème.

Modes de défaillance et récupération

Malgré une surveillance proactive, les défaillances surviennent. Cette section décrit les modes de défaillance courants, comment les détecter et en récupérer.

Mode de défaillance 1 : Panne de mémoire NiFi (OOM)

Symptômes :

Le processus NiFi plante ou devient insensible
Les journaux montrent java.lang.OutOfMemoryError: Java heap space
Les métriques montrent une utilisation du tas proche de 100%

Détection :

Alerte Prometheus sur nifi_jvm_heap_utilization > 0.9
Vérifiez via l'API : curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/system-diagnostics | jq '.systemDiagnostics.aggregateSnapshot.heapUtilization'

Récupération :

Redémarrez le nœud NiFi s'il est arrêté.
Augmentez la taille du tas dans bootstrap.conf (par exemple, java.arg.2=-Xmx8g).
Redémarrez NiFi.
Examinez la conception du flux pour les fuites de mémoire (par exemple, contenu volumineux dans les attributs, files d'attente non bornées).

Mode de défaillance 2 : Contre-pression de connexion

Symptômes :

Les FlowFiles s'accumulent dans une connexion au-delà de son seuil de contre-pression
Le processeur en amont s'arrête
La latence des données augmente

Détection :

L'interface utilisateur NiFi montre une file d'attente pleine, contre-pression engagée
API : curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/connections/{CONNECTION_ID} | jq '.status.aggregateSnapshot.percentUseCount'
Alerte sur nifi_amount_flowfiles_queued / nifi_connection_backpressure_threshold > 1

Récupération :

Identifiez pourquoi l'aval est lent : vérifiez les journaux du processeur, les files d'erreur ou le système externe (par exemple, base de données, Kafka).
Si transitoire, laissez la file d'attente se vider.
Si permanent, faites évoluer les processeurs en aval ou augmentez le seuil de contre-pression (attention à la mémoire).

Mode de défaillance 3 : Tâche de reporting arrêtée d'envoyer des métriques

Symptômes :

Pas de données récentes dans Grafana, la cible Prometheus montre down
L'état de la tâche de reporting NiFi est STOPPED ou FAILED

Détection :

Alerte de santé de cible Prometheus en baisse
Vérifiez l'état de la tâche : curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/reporting-tasks/{TASK_ID} | jq '.status.runStatus'

Récupération :

Redémarrez la tâche de reporting via l'API ou l'interface utilisateur.
Vérifiez les journaux NiFi pour les erreurs dans la tâche de reporting.
Si la configuration de la tâche est corrompue, recréez-la.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle quotidienne/hebdomadaire pour assurer une surveillance complète et une réponse rapide.

Contrôles quotidiens

[ ] Vérifiez que toutes les cibles Prometheus sont up pour les nœuds NiFi.
[ ] Vérifiez les diagnostics système NiFi : curl -k https://{NIFI_HOST}:{NIFI_PORT}/nifi-api/system-diagnostics | jq '.systemDiagnostics.aggregateSnapshot | {heapUtilization, cpuUtilization, totalQueued}'
[ ] Examinez le gestionnaire d'alertes pour toute alerte active.
[ ] Regardez le tableau de bord Grafana pour des anomalies (accumulation de files d'attente, compteurs d'erreurs).

Contrôles hebdomadaires

[ ] Examinez les journaux NiFi pour les avertissements et erreurs (grep -i 'ERROR\|WARN' {NIFI_HOME}/logs/nifi-app.log).
[ ] Vérifiez l'espace disque sur les nœuds NiFi (df -h), assurez-vous que les référentiels de contenu ont suffisamment d'espace libre (au moins 20%).
[ ] Vérifiez la sauvegarde de la configuration de flux : ls -l {NIFI_HOME}/conf/flow.xml.gz et testez la restauration vers un environnement non-production.
[ ] Examinez les tendances d'utilisation des ressources dans Grafana ; planifiez la capacité si la croissance est régulière.

Contrôles mensuels

[ ] Mettez à jour les tableaux de bord de surveillance pour refléter les changements de flux.
[ ] Testez les règles d'alerte en simulant une panne (par exemple, arrêtez un processeur et assurez-vous que l'alerte se déclenche).
[ ] Examinez et mettez à jour la documentation pour les procédures de récupération.
[ ] Vérifiez les mises à jour NiFi et les correctifs de sécurité.

Conclusion

Une surveillance et des alertes efficaces pour NiFi nécessitent une approche systématique : connaître son environnement, configurer l'exportation de métriques en toute sécurité, vérifier le flux de données et se préparer aux défaillances courantes. Utilisez les commandes et exemples de ce guide comme point de départ.

Commencez par une amélioration à faible risque : activez le reporting Prometheus sur une instance NiFi de test, configurez un tableau de bord Grafana avec des métriques de base et créez une alerte pour l'utilisation du tas. Enregistrez la référence, exécutez-la pendant une semaine et affinez les seuils. Ensuite, étendez à d'autres modes de défaillance et intégrez à votre processus de réponse aux incidents.

Rappelez-vous : l'observabilité ne consiste pas seulement à collecter des métriques ; il s'agit de les utiliser pour prendre des décisions éclairées rapidement. Gardez votre pile de surveillance aussi fiable que vos flux de données.

Surveillance et alertes NiFi avec exemples pratiques

Introduction

Inventaire de version et d'environnement

Vérifier la version de NiFi et les informations de build

Identifier la topologie du cluster

Liste de contrôle des prérequis

Observation en lecture seule : diagnostics système

Capturer l'état actuel pour le contrôle des changements

Chemin de configuration sûr

Activer la tâche de reporting Prometheus

Rayon d'impact et sécurité

Chemin de récupération

Vérification et diagnostics

Vérifier le scraping Prometheus

Interroger des métriques spécifiques

Commandes de diagnostic pour la santé de NiFi

Modes de défaillance et récupération

Mode de défaillance 1 : Panne de mémoire NiFi (OOM)

Mode de défaillance 2 : Contre-pression de connexion

Mode de défaillance 3 : Tâche de reporting arrêtée d'envoyer des métriques

Liste de contrôle opérationnelle

Contrôles quotidiens

Contrôles hebdomadaires

Contrôles mensuels

Conclusion

Recherches connexes

Score de qualité de l’article