Glean utilise un modèle single-tenant (en fournissant à chaque client un projet GCP dédié) pour déployer nos services et offrir la meilleure expérience possible en matière de sécurité. Un défi majeur auquel nous sommes toutefois confrontés est la supervision et l’exploitation de multiples projets GCP à mesure que notre base de clients grandit. Des alertes multiples, issues de projets GCP distincts, peuvent se déclencher simultanément, ce qui complique leur gestion. ;
Le service Error Reporting de Google rencontre le même problème : une même exception applicative peut se produire au même moment dans plusieurs projets GCP. Dans cet article, nous expliquons comment nous utilisons notre outil Notification Dispatcher pour faire évoluer nos capacités de monitoring dans le Cloud.
Principaux défis
Pour gérer efficacement plusieurs projets GCP, nous devons conserver une vue globale des notifications d’alerte et des exceptions applicatives sur l’ensemble de nos projets GCP. Cela nous aide à comprendre à quel point un incident de production s’est propagé à l’échelle globale, et nous permet de trier et traiter les problèmes de production de manière efficace.
Cloud Monitoring Alerting prend en charge de nombreux types de canaux de notification, mais ne propose pas d’intégration Jira. Error Reporting ne prenait pas en charge les notifications au moment où l’outil Notification Dispatcher a été développé. Comme Glean est une entreprise orientée recherche, nous voulons connecter ces services GCP critiques liés à la production à d’autres applications SaaS comme Jira — et surtout rendre l’information consultable et transformer les résolutions en connaissances partageables.
De plus, nous développons de nombreuses fonctionnalités maison qui nous permettent de gérer, de façon unifiée, les mêmes problèmes pour plusieurs projets.
Présentation de l’outil Notification Dispatcher
Notification Dispatcher est l’outil interne de Glean pour gérer les notifications d’alertes GCP et les erreurs Error Reporting. Il est intégré à Cloud Monitoring et Error Reporting comme source de notifications, et à Slack, Jira et OpsGenie comme destinations de notification.
Cet outil comporte plusieurs composants :
- Crawler Error Reporting : un service App Engine Flex qui envoie des appels à l’API Error Reporting pour parcourir les erreurs de l’ensemble de nos projets GCP. Afin de respecter les quotas de l’API Error Reporting, nous utilisons une App Engine Task Queue pour parcourir les erreurs par lots.
- Récepteur de notifications d’alerte : implémenté sous forme de service App Engine Flex qui surveille un canal PubSub pour les notifications d’alerte. Toutes nos règles d’alerte ont ce canal PubSub ajouté comme canal de notification.
- Règles de politique de notification : un fichier proto texte dans lequel les ingénieurs Glean peuvent définir comment faire correspondre des incidents d’alerte ou des erreurs et vers quelles applications SaaS les transférer.
- Base de données d’états : une base Cloud SQL qui stocke les incidents d’alerte collectés, les erreurs Error Reporting, ainsi que leurs états de dispatch.
- Notification Dispatcher : le moteur d’exécution qui traite l’ensemble des notifications et les distribue conformément aux règles de politique de notification. Il est implémenté sous forme de bibliothèque cliente partagée, compilée à la fois dans les services Flex Error Reporting Crawler et Alert Notification Receiver.
Fonctionnalités avancées
Nous avons développé d’autres fonctionnalités intéressantes qui nous permettent de faire évoluer les opérations dans le Cloud :
- Intégration Jira : les ingénieurs Glean peuvent utiliser l’outil pour préciser quels composants Jira et quelles priorités Jira doivent être utilisés pour créer de nouveaux tickets Jira lorsqu’un incident d’alerte ou des erreurs Error Reporting sont reçus. Comme Glean indexe notre instance Jira, tous les incidents d’alerte et les erreurs deviennent consultables.
- Déduplication des incidents et des erreurs : les règles de correspondance des notifications sont très flexibles et prennent en charge les expressions régulières, ce qui permet aux ingénieurs Glean de dédupliquer les mêmes incidents d’alerte ou erreurs sans spammer les équipes d’ingénierie. C’est particulièrement important lorsqu’il y a une tempête de pages ou lorsque le même problème survient dans plusieurs projets au même moment.
- Mise en sourdine des notifications : nous avons développé cette fonctionnalité avant que GCP n’introduise la fonctionnalité Pre-GA Notification Snooze. Elle permet même aux ingénieurs Glean de mettre en sourdine les alertes en se basant sur des labels d’incident d’alerte, ou de mettre en sourdine les alertes d’un projet entier.
- Contrôle de la fréquence des notifications : les ingénieurs Glean peuvent définir la fréquence à laquelle ils souhaitent recevoir des mises à jour vers les destinations de notification choisies. Cela empêche les alertes de générer des mises à jour trop souvent.
- Suppression de notifications : cette fonctionnalité est généralement utilisée lorsqu’un incident d’alerte d’une sévérité plus élevée se déclenche : nous voulons alors supprimer une alerte pertinente de sévérité plus faible.
- Escalade automatique des notifications : les ingénieurs Glean peuvent utiliser cette fonctionnalité pour augmenter les priorités OpsGenie ou Jira lorsque les critères spécifiés sont remplis. Cela signifie généralement qu’un problème s’est largement propagé et requiert une attention immédiate.
- Regroupement des erreurs : nous avons introduit une empreinte d’erreur similaire à la façon dont GCP Error Reporting regroupe les erreurs. Cette technique utile nous permet de regrouper des erreurs GCP sur plusieurs projets. En outre, les ingénieurs Glean peuvent utiliser des règles de politique de notification pour faire correspondre les erreurs par message d’exception, frame ou stack trace, à travers l’ensemble de nos langages de programmation.
À retenir
L’outil Notification Dispatcher a considérablement amélioré notre productivité מאז son lancement. Il offre un mécanisme permettant à nos ingénieurs de consolider les signaux de production issus de l’ensemble de nos projets GCP et de se concentrer sur les problèmes de production importants. Une fois ces notifications transférées vers Jira ou Slack, les ingénieurs peuvent Glean
les informations et transformer les résolutions ou discussions en connaissances.Si vous souhaitez mettre la main à la pâte pour faire évoluer nos opérations dans le Cloud, consultez notre page carrières — ou planifiez une démo pour découvrir ce que Glean peut faire pour vous.
