Concepts avancés d’Apache NiFi expliqués avec des exemples pratiques

Intro

Ce guide explique des concepts avancés d’Apache NiFi avec des étapes pratiques et à faible risque que vous pouvez exécuter en production. Il met l’accent sur la sécurité opérationnelle : observer d’abord, ne modifier que ce que vous comprenez, vérifier les résultats, et documenter un chemin de retour clair. Vous apprendrez à inventorier un environnement NiFi, à ajuster le comportement d’un flux en toute sécurité, à diagnostiquer des problèmes et à récupérer après des défaillances courantes au moyen d’exemples concrets.

S’applique à : NiFi 1.12+ (étapes UI) et exemples NiFi Toolkit/REST ciblant l’API REST de NiFi. Remplacez les éléments génériques comme <NIFI_URL> et <TOKEN> avant d’exécuter les commandes.

Idées clés:

Séparer l’observation de l’intervention.
Privilégier les contrôles en lecture seule avant tout changement.
Limiter le périmètre d’impact avec des étapes petites et réversibles.
Utiliser des placeholders et des Parameter Contexts plutôt que d’intégrer des secrets en dur.

Inventaire de la version et de l’environnement

Avant tout changement, établissez précisément ce que vous opérez et comment c’est déployé.

Prérequis

Accès réseau à l’UI et à l’API REST de NiFi.
Un compte de service ou un utilisateur avec des permissions de lecture.
Un terminal avec curl ou un client HTTP.

Vérifications en lecture seule

Signal attendu : version, buildTag, buildRevision sont renvoyés.

Signal attendu : compte des nœuds (connectedNodeCount) et état du cluster.

Signal attendu : statistiques de heap non nulles, utilisation des dépôts de contenu/provenance.

Identifier la version de NiFi et les métadonnées de build :
curl : curl -sS -H "Authorization: Bearer <TOKEN>" <NIFI_URL>/nifi-api/flow/about | jq .about
Identifier la topologie (nœud unique vs cluster) :
curl : curl -sS -H "Authorization: Bearer <TOKEN>" <NIFI_URL>/nifi-api/flow/cluster/summary | jq .clusterSummary
Trouver l’ID du groupe de processus racine pour cadrer de futures opérations :
curl : curl -sS -H "Authorization: Bearer <TOKEN>" <NIFI_URL>/nifi-api/flow/process-groups/root | jq .processGroupFlow.id
Capturer les diagnostics système (CPU, heap, dépôts) :
curl : curl -sS -H "Authorization: Bearer <TOKEN>" <NIFI_URL>/nifi-api/system-diagnostics | jq .systemDiagnostics

Consignez ce que vous capturez avec horodatage et étiquettes d’environnement (p. ex. prod, région, ID de cluster). Gardez les secrets hors de l’historique de commandes et des journaux.

Plus petite intervention justifiée

Si vous devez changer quelque chose, limitez-la à un composant (p. ex. le paramètre de contre‑pression d’une seule connexion) et enregistrez :
Pourquoi le changement est nécessaire et l’amélioration attendue.
Le ou les paramètres modifiés et leurs valeurs d’origine (pour revenir en arrière).
Le signal de vérification que vous contrôlerez après le changement.

Chemin de configuration sécurisé

Cette section illustre deux changements courants et à faible risque : le réglage de la contre‑pression sur une connexion sollicitée et l’introduction de Parameter Contexts pour une gestion de configuration plus sûre.

Exemple A : Réglage de la contre‑pression sur une connexion « chaude »

Objectif : Éviter la pression mémoire des nœuds en abaissant les seuils de file entre deux processeurs lorsque les messages affluent.
Périmètre d’impact : Uniquement la connexion ciblée. Le débit en aval peut baisser lorsque la contre‑pression s’enclenche.
Prérequis : Identifier l’ID de la connexion dans l’UI ou via REST.
Astuce : Dans l’UI, sélectionnez la connexion et choisissez Voir la configuration. Notez l’ID de la connexion.
Observation (lecture seule) :
UI : Connection Configuration > onglet Settings affiche les seuils d’objets et de taille de données pour la contre‑pression.
REST : curl -sS -H "Authorization: Bearer <TOKEN>" <NIFI_URL>/nifi-api/connections/<CONNECTION_ID> | jq .component.backPressureObjectThreshold,.component.backPressureDataSizeThreshold
Changement (plus petite étape) : Réduisez les seuils de 10 à 25 % par rapport à leurs valeurs actuelles plutôt que de faire de grands sauts. Utilisez l’UI pour appliquer les changements afin d’éviter les conflits de révision REST.
Vérification attendue : La taille de la file de la connexion se stabilise sous les nouveaux seuils ; aucune erreur persistante sur le Bulletin Board pour les processeurs concernés.
Contrôles post-changement :
La profondeur de file dans l’UI reste sous les seuils pendant au moins une période de pointe.
Les diagnostics REST indiquent toujours un heap sain et aucune sur‑utilisation des dépôts.
Reprise : Revenez aux seuils d’origine si les SLA (Service Level Agreement) de l’aval sont impactés ou si les arriérés en amont deviennent inacceptables.

Exemple B : Introduire un Parameter Context pour supprimer les valeurs codées en dur

Objectif : Remplacer des URL ou tailles de lot codées en dur dans un groupe de processus par des Parameter Contexts afin de faciliter la promotion entre environnements.
Périmètre d’impact : Uniquement le groupe de processus sélectionné une fois lié au Parameter Context.
Prérequis : Un groupe de processus nommé contenant des processeurs prenant en charge des propriétés paramétrées.
Observation (lecture seule) : Dressez l’inventaire des valeurs codées en dur dans les processeurs que vous prévoyez de paramétrer.
Changement :

Dans l’UI, créez un Parameter Context nommé pg-orders avec des paramètres comme api.base.url, batch.size et un paramètre sensible api.token (laissez la valeur vide si vous utilisez un fournisseur externe).
Assignez le groupe de processus à pg-orders et modifiez les propriétés des processeurs pour utiliser #{api.base.url} et #{batch.size}.

Vérification attendue : Le groupe de processus devient valide avec le nouveau contexte assigné, les processeurs démarrent avec succès et le comportement correspond aux exécutions précédentes.
Signaux d’échec : Des processeurs deviennent invalides en raison de paramètres non résolus, ou un paramètre sensible est manquant.
Reprise : Désassignez le Parameter Context pour revenir aux valeurs explicites, ou réappliquez les valeurs d’origine capturées plus tôt.

Notes

Pour les secrets, préférez des fournisseurs de secrets externes ou des Parameter Providers pris en charge par votre version. Ne placez jamais de vrais secrets dans des articles, des tickets ou des captures d’écran.

Vérification et diagnostics

Utilisez ces outils intégrés pour confirmer la santé et circonscrire rapidement les problèmes.

Signaux clés à vérifier

Bulletins (avertissements/erreurs à l’exécution) :
curl : curl -sS -H "Authorization: Bearer <TOKEN>" "<NIFI_URL>/nifi-api/flow/bulletin-board?after=0" | jq .bulletinBoard.bulletins[]?.bulletin.message
Attendu : Des reprises réseau occasionnelles sont acceptables ; des erreurs persistantes de services contrôleurs ou des échecs d’autorisation nécessitent une action.
Compteurs (débit, reprises) :
curl : curl -sS -H "Authorization: Bearer <TOKEN>" <NIFI_URL>/nifi-api/counters | jq .counters
Attendu : Les compteurs progressent ; les compteurs d’erreurs ne dominent pas les réussites.
Diagnostics système (heap/GC, dépôts) : déjà présent dans l’inventaire. Recherchez :
Un heap proche du maximum et des pauses GC fréquentes.
Une utilisation disque élevée des dépôts de contenu/provenance au‑delà de seuils sûrs.

Vérification ciblée de Data Provenance

Dans l’UI, ouvrez Data Provenance pour le processeur concerné.
Filtrez sur le nom du composant et une fenêtre temporelle récente.
Vérifiez la chaîne d’événements : RECEIVE -> ROUTE -> SEND (ou le chemin nominal de votre flux).
Vérification attendue : La latence reste dans le cadre du SLA (Service Level Agreement) ; les erreurs ou événements de drop sont rares et explicables.

Vérifications de cluster

Dans l’UI, la vue Cluster affiche tous les nœuds comme connectés, même version de NiFi, même empreinte de flux.
Processors « Primary Node Only » : Confirmez qu’un seul nœud exécute ces tâches et que la bascule est acceptable si le nœud primaire change.

Modes de défaillance et reprise

Reconnaissez les schémas d’échec courants et appliquez de petites étapes de reprise ciblées.

Invalidations en cascade d’un service contrôleur

Symptôme : De nombreux processeurs deviennent invalides après la modification d’un service contrôleur (p. ex. mise à jour de schéma d’un Record Reader).
Observation : Le Bulletin Board affiche des erreurs de validation ; les processeurs concernés sont en état Invalid.
Chemin de reprise :
Rétablissez la propriété du service contrôleur à la dernière valeur connue comme valide.
Appliquez les changements et attendez la validation des processeurs.
Au besoin, arrêtez uniquement le groupe de processus affecté, puis redémarrez après disparition des invalidations.

Chute d’un nœud du cluster

Symptôme : Le résumé du cluster indique un nombre de nœuds connectés réduit ; les données en file se concentrent sur les nœuds restants.
Observation : Résumé de cluster et statut du nœud ; journaux OS pour réseau, disque ou pression mémoire.
Chemin de reprise :
Quarantaine : Arrêtez l’ordonnancement sur le nœud concerné via l’UI s’il clignote.
Corrigez le problème hôte (disque, réseau, CPU), puis laissez le nœud rejoindre de nouveau.
Vérifiez que les tâches « Primary Node Only » disposent toujours d’un primaire valide.

Arriérés incontrôlés et pression sur les dépôts

Symptôme : Les files croissent sans borne ; l’utilisation des dépôts augmente ; la pression GC s’intensifie.
Observation : Diagnostics système et profondeurs de connexion en file.
Chemin de reprise (choisissez l’option la moins destructrice) :
Réduisez temporairement le débit entrant : désactivez ou appliquez la contre‑pression en amont.
Augmentez le parallélisme pour les processeurs en aval sûrs.
En tout dernier recours, videz une file non critique précise via l’UI après avoir confirmé que les données peuvent être rejouées depuis la source.

Disque plein sur les dépôts de contenu/provenance

Symptôme : Échecs d’écriture, erreurs d’E/S fréquentes, processeurs pénalisés.
Observation : Les diagnostics système montrent une utilisation des dépôts proche de 100 %.
Chemin de reprise :
Arrêtez d’abord l’ordonnancement des plus gros émetteurs.
Libérez de l’espace disque ou étendez le stockage.
Reprenez l’ordonnancement par paliers et vérifiez une E/S stable et l’absence de nouveaux bulletins.

Rétrogradation d’un flux versionné via NiFi Registry

Symptôme : Une nouvelle version introduit des erreurs.
Observation : Le groupe de processus affiche la nouvelle version et des composants invalides.
Chemin de reprise :
Dans l’UI, Revert Local Changes ou Rollback vers la version antérieure du flux.
Vérifiez que les processeurs se valident et démarrent proprement ; comparez compteurs et latences à la référence d’avant changement.

Liste de contrôle d’exploitation

Utilisez cette liste courte et répétable pour travailler en toute sécurité sur NiFi.

Avant de changer

Confirmez la version NiFi et le mode de déploiement :
curl -sS -H "Authorization: Bearer <TOKEN>" <NIFI_URL>/nifi-api/flow/about
curl -sS -H "Authorization: Bearer <TOKEN>" <NIFI_URL>/nifi-api/flow/cluster/summary
Capturez un instantané de diagnostics avec horodatage :
curl -sS -H "Authorization: Bearer <TOKEN>" <NIFI_URL>/nifi-api/system-diagnostics > diag-$(date +%F-%H%M).json
Notez les ID exacts des composants que vous prévoyez de modifier et leurs réglages actuels.

Pendant le changement

N’agissez que sur un composant à la fois ; préférez l’UI pour les changements de configuration afin d’éviter les conflits de révision REST.
Utilisez des Parameter Contexts pour les valeurs qui diffèrent selon l’environnement.
Maintenez une courte fenêtre d’observation entre les étapes ; surveillez les bulletins et la profondeur des files.

Après le changement

Vérifiez les signaux de succès :
Pas de nouveaux bulletins critiques.
Les tailles de file et les latences se stabilisent dans les bornes attendues.
Les compteurs indiquent un bon rapport débit/rate d’erreurs.
Si les signaux sont négatifs, revenez immédiatement en arrière à l’aide des valeurs d’origine sauvegardées ou de la version antérieure dans Registry.

Conclusion

Les opérations avancées sur NiFi reposent sur une observation disciplinée et de petites étapes réversibles. Commencez par un inventaire précis de votre version, de votre topologie et des signaux d’exécution actuels. Lorsque vous modifiez, limitez‑vous à un composant bien cadré, privilégiez les Parameter Contexts pour la configurabilité et définissez les signaux de vérification attendus. Si ces signaux ne sont pas au rendez‑vous, revenez vite en arrière grâce aux valeurs ou à la version de flux capturées avant l’intervention. Ce cycle maintient des dataflows fiables, protège les valeurs sensibles et permet aux équipes de se rétablir rapidement lorsque les conditions changent.