Les flux de données s’accélèrent dans les Systèmes d’Information. Tout le monde veut faire du business avec ses nouvelles API.

Mais à chaque fois que c’est en ligne, on m’interroge: Comment puis-je vérifier que tout fonctionne ? Comment mes équipes métier peuvent suivre les appels ? Est-ce que mes flux restent bloqués ? Comment les erreurs remontent-elles ? Que faut-il suivre ? Existe-il des bonnes pratiques ? Est-ce que mon équipe IT de développement des flux va être submergé par le support ? Quels sont les outils disponibles ? Existe-t-il des standards ? etc.

Je vous propose ma vision à ce sujet passionnant mais très mal outillé par les éditeurs traditionnels. La question est réduite à son plus simple appareil:

Comment superviser les flux entre applications ?

dixit tous LES DSI.

La réponse nécessite de prendre un peu de recul.

Réponse applicative standard

Le reflex est d’appliquer les approches et les modèles standards. Pour vérifier qu’une application fonctionne nominalement, il convient donc de suivre:

  1. les interactions des utilisateurs,
  2. les sorties techniques de l’applications,
  3. la consommation de ressources matérielles.

Interactions Homme Machine

Lors d’une interaction, l’utilisateur final reçoit une confirmation de ses actions par un résultat qu’il constate visuellement.

Le processus que cet utilisateur final applique est “confirmé” ou “infirmé” par une succession de messages positifs ou négatifs.

Exemple de workflow utilisateur “impots.gouv.fr”:

Workflow proposé par impots.gouv.fr

Ce point n’est pas supervisé en tant que tel. L’utilisateur fonctionnel doit finaliser ses opérations afin que le système accepte ses données. Il réagit à son propre rythme aux messages.

Sorties textuelles de l’application

Lors de l’exécution de code d’un logiciel, des messages sont générés sur la sortie standard ou dans des fichiers. En cas de problème sur cette application, des informations “illustrent” un contexte afin de comprendre ce dysfonctionnement.

5 Best Tools to Tail Logs - SolarWinds
Traces quelconques

Ces informations, corrélées au code, permettent de remonter à la cause… le plus souvent. Elles sont organisées par niveau:

  • FATAL: Le programme ne peut continuer.
  • ERROR: Le workflow est bloqué. Une action humaine est nécessaire.
  • WARNING: Une erreur est intervenue mais elle a été contournée.
  • INFO: Information du déroulement d’une étape fonctionnelle.
  • DEBUG: Contexte complet pour le développeur.

Ressources matérielles

Un dernier aspect permet de comprendre l’état d’un processus par l’évaluation des ressources qu’il utilise. Il s’agit ici de “mesurer sa santé” afin de corréler d’autres faits.

Les indicateurs mesurés sont les ressources consommées comme le temps processeur (CPU), l’espace mémoire (RAM) ou l’espace persistant des fichiers (DISK).

Outils de collecte

Ces informations, formatées et structurées, sont analysables par des automates organisés en famille de fonctionnalité.

Les familles des outils de mesure sont:

Pour l’analyse des informations manipulées 2 familles sont aussi mises en oeuvre:

  • Les rapports métier à posteriori: Business Intelligence,
  • Les rapports métier en temps-réel: Business Activity Monitoring.

Je ne traiterai ces 2 derniers éléments car elles mettent en jeu des mécanismes lourds d’exploitation des données stockées ou interceptées.

Log Management

La collecte des traces des processus, les logs, est vieille comme l’informatique. Elle consiste à:

  1. Lire les traces produites dans les consoles ou des fichiers,
  2. Les envoyer à un système central qui les analyse,
  3. Positionner des alertes sur le contenu.

Les solutions du moment sont par exemple GrayLog, Elastic ou Fluentd.

Les cas d’usages principaux couverts par ces solutions sont:

  • la centralisation des traces applicatives et systèmes,
  • la recherche,
  • l’alerte sur leur contenu.

Exemple avec Gray Log:

System monitoring

La mesure de l’état d’un serveur, d’un processus ou des ressources disques est aussi ancienne. Des agents collectent à intervalles réguliers les indicateurs sélectionnés par l’utilisateur (cpu, threads, mémoire, disque, etc).

Les solutions couramment rencontrées sont Nagios, Centreon ou Zabbix.

Les cas d’usages principaux couverts par le System monitoring sont:

  • la centralisation des indicateurs systèmes et processus,
  • le stockage par agrégation temporelle des données,
  • l’alerte sur seuils.

Exemple de monitoring avec Nagios:

Nagios XI - Easy Network, Server Monitoring and Alerting

Application Performance Management

Le suivi du comportement des applications est basé sur l’analyse du code, des protocoles manipulés et des processus sous-jacents. L’objectif principal est de corréler un comportement avec un dysfonctionnement: blocage, exception, consommation de ressources, etc.

Les outils leaders sur ce marché sont AppDynamics, DynaTrace, NewRelic ou Instana.

Les principaux cas d’usages couverts par ces solutions sont:

  • la mise en évidence de goulets d’étranglement,
  • l’analyse de la performance de l’exécution du code front et back,
  • la cartographie des dépendances.

Exemple avec AppDynamics:

Des outils qui proposent un mix

De plus en plus de solutions agrègent plusieurs caractéristiques de ces familles.

Par exemple, Datadog ou Elastic proposent maintenant un panel complet de services afin de :

  • superviser les systèmes,
  • exploiter des logs,
  • visualiser et/ou analyser la performance du code.

Par ailleurs, le consortium Open Telemetry a fait naître un standard pour uniformiser les formats des traces, logs et indicateurs. Ainsi le passage d’un outil à l’autre est plus aisé et la couverture des agents plus importante. Si cela n’est pas suffisant, il est même possible d’enrichir les données transportées.

En quoi le domaine de l’interconnexion est-il spécial ?

En quoi les éléments présentés ci-dessus ne sont pas applicables au domaine des interconnexions ? Pourquoi ces outils ne permettent pas d’atteindre cet objectif ?

Interconnexion entre systèmes

Les applications de ce domaine prennent en charge le transport des données. Une application qui prend en charge un transport se définit par:

  • un système source,
  • un message en entrée,
  • un ou plusieurs systèmes destinations,
  • avec pour chacun un message à délivrer.

Cela représente un “échange” entre ces systèmes.

Déterminer l’état d’un échange consiste donc à collecter les états de ces applications de transport. Chaque état (succès, erreur, bloqué, etc) est calculé pour le transport entier, de la source aux cibles.

Chaque échange met en jeu des manipulations et des transformations sur le message en entrée:

  • soit par lots. Le message contient plusieurs données (exemple: les factures d’un client),
  • soit unitaire. Le message ne contient qu’une seule donnée (exemple: un bon de livraison).

Dans le cas où chaque donnée du lot peut être délivrée indépendamment des autres, il convient de communiquer un état de transport pour chacune des données.

Disparité forte des technologies

Dans le monde de l’interconnexion des systèmes, la disparité des technologie est très forte. Les socles technologies sont nombreuses:

  • Extract Transform Load,
  • EDI,
  • Managed File Transfert,
  • Enterprise Service Bus,
  • API Management,

Les produits évoluent vite. Les migrations peu souvent réalisées.

Lors d’un échange, il est courant que le message passe d’une plateforme à l’autre et d’un produit à un autre.

Cette caractéristique complexifie la supervision car les socles ne pas/plus supportés. Ils ne sont pas toujours compatibles avec les protocoles demandés.

Multiplicité des flux

Les programmes développés sont assez basiques. Ils consistent à :

  1. lire un contenu sur un protocole particulier (HTTP, JMS, Kafka, Fichier, etc),
  2. interpréter le contenu (CVS, XML, JSON, etc),
  3. enrichir le contenu par une autre source,
  4. Pour chaque destinataire:
    1. transformer le contenu dans un autre format,
    2. écrire le contenu final sur un protocole.

Pour des raisons de maintenance, de performance, de robustesse, de capacité de reprise, de transaction, de persistence, ou tout simplement de faisabilité, ces programmes sont découpés en petits morceaux.

Pour chaque technologie, le découpage suit des motivations différentes. Cela produit une dispersion volontaire ou subie des traitements. Par exemple:

  • pour les ETL, chaque programme exécute un ou plusieurs processus.
  • pour les ESB, les médiations sont organisées en 1/2 flux puis en fonctions réutilisées,
  • pour les API, les appels de blocs ou d’ API “utilitaires” foisonnent.

Un échange est systématiquement composé de plusieurs programmes appelés “flux“.

A cela s’ajoute les contraintes de qualité de services. La distribution des processus sur plusieurs serveurs permet, entre autres:

  • une forte disponibilité,
  • un fort débit,
  • une gestion plus fine des ressources matérielles.

Chaque “flux” est alors déployé plusieurs fois, soit statiquement, soit dynamiquement (cf. kubernetes).

Fréquence variable

Mettre en jeu des socles et des protocoles variés apporte aussi une diversité des fréquences pour chacun des flux.

La cohabitation de flux exige le respect de diverses fréquences d’exécution:

  • les flux fichiers à intervalles réguliers,
  • les flux en lots par quantité ou par délai,
  • les flux asynchrones en fonction de la disponibilité,
  • les flux unitaire ont des seuils de débit,
  • les flux synchrones sont instantanés,
  • les flux peuvent avoir une durée de validité,
  • les flux asynchrones peuvent être priorisés.

La chorégraphie des flux prend en charge les fréquences variables des flux.

Une “pause” peut être subie ou volontaire afin de respecter ces contraintes. La supervision des échanges doit le détecter.

Exemple d’un échange

Je vous propose un exemple d’un échange fonctionnellement simplifié: la diffusion des produits d’un référentiel PIM vers 2 applications A et B.

Cet échange est composé de 3 demi-flux:

  1. Le traitement de l’événement de création émis par le PIM,
  2. La diffusion du produit au WebService exposé par l’application A,
  3. Le regroupement de tous les produits, 1 fois pas jour, pour le mettre à disposition de l’application B dans un fichier.

Le détail de cet échange a été simplifié en:

  • 1er flux unitaire PIM: Evenement Produit. Pris en charge par un ESB
    • Réception de l’événement de “création du produit PP”,
    • Lecture de la description complète du produit PP sur l’ API Produit,
      • flux intermédiaire: getProduit de l’API Produit
    • Ecriture du Produit au format JSON dans une file Kafka,
  • 2nd flux unitaire vers A: Nouveau produit vers A. Pris en charge par un ESB.
    • Lecture du Produit dans la file Kafka,
    • Transformation de la catégorie des Produits
      • flux intermédiaire: transcodification des catégories gérée par le référentiel MDM via API
    • Transformation du format JSON en XML,
    • Appel du WebService SOAP proposé par A.
  • 3ème flux vers B: Produits de la journée vers B. Pris en charge par un ETL.
    • Lecture de tous les produits de la journée dans la file Kafka,
    • Transformation au format CSV,
    • Ecriture du fichier dans le répertoire du serveur sFTP
      • flux intégration de B: flux spécifique au sein de l’application B pour l’ingestion.

Si l’on souhaite obtenir un état global du transfert, il convient de récupérer et d’agréger ceux de tous les flux qui la compose.

Pour une exécution réussi, l’état de l’échange serait:

  • Diffusion des produits du référentiel PIM vers A et B: succès

Pour chaque flux le composant, les états seraient:

NomEtatTechnologie
Evenement ProduitsuccèsESB
getProduit de l’API ProduitsuccèsAPI
Nouveau produit vers AsuccèsESB
Transcodification des catégoriessuccèsAPI
Produits de la journée vers BsuccèsETL
Ingestion des produits de BsuccèsSpé
Scénario nominal

Erreur versus état

Les programmes composant les interconnexions prennent en compte :

  1. les manques et les problèmes de qualité de données.
  2. les indisponibilités des applications.

Ils sont robustes. Les développeurs ont anticipés la gestion d’un nombre important d’erreurs.

Cette gestion des erreurs est une des particularités du développement de médiations, quelques soient les technologies utilisées.

Par exemple, lors d’une erreur protocolaire, un flux va être exécuté une 2nde fois (voir plus) dans un cas asynchrone, pour retenter l’appel vers sa destination. Lors du 1er essai, le message retourne dans la file d’origine en cas d’erreur.

En reprenant l’échange de l’exemple précédent, le WebService de A de ne répond pas la 1ère fois. L’exécution porte une 2nde exécution du flux ‘Nouveau produit vers A’ et devient alors:

NomEtatExecutionTechnologie
Evenement Produitsuccès1ESB
getProduit de l’API Produitsuccès1API
Nouveau produit vers Aerreur1 (initial)ESB
Transcodification des catégoriessuccès1API
Nouveau produit vers Asuccès2 (rejeu)ESB
Transcodification des catégoriessuccès2API
Produits de la journée vers Bsuccès1ETL
Ingestion des produits de Bsuccès1Spé
Scénario avec un rejeu automatique

Comme démontré, un échange peut porter une succession d’erreurs techniques dues à:

  1. des erreurs protocolaires,
  2. des transformations incompatibles,
  3. des données manquantes.

Un rejeu peut être opéré plusieurs fois afin d’aboutir à une fin en succès du flux.

Par ailleurs, le rejeu d’un flux n’implique pas le rejeu de l’échange complet.

La combinaison des cas de figure est ici importante. Ce fait impacte fortement les analyses des dysfonctionnements par les équipes support.

Erreur fonctionnelle versus Erreur technique

Il est primordial de comprendre qu’un flux est programmé pour rejeter des messages incomplets ou non conformes avec les formats manipulés. La qualité des données en entrée n’est jamais garantie.

Le flux ne doit pas tomber en erreur. Il ne doit pas s’arrêter. Les messages valides continuent d’être traités et routés. Les exceptions sont, quant à elles, gérées et routées vers des flux dédiées.

Lors d’une incohérence sur les données mises en jeu, par exemple lors d’une transcodification, le message est mis de côté car il ne peut plus avancer dans les traitements suivants. Il est alors rejeté. Le flux doit cependant continuer à traiter les autres messages. Le traitement n’est pas bloqué, c’est le message.

Un rejet est assimilable à une erreur envers l’utilisateur. Il doit corriger sa donnée initiale ou complémentaire.

Rejouer le message initial sans modification reproduira le même résultat: un rejet.

Que proposent les éditeurs des socles d’interconnexion ?

De nombreux produits proposent bien des outils qui supervisent les erreurs techniques, les logs, les indicateurs systèmes.

Exemples de consoles de supervision:

TalendMuleSoft
Logs
Google ApigeeAzure Logic Apps
Vue Examen de l'UI de surveillance des APIOverview, runs history, and other logic app information
Liste de consoles de suivi d’éditeurs de socles/solutions d’interconnexion

Mais le besoin fonctionnel n’est pas couvert. Cette problématique de suivi fonctionnel n’est pas prise en charge par les éditeurs.

La réalisation d’une vision fonctionnelle reste alors à la charge des équipes de gestion ou de développement d’interconnexion.

La supervision maison

La démarche minimale à suivre est d’adapter/compléter les flux et les médiations (bouts de programme ou fonctions) avec une production de traces de transport. Ces traces décrivent le contexte du transport comme:

  • un ID de correlation,
  • le nom de la médiation,
  • le status de la médiation,
  • des informations de contexte,
  • l’erreur relevée.

Ces traces sont ensuite stockées dans des bases NoSQL suivant un axe temporel. Ci-dessous, un index sous elasticsearch:

Collecte avec Elasticsearch

En complétant cette collecte avec des outils comme Kibana ou Graphana, des tableaux de bords offrent alors un suivi technique des flux, pour suivre:

  • la performance de médiations,
  • l’historique d’un flux,
  • la liste des erreurs.

Malgré cet intérêt pour les équipes IT, ces informations sont difficiles à rapprocher et ne sont pas exploitables par les équipes métier.

Alors, comment superviser les flux entre applications ?

La supervision technique des traces, de la performance et des systèmes doit être faite. Les flux sont des logiciels. Ils doivent être supervisés comme tels. Les erreurs techniques doivent être connues et maîtrisées.

Toutefois, la supervision technique est actuellement restreinte à une perspective dédié à un socle technologique (API, Azure Logic apps, etc.) ou un éditeur (Azure, GCP, etc.) ou bien à un sujet transverse précis (log, transaction http, CPU, etc).

Cette supervision d’indicateurs et de code reste cloisonnée dans les équipes IT. Ces informations ne sont pas exploitables par le métier sans retraitement et réinterprétation.

Comme expliqué ci-dessus, une erreur fonctionnelle d’un flux est assimilable à un “message d’erreur pour l’utilisateur”. Ce besoin simple est le cœur de la problématique.

Pour y répondre, la supervision fonctionnelle des interconnexions de systèmes doit porter, à minima,:

  1. la connaissance des états des flux exécutés,
  2. le regroupement les flux en échanges “métier”,
  3. la mise à disposition de l’état et des erreurs fonctionnelles aux utilisateurs “métier”,
  4. des recherches par application ou par donnée métier.

Une fois cette simplification faite, le métier est en capacité pour appréhender les échanges et les problèmes de qualité de données sous-jacents.

Enfin, pour “informer” l’utilisateur responsable, l’alerter rapidement d’un dysfonctionnement est primordial. Sans cela, le délai de prise en charge et de réaction est important.

En combinant, la simplification des flux en échange avec des alertes, les équipes fonctionnelles peuvent agir rapidement, en pleine connaissance des dysfonctionnement, sur leurs données.

Une solution vaut mieux qu’un long discourt

Ce constat est le point de départ de la solution Enterprise Flows Repository. Ce produit unique et original, tente de répondre à ce besoin spécifique récurrent. Il propose une vision experte dédiée au suivi fonctionnel des échanges et des flux.

Comment superviser les flux entre applications ?

Vous pourrez aussi aimer