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.
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.
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.
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'é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.
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.
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 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.
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.
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.
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 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.
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.
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.
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.
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é.
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.
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 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é.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.