« J'ai besoin d'être informé si un événement important se produit avec SignalFx. » C'est ce que je dis à mon équipe. Cependant, bien que directeur technique d'une entreprise de surveillance, créer le bon ensemble d'alertes pour rester informé des incidents en cours ou des problèmes potentiels s'est avéré plus difficile qu'il n'y paraissait à première vue.

Pourquoi?

Bien que l'avènement du cloud et des technologies open source nous ait permis de créer des logiciels beaucoup plus rapidement, les environnements d'aujourd'hui sont beaucoup plus complexes à utiliser. moniteur et gérer pour un certain nombre de raisons, notamment :

1. L'explosion du nombre d'instances de calcul à surveiller (hôtes, conteneurs, fonctions).
2. Les services émettent rarement des mesures « bien comportées » et changent constamment au fil du temps.
3. Le nombre croissant de services devant être surveillés individuellement en raison de l'architecture des microservices.

Pour beaucoup d'entre nous, cela se traduit par une avalanche de faux positifs ou d'alertes redondantes. La lassitude face aux alertes entrave non seulement la capacité de votre équipe à identifier et à résoudre les problèmes en temps réel, mais, si elle n'est pas traitée pendant une période prolongée, elle sape également le moral de l'équipe et entraîne des pannes évitables.

Stratégies pour réduire la fatigue d'alerte

Réduire la fatigue liée aux alertes Il faut commencer par élargir son champ d'action. Si une mesure précise des indicateurs est extrêmement utile lors du dépannage et de l'analyse forensique, les alertes les plus exploitables reposent sur une combinaison de signaux créant des indicateurs plus précis de l'état de santé des applications. En particulier, vous devriez considérer :

Suivi des populations, et non des cas individuels
Définissez et abonnez-vous à des indicateurs de santé par service ou par population, plutôt que de recevoir des alertes sur l'état de chaque composant individuel de votre environnement. Par exemple, vous pouvez suivre la latence au 99e percentile d'un appel d'API sur plusieurs instances de service, l'utilisation moyenne du processeur pour un cluster de nœuds donné ou la somme des erreurs d'API pour un groupe de conteneurs qui le dessert.

Mesures système agrégées sur 1 436 hôtes

Alerter sur les modèles et les tendances plutôt que sur des seuils numériques fixes
Utilisez des seuils générés par des algorithmes capables de s'adapter aux environnements changeants. Les systèmes distribués se comportent souvent de manière imprévisible, ce qui rend extrêmement difficile la détermination du niveau « approprié » d'utilisation du processeur ou des erreurs d'API avant le déclenchement d'une alerte.

Alerte sur le nombre brut de sessions par rapport à l'évolution d'une semaine à l'autre

En tenant compte des modèles réguliers (par exemple, un trafic plus élevé en semaine) ou en émettant des alertes prédictives (alerte lorsqu'un cluster est sur le point de manquer d'espace disque dans les N prochains jours), vous pouvez mieux faire la différence entre le comportement normal du système et quelque chose qui justifie une réponse.

Graphique affichant une tendance métrique vers la capacité

Définition des mesures globales de performance des applications
Combinez les métriques de différents microservices pour générer des signaux et des alertes de niveau supérieur. Deux possibilités : le nombre de chargements de pages par utilisateur connecté et le nombre d'erreurs d'API mesuré en pourcentage du total des appels d'API. L'un de nos clients combine les métriques de tous ses microservices pour créer un score de santé pour les versions de déploiement, indiquant si les performances globales de l'application se sont améliorées.

Mesurer les signaux sociaux

Malgré l'utilisation de toutes ces techniques chez SignalFx, je recevais encore trop de fausses alertes positives. Gardez à l'esprit les points suivants :

1. En tant que responsable ingénierie, je n'ai pas besoin d'alertes aussi précises qu'un responsable de service ou un ingénieur d'astreinte. Suivre uniquement un sous-ensemble d'alertes est également peu pratique, car cette liste d'abonnement devient rapidement obsolète sans une vigilance constante.
2. Bien que notre organisation utilise PagerDuty, je ne suis pas toujours sur le chemin d'escalade d'astreinte .
3. Bien que je puisse filtrer les problèmes mineurs en consultant des sources telles que la page d'état de SignalFx, cela enverrait des alertes trop tard (après qu'un problème de site soit en plein essor plutôt qu'avant) pour que je puisse contribuer activement à la réponse aux incidents.

Quels autres signaux puis-je mesurer ? Chez SignalFx, nous avons un canal Slack nommé #panne, spécifiquement dédié aux discussions sur les incidents. Ce canal reçoit également des notifications d'alertes critiques de PagerDuty afin de préserver le contexte de ces discussions. Sachant que les problèmes importants poussent souvent plusieurs utilisateurs à collaborer sur Slack et à remonter le problème via PagerDuty, j'ai décidé de collecter des indicateurs d'activité humaine dans #panne. Le résultat ressemblait à ceci :

Gris : Flux de travail d'alerte SignalFx « normal »
Jaune : Alerte avec signaux sociaux

J'ai utilisé un AWS Lambda J'ai configuré l'interrogation et la classification des messages (par exemple, générés par des humains ou par des robots), puis je les ai publiés sur SignalFx. J'ai ensuite créé un détecteur d'alertes qui m'avertissait lorsque plus de trois auteurs humains uniques saisissaient #panne pendant cinq minutes ou plus. Les alertes étaient envoyées sur mon téléphone via PagerDuty et par message direct. Mou .

Notification de panne potentielle en cours

Cela a fonctionné étonnamment bien : même si j'ai encore reçu quelques faux positifs, leur nombre est tombé à presque zéro, et j'ai été notifié de chaque incident pertinent. Fait intéressant, j'ai également été informé de quelques incidents potentiels en préparation pour lesquels je n'avais pas d'alertes actives, mais que nos ingénieurs avaient découverts lors de leur observation générale du service.

Ne cessez pas de surveiller le matériel et les logiciels

J'ai d'abord été déçu de ne pas pouvoir créer l'alerte « parfaite » en me basant uniquement sur les indicateurs d'application et d'infrastructure, mais c'était peut-être une attente naïve. Créer l'alerte idéale nécessite non seulement de comprendre votre environnement, mais aussi la façon dont votre organisation réagit aux incidents.

Mesurer le comportement humain était suffisant pour mon cas d’utilisation spécifique, mais étant donné l’interopérabilité et l’indépendance des données de nombreux outils actuels, il existe une multitude d’autres signaux que nous pourrions potentiellement intégrer dans notre surveillance.

Intégrer la détection des problèmes à la gestion des incidents

Les activités en temps réel nécessitent une intelligence opérationnelle en temps réel, et les technologies actuelles génèrent bien plus de données que ne peuvent en gérer les outils de surveillance traditionnels. SignalFx collecte des indicateurs en continu sur chaque composant de votre environnement pour fournir des analyses et des alertes en quelques secondes, vous permettant ainsi d'identifier et de résoudre les problèmes avant qu'ils n'impactent vos clients.

Avec SignalFx et PagerDuty , vous pouvez ouvrir automatiquement des incidents dans PagerDuty lorsqu'un détecteur d'alerte est déclenché dans SignalFx, mapper différentes politiques d'escalade en fonction de l'alerte et marquer automatiquement les incidents résolus lorsque les choses reviennent à la normale.

Chez SignalFx, nous aidons les organisations à surveiller tous les signaux importants, en temps réel, à n'importe quelle échelle, et leur donnons la confiance nécessaire pour innover plus rapidement que jamais.

Arijit Mukherji est CTO chez SignalFx et passionné par la surveillance. Il a été l'un des premiers développeurs de la solution de mesure de Facebook (ODS) et a ensuite dirigé le développement des outils réseau, de la visualisation de données et d'autres logiciels de surveillance des infrastructures de Facebook. Bien qu'il se soit concentré sur la surveillance pendant plus de dix ans, sa carrière diversifiée de plus de vingt ans couvre également la téléphonie IP, la conférence VoIP et la virtualisation des réseaux.