## Introduction Exécuter Apache NiFi en production repose sur la fiabilité, la sécurité et la rapidité des changements. Cette liste de contrôle transforme les bonnes pratiques en actions concrètes couvrant la configuration, la sécurité, le monitoring, la maintenance, les sauvegardes, les mises à niveau et les pièges courants. Chaque élément s'accompagne d'exemples pratiques et de réglages prêts à l'emploi pour une application immédiate. ## Vue d'ensemble du flux de travail Un flux clair et reproductible, de l'idée à la production, réduit les risques et les retouches. - Planifier : définir les sources de données, les destinations, les SLA et les modes de défaillance. - Construire localement : implémenter un flux minimal avec des Contextes de paramètres (Parameter Contexts) et des Services de contrôle (Controller Services). - Versionner : utiliser NiFi Registry pour le versionnage des flux. - Tester : valider les parcours fonctionnels, la contre-pression (backpressure) et la gestion d'erreurs. - Mettre en préproduction : déployer sur un cluster non-prod miroir des limites de production. - Relâcher : promouvoir en production avec notes de changement et étapes de retour arrière (rollback). - Opérer : surveiller la santé, le débit, la latence et les erreurs. - Améliorer : collecter les métriques, ajuster les seuils et retirer les composants inutilisés. ## Configuration et durcissement Réglages de base à verrouiller et à optimiser : ### Sécurité - Activer HTTPS dans nifi.properties avec un TLS robuste : nifi.web.https.host=0.0.0.0 nifi.web.https.port=8443 nifi.security.keystore=./conf/keystore.jks nifi.security.keystoreType=JKS nifi.security.keystorePasswd=changeit nifi.security.truststore=./conf/truststore.jks nifi.security.truststoreType=JKS nifi.security.truststorePasswd=changeit - Configurer utilisateurs et groupes, et appliquer des politiques de moindre privilège. - Stocker les secrets dans les Contextes de paramètres. Éviter de coder en dur les identifiants dans les processeurs. ### Dépôts et rétention - Placer flowfile_repository , content_repository et provenance_repository sur des disques rapides et séparés. - Définir la rétention de la provenance pour concilier auditabilité et espace disque : nifi.provenance.repository.max.storage.time=24 hours nifi.provenance.repository.max.storage.size=50 GB - S'assurer que le dépôt de contenu conserve de la marge (ex. : usage ### Performance et sécurité des flux - Appliquer la contre-pression sur chaque connexion. Exemple : 20 000 objets ou 5 Go. - Configurer la pénalité (penalization) et le rendement (yield) pour protéger les sources quand l'aval ralentit. - Privilégier les motifs sans état (stateless) quand c'est possible ; maintenir les files courtes. ### Ordonnancement et ressources - Dans bootstrap.conf , dimensionner la JVM de façon conservatrice et prévisible : java.arg.2=-Xms8g java.arg.3=-Xmx8g - Ajuster les tâches concurrentes par processeur selon CPU et E/S. Un bon point de départ : tâches concurrentes = nombre de cœurs CPU alloués à NiFi, puis affiner selon le débit observé. - Utiliser Run Schedule et Run Duration pour éviter le thrash CPU sur les processeurs légers. ### Services de contrôle - Centraliser les configs partagées (DBCPConnectionPool, SSLContextService, etc.). - Valider les services d'abord, puis activer les processeurs pour éviter les démarrages partiels. ## Monitoring et alerting Ce qu'il faut surveiller et comment le brancher : ### Signaux de santé clés - Santé des nœuds : CPU, tas (heap), GC, usage disque par dépôt. - Santé des flux : nombre/taille en file vs seuils de contre-pression, fréquence des bulletins, relations d'erreur. - Indicateurs SLA : latence de bout en bout, débit par parcours, ratios succès/échec. ### Outils natifs NiFi - Status History : suivre les métriques par composant dans le temps. - Bulletins : faire remonter rapidement avertissements et erreurs des processeurs. - ReportingTasks : émettre métriques et bulletins vers votre pile de monitoring. - Processeurs MonitorActivity : détecter les arrêts en amont et déclencher des alertes. ### Règles d'alerte (exemples) - Taux de croissance de file > 20 % pendant 5 min sur chemins critiques. - Bulletin ERROR répété > 3 fois en 5 min. - Trou dans les événements de provenance indiquant une source manquante. - Disque dépôt de contenu ou provenance > 80 %. ### Runbooks - Pour chaque alerte, documenter les étapes de triage : identifier les processeurs affectés, pauser l'ingestion, drainer ou réacheminer, revenir à la dernière version connue saine, valider la récupération. ## Maintenance Maintenir le cluster sain avec une routine légère mais constante : ### Quotidien - Revue des bulletins et relations d'erreur sur les groupes de processus clés. - Vérification de l'usage disque des dépôts et des plus grosses files. - Confirmation que les ReportingTasks tournent et sont à jour. ### Hebdomadaire - Ajuster les seuils de contre-pression si les files saturent souvent. - Rotation et archivage des logs ; confirmer les politiques de taille et rétention Logback. - Valider les Services de contrôle et supprimer les inutilisés. ### Mensuel - Revue de la rétention de provenance ; ajuster plafonds taille/temps. - Nettoyage des processeurs et connexions désactivés ou abandonnés. - Exercice de restauration depuis sauvegarde en bac à sable (sandbox). ### Trimestriel - Revue de capacité : CPU, tas, disque selon tendances de croissance. - Audit de dépendances : NARs personnalisés, drivers, endpoints externes. - Exercices de chaos : simuler la perte d'un nœud et le remplissage d'un disque de dépôt. ## Sauvegardes et récupération Sauvegarder ce qu'il faut pour restaurer les opérations, pas les données transitoires. ### Quoi sauvegarder - conf/ (dont nifi.properties , authorizers, utilisateurs, logback) - flow.json.gz (le flux de données en cours) - state/ (état local et cluster) - NARs et drivers personnalisés (ex. : extensions lib/ ) - Données NiFi Registry (sauvegarde depuis son backend de stockage) ### Processus recommandé (nœud unique) - Arrêter NiFi proprement. - Copier conf/ , flow.json.gz et state/ vers un emplacement versionné, hors hôte. - Copier NARs et drivers personnalisés. - Redémarrer et vérifier. ### Processus recommandé (cluster) - Décharger ou drainer chaque nœud avant maintenance pour minimiser les données au repos. - Sauvegarder chaque nœud comme ci-dessus plus les ressources cluster. - Conserver les sauvegardes au moins un cycle complet de mise à niveau. ### Notes de reprise après sinistre - Les dépôts (flowfile, contenu, provenance) peuvent être très volumineux ; préférer le redéploiement des flux et le retraitement depuis les sources (ex. : Kafka) plutôt que la restauration des dépôts. - Garder NiFi Registry comme source de vérité pour les versions de flux afin d'accélérer le redéploiement. - Documenter les étapes de démarrage à froid par flux : comment reprendre depuis le dernier point de contrôle (checkpoint) ou offset. ## Mises à niveau et gestion des changements Réduire le risque avec des changements par étapes, réversibles. ### Hygiène du changement - Versionner chaque groupe de processus avec NiFi Registry. - Rédiger des notes de changement : but, risque, 델tas de métriques attendus, retour arrière. - Utiliser les Contextes de paramètres pour isoler les différences d'environnement. ### Mise à niveau nœud unique - Sauvegarde : conf/ , flow.json.gz , state/ , NARs personnalisés. - Arrêter NiFi. Installer la nouvelle version côte à côte. - Reporter configs et extensions ; réconcilier les diffs dans nifi.properties et bootstrap.conf . - Démarrer, valider logs et UI, exécuter un flux de test (smoke test). ### Mise à niveau par roulement (cluster) - Déconnecter et décharger un nœud pour drainer le travail. - Mettre à niveau ce nœud, valider, puis le réintégrer. - Répéter nœud par nœud pour maintenir le cluster en service. ### Post-mise à niveau - Vérifier compatibilité des Services de contrôle et dépréciations des processeurs. - Surveiller GC, débit et profils de files pendant 24-48 h. - Garder la version précédente prête pour rollback jusqu'à stabilisation. ## Pièges courants en production Éviter ces erreurs coûteuses : - Pas de contre-pression sur les connexions : mène à la pression mémoire et l'instabilité. - Files surdimensionnées et longue durée : masquent les problèmes et ralentissent la récupération. - Réessais non bornés : boucles chaudes qui hammer les systèmes en aval. - Secrets dans les propriétés des processeurs : déplacer vers Contextes de paramètres sécurisés. - Monothread partout : sous-utilise les ressources ; dimensionner la concurrence par parcours. - Rétention de provenance absente : bloque l'analyse de cause racine. - Sauter la préproduction : changements qui passent direct en prod et causent des pannes. - Ignorer l'E/S disque : placer tous les dépôts sur le même volume lent. - Pas de runbooks : alertes qui tirent mais réponse ad hoc et lente. ## Exemples pratiques ### Exemple 1 : Kafka vers HDFS avec contre-pression sûre - Processeurs : ConsumeKafka, UpdateAttribute, PutHDFS, LogAttribute (chemin d'échec) - Seuils de connexion : 20 000 objets ou 5 Go entre chaque étape - Gestion d'échec : router l'échec vers un groupe de processus File d'attente de lettres mortes (Dead Letter Queue) avec un puits PutFile, capturant kafka.topic , partition , offset - Réglage : tâches concurrentes PutHDFS = cœurs client HDFS disponibles ; Run Schedule 0 sec pour streaming, 1-2 sec si petits fichiers causent du churn - Vérifications SLA : MonitorActivity sur ConsumeKafka et alerte sur croissance de file après PutHDFS ### Exemple 2 : Tirage REST avec limites de taux et réessais - Processeurs : GenerateTableFetch ou InvokeHTTP, EvaluateJsonPath, PutDatabaseRecord - Limite de taux : utiliser ControlRate avant InvokeHTTP (ex. : 100 req/min) - Motif de réessai : router les 5xx vers une file de réessai avec pénalité et backoff ; router les 4xx vers une File d'attente de lettres mortes avec attributs de contexte - Observabilité : logger status.code et response.time ; alerte sur ratio 5xx > 2 % pendant 10 min ### Exemple 3 : Fenêtre par lots avec points de contrôle - Processeurs : ListFile -> FetchFile -> PutHDFS - Idempotence : suivre les noms de fichiers vus dans DistributedMapCache pour prévenir les doublons - Fenêtrage : planifier ListFile toutes les 5 minutes ; l'aval tourne en continu - Récupération : si crash, le re-listing vérifie le cache et ne récupère que les fichiers inédits ## Plan pilote local Démarrer petit, mesurable et localement inspectable. ### Objectif - Prouver le débit et la gestion d'erreurs sur un flux mono-chemin imitant les motifs d'E/S de production. ### Périmètre - Une ingestion fichier locale vers un répertoire local avec une étape de transformation et une contre-pression claire. ### Étapes - Créer un groupe de processus avec GenerateFlowFile -> UpdateAttribute -> PutFile. - Ajouter un Contexte de paramètres pour chemins de fichiers et bascules d'environnement. - Régler la contre-pression de connexion à 1 000 objets ou 500 Mo. - Ajouter MonitorActivity après GenerateFlowFile. - Définir critères d'acceptation : soutenir 5 000 msg/min pendant 15 min, 0 erreur, file < 60 % du seuil. - Exécuter localement, collecter captures Status History et logs. - Si stable, porter en préproduction en changeant les Contextes de paramètres ; conserver les mêmes seuils. ### Sortie - Promouvoir le motif vers les chemins de production après validation des critères. ## Conclusion Le succès de NiFi en production vient d'une checklist claire, d'une séparation disciplinée des étapes et de pilotes petits et mesurables. Durcir la plateforme, l'observer sans relâche, la maintenir à cadence, sauvegarder l'essentiel et la faire évoluer en sécurité. Utiliser les exemples et réglages ici pour démarrer vos propres runbooks et standards, puis itérer selon les métriques collectées.