Corticon.js aide à fournir des notifications pertinentes dans la surveillance de systèmes et d’applications complexes.

Lors de la surveillance de systèmes et des applications qui y sont exécutées pour des déploiements à grande échelle, de nombreux événements de surveillance sont générés. A partir de ces événements, des alertes sont générées et des notifications doivent être envoyées aux utilisateurs intéressés. Cependant, très vite, trop de notifications sont envoyées et les différents utilisateurs responsables de ces systèmes et applications peuvent être débordés.

Les utilisateurs doivent recevoir uniquement les alertes les plus pertinentes pour eux. Ceci peut être réalisé en laissant les utilisateurs définir des règles pour obtenir uniquement ce qu’ils veulent. Par exemple, certains utilisateurs peuvent n’être responsables que de deux applications parmi toutes les applications, et ils ne sont responsables que de celles-ci dans un sous-domaine de l’infrastructure globale surveillée. Ils devraient recevoir des notifications par e-mail pour les alertes non critiques et par SMS pour toutes les alertes critiques.

Ça se complique rapidement

Cet exemple est relativement simple, mais les choses peuvent se compliquer rapidement . Pour avoir une idée de la complexité du domaine du problème, examinons deux exemples supplémentaires.

Premier exemple :

Un client a trois charges équilibreurs avec deux applications sur chacun (app-prod1, app-prod2, app-stage1, app-stage2, app-dev1, app-local-dev1).

Les notifications d’alerte peuvent être configurées comme ceci :

• dev-team1 ne recevra que les notifications relatives à app-dev1 et app-local-dev1 de 9h à 17h, du lundi au vendredi ; toutes les autres doivent être ignorées.
• l’équipe de développement1 doit également être informée des problèmes survenant sur app-prod1 et app-prod2 24h/24 et 7j/7, mais uniquement s’ils sont critiques
• L’équipe QA recevra des notifications sur l’application -étapes 1 et 2.
• L’équipe d’infrastructure recevra les notifications générées par les trois équilibreurs de charge.

Deuxième exemple :

Un client dispose d’un équilibreur de charge avec cinq applications :

• Serveur de messagerie MS Exchange
• Serveur Web Apache
• WordPress int ernal
• Blog public
• Serveur FTP

Les notifications d’alerte peuvent être configurées comme ceci :

• L’équipe QA recevra des notifications sur les étapes 1 et 2 de l’application.
• L’équipe d’infrastructure recevra les notifications générées par les équilibreurs de charge.
• Le serveur Web Apache et les notifications internes WordPress seront envoyées à l’équipe de développement Web et à l’équipe de développement, mais uniquement si la gravité est critique.
• Les notifications de blog Exchange et Public seront envoyées à la personne sur le canal d’appel, mais uniquement si la gravité est critique et c’est en dehors des heures de travail.
• Les notifications du serveur FTP sont ignorées uniquement si c’est en dehors des heures de travail.

Avantages de l’utilisation de Corticon.js

Comme vous pouvez le voir dans les exemples précédents, le nombre de cas d’utilisation et de combinaisons peut augmenter très rapidement. L’implémentation de tout cela dans le code est complexe et difficile à maintenir. Une solution, mise en œuvre par l’un de nos clients, consiste à utiliser Corticon.js comme moteur de règles sans code pour traiter les événements et les alarmes et décider si ceux-ci doivent être envoyés à des utilisateurs spécifiques.

Il existe plusieurs avantages à utiliser un système de règles comme Corticon.js :

• Les règles ne sont pas codées en dur dans le code principal de l’application. Cela évite les codes difficiles à créer et à maintenir sur le backend. Plus important encore, il en résulte une mise sur le marché plus rapide car les règles de Corticon.js ont été mises en œuvre par les commerciaux, libérant ainsi un temps précieux pour les développeurs sur l’application de surveillance principale.
• Les règles peuvent être testées directement dans Corticon ; cette amélioration de la productivité car elle s’est traduite par une intégration très fluide entre le service de décision de règles et le backend.
• Corticon.js est une solution cloud native ; le client a pu intégrer le processus décisionnel très rapidement, car il s’intègre dans son modèle existant.
• Agilité améliorée, car il est très facile de maintenir et d’étendre les règles pour des cas d’utilisation supplémentaires. Par exemple, le client envisage d’ajouter des règles supplémentaires pour décider du canal de communication (e-mail, SMS, etc.) à utiliser en fonction de l’heure et de la criticité des événements.
• Aucune maintenance du code : modifications apportées au règles et l’ajout de règles supplémentaires se fait entièrement dans Corticon. Ils sont atteints avec un déploiement simple du nouveau service de décision, qui est entièrement automatisé via un pipeline CI/CD. Le point important est que de nouveaux cas d’utilisation peuvent être implémentés sans modification du code du backend.
• Il était facile pour le client d’exécuter les services de décision Corticon en tant que micro-services en tant que support pour Node.js, et Les fonctions sans serveur leur ont permis de s’exécuter dans des conteneurs en utilisant l’infrastructure et l’écosystème du client existant.

En conclusion

Pour ce client, l’utilisation d’un système de règles comme Corticon .js a rapporté d’importants dividendes, car ils peuvent arriver plus rapidement sur le marché, confiants dans leur capacité à maintenir et à étendre facilement le système.

Découvrez ici comment Corticon, en tant qu’environnement sans code/à faible code, peut vous aider à augmenter votre productivité et à fournir vos solutions plus rapidement. 

Et vous pouvez vous inscrire à un formation gratuite pour Corticon.jsici.

Inscrivez-vous à une formation Corticon gratuite

Source link