Si chaque événement se comporte comme la même alarme, le signal critique se perd dans le bruit.
En environnement de production, tous les événements n'ont pas la même importance. La maintenance d'un backend, l'indisponibilité de tous les backends, le passage de l'IP de cluster vers un autre node, l'expiration d'un certificat dans 30 jours ou le dépassement du seuil de request rate exigent des réponses opérationnelles différentes. Si tout cela se transforme en une alarme email uniforme, l'équipe subit rapidement une fatigue d'alarme.
Dans les approches classiques, la notification se limite généralement à l'email et au syslog. Or les équipes d'exploitation veulent recevoir les différents événements par différents canaux : un failover critique par SMS, un avertissement de routine via l'UI, un événement de sécurité par SNMP ou Syslog, une synthèse pour les responsables par email. Sans séparation des canaux, soit tout le monde reçoit tout, soit les événements critiques passent inaperçus.
La gestion des heures silencieuses est également importante. Réveiller toute l'équipe à 03h00 pour un avertissement de faible importance est inutile ; mais une véritable interruption ou un changement d'IP de cluster doit néanmoins rester visible. Les heures silencieuses ne doivent pas signifier la disparition complète de l'événement, mais son traitement par le bon canal et au bon moment.
Rapporter avec le même texte des événements tels que pool down, backend down, cluster IP swap et fermeture de zone complique l'analyse de cause racine. L'opérateur tente d'abord de comprendre ce que signifie l'alarme, puis agit. Ce délai se répercute directement sur la qualité de service, en particulier sur les plateformes à fort trafic.
Le système de notification TR7 différencie les événements grâce au cycle de vie des alarmes, à plus de 30 clés d'état prêtes à l'emploi, au multi-canal, au multilingue, aux heures silencieuses et à la gestion des seuils par pool ; il les transmet à la bonne personne, par le bon canal, avec le bon contexte.
Notre approche
TR7 gère les notifications non pas comme des messages ponctuels, mais comme des objets d'alarme dotés d'un cycle de vie et des actions par canal.
La state machine d'alarme suit le cycle de vie de l'événement
Les alarmes actives sont conservées par alarmKey, mises à jour avec updateAlarm et clôturées avec endAlarm. Ainsi le même événement n'est pas regénéré encore et encore comme une nouvelle alarme ; le début, la mise à jour et la clôture de l'événement sont suivis.
La synchronisation du cluster rend l'alarme visible sur tous les nodes
L'état des alarmes et des notifications peut être transmis aux autres nodes du cluster. Ainsi l'équipe d'exploitation peut voir non seulement les événements du node auquel elle est connectée, mais aussi l'état critique à l'échelle de l'ensemble du cluster.
L'évaluation de l'état du pool répartit la santé du service en six classes
L'état du pool est classé selon les valeurs UNKNOWN, OK, WARN, DISABLED, ERR et EVALUATING. Ce modèle ne réduit pas les états de maintenance, d'avertissement, d'erreur et d'évaluation au même texte d'alarme plat.
La state machine d'IP de cluster suit le comportement de failover en détail
Les états d'IP de cluster sont évalués via différents signaux tels que l'accessibilité de l'interface, le conflit d'IP, la transition d'IP et le comportement à deux nodes. Les événements de failover sont transmis à l'équipe d'exploitation avec un contexte plus clair.
Capacités
Le système de notification offre le cycle de vie des alarmes, les seuils de pool, le multi-canal, le multilingue, les heures silencieuses, l'avertissement de certificat et un historique d'événements archivable.
Le cycle de vie de l'alarme gère le début, la mise à jour et la clôture du même événement
Le flux updateAlarm, endAlarm et getAlarms suit les alarmes actives avec leur cycle de vie. Lorsque le même alarmKey revient, l'événement est mis à jour ; il n'est pas dupliqué comme une alarme entièrement nouvelle. Le comportement de l'événement peut être géré de façon plus contrôlée grâce à des champs comme staticPayload, ifAbsent et dontNotify. Cette structure réduit le bruit d'alarme et rend l'historique des événements plus pertinent.
Les alertes arrivent sur le canal que l'ingénieur regarde vraiment
L'e-mail et le SNMP sont les endroits où les alertes vont pour être ignorées. Au-delà, TR7 délivre sur WhatsApp et BiP comme canaux à part entière, aux côtés du SMS, du syslog et des webhooks sortants vers Jira, Slack, Teams ou ServiceNow. Le canal se choisit par pool et par sévérité : un dépassement de seuil à 03h40 arrive là où quelqu'un regarde, pas dans une boîte qu'on ouvrira le matin.
La config notify par pool permet une sélection de seuil et de canal par service
Pour chaque pool, des seuils serviceStatus, poolStatus, bandwidth, request rate, current session et new connection peuvent être définis. Au sein de la même structure, les préférences de canal email, SMS, WhatsApp, BiP, SNMP et UI peuvent être déterminées. Ainsi un service critique peut être surveillé avec une politique d'alarme plus agressive, et un service de faible importance avec une politique plus silencieuse. Le comportement de notification n'est pas appliqué de façon uniforme à toute la plateforme.
Les canaux de notification multiples offrent une action adaptée aux différentes équipes d'exploitation
TR7 propose un modèle de notification prenant en charge plusieurs canaux comme email, SMS, WhatsApp, BiP, SNMP, Syslog et UI. Les événements d'infrastructure critiques peuvent être transmis par SMS ou SNMP aux systèmes de gestion réseau, les synthèses pour les responsables par email, les états de routine via l'UI. Le même événement peut être envoyé à différents canaux avec différentes priorités. Cette flexibilité réduit la dépendance à un gestionnaire d'alarmes externe.
Le moteur de modèles multilingue génère la notification dans la langue de l'utilisateur
NotificationTranslator peut générer les textes de notification dans différentes langues grâce à une logique de traduction basée sur un dictionnaire. Une équipe d'exploitation peut recevoir la notification dans une langue, une équipe internationale en anglais. Il est possible de transmettre le même événement à différents utilisateurs dans différentes langues. Cela réduit le risque de mauvaise interprétation dans les opérations multi-pays.
Plus de trente clés d'état de pool et de cluster fournissent une cause racine détaillée
Plus de 30 clés d'état comme poolDisabled, allBeDown, noBeGiven, beDown, beStateUnknown, beMaint, poolDown, poolInterfaceAbsent, zoneClosed, clusterIpBoth, clusterIpPossibleCollide, clusterIpSwitched et clusterIpNone peuvent être utilisées. Ces clés rendent le texte d'alarme plus explicite. L'opérateur ne reçoit pas seulement un message « service en difficulté » ; il voit aussi le type du problème. Le temps d'intervention se raccourcit.
silentAtNight contrôle le comportement des canaux pendant les heures silencieuses
Avec silentAtNight, certaines notifications peuvent être mises en sourdine pendant les heures nocturnes. Cela ne signifie pas la disparition complète de l'événement ; il peut rester visible dans l'UI ou être inclus dans la synthèse du matin. En appliquant une politique de canal distincte pour les événements critiques, les alarmes réellement importantes peuvent tout de même être transmises. La fatigue d'alarme est réduite tout en préservant la visibilité opérationnelle.
Un avertissement automatique peut être généré à l'approche de l'expiration d'un certificat
Grâce au champ notifyDaysBeforeCertificateExpiry, un avertissement peut être généré un certain nombre de jours avant la date d'expiration du certificat. Par exemple, une notification email ou UI peut être envoyée 30 jours avant. Ainsi l'opération de renouvellement du certificat n'est pas repoussée au dernier jour. Les oublis susceptibles de provoquer une interruption TLS sont détectés à un stade précoce.
Le modèle de contact group permet une distribution par utilisateur et par équipe
Les membres d'un contact group peuvent être définis avec des adresses email, des numéros SMS et des informations de type d'utilisateur. Les notifications peuvent être dirigées vers un utilisateur unique, un groupe d'équipe ou un type d'utilisateur. Ce modèle facilite le ciblage séparé des équipes d'astreinte, SOC, SRE ou groupes de responsables. Les changements de personnes peuvent être gérés sans perturber la politique de canal.
La configuration SMTP s'adapte à l'infrastructure email de l'entreprise
Les paramètres SMTP host, port, authentication, username, password, sécurité TLS, validation de certificat, sender name, sender address, cc, bcc, attachment et message HTML peuvent être configurés. La valeur de timeout de connexion email peut être maintenue autour de 10 secondes. Cette structure facilite l'intégration avec le mail relay ou l'infrastructure SMTP existante de l'entreprise. Les notifications email peuvent être adaptées aux politiques de marque et de sécurité.
L'archive de logs conserve l'historique des alarmes et notifications dans une archive compressée
Les logs d'alarme et de notification peuvent être archivés sous des noms distincts. Grâce à la compression zip et à un niveau de compression élevé, les événements passés peuvent être conservés pour l'audit et l'examen. L'historique des notifications peut servir de preuve dans les processus PCI, de gestion du changement ou d'analyse post-incident. Il peut fonctionner avec des processus d'archivage externes sans perdre la visibilité locale.
NotificationType distingue si l'événement est une alarme, une notification ou une information
Le champ NotificationType fait la distinction entre alarme, notification et info avec des classes comme A, N et I. Cette distinction est importante pour la criticité de l'événement et la façon dont il est présenté à l'utilisateur. Chaque message d'information ne se comporte pas comme une alarme ; chaque alarme ne se perd pas non plus comme une simple notification. Le comportement de l'UI et des canaux externes peut s'alimenter de cette classification.
Le regroupement par Pair ID suit ensemble la même famille d'événements
Le champ pairId de BasicNotification peut être utilisé pour associer les notifications appartenant au même groupe d'événements. Par exemple, l'ouverture, la mise à jour et la clôture d'une alarme peuvent être suivies au sein de la même famille d'événements. Cela facilite la vue d'ensemble de la chaîne d'événements côté SIEM ou audit. Au lieu de messages isolés, l'ensemble du processus de l'événement peut être analysé.
Profondeur opérationnelle
Le système de notification fonctionne conjointement avec les valeurs de statut, les noms de log, la compression, la sécurité SMTP et la state machine d'IP de cluster.
Valeurs de pool status
Les valeurs de pool status sont classées comme UNKNOWN=-1, OK=0, WARN=1, DISABLED=2, ERR=3 et EVALUATING=4. Ce modèle numérique fournit une base cohérente pour l'évaluation des alarmes et l'affichage dans l'UI. Les états ne sont pas seulement traités comme du texte, mais comme des valeurs décidables.
Logs d'alarme et de notification
Les logs d'alarme peuvent être conservés sous le nom basic-alarms, les logs de notification sous le nom basic-notifications. Cette séparation permet d'examiner séparément le cycle de vie des événements et les notifications transmises à l'utilisateur. Les processus d'exploitation et d'audit peuvent lire différents types de logs selon leurs besoins propres.
Compression des logs
Les archives d'alarmes et de notifications peuvent être conservées au format zip avec un niveau de compression élevé. Cela réduit le coût de conservation à long terme. L'accès aux enregistrements de notification passés est facilité pour l'audit.
Catalogue de clés d'état prédéfinies
Plus de 30 clés d'état prêtes à l'emploi se trouvent sous `_lb.*`. Ces clés sont utilisées pour décrire plus finement les comportements de pool, backend, interface, zone et IP de cluster. Le texte de notification et la logique de décision s'enrichissent grâce à ces clés.
Comportement de connexion SMTP
Lors de l'envoi d'email, la valeur de timeout de connexion peut être configurée à 10000 ms. La sécurité TLS et le comportement de validation de certificat sont contrôlés par l'utilisateur. Cela permet d'intégrer le mail relay selon les exigences de sécurité de l'entreprise.
State machine d'IP de cluster
Les états d'IP de cluster sont interprétés par une state machine distincte. Les situations telles que l'inaccessibilité de l'IP, l'état de l'interface, un éventuel conflit ou une transition de node peuvent être converties en valeurs d'état d'IP de cluster consolidées. Les alarmes de failover sont générées plus précisément avec ce contexte.
Dans quels scénarios l'utiliser
Gérer un événement backend down nocturne de façon silencieuse mais visible
Lorsqu'un événement backend down de faible importance survient à 02h00, silentAtNight peut arrêter l'envoi d'email. L'événement reste actif dans l'UI et peut être inclus dans la synthèse du matin. Ainsi les alarmes nocturnes inutiles sont réduites, sans que l'événement disparaisse complètement.
Avertissement de renouvellement automatique avant l'expiration d'un certificat
L'équipe d'exploitation peut régler la valeur notifyDaysBeforeCertificateExpiry à 30 jours. À l'approche de l'expiration du certificat, le système génère une notification email ou UI. Les risques de renouvellement de dernière minute susceptibles de provoquer une interruption TLS diminuent.
Transmettre un événement de failover d'IP de cluster par un canal critique
Lorsque l'IP de cluster passe vers un autre node, l'événement clusterIpSwitched peut être généré. Cet événement peut être transmis à l'équipe d'exploitation par SMS, SNMP ou UI. Lorsque le failover se produit, l'équipe en est informée au moment de l'événement, et non après.
Transmettre un dépassement de seuil WAAP ou de trafic au système de gestion réseau
Lorsqu'un seuil de request rate, bandwidth, session ou new connection est dépassé, une notification SNMP peut être générée. Le système de gestion réseau reçoit cet événement dans son propre tableau d'alarmes. Les équipes de sécurité et d'exploitation réseau voient le même seuil dans un flux de surveillance commun.
Archiver l'historique des notifications pour un audit PCI
Les logs d'alarme et de notification peuvent être conservés sous forme d'archive compressée. Lors d'un audit, on peut montrer quel événement s'est produit et quand, quel canal a été utilisé et si l'alarme a été clôturée. L'historique des notifications devient une preuve d'exploitation.
Envoyer des alarmes dans différentes langues à une équipe d'exploitation multilingue
Tandis qu'une équipe reçoit la même alarme par email dans une langue, l'équipe d'exploitation internationale peut recevoir le message en anglais. NotificationTranslator génère le texte de l'événement selon la langue de l'utilisateur. Dans les opérations multi-pays, le risque de mauvaise compréhension de l'alarme est réduit.
Questions fréquentes
Quels canaux de notification sont pris en charge ?
Comment fonctionnent les heures silencieuses ? L'événement disparaît-il complètement ?
Que signifient les 30+ clés de pool status ?
Comment fonctionne le cycle de vie de l'alarme ?
Les notifications peuvent-elles être envoyées dans différentes langues ?
Quelles options existent pour la configuration SMTP et email ?
Centralisez la gestion des événements avec le bon canal et le bon contexte
Cycle de vie des alarmes, plus de 30 clés d'état, multi-canal et heures silencieuses. Montrons-le sur une installation en direct dans votre propre environnement.