Sur cette page

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 :

flowchart LR M["Moniteurs
(exec, URL, API, TCP, UDP, ping,
nslookup, BD, systeme, SNMP, WMI)"] -- "portent" --> T["Tags"] T -- "definissent l'appartenance aux" --> A["Applications"] A -- "peuvent imbriquer" --> A2["Applications enfants"] T -- "delimitent" --> U["Utilisateurs, rapports,
maintenances, dashboards"] A -- "delimitent" --> U
  • 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 :

Regle Statut agrege
worst (defaut) le statut le plus severe parmi les membres actifs
best le statut le moins severe parmi les membres actifs
highestPercentage le statut le plus frequent parmi les membres (egalite resolue vers le plus severe)
weighted la severite de chaque membre est multipliee par le poids de son type de moniteur ; la severite ponderee la plus elevee l’emporte

Les membres desactives sont exclus du calcul.

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.

Objectifs SLA et historique

Chaque application porte trois objectifs SLA mensuels (pourcentages de disponibilite) :

  • Minor (defaut 99), Major (defaut 95), Critical (defaut 90).

Le webserver calcule un historique SLA mensuel (jusqu’a 24 mois) a partir de la chronologie des changements de statut de l’application : pourcentage de disponibilite, duree cumulee des pannes et nombre de pannes par mois, evalues par rapport aux trois objectifs.

Les exclusions SLA — une liste de fenetres date/heure avec un motif (par exemple une maintenance convenue) — sont soustraites du temps de panne avant le calcul du pourcentage de disponibilite. 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.
  • Plan 3D (App 3D) — une scene 3D ou chaque application est une tuile disposee sur un plan, utile comme vue NOC/wallboard. La disposition est par utilisateur : glissez les tuiles pour les arranger, enregistrez la disposition et la position de la camera, et televersez optionnellement un fond personnalise. Disposition, camera et fond peuvent etre reinitialises a tout moment.

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 les objectifs SLA sur les valeurs contractuelles et enregistrez les fenetres de maintenance comme exclusions SLA plutot que de supprimer l’historique.

Voir aussi

Traductions

Operations de comparaison