Definition d'applications et modelisation des donnees

Cette section decrit comment structurer votre inventaire de moniteurs avec des tags, et comment regrouper les moniteurs en applications avec leurs propres regles de sante, objectifs SLA, notifications et vues de dependances.

Le modele de donnees

Mugnsoft utilise un modele simple a trois niveaux :

• Les moniteurs sont l’unite atomique : chaque controle (script navigateur, sonde URL, ping, equipement SNMP…) produit un statut et des donnees de performance.
• Les tags sont des etiquettes libres attachees aux moniteurs. Ils sont le ciment de la plateforme : rapports, periodes de maintenance, visibilite des utilisateurs et appartenance aux applications sont tous resolus via les tags.
• Les applications regroupent des moniteurs (via des tags) et/ou d’autres applications en un objet de niveau metier avec son propre statut agrege, son historique SLA et ses notifications.

Schema de tags recommande

Les tags sont la fondation de tout le reste : convenez d’une convention de nommage avant de creer des moniteurs a grande echelle. Un schema qui fonctionne bien en pratique :

• un tag par service metier (crm, webshop, intranet),
• un tag par environnement (prod, uat, dev),
• un tag par equipe proprietaire (team-infra, team-app),
• des tags optionnels par tier (frontend, backend, db).

Un moniteur peut porter plusieurs tags ; chaque fonctionnalite de portee (applications, rapports, maintenances, visibilite utilisateur) calcule sa liste de moniteurs comme tous les moniteurs portant au moins un des tags selectionnes, plus les moniteurs explicitement selectionnes.

Definir une application

Les applications sont gerees depuis la page App. Les utilisateurs du groupe ADMIN peuvent creer, modifier ou supprimer des applications ; les utilisateurs du groupe USER peuvent gerer les applications correspondant a leurs tags.

Une application est definie par :

• Nom d’affichage, description, etat (on/off) et un logo optionnel (televerse apres l’enregistrement ; affiche sur la tuile de l’application et dans les vues de dependances).
• Appartenance — au moins l’un des deux :
  • tags : chaque moniteur de n’importe quel type portant un de ces tags devient membre,
  • applications : une ou plusieurs applications existantes deviennent enfants de cette application (voir Applications imbriquees).
• Regle metier, poids, objectifs SLA et notifications, decrits ci-dessous.

Regle metier : calcul du statut de l’application

La regle metier (bRule) decide comment les statuts des membres se consolident en un statut d’application :

Les membres desactives sont exclus du calcul.

Ce qui compte comme membre

Une application resout ses membres a partir soit de ses tags, soit de ses sous-applications — jamais des deux :

• si l’application porte des tags, son statut est calcule a partir des moniteurs correspondant a ces tags, et ses sous-applications ne sont pas prises en compte ;
• ce n’est que si elle n’a aucun tag qu’elle consolide les statuts des applications listees dans apps.

Definissez la regle explicitement

Une application dont la regle metier est vide ou inconnue est evaluee a OK, sans condition, quoi que fassent ses moniteurs. Les applications creees depuis l’interface recoivent worst par defaut ; celles creees par import ou par auto-enregistrement peuvent ne pas en avoir. Si une application se declare saine alors que ses membres ne le sont pas, verifiez sa regle avant toute autre chose.

Le statut est stocke, pas calcule a la lecture

Chaque application recalcule son propre statut selon une planification d’une minute et en stocke le resultat. Une application parente lit cette valeur stockee pour chacun de ses enfants : une panne remonte donc un arbre imbrique a raison d’environ un niveau par minute, soit environ trois minutes pour atteindre le sommet d’un arbre de trois niveaux. C’est normal, et c’est pourquoi le statut agrege peut brievement diverger d’un moniteur que vous observez en direct dans les vues de dependances.

Poids par type

Avec la regle weighted, chaque type de moniteur (API, BD, discovery, exec, nslookup, ping, equipement SNMP, equipement WMI, systeme, TCP, UDP, URL) a un poids entier configurable (defaut 1). Donnez un poids plus eleve aux types qui definissent reellement la disponibilite percue — par exemple, ponderez les scripts navigateur et les URL au-dessus des pings — afin qu’un ping en echec ne puisse pas surpasser une transaction en echec.

SLA : disponibilite et performance

Une application possede deja un statut de sante, consolide depuis ses membres par la regle metier. Un SLA est un engagement distinct pose par-dessus, compose d’exactement deux elements :

Il n’y a deliberement pas de troisieme element. En particulier, il n’existe aucun “statut SLA” : un SLA est atteint ou manque, face a un seul objectif. Reconvertir le pourcentage obtenu en severite — le modele utilise auparavant — inventait une seconde echelle de severite par-dessus la vraie.

Chaque application porte deux dimensions independantes, et la performance est optionnelle :

• La condition d’impact est un plancher. La valeur par defaut de la disponibilite, ERROR (affichee “ERROR only” dans le formulaire), ne consomme le budget que sur une panne franche : un statut d’application CRITICAL est visiblement casse mais reste conforme. Reglez-la sur CRITICAL+ et CRITICAL consomme aussi le budget, MAJOR toujours pas. Le cout en disponibilite d’une degradation est un choix de politique interne, d’ou un defaut limite au seul point sur lequel toutes les installations s’accordent.
• La performance ne compte jamais ERROR. Un service qui n’a pas repondu est un defaut de disponibilite ; imputer la meme minute aux deux engagements ferait de l’indicateur de performance une copie strictement plus mauvaise de celui de disponibilite.
• Une application sans SLA de performance affiche —, pas 100%. Rien n’a ete promis, donc rien n’est rapporte. Les degradations colorent toujours les barres ; elles restent informatives tant que vous n’avez pas defini d’engagement.
• Les deux dimensions sont retroactives. Elles lisent la chronologie de statut de l’application, dont chaque mois stocke dispose deja : modifier un objectif ou une condition re-evalue tout l’historique au lieu d’en demarrer un nouveau.

Le webserver conserve un historique SLA mensuel (jusqu’a 24 mois) calcule depuis cette chronologie : pourcentage, duree impactee cumulee et nombre d’episodes par mois et par dimension, ainsi que le budget d’erreur — la part de l’allocation consommee, 0% intact, 100% exactement epuise, au-dela de 100% l’objectif est manque.

Un mois stocke enregistre le premier instant reellement mesure. Un mois dont l’historique commence le 21 est rapporte sur cette seule fenetre, jamais moyenne sur les semaines que personne n’a observees. Tant que la chronologie de statut remonte jusque-la, c’est elle qui fait foi et le mois stocke est recalcule a partir d’elle.

Le temps pendant lequel le webserver lui-meme ne tournait pas est traite de la meme facon. Le statut d’application est recalcule par le cron du webserver : une periode sans webserver derriere elle est une periode que personne n’a mesuree — elle est marquee comme absence de donnees plutot que de conserver le statut que la consolidation tenait au moment de l’arret, et elle quitte les deux dimensions des deux cotes du ratio.

Les exclusions SLA (presentees comme SLA corrections dans l’editeur d’application) — fenetres date/heure avec un motif, par exemple une maintenance convenue — quittent la mesure des deux cotes du ratio : le temps exclu est retire de la duree impactee et du total mesure. Une maintenance declaree n’est donc jamais creditee comme du temps de bon fonctionnement, et une panne survenue pendant une fenetre de maintenance n’est pas silencieusement pardonnee non plus. Modifier la liste des exclusions invalide et reconstruit les mois concernes.

Notifications et remediation

Les applications disposent des memes options d’alerte que les moniteurs, appliquees au statut agrege de l’application :

• notifications email, Slack, Teams et PagerDuty, chacune declenchee independamment sur echec et/ou changement de statut,
• un seuil de notification (notifyStatus : critical/major/minor) et un compteur notify after pour supprimer les oscillations,
• des scripts de remediation optionnels executes sur echec et/ou changement de statut, avec un delai d’expiration configurable.

Applications imbriquees

Une application peut contenir d’autres applications au lieu de (ou en plus de) tags. Les statuts des applications enfants sont agreges par la regle metier du parent, ce qui permet de modeliser des hierarchies comme :

Poste de travail numerique (application parente)
├── Messagerie (application : tags mail-prod)
├── Intranet (application : tags intranet-prod)
└── Visioconference (application : tags visio-prod)

L’imbrication est resolue recursivement partout ou les applications sont utilisees — y compris la portee des maintenances, ou selectionner une application parente met en maintenance tous les moniteurs de ses descendants.

Vues de dependances

Deux visualisations restituent le modele applicatif :

• Carte de dependances applicatives — un graphe 2D interactif des applications, de leurs applications enfants et de leurs moniteurs membres, colore par statut courant. Utilisez-la pour reperer quel membre degrade une application.
• Vue aerienne 3D (App 3D) — une scene 3D ou chaque application est une dalle disposee sur un plan, utile comme vue NOC/wallboard. La disposition est par utilisateur : glissez les dalles pour les arranger, enregistrez la disposition et la position de la camera, et televersez optionnellement un fond personnalise.

Voir Vues de dependances pour savoir comment les lire, y rechercher et y agir.

Import d’applications en masse

Les applications peuvent etre creees via les operations d’import/export avec le type app. Le format de ligne CSV est :

app;displayName;description;state (on|off);applications;tags;businessRule (worst|best|highestPercentage|weighted);WeightApi;WeightDb;WeightDiscovery;WeightExec;WeightNslookup;WeightPing;WeightSnmpdevice;WeightWmidevice;WeightSys;WeightTcp;WeightUdp;WeightUrl;threshCri;threshMaj;threshMin;notifyStatus;notifyAfter;emailOnF;emailOnSC;emailR;slackOnF;slackOnSC;slackChan;slackTok;teamsOnF;teamsOnSC;teamsWH;pdOnF;pdOnSC;pdAPI;ScriptOnF;ScriptOnSC;ScriptAction;ScriptActionT;image

applications ou tags est requis ; businessRule vaut worst par defaut.

Conseils de modelisation

• Une application par service metier, nommee comme le metier la nomme — les applications sont ce qui apparait sur les rapports et les wallboards.
• Appartenance par tags, pas par listes de moniteurs : les nouveaux moniteurs tagues de facon coherente rejoignent automatiquement les bonnes applications.
• Utilisez l’imbrication avec parcimonie — deux niveaux (service → macro-service) couvrent la plupart des organisations ; des arbres plus profonds rendent les consolidations de statut difficiles a interpreter.
• Choisissez worst sauf raison contraire : c’est la regle la plus conservatrice. Ne passez a weighted qu’une fois les poids valides avec le proprietaire du service.
• Alignez l’objectif de disponibilite et sa condition d’impact sur les valeurs contractuelles, et enregistrez les fenetres de maintenance comme exclusions SLA plutot que de supprimer l’historique. Ne definissez un SLA de performance que la ou il a reellement ete convenu — une application sans SLA affiche —, ce qui est exact, alors que 100% ne le serait pas.

Voir aussi

• Lire le rapport d’application — le panneau chronologique, ses pastilles, badges et tuiles SLA
• Operations sur les moniteurs — creation des moniteurs et des tags dont les applications sont constituees
• Operations sur les rapports — rapports d’application et rapports par tag
• Operations sur les periodes de maintenance — mise en maintenance d’applications entieres
• Operations d’import/export — creation d’applications en masse depuis un CSV

Traductions

• en: App definition and data modelling