Logo Mugnsoft Mugnsoft
Journal des versions

Notes de version Core

Informations détaillées sur chaque version de la plateforme de supervision Mugnsoft Core — serveur web, sondes, agent sentinelle et intégrateur. Vous cherchez le constructeur de parcours portable ? Consultez les notes de version Pulse. Pour le guide d'installation, rendez-vous sur doc.mugnsoft.com/installation.

v4.3.0

dernière

La v4.3.0 ajoute l'alerting SIGNL4, passe PagerDuty à l'Events API v2 et rend l'interface plus agréable au quotidien : une vue 3D plus fluide, des messages plus clairs quand un composant ne répond pas, et des exports CSV qui constituent une sauvegarde complète. La mise à jour depuis la 4.2.x se fait sans action particulière, dans l'ordre habituel (integrators, sondes, agents sentinel, webserver, puis webserver-front). Votre configuration, vos seuils et vos destinations d'alerte sont conservés tels quels.

＋ Nouveautés

  • Alerting SIGNL4. Les alertes peuvent être envoyées à une équipe SIGNL4 via son webhook entrant, avec les mêmes interrupteurs On fail et On change que les autres canaux. Chaque moniteur ouvre une seule alerte SIGNL4, fermée automatiquement quand il repasse OK. Renseignez le secret d'équipe sur le moniteur, ou un secret par défaut sur l'integrator. Les synthèses d'application et les agents sentinel peuvent aussi alerter SIGNL4, et le réglage suit les exports et imports de moniteurs.
  • PagerDuty Events API v2. Les alertes PagerDuty passent par l'Events API v2, qui remplace la v1 dépréciée. Chaque moniteur garde un seul incident : les alertes suivantes y sont regroupées et le retour à OK le résout. La sévérité de l'incident suit le statut (CRITICAL, MAJOR / ERROR, MINOR), le détail de l'alerte arrive en custom details, et un lien ouvre le moniteur dans la vue 3D. Vos clés d'intégration PagerDuty restent en place.
  • Envoi d'une notification de test. Depuis les réglages de l'integrator, envoyez une alerte de test par e-mail, Slack, Teams, PagerDuty, SIGNL4 ou script. Elle part de l'hôte de l'integrator, par le même chemin que les vraies alertes. Laissez la destination vide pour tester celle enregistrée par défaut.
  • Priorité de statut des moniteurs URL et API. Quand un moniteur a des groupes de patterns, choisissez comment se combinent le verdict des patterns et le temps de réponse : le plus sévère des deux (par défaut, inchangé), les patterns d'abord, le temps de réponse d'abord, ou les patterns seuls.

▲ Améliorations

  • Vue 3D. Les applications imbriquées sont disposées en grille de sous-applications. La vue météo garde sa propre disposition, distincte de la vue standard. Seul Enregistrer la disposition mémorise les positions : quitter la page ne les enregistre plus par mégarde. Faire défiler une popup ne déplace plus la caméra, et le survol des applications est plus précis.
  • Messages plus clairs sur les composants. Toutes les pages disent la même chose quand une sonde ou un integrator ne répond pas, et précisent si l'hôte est injoignable, si le service est arrêté ou s'il n'a envoyé aucune donnée. L'ajout d'un composant explique pourquoi la connexion a échoué (injoignable, délai dépassé ou refusée), et le formulaire garde ce que vous avez saisi.
  • Sauvegardes CSV complètes. Les utilisateurs, les rapports et les maintenances s'exportent et s'importent désormais comme les moniteurs et les applications. Les logos d'application sont intégrés au fichier, et une ligne utilisateur emporte ses dispositions et caméras 3D, ses préférences d'affichage, son fond et sa photo de profil : un profil passe d'une installation à l'autre en un seul fichier. Les rapports et maintenances importés sont planifiés aussitôt.
  • Imports plus sûrs. Réimporter un moniteur existant conserve les seuils ajustés depuis l'export. Une ligne en erreur est signalée avec son numéro et ce qu'il faut corriger, et le reste du fichier est importé.
  • Les rapports d'application couvrent les sous-applications à toute profondeur. Les moniteurs associés se chargent d'eux-mêmes, et chaque type de rapport affiche un aperçu des moniteurs qu'il couvre.
  • Les graphiques de métriques des composants affichent les coupures et les silences en bandes aucune donnée au lieu de tracer une ligne par-dessus, et les graphiques des rapports de moniteur suivent la même règle.
  • La page de comparaison classe les moniteurs sur les bons chiffres, et le calcul de baseline d'une sonde indique ce qu'il a mis à jour ou ignoré.
  • Nouvelles traductions en français et en espagnol sur les nouveaux écrans.

✕ Corrections

  • La session web pouvait expirer pendant la navigation entre les pages, ou au réveil de l'ordinateur. Elle est désormais renouvelée à temps.
  • Une alerte pouvait afficher une mauvaise durée pour un nouveau statut, par exemple un CRITICAL tout juste apparu indiquant depuis 3 j après trois jours OK.
  • Derrière un proxy, les moniteurs URL lisent désormais le certificat sur la connexion du contrôle lui-même, en respectant le proxy et le délai du moniteur. Les moniteurs en http simple ne lèvent plus de fausse alerte certificat bientôt expiré.
  • Un contrôle de moins de 1 ms ou de plus d'une minute pouvait perdre son résultat. Les résultats envoyés à un integrator lent ne sont plus interrompus puis envoyés deux fois.
  • Les sondes sur un réseau filtré peuvent télécharger les web drivers EUM via leur proxy sortant.

⬢ Mises à jour des composants

  • Les messages du client HTTP des sondes vont désormais dans monitor.log, avec le moniteur, la cible et le proxy, sans jamais inclure d'identifiants ni de paramètres d'URL.

v4.2.0

La v4.2.0 ajoute la supervision WebSocket et Kubernetes / Docker, sépare le SLA en disponibilité et performance, et place une timeline de statut sur chaque application. Les rapports peuvent être envoyés en PDF, et l'interface comme les rapports sont disponibles en français et en espagnol. Lisez d'abord Avant la mise à jour : l'usage de la licence compte désormais les moniteurs WebSocket et workload, les licences sont liées à une empreinte matérielle, le secret interne des composants n'est plus partagé, et la clé de signature des versions a changé.

⬢ Avant la mise à jour

  • L'usage de la licence compte les moniteurs WebSocket et workload. Chaque moniteur WebSocket et chaque moniteur workload coûte 1 point, comme un moniteur URL ou TCP. Un moniteur workload existe une fois par sonde ; le container host lui-même reste gratuit, comme les équipements SNMP et WMI. Au-delà de la limite, rien ne s'arrête — seule la création de moniteurs est refusée, depuis l'interface, l'API et la découverte. Comptez-les avant la mise à jour et demandez une extension de licence si nécessaire.
  • Les licences sont liées à une empreinte matérielle. Une licence webserver ou intégrateur est désormais générée à partir de l'empreinte du serveur sur lequel le composant s'exécute, ce qui remplace la liaison à une adresse IP. Capturez-la avec l'outil d'empreinte de la page de téléchargement et envoyez-nous le jeton. Une machine virtuelle redimensionnée conserve sa licence ; les licences déjà émises continuent de fonctionner.
  • Définissez votre propre secret interne entre composants. _sharedInternal est le mot de passe de adminMNS, le compte que les composants utilisent pour se piloter entre eux, et les paquets précédents livraient la même valeur à tous les clients. Les paquets 4.2.0 le livrent vide : un nouveau webserver en génère un aléatoire au premier démarrage, et chaque composant journalise un avertissement SECURITY tant qu'il utilise une valeur livrée dans un paquet. Il n'y a plus de valeur par défaut intégrée — placez la même valeur dans webserver.json, monitor.json, integrator.json et discovery_agent.json, puis redémarrez, sinon Resync tokens, Enable et Push Settings échouent avec un HTTP 401.
  • Mettez à jour de la périphérie vers le centre : intégrateurs, sondes, agents sentinelle, webserver, puis webserver-front. Un webserver 4.2.0 devant des sondes plus anciennes affiche les nouveaux types de moniteurs mais ne peut pas les créer sur ces sondes.
  • Les métriques d'E/S processus de l'agent sentinelle changent d'unité. iostatRead et iostatWrite mesurent désormais le débit par processus en Ko/s. Revoyez les seuils posés sur ces deux métriques.
  • Les e-mails d'alerte ont un nouvel objet, qui commence par le statut et le fait principal — par exemple [MAJOR] web-shop · Execution time: 580 ms · probe-paris. Les règles de messagerie qui filtrent l'ancien objet Mugnsoft - … status is … doivent être mises à jour.
  • La clé de signature des versions a changé. Les archives sont signées avec une nouvelle clé à partir de cette version, et les archives des versions précédentes ont été signées à nouveau avec elle. Importez à nouveau Mugnsoft_public.key avant de vérifier un téléchargement — empreinte 65F8 B880 F8CC 9DCF D2C8 4887 8FEE 1578 1BEF 9B7A.

＋ Nouveautés

  • Moniteur WebSocket. Ouvre une session, envoie vos messages, valide les réponses et évalue les temps de connexion, de latence et de session, avec contrôle de l'expiration et de l'identité du certificat comme le moniteur URL.
  • Supervision des conteneurs (Kubernetes et Docker). Un équipement container host découvre les workloads via l'apiserver Kubernetes ou l'API Docker Engine ; adoptez ceux à surveiller et chacun devient un moniteur workload (replicas, redémarrages, OOM kills, CrashLoopBackOff). La dérive est réconciliée : les nouveaux workloads sont proposés, ceux qui disparaissent sont conservés et désactivés.
  • Sonde dans Kubernetes. Un chart Helm et une image de sonde allégée exécutent une sonde dans le cluster qu'elle supervise.
  • SLA disponibilité et performance. Un SLA est désormais une cible plus une condition d'impact, suivi séparément pour la disponibilité et, en option, la performance.
  • Timelines d'application. Des timelines de statut dans le tableau des applications, dans le rapport d'application et sous la puce de statut de chaque application dans la vue 3D.
  • L'interface en français et en espagnol. Chaque utilisateur choisit sa langue dans son profil ; notifications, dialogues, tableaux et infobulles la suivent.
  • Rapports en français et en espagnol, en HTML ou en PDF. Chaque rapport a une langue, suivie par sa page et son e-mail, et peut être envoyé en HTML, en PDF ou les deux. Le PDF est imprimé par un Chrome, Chromium ou Edge sans interface sur l'hôte du webserver ; si aucun n'est trouvé, le rapport HTML est envoyé à la place et le résultat de l'envoi en donne la raison.
  • Des rapports qui s'ouvrent sans accès Internet. Le paramètre HTML report libraries du webserver peut embarquer les bibliothèques de graphiques dans chaque rapport HTML envoyé, pour environ 820 Ko de plus par fichier. Le comportement par défaut est inchangé.
  • Contrôles de colonnes pour les bases de données. Un moniteur base de données peut évaluer des valeurs de son jeu de résultats, comme un groupe de patterns le fait pour les moniteurs URL et API. Les groupes de patterns et les contrôles de colonnes acceptent aussi string in / string not in, number between / number outside, et un contrôle de contenu « ne doit pas contenir ».
  • Modes du moniteur UDP — joignabilité seule ou requête / réponse, pour qu'un statut et un temps de réponse UDP n'affirment que ce que le protocole peut prouver.
  • Destinations de notification par défaut sur l'intégrateur. Un moniteur qui active un canal sans renseigner de destination est délivré à la destination par défaut de l'intégrateur ; une destination définie sur le moniteur l'emporte toujours.
  • Événements : cause racine au niveau service, suppression et moniteurs en pause. Le bandeau d'incident nomme le service, pas seulement l'hôte ; les événements peuvent être sélectionnés et supprimés ensemble ; un moniteur ou une application désactivé apparaît PAUSED au lieu de not reporting.
  • Les changements d'adresse sont propagés. Quand l'adresse d'un intégrateur est modifiée dans Components, les sondes et les agents sentinelle la reçoivent, avec une nouvelle tentative toutes les 5 minutes pour ceux qui étaient injoignables, et les résultats mis en tampon pour l'ancienne adresse sont envoyés à la nouvelle.
  • SMTP « Vérifier le certificat » — un interrupteur dans les paramètres SMTP, respecté par tous les composants. Désactivé par défaut : les serveurs de messagerie à certificat auto-signé continuent de fonctionner.

▲ Améliorations

  • Les notifications d'alerte affichent les mêmes informations sur chaque canal (e-mail, Slack, Teams, PagerDuty) : statut et depuis combien de temps, cible, sonde et localisation, heure du contrôle et message. Les e-mails sont colorés selon la sévérité et contiennent une partie texte brut ; les alertes Teams sont des Adaptive Cards et les webhooks Power Automate Workflows sont pris en charge.
  • Les rapports de moniteur gagnent un bandeau de synthèse (part de contrôles OK, contrôles non OK par sévérité, temps de réponse moyen / p95 / min / max), des barres de temps de réponse colorées selon le statut, des panneaux de gigue et de perte de paquets dans les rapports ping, et un panneau par groupe de patterns numérique dans les rapports URL, API et base de données.
  • Les moniteurs WebSocket, WMI et workload ont leur propre section dans les rapports All et d'application, et un downtime peut couvrir les moniteurs WebSocket et workload.
  • Les rapports planifiés ressemblent au rapport affiché dans l'interface, rapports EUM, d'application et All compris.
  • Les sauvegardes copient toutes les bases d'un composant dans un dossier par exécution, lisible uniquement par le compte de service ; Backup all demande le rôle admin.
  • Les paquets Linux s'extraient avec leurs programmes exécutables (binaires, scripts, JDK et ffmpeg embarqués) : plus besoin de chmod +x après la décompression.
  • Les nouveaux tags sont enregistrés en minuscules ; les tags existants gardent leur orthographe.

✕ Corrections

  • Un moniteur URL dont la requête échouait complètement (connexion refusée, timeout, erreur DNS ou de certificat) affichait ERROR sur sa propre page mais n'atteignait jamais l'intégrateur : aucun événement, aucune notification. Un moniteur URL dont la configuration de proxy était inutilisable n'était pas remonté du tout. Les deux sont désormais remontés comme tout autre résultat — mettez à jour vos sondes pour bénéficier de cette correction.
  • Un moniteur URL ou API en échec donne désormais la cause — l'erreur de la requête, ou le statut HTTP renvoyé, par exemple The API answered HTTP 500 Internal Server Error. — au lieu de Failed to reach the API. Les règles de messagerie qui filtrent sur l'ancien texte sont à mettre à jour.
  • API REST : POST /api/apis échouait avec un simple 400 dès que headers était omis ou contenait de vrais en-têtes. Les en-têtes sont désormais optionnels et acceptés sous forme d'objet JSON ou du tableau d'objets documenté.
  • L'export des moniteurs API écrivait les en-têtes de requête sous une forme qui ne pouvait pas toujours être réimportée ; il écrit désormais un objet JSON, et l'import accepte toujours l'ancienne liste.
  • Les moniteurs URL et API créés via l'API REST avec insecureCert enregistraient une valeur que la sonde ignorait. Un tel moniteur créé avec insecureCert: true commence à ignorer la vérification du certificat après la mise à jour, comme demandé à sa création.
  • L'export des contrôles système échouait ; les équipements SNMP v3 utilisant SHA-224 à SHA-512 ou AES-192/256 pouvaient être exportés mais pas réimportés ; l'import d'un hôte refusait notifyStatus écrit en minuscules.
  • La page des événements pouvait marquer tout le parc not reporting quand une sortie d'intégrateur était lente.
  • Les timelines affichaient de fausses barres unknown.
  • Les rapports UDP n'étaient jamais envoyés, et les rapports ping affichaient des valeurs en microsecondes étiquetées en millisecondes.
  • Réplication ADMIN vers webserver-front : une copie plus ancienne pouvait écraser une plus récente, les suppressions n'atteignaient pas toujours le front, et la session d'un utilisateur supprimé restait valide.
  • Les rapports EUM traçaient une nouvelle série à chaque modification d'un script : les étapes sont désormais fusionnées par nom.
  • Les sauvegardes omettaient les configurations des moniteurs SNMP / WMI et les container hosts sur le webserver, et l'historique de supervision des logs et des dossiers sur l'agent sentinelle.
  • La page /docs de l'agent sentinelle affichait l'API du webserver au lieu de la sienne.
  • Corrections de l'audit pré-version sur tous les composants, notamment l'alerting et la supervision des logs et des dossiers.

⬢ Mises à jour des composants

  • Tous les composants sont compilés avec Go 1.27.2 et des dépendances à jour. À la sortie de la version, govulncheck ne signale aucune vulnérabilité connue atteignable depuis un composant.
  • Le compte machine adminMNS n'est plus livré avec un mot de passe partagé, et le webserver-front ne porte jamais ce compte.
  • Outil d'empreinte de licence v1.0.0 pour Linux et Windows, signé comme les archives, sur la page de téléchargement.

v4.1.1

La v4.1.1 améliore la clarté et la cohérence de l'interface afin de rendre la navigation et l'exploitation des données plus simples au quotidien.

▲ Améliorations

  • Présentation des rapports améliorée pour une lecture plus claire.
  • Navigation inter-vues plus claire et plus cohérente.
  • Tooltips enrichis pour fournir davantage de contexte et d'informations utiles.
  • Interface harmonisée avec des espacements, une mise en page des tableaux et des styles de navigation active plus cohérents dans toute l'application.

v4.1.0

La v4.1.0 rend la découverte consciente des protocoles : chaque connexion capturée est désormais étiquetée avec le protocole ou le framework applicatif qu'elle transporte réellement — gRPC, WebSocket, Arrow Flight SQL, HTTP/2, PostgreSQL, Redis, Kafka, MQTT — accompagné du signal qui a produit le verdict et du degré de confiance associé. Elle met également fin à la configuration à l'aveugle : les OID SNMP et les requêtes WMI sont proposés depuis un catalogue puis vérifiés en direct sur la cible via la sonde, les règles de log et de répertoire peuvent être essayées sur le fichier réel, et les fenêtres d'indisponibilité, les exclusions de SLA et les périmètres de rapport montrent tous ce qu'ils vont affecter avant d'être validés.

＋ Nouveautés

  • Identification du protocole applicatif sur la carte de découverte. Les arêtes de flux portent désormais le protocole ou le framework qu'elles transportent. Trois signaux indépendants alimentent le verdict : les signatures présentes dans les premiers octets d'un flux (HTTP/1.x, HTTP/2, gRPC, Arrow Flight SQL, WebSocket, PostgreSQL, MySQL, Redis, AMQP, Kafka, MongoDB, MQTT, SSH), les métadonnées de la poignée de main TLS (ALPN et SNI, toujours en clair), et l'inférence par processus et par port en dernier recours. Chaque étiquette indique sa source (dpi, alpn, process, port) et son niveau de confiance (observed, inferred, guessed) : un protocole déduit ne peut donc jamais être pris pour un protocole mesuré. La carte peut être filtrée par protocole, et la détection peut être désactivée agent par agent.
  • Assistants OID SNMP et requêtes WMI. Les deux types d'équipement proposent des métriques issues d'un catalogue indexé par type d'équipement, vérifient l'ensemble de la sélection en une fois sur la cible réelle via la sonde, et permettent d'enregistrer des modèles nommés réutilisables. Un explorateur de parcours d'OID et un explorateur de classes WMI sont disponibles pour tout ce que le catalogue ne couvre pas.
  • Calendrier des indisponibilités et aperçu de l'impact. Les fenêtres d'indisponibilité peuvent être parcourues sous forme de calendrier mensuel, à côté du tableau existant, avec un sélecteur de plage pour la période. Avant l'enregistrement, un aperçu de l'impact liste précisément les moniteurs et les applications que la fenêtre va rendre silencieux.
  • Fenêtres d'exclusion de SLA. Les périodes de maintenance ou d'incident connu peuvent être exclues du calcul de disponibilité SLA, avec un motif documenté. Les interruptions survenues dans une fenêtre ne comptent plus contre le SLA, et les périodes corrigées sont signalées par une ★ dans l'historique SLA.
  • Aperçu du périmètre d'un rapport. Chaque type de rapport peut résoudre à la demande, depuis son formulaire, sa sélection de tags, d'applications et de sondes en la liste réelle des moniteurs qu'il va couvrir.
  • Provenance des seuils. Pour chaque métrique système et processus, l'interface indique si le seuil qui a gouverné l'exécution provient de la base de référence automatique ou du repli fixe — une valeur fixe alors que l'automatique est activé signifie que la base de référence n'était pas disponible. Les seuils fixes sont modifiables métrique par métrique, et les bases de référence peuvent être recalculées à la demande.
  • La disponibilité de la capture est signalée, plus devinée. Lorsqu'un hôte ne dispose d'aucun moteur de capture de paquets, la topologie le dit explicitement au lieu d'afficher un trafic nul qui ressemble à un hôte inactif. Une vue fusionnée ne revendique la capture que si tous les agents contributeurs en disposaient.
  • Test des moniteurs de log et de répertoire. Les règles de log et les règles de répertoire peuvent être exécutées sur le fichier ou le dossier réel depuis l'interface, et leurs correspondances inspectées, avant l'enregistrement du moniteur.
  • Plusieurs groupes de motifs nommés par moniteur URL et API, évalués selon le statut le plus dégradé, avec des vérifications contains et des corps de requête typés selon leur content-type.
  • Panneau de test des moniteurs URL et API — un moniteur peut être exécuté à la demande depuis son formulaire et les étapes obtenues inspectées, aux côtés d'une visionneuse HAR intégrée réécrite.
  • CPU iowait et nombre de sockets TCP ajoutés à la supervision système côté sonde.

▲ Améliorations

  • Les notifications d'alerte sont unifiées : les messages e-mail, Slack, Teams et PagerDuty portent tous le type de moniteur, la sonde d'origine et une couleur de statut, et se présentent de façon identique qu'ils aient été envoyés directement par une sonde ou routés par l'intégrateur.
  • La liste consolidée des moniteurs gagne un filtre par type à sélection multiple, des contrôles de pagination déplacés dans l'en-tête du tableau, et une mise en page cohérente entre les tableaux de moniteurs, d'applications et de serveurs.
  • Le trafic de boucle locale est regroupé en une seule arête par flux, la direction étant déduite de la socket en écoute ; la capture de la boucle locale est elle-même activable agent par agent.
  • Les seuils de découverte traitent partout une valeur vide comme « non défini », et signalent erreurs et avertissements de validation à l'enregistrement d'une configuration.
  • Validation plus stricte des dates et heures dans les vérifications de motifs URL et API.
  • La validation de licence est mise en cache au lieu d'être relue sur les chemins critiques, et n'écrit qu'une seule ligne de journal au lieu de se répéter.
  • Les tâches planifiées sont protégées contre les paniques, sur le serveur web comme sur la sonde : une tâche défaillante n'emporte plus l'ordonnanceur avec elle.
  • La sauvegarde vers un dépôt accepte une URL de base GitLab auto-hébergé, avec une aide à la configuration intégrée pour GitLab et GitHub.
  • Le générateur de configuration de composant introduit en v3.2.0 couvre désormais les moniteurs URL et API, les règles de log, les règles de répertoire, la capture de trafic et le routage des notifications, et le JSON produit peut être copié autant que téléchargé.
  • Finitions d'interface : survol synchronisé des graphiques et enregistrement de ceux-ci, composant d'attente partagé, empilement des panneaux latéraux, et vues de découverte servies sur le serveur frontal en lecture seule en DMZ.
  • Supports de formation (présentations Consultation, Utilisateur et Administrateur, en anglais et en français) actualisés pour cette version.

✕ Corrections

  • Calcul des seuils de l'agent Sentinel : les séries plates sont ignorées, les fenêtres de performance vides ne produisent plus de bases de référence absurdes, et un nombre minimal d'échantillons est exigé avant qu'une base de référence soit jugée fiable.
  • La supervision des processus en boucle locale attribuait le trafic au mauvais processus.
  • Les seuils de l'agent de découverte n'étaient pas repris dans le panneau de détails.
  • Vérification de connectivité des services externes de l'intégrateur.
  • Métriques de répertoire : comptage des fichiers, comptage récursif et taille totale corrigés, y compris pour les répertoires absents et les règles désactivées.
  • Exposition des métriques des groupes de motifs, export et import des moniteurs URL et API, et régressions de mise en page et de filtrage sur la liste consolidée.

⬢ Mises à jour des composants

  • Agent de découverte Sentinel — identification des protocoles avec mise en cache par flux ; supervision des logs durcie face à la rotation par troncature et par renommage, avec regroupement de lignes, échantillons de lignes capturées, contrôles de rafale et de silence de débit ainsi que de fraîcheur ; métriques de répertoire refondues ; regroupement des arêtes de boucle locale ; remontée de l'état de la capture.
  • Sonde de supervision — test et parcours d'OID en lot, test de requêtes WMI et exploration des classes derrière les assistants de configuration ; corps de requête API typés selon le content-type ; validation des dates et heures dans les vérifications de motifs ; calcul des seuils automatiques refondu ; détection des processus appartenant à la sonde pour nettoyer les navigateurs et processus CLI orphelins ; scripts d'installation et de désinstallation Linux et refonte de la concurrence.
  • Intégrateur — vérification de connectivité des services externes corrigée, et charges utiles d'alerte alignées sur le nouveau format de notification.
  • Analyse prédictive — livrée sous forme d'exécutable autonome, avec une résolution cohérente de la fenêtre et de l'horizon, et un arrêt anticipé activé uniquement lorsque la plage temporelle produit réellement un lot de validation (avec un avertissement explicite dans le cas contraire).

v4.0.0

La v4.0.0 est une version majeure sur trois fronts. Les équipements SNMP et WMI deviennent des objets supervisés de premier plan, avec auto-découverte et leur propre place sur la topologie. Une réplique en lecture seule du serveur web peut désormais être publiée en DMZ, alimentée par une réplication mTLS unidirectionnelle : les statuts peuvent ainsi être exposés hors du réseau de confiance sans exposer la plateforme. Enfin, l'identité passe à l'authentification unique, avec une billetterie ITSM branchée directement sur l'état des moniteurs.

＋ Nouveautés

  • Supervision des équipements WMI. Les hôtes Windows peuvent être supervisés via des requêtes WMI, avec un statut par équipement, un tableau d'équipements dédié, un onglet d'actions et un panneau de détails scindé.
  • Équipements SNMP. Les équipements distants deviennent des équipements SNMP, objets supervisés à part entière, avec auto-découverte SNMP, une colonne de statut globale et leur propre représentation sur la carte de topologie.
  • Serveur frontal en lecture seule en DMZ. Un second serveur web peut être déployé en DMZ et alimenté par une réplication mTLS unidirectionnelle depuis le serveur web de confiance. Il sert une vue en lecture seule, ne requiert aucune licence propre, et applique un délai de grâce configurable sur les statuts afin que les transitions brèves n'atteignent jamais la vue publique.
  • Authentification unique OIDC — une troisième méthode d'authentification, aux côtés des comptes locaux et de LDAP.
  • Billetterie ITSM. Les tickets ServiceNow, GLPI et Jira sont créés et clôturés à partir de l'état des moniteurs, la résolution s'en remettant au côté ITSM afin qu'un ticket déjà pris en charge par un humain ne soit pas clôturé automatiquement.
  • Les parcours utilisateur en client lourd (GUI) gagnent le rejeu, et les alertes EUM portent désormais l'information de dépassement par transaction.
  • Une seule liste consolidée de moniteurs. Les onze pages par type de moniteur sont remplacées par une liste unique couvrant tous les types, avec filtrage par type.
  • Vue applicative 3D : vue simplifiée et partage. Un rendu « météo » simplifié pour les publics non techniques, une disposition et une caméra enregistrées par utilisateur, et la vue entière intégrable dans une iframe.
  • Supervision de l'utilisation des inodes de systèmes de fichiers, indisponibilité au niveau applicatif, légende des statuts, rapports en panneaux latéraux et photos de profil des utilisateurs.
  • Supports de formation : présentations Consultation, Utilisateur et Administrateur, en anglais et en français.

▲ Améliorations

  • Pages d'équipement refondues : panneau de détails scindé, onglet d'actions, icônes dans le tableau, et mises à jour de moniteur qui conservent les données collectées.
  • Les données de statut sont purgées lorsque les moniteurs qui les ont produites sont supprimés.
  • Performance et sûreté : libération des scènes 3D, durcissement contre le XSS, concurrence bornée dans les chemins de nettoyage de fichiers, et correction d'un accès concurrent sur l'accumulation de bande passante.
  • Espacements, mise en page des tableaux et style de navigation active homogènes dans toute l'interface.

✕ Corrections

  • Les moniteurs SNMP n'étaient pas planifiés au démarrage ; mises à jour des équipements SNMP et moniteurs UDP corrigés.
  • Import des moniteurs API.
  • Fuites mémoire sur la page des équipements SNMP et dans la vue applicative 3D.
  • Dépliage du graphe applicatif, sous-applications sur le serveur frontal, défilement de la bannière 3D, et boucle de rafraîchissement des équipements.

⬢ Mises à jour des composants

  • Serveur web frontal — nouveau composant : réplique en lecture seule en DMZ, aucune licence requise, réplication mTLS unidirectionnelle, délai de grâce configurable sur les statuts.
  • Sonde de supervision — prise en charge de WMI, correction de la planification SNMP au démarrage, purge des données de statut obsolètes, corrections de fuites mémoire, concurrence bornée dans les chemins de nettoyage, rejeu des parcours GUI et remontée des dépassements EUM par transaction.
  • Agent de découverte Sentinel — supervision des inodes de systèmes de fichiers, métriques système supplémentaires, et correction d'un accès concurrent sur l'accumulation de bande passante.

v3.3.0

La v3.3.0 ajoute les deux éléments qui transforment la supervision en reporting : des chiffres de SLA défendables, et une prévision qui montre une métrique se diriger vers son seuil avant qu'elle ne l'atteigne. L'agent de découverte apprend par ailleurs à lire les fichiers de log.

＋ Nouveautés

  • Reporting SLA. La disponibilité est calculée et restituée sous forme de SLA, avec une pondération par élément supervisé et des corrections manuelles pour les périodes qui ne doivent pas compter comme mesurées.
  • Prévision. Chaque type de moniteur peut porter des champs de prédiction, alimentés par le moteur d'analyse prédictive : une métrique qui tend vers son seuil se voit donc avant qu'elle ne le franchisse.
  • Supervision des fichiers de log sur l'agent de découverte. Règles de motifs sur les fichiers de log avec alerte, positions de lecture conservées entre les redémarrages, et nombre de lignes lues par cycle borné. Le nombre de connexions à la base de données est supervisé et alerté de la même manière.
  • Bases de référence automatiques. Les métriques système globales obtiennent des bases de référence calculées automatiquement sur l'agent, et la gigue de ping des seuils calculés automatiquement sur la sonde, remontés par l'API à côté des valeurs mesurées.

▲ Améliorations

  • L'alerte sur processus manquant suit la même sémantique notifyAfter et notifyFor que toutes les autres alertes.
  • Configuration de l'agent de découverte : tableaux de seuils compacts et interrupteurs de trafic à la place de longs formulaires.
  • Présentation des rapports : étiquettes de chronologie, dimensionnement des camemberts, et contrôles de visibilité et de capture rapprochés.
  • Mise en cache des expressions régulières et purge de rétention sur l'agent, avec un plafond configurable de lignes lues par cycle.

✕ Corrections

  • L'écart type de la gigue débordait sur de grandes valeurs ; il est désormais calculé en flottant.
  • Gestion du TTL ICMP annulée sur les sockets brutes Windows, où elle n'est pas prise en charge.
  • Panique à l'enregistrement de l'agent et échecs d'authentification administrative.
  • Couleur de statut des événements MINEUR dans le navigateur d'événements.

⬢ Mises à jour des composants

  • Agent de découverte Sentinel — supervision des fichiers de log avec alerte et persistance des positions de lecture, supervision des connexions à la base de données, bases de référence automatiques pour les métriques système globales, mise en cache des expressions régulières et purge de rétention.
  • Sonde de supervision — seuils de gigue avec calcul automatique et remontée par l'API, champs de prédiction sur tous les types de requête de moniteur.
  • Analyse prédictive — prise en charge d'InfluxDB v3, LSTM agrandi, arrêt anticipé, taille de fenêtre configurable et scripts de prise en main.

v3.2.0

La v3.2.0 vise à retrouver ses éléments dans un grand parc. Chaque carte et chaque liste gagne une barre de recherche, la vue applicative 3D se souvient de la façon dont chaque utilisateur l'a laissée, et le trafic réseau devient un seuil de plein droit plutôt qu'un chiffre à lire sur un graphique.

＋ Nouveautés

  • Recherche partout — une barre de recherche dans la carte de topologie d'infrastructure, la vue applicative 3D, la vue des applications et la liste des moniteurs, afin de localiser un élément sans savoir où il se trouve.
  • Seuils de trafic. Le trafic entrant et sortant peut recevoir des seuils avec une fenêtre de moyennage configurable : une rafale brève ne déclenche pas d'alerte, une charge soutenue si.
  • Une vue tableau de la liste consolidée des moniteurs, avec suppression par sélection multiple, à côté de la vue en cartes existante.
  • Générateur de configuration de composant. Un assistant conversationnel guidé produit, question par question, les fichiers de configuration de la sonde, de l'intégrateur et de l'agent Sentinel, avec remise à zéro possible à tout moment et téléchargement du JSON obtenu.
  • Nouvelles métriques système de l'agent de découverte : iowait, CPU utilisateur et d'autres, tracées aux côtés des métriques existantes.

▲ Améliorations

  • Vue applicative 3D : disposition et caméra enregistrées par utilisateur, image de fond par utilisateur, bannière de statut, fenêtre d'aide et barre de synthèse.
  • Graphes de topologie d'infrastructure et de serveurs redessinés, avec les services externes affichés dans la topologie des composants et le nom des interfaces porté sur les arêtes.
  • Les notifications en échec sont mises en tampon sur disque et réessayées, sur le serveur web, la sonde et l'agent.
  • Le routage des alertes gagne la sémantique notifyAfter et notifyFor.
  • Refonte de l'éditeur de planification : jours sous forme de pastilles, synthèse en direct de la planification obtenue, et contrôles de validité.
  • Passes d'analyse de sécurité et de fuites mémoire sur le serveur web, la sonde et l'agent, avec réduction des allocations dans le code Go.

✕ Corrections

  • La synchronisation du zoom entre graphiques ne s'achevait pas sur tous les graphiques.
  • L'état des arêtes était incorrect lorsqu'un nœud était désactivé.
  • Intervalle de rafraîchissement du statut des serveurs dans la vue 3D.
  • Listes des URL et des API de l'agent de découverte.

⬢ Mises à jour des composants

  • Agent de découverte Sentinel — seuils de trafic avec fenêtre de moyennage, nouvelles métriques système, informations d'arête enrichies, corrections de mémoire et de performance.
  • Sonde de supervision — tampon de reprise des notifications sur disque, réduction des allocations et corrections issues de l'analyse de sécurité.
  • Intégrateur — tampon de reprise sur disque pour les envois de notification en échec.

v3.1.0

La v3.1.0 reconstruit la supervision SNMP sur la sonde et apprend à la carte de découverte à rendre compte du volume, pas seulement de la forme : le trafic réseau entrant et sortant est désormais comptabilisé par processus et affiché sur la carte.

＋ Nouveautés

  • Supervision SNMP reconstruite. SNMP devient un module à part entière sur la sonde, avec une planification et un traitement des résultats refondus, et une vue de configuration et de résultats correspondante dans l'interface.
  • Trafic réseau par processus. L'agent de découverte comptabilise le trafic entrant et sortant de chaque processus découvert, et la carte de découverte l'affiche à côté des flux existants.

▲ Améliorations

  • Les nœuds et les arêtes de la carte de découverte portent des informations plus riches, et la mise en page de la configuration de l'agent a été refondue autour de celles-ci.
  • La configuration des composants est transportée encodée entre le serveur web et la sonde : aucun caractère d'une définition de moniteur ne peut donc casser un envoi de configuration.
  • Fuites mémoire corrigées côté navigateur et ressources web livrées allégées.

⬢ Mises à jour des composants

  • Sonde de supervision — SNMP extrait dans un module dédié, transport de la configuration des moniteurs refondu, gestion des webdrivers simplifiée.
  • Agent de découverte Sentinel — comptabilisation du trafic entrant et sortant par processus.

v3.0.0

La v3.0.0 vise à voir l'ensemble du parc d'un seul coup d'œil. Les applications et leurs moniteurs sont disposés dans une vue 3D navigable, et l'agent de découverte passe de l'inventaire de processus à un véritable récit de statut : une chronologie par périmètre, un graphe rejouable dans le temps, les métriques système et de performance par processus, et les flux réseau entre processus.

＋ Nouveautés

  • Vue 3D des applications et de leurs moniteurs : chaque application est un plan portant ses moniteurs, colorés selon leur statut, avec sous-applications imbriquées, détails au survol (type, sonde, statut, tags) et une position de caméra et une disposition enregistrées par utilisateur. Vue applicative 3D Vue 3D du parc
  • Chronologie de statut de la découverte, séparée en périmètres global, système et processus, avec le nombre de changements d'état et le temps passé en état dégradé sur la période sélectionnée. Chronologie de statut et graphe de découverte
  • Les flux réseau entre processus découverts sont représentés sur le graphe de découverte avec leur volume de trafic, aux côtés des métriques CPU, mémoire, swap et E/S par processus et des métriques système de l'hôte lui-même. Flux réseau entre processus Flux réseau entre processus

▲ Améliorations

  • Le graphe de découverte s'explore par niveau de profondeur, se replie, et peut être rejoué à un instant antérieur au lieu de n'afficher que l'état courant.
  • Un fichier de configuration unique de l'agent porte désormais tout ce dont celui-ci a besoin : processus et ports supervisés, systèmes de fichiers, seuils automatiques et fixes par métrique, moniteurs URL et API dont il a la charge, et routage de ses notifications. Configuration de l'agent de découverte

✕ Corrections

  • Les graphiques de découverte ne s'affichaient pas pour les métriques sans données sur la période sélectionnée.

v2.6.0

La v2.6.0 apporte une refonte complète du cœur de Mugnsoft, avec des améliorations significatives de la supervision de la performance des applications web grâce à l'agent de découverte. Cet agent simplifie l'accès aux métriques système et de performance d'un serveur hôte et des processus supervisés, en identifiant ces processus et leurs métriques, y compris les communications interprocessus. Tous les éléments supervisés sont désormais regroupés sur une seule page web, ce qui rend la supervision de la performance plus efficace. Ces évolutions visent à améliorer la supervision de la performance des applications web métier. Grâce aux règles de propagation métier, les utilisateurs comprennent mieux la façon dont chaque élément supervisé affecte la performance et la disponibilité de l'application.

▲ Améliorations

  • L'import depuis des fichiers CSV est simplifié. Import de fichier CSV
  • Amélioration de l'interface web pour une expérience utilisateur simple et efficace.
  • Les alertes sont désormais centralisées dans le composant Intégrateur, ce qui simplifie les flux réseau. Alerte centralisée Alerte centralisée

✕ Corrections

  • Corrections de bugs mineurs.

＋ Nouveautés

  • La version précédente avait posé les fondations de l'agent de découverte, chargé d'identifier les processus, leurs métriques système et de performance, ainsi que les communications interprocessus. Cette version introduit officiellement l'agent de découverte. Supervision par agent de découverte Supervision par agent de découverte Supervision d'hôte distant Les flux réseau entre processus sont découverts automatiquement, et les seuils des métriques système et de performance peuvent être configurés automatiquement.
  • Un navigateur d'événements est disponible pour afficher les alertes en cours. Navigateur d'événements
  • Les statuts des applications sont mieux organisés et offrent une vue d'ensemble claire en un coup d'œil.
  • Les statuts des applications peuvent désormais être partagés publiquement et intégrés dans une page web. Statuts d'application intégrés Statuts d'application intégrés

v2.5.0

La v2.5.0 introduit l'exécution distante de scripts et de binaires, ce qui permet de superviser n'importe quoi sans installer d'agent. Cette version comprend également des corrections de bugs mineurs. Elle pose par ailleurs les fondations d'un agent de découverte, qui sera introduit dans la version suivante.

▲ Améliorations

  • Meilleure gestion de l'import de fichiers CSV pour créer des lots de moniteurs. Import de fichier CSV
  • Cette version pose également les fondations de l'agent de découverte, qui sera chargé d'identifier les processus, leurs métriques système et de performance, ainsi que les communications interprocessus.

✕ Corrections

  • Les en-têtes du moniteur API sont désormais correctement disposés. En-têtes API

＋ Nouveautés

  • Vous pouvez superviser tout ce que vous voulez sans installer d'agent, en définissant des hôtes distants et en y déposant les scripts ou binaires nécessaires. Les hôtes distants peuvent être gérés par une ou plusieurs sondes de supervision. Supervision d'hôte distant Supervision d'hôte distant Supervision d'hôte distant Supervision d'hôte distant À la définition d'un hôte distant, 2 moniteurs (tcp et ping) de type SYS sont créés automatiquement. L'état (activé/désactivé) de ces 2 moniteurs constitue l'état de l'hôte distant lui-même.

v2.4.0

La v2.4.0 introduit une fonctionnalité inédite : la supervision des parcours utilisateur en client lourd. Concrètement, vous pouvez désormais utiliser Mugnsoft pour superviser de grosses applications clientes riches (non web, de type IDE). Avec la sortie de Zabbix 7.0 en juin, Mugnsoft prend déjà en charge cette version de Zabbix.

▲ Améliorations

  • Il est possible de se connecter à l'API Zabbix à l'aide d'un jeton d'API Zabbix. Connexion par jeton Zabbix
  • Il est possible de se connecter à la dernière version 7.0 de Zabbix. Zabbix v7
  • Il est possible de planifier des fenêtres d'indisponibilité récurrentes. Planifier des indisponibilités récurrentes

✕ Corrections

  • Certains graphiques historiques échouaient à s'afficher en l'absence de données.

＋ Nouveautés

  • Voici la supervision des parcours utilisateur en client lourd ! Mugnsoft permet désormais de superviser les parcours utilisateur sur de grosses applications clientes riches (de type IDE, non web). Suivez et analysez les interactions de vos utilisateurs en temps réel pour améliorer la performance et leur satisfaction. Supervision de client lourd

v2.3.0

La v2.3.0 apporte des améliorations mineures et les nouveautés détaillées ci-dessous.

▲ Améliorations

  • Il est possible de se connecter à l'API Zabbix à l'aide d'un jeton d'API Zabbix. Connexion par jeton Zabbix
  • Il est possible de planifier des fenêtres d'indisponibilité récurrentes. Planifier des indisponibilités récurrentes

✕ Corrections

  • Sans objet

＋ Nouveautés

  • Il est désormais possible de récupérer identifiant et mot de passe depuis les secrets d'un coffre-fort de clés.
    Les coffres-forts pris en charge sont actuellement :
    • Hashicorp Vault Hashicorp Vault
    • Azure Key Vault Azure Key Vault
    • Cyberark Conjur Vault Cyberark Conjur Vault
    Coffre-fort de clés dans l'IDE Mugnsoft Coffre-fort de clés du serveur web Mugnsoft Coffre-fort de clés de la sonde Mugnsoft

v2.2.0

La v2.2.0 apporte des corrections de bugs mineurs.

✕ Corrections

  • Ajustement de la couleur des applications dans l'arbre de services.
  • Application : l'état et le statut de l'application de plus haut niveau n'étaient pas correctement reflétés dans l'arbre de services.
  • Multi-tenant : les utilisateurs ayant une application définie dans leur profil ne voyaient pas toujours cette application dans la page des applications.

v2.1.0

La v2.1.0 apporte 1 nouveauté : la possibilité d'enregistrer des scénarios comportant une authentification multifacteur TOTP. Et 1 amélioration : les alertes Mugnsoft dans Zabbix sont plus descriptives.

▲ Améliorations

  • Les alertes dans Zabbix sont désormais plus descriptives. Davantage de détails sur un événement Mugnsoft dans Zabbix

＋ Nouveautés

  • Il est désormais possible d'enregistrer et de rejouer des scénarios avec authentification multifacteur TOTP activée. Authentification multifacteur TOTP

v2.0.0

La v2.0.0 introduit des améliorations de l'interface de supervision de la performance des applications web. Cette version permet de filtrer une supervision complète des éléments critiques d'une application web : temps de connexion TCP, résolution DNS, contrôle de métriques distantes et performance des requêtes en base de données. Tous les éléments supervisés sont désormais accessibles depuis une seule page web, ce qui fluidifie le processus de supervision de la performance. Ces évolutions visent à améliorer la supervision de la performance des applications web métier. Grâce aux règles de propagation métier, les utilisateurs comprennent mieux l'impact de chaque élément supervisé sur la performance et la disponibilité de l'application.

▲ Améliorations

  • Améliorations cosmétiques de l'interface. Le menu de navigation de l'en-tête a été réorganisé. Mise en page
  • Le rapport de métriques de supervision utilisateur final a été redessiné. Mise en page

＋ Nouveautés

  • Filtrage des éléments critiques d'une application web : temps de connexion TCP, résolution DNS, contrôle de métriques distantes et performance des requêtes en base de données. Nouvel élément supervisé
  • Tous les éléments supervisés sont désormais accessibles depuis une seule page web, ce qui fluidifie le processus de supervision de la performance. Nouvel élément supervisé
  • Définition d'applications et supervision de leur performance. Grâce aux règles de propagation métier, les utilisateurs comprennent mieux l'impact de chaque élément supervisé sur la performance et la disponibilité de l'application. Applications Applications

v1.8.0

Du côté du cœur de Mugnsoft, cette v1.8.0 apporte des améliorations notables à l'interface web. Tous les composants sont désormais regroupés sur une seule page web, et les scénarios web peuvent être déployés automatiquement en fonction de l'utilisation des sondes. L'algorithme d'auto-déploiement sélectionne les sondes les moins chargées, tandis que les composants embarquent des graphiques d'utilisation des métriques système pour comparer CPU, mémoire et charge moyenne.

▲ Améliorations

  • Améliorations cosmétiques de l'interface. Le menu de navigation de l'en-tête a été réorganisé et les composants ont été déplacés sur la même page web. Mise en page

✕ Corrections

  • Repli sur les versions précédentes des webdrivers chromedriver, geckodriver et msedgedriver lorsque celles correspondant à la version de navigateur demandée sont introuvables.
  • L'URL de téléchargement automatique de chromedriver a changé.
  • Scintillement du graphique d'infrastructure des statistiques de sondes.
  • Les graphiques des rapports sur 4 semaines ne s'affichaient pas correctement.
  • Problème de calcul de base de référence automatique résolu pour la plage de 4 semaines.

＋ Nouveautés

  • Auto-déploiement : les scénarios web peuvent désormais être déployés automatiquement sur les sondes les moins chargées. La décision d'auto-déploiement s'appuie sur l'utilisation des métriques système, dont le CPU, la mémoire et la charge moyenne. Cette fonctionnalité est particulièrement utile pour répartir la charge de la supervision des parcours utilisateur. Auto-déploiement Auto-déploiement
  • Les certificats auto-signés peuvent être échangés de façon sécurisée entre composants en cas de migration d'adresse IP.
  • Tous les composants disposent désormais de leurs propres graphiques de métriques système. Métriques système Métriques système
  • Des points d'accès supplémentaires ont été ajoutés à la page Swagger de tous les composants. Cette évolution facilite encore la création d'intégrations sur mesure. Swagger

v1.7.0

Cette version apporte des améliorations de l'interface web et la gestion des tags. Les moniteurs, URL et API peuvent être regroupés par groupes de tags.

▲ Améliorations

  • Améliorations cosmétiques de l'interface. Mise en page

＋ Nouveautés

  • Gestion des tags : les moniteurs, URL et API peuvent être regroupés par groupes de tags. C'est particulièrement utile lorsque vous devez les regrouper par fonctionnalité et souhaitez les afficher tous en un clic. De plus, l'affichage des tags et des groupes de tags peut désormais être activé ou désactivé. Gestion des tags Gestion des tags

v1.6.0

Cette version apporte des améliorations de l'interface web (tableau de bord, mise en page). Le mécanisme de filtrage par tags a été enrichi — ce qui encourage encore davantage l'usage des tags pour organiser ses actifs. La couleur du tag dans la barre latérale gauche reflète l'élément de plus forte sévérité. Améliorations des privilèges utilisateur, avec des profils complets et restreints. Les LLD, itemprototype et triggerprototype de l'intégration Zabbix en un clic sont créés automatiquement au niveau du modèle, avec la prise en charge de Zabbix 6.x. Toutes les métriques (dont First Contentful Paint, Page Interactive Time, Network Latency, Page Load Time, DNSLookup, TCPConnTime, TLSHandshake, ServerTime) sont désormais envoyées vers Influx 1.x et 2.x et peuvent être tracées dans des tableaux de bord Grafana, Splunk ou Kibana. Toutes les données sensibles sont chiffrées dans les magasins KV.

▲ Améliorations

  • Améliorations globales de la mise en page : en-tête des éléments (moniteurs, URL, API), couleurs, etc.
  • Améliorations du filtrage par tags : les éléments peuvent être regroupés par tags. La couleur d'un tag dépend de la sévérité la plus forte parmi les éléments étiquetés. Tags colorés

✕ Corrections

  • Les tags sont correctement définis par les utilisateurs.
  • Le commutateur de filtrage ne fonctionnait pas.

＋ Nouveautés

  • Filtrage par tags. Filtrage par tags
  • Des privilèges restreints peuvent être attribués aux utilisateurs. Avec des privilèges complets un utilisateur peut ajouter de nouveaux tags, ce qu'il ne peut pas faire avec des privilèges restreints. Privilèges utilisateur
  • Les LLD, itemprototype et triggerprototype de l'intégration Zabbix en un clic sont créés automatiquement au niveau du modèle.
    Prise en charge de Zabbix 6.x. Intégration Zabbix
  • Toutes les métriques (dont First Contentful Paint, Page Interactive Time, Network Latency, Page Load Time, DNSLookup, TCPConnTime, TLSHandshake, ServerTime) sont désormais envoyées vers Influx 1.x et 2.x et peuvent être tracées dans des tableaux de bord Grafana, Splunk ou Kibana. Tableau de bord Grafana
  • Les données sensibles sont chiffrées dans les magasins KV.
  • Chaque composant est livré avec sa page Swagger, ce qui permet des tests d'API personnalisés et facilite l'intégration avec d'autres outils. Swagger

v1.5.0

Cette version apporte des améliorations de l'interface web. Des graphiques sparkline sont désormais disponibles pour les URL et les API. Chaque élément supervisé dispose d'un indicateur de tendance qui aide à repérer quelle application web se comporte le mieux sur les dernières 24 h, 7 jours et 4 semaines.

▲ Améliorations

  • Améliorations cosmétiques de l'interface. Des graphiques sparkline sont désormais disponibles pour les URL et les API. Sparkline

＋ Nouveautés

  • Indicateur de tendance qui aide à repérer quelle application web se comporte le mieux sur les dernières 24 h, 7 jours et 4 semaines. Tendance Tendance
  • Des captures automatiques sont prises au début et à la fin de chaque transaction des éléments supervisés. Capture de transaction

v1.4.0

Cette version améliore l'enregistrement des composants. Elle corrige des bugs du processus d'enregistrement. Améliorations cosmétiques avec de nouvelles icônes.

▲ Améliorations

  • Améliorations cosmétiques de l'interface. De nouvelles icônes sont utilisées.

✕ Corrections

  • L'enregistrement d'un composant était signalé en échec alors que le composant s'était en réalité correctement auto-enregistré.

＋ Nouveautés

  • Vous pouvez auto-enregistrer un composant depuis la ligne de commande. Auto-enregistrement

v1.3.0

Cette version ajoute la prise en charge de la supervision d'URL et d'API à travers des proxys simples ou authentifiés, ainsi que des améliorations cosmétiques.

▲ Améliorations

  • Améliorations cosmétiques de l'interface.

＋ Nouveautés

  • Vous pouvez superviser des URL et des API à travers des proxys simples ou authentifiés. L'import depuis un fichier CSV, pour les URL comme pour les API, a été mis à jour en conséquence. Proxy

v1.2.0

Cette version apporte une nouvelle fonctionnalité : l'import d'une liste d'URL depuis des fichiers CSV, ainsi que d'une liste d'API depuis des fichiers CSV. Vous commencez à superviser un ensemble d'URL rapidement et efficacement.

＋ Nouveautés

  • Vous pouvez importer une liste d'URL ou d'API depuis des fichiers CSV. Import CSV

v1.1.0

Cette version apporte une fonctionnalité majeure en matière de test de charge de site web : le composant loadtest, intégré de façon transparente aux autres composants du cœur Mugnsoft. Testez la performance de votre site web en période de pointe et voyez comment vos transactions supportent la charge.

＋ Nouveautés

  • Vous pouvez réaliser facilement votre test à partir du scénario que vous avez construit ou du fichier HAR généré. Autrement dit, vous pouvez réutiliser un scénario de moniteur existant pour bâtir votre cas de test de charge. Test de charge
  • Vous obtenez des statistiques sur le plan de test de charge. Vous pouvez en déduire ce qui doit être optimisé. Statistiques de test de charge Statistiques de test de charge

v1.0.0

Cette version apporte de nouveaux graphiques et de nouvelles fonctionnalités concernant la supervision des URL, des certificats et des API. L'ensemble du processus d'enregistrement d'une sonde a été refondu. Il s'agit désormais d'un auto-pré-enregistrement auprès du serveur web — ce qui apporte de l'agilité au processus d'ajout de nouvelles sondes ou de nouveaux intégrateurs. Par ailleurs, l'échange de certificats TLS entre les composants Mugnsoft est désormais transparent : il est automatique. Autrement dit, une infrastructure Mugnsoft simple et sécurisée (1 serveur web, 1 sonde, 1 intégrateur) peut être déployée en moins de 2 minutes.

＋ Nouveautés

  • Les graphiques existants peuvent n'afficher que les données de sondes ou de localisations sélectionnées. Filtrer par localisation ou par sonde
  • De nouveaux graphiques — nombre d'exécutions et temps de réponse min, max, moyen — n'affichent que les données des localisations sélectionnées. Nouveaux graphiques
  • La supervision d'URL comprend désormais le contrôle d'intégrité et d'expiration des certificats. Contrôle de certificat d'URL
  • La supervision d'API est désormais disponible. Vous pouvez suivre la performance de vos points d'accès d'API. Supervision d'API
  • Auto-pré-enregistrement des composants Mugnsoft (fonctionne de façon transparente sous Linux) :
    À l'installation d'une sonde, celle-ci peut s'auto-pré-enregistrer. Son enregistrement complet auprès du serveur web doit toutefois être effectué par un administrateur du serveur web. Auto-pré-enregistrement des composants
  • Communication sécurisée entre les composants Mugnsoft :
    Les composants peuvent communiquer de façon sécurisée à l'aide de certificats d'entreprise ou auto-signés. Ces certificats sont ensuite échangés automatiquement entre pairs Mugnsoft de confiance. Communication sécurisée entre composants

v0.1.1

▲ Améliorations

  • Le chemin réseau s'affiche ou se masque selon la sélection dans le sélecteur de HAR. Chemin réseau Chemin réseau

✕ Corrections

  • Ajustement des couleurs du chemin réseau : en vert les passerelles (IP) qui ont répondu, en rouge les délais dépassés et les non-réponses (ce qui peut être tout à fait normal — le fournisseur peut simplement avoir mis en place une règle filtrant les paquets ICMP/UDP utilisés par le traceroute).

＋ Nouveautés

  • Chemin réseau calculé pour l'URL de base de toutes les ressources utilisées. Traceroute
  • Possibilité d'émuler une connexion Internet lente (disponible pour les navigateurs Chrome et Edge). Limitation de débit

v0.1.0

Version initiale.