Mettre en pratique la surveillance et les alertes

Bien que la majeure partie du système de surveillance puisse être déployée sur un ou plusieurs serveurs dédiés, les données doivent être collectées à partir de nombreuses sources différentes au sein de votre infrastructure. Pour ce faire, un agent de surveillance - une petite application conçue pour collecter et transmettre des données à un point de terminaison de collecte - est installé sur chaque machine individuelle du réseau. Ces agents collectent des statistiques et des mesures d'utilisation à partir de l'hôte sur lequel ils sont installés et les envoient au logiciel de surveillance central.

Les agents s'exécutent en tant que démons permanents sur chaque hôte du système. Ils peuvent inclure une configuration de base pour s’authentifier de manière sécurisée avec le point de terminaison de données distant, définir la fréquence des données ou les règles d’échantillonnage et définir des identifiants uniques pour les données des hôtes. Pour réduire l'impact sur les autres services, l'agent doit utiliser un minimum de ressources et pouvoir fonctionner sans aucune gestion. Idéalement, l'installation d'un agent sur un nouveau nœud et l'envoi des métriques au système de surveillance central devraient être simples.

Les agents de surveillance collectent généralement des métriques génériques au niveau de l'hôte, mais des agents pour surveiller des logiciels tels que des serveurs Web ou de base de données sont également disponibles. Cependant, pour la plupart des logiciels spécialisés, les données devront être collectées et exportées soit en modifiant le logiciel lui-même, soit en créant votre propre agent en créant un service analysant les points de terminaison de l’état du logiciel ou les entrées de journal. De nombreuses solutions de surveillance courantes disposent de bibliothèques permettant d'ajouter facilement une instrumentation personnalisée à vos services. Comme avec les logiciels agents, vous devez veiller à ce que vos solutions personnalisées minimisent leur empreinte au sol afin d'éviter tout impact sur la santé ou les performances de vos applications.

Jusqu'à présent, nous avons émis certaines hypothèses sur une architecture de surveillance basée sur la technologie Push, dans laquelle les agents transmettent les données à un emplacement central. Cependant, des conceptions basées sur la traction sont également disponibles. Dans les systèmes de surveillance basés sur l'extraction, les hôtes individuels sont responsables de la collecte, de l'agrégation et de la fourniture des métriques dans un format connu sur un noeud final accessible. Le serveur de surveillance interroge le point de terminaison des métriques sur chaque hôte pour rassembler les données de métriques. Le logiciel qui collecte et présente les données via le système d'extrémité présente les mêmes exigences qu'un agent, mais nécessite souvent moins de configuration, car il n'a pas besoin de savoir comment accéder aux autres machines.

L’un des éléments les plus actifs d’un système de surveillance à un moment donné est le composant d’entrée des métriques. Étant donné que les données sont constamment générées, le processus de collecte doit être suffisamment robuste pour gérer un volume d'activité élevé et être coordonné avec la couche de stockage pour enregistrer correctement les données entrantes.

Pour les systèmes Push, le point final d'entrée de métriques est un emplacement central sur le réseau où chaque agent de surveillance ou agrégateur de statistiques envoie ses données collectées. Le noeud final doit pouvoir authentifier et recevoir les données d'un grand nombre d'hôtes simultanément. Les points de terminaison d'entrée pour les systèmes de métriques sont souvent équilibrés en charge ou répartis à l'échelle, à la fois pour des raisons de fiabilité et pour faire face aux volumes de trafic élevés.

Pour les systèmes basés sur l'extraction, le composant correspondant est le mécanisme d'interrogation qui analyse et analyse les points de terminaison des métriques exposés sur des hôtes individuels. Cela a certaines des mêmes exigences, mais certaines responsabilités sont inversées. Par exemple, si des hôtes individuels implémentent l'authentification, le processus de collecte des mesures doit pouvoir fournir les informations d'identification correctes pour la connexion et l'accès au point de terminaison sécurisé.

La couche de gestion de données est chargée d'organiser et d'enregistrer les données entrantes en provenance du composant d'entrée de métriques et de répondre aux requêtes et aux demandes de données des couches administratives. Les données métriques sont généralement enregistrées dans un format appelétime series qui représente les changements de valeur au fil du temps. Les bases de données de séries chronologiques - bases de données spécialisées dans le stockage et l'interrogation de ce type de données - sont fréquemment utilisées dans les systèmes de surveillance.

La principale responsabilité de la couche de gestion des données consiste à stocker les données entrantes au fur et à mesure de leur réception ou de leur collecte par les hôtes. Au minimum, la couche de stockage doit enregistrer la métrique en cours de rapport, la valeur observée, l'heure à laquelle la valeur a été générée et l'hôte qui l'a produite.

Pour la persistance sur de longues périodes, la couche de stockage doit fournir un moyen d’exporter des données lorsque la collecte dépasse les limites locales en matière de traitement, de mémoire ou de stockage. En conséquence, la couche de stockage doit également pouvoir importer des données en bloc pour ré-ingérer les données historiques dans le système lorsque cela est nécessaire.

La couche de gestion de données doit également fournir un accès organisé aux informations stockées. Pour les systèmes utilisant des bases de données chronologiques, cette fonctionnalité est fournie par des langages d'interrogation ou des API intégrés. Ceux-ci peuvent être utilisés pour l'interrogation interactive et l'exploration de données, mais les principaux consommateurs seront probablement les tableaux de bord de présentation des données et le système d'alerte.

Les interfaces avec lesquelles vous interagissez pour comprendre les données collectées reposent sur la couche de gestion des données. Les métriques étant des données de séries chronologiques, les données sont mieux représentées sous forme de graphique avec le temps sur l'axe des x. De cette façon, vous pouvez facilement comprendre comment les valeurs changent avec le temps. Les métriques peuvent être visualisées sur différentes échelles de temps pour comprendre les tendances sur de longues périodes ainsi que les changements récents susceptibles d'affecter vos systèmes.

Les couches de visualisation et de gestion des données sont toutes deux impliquées dans la garantie que les données de différents hôtes ou de différentes parties de votre pile d'applications peuvent être superposées et affichées de manière globale. Heureusement, les données chronologiques fournissent une échelle cohérente qui permet d'identifier les événements ou les changements survenus simultanément, même lorsque l'impact est réparti sur différents types d'infrastructure. La possibilité de sélectionner les données à superposer de manière interactive permet aux opérateurs de créer les visualisations les plus utiles pour la tâche à accomplir.

Les graphiques et les données couramment utilisés sont souvent organisés dans des tableaux de bord enregistrés. Celles-ci sont utiles dans un certain nombre de contextes, soit en tant que représentation continue des métriques d'intégrité actuelles pour les affichages permanents, soit en tant que portails ciblés pour le dépannage ou la plongée en profondeur dans des zones spécifiques de votre système. Par exemple, un tableau de bord avec une ventilation détaillée de la capacité de stockage physique dans une flotte peut être important lors de la planification de la capacité, mais il peut ne pas être nécessaire de faire référence à une administration quotidienne. Faciliter la construction de tableaux de bord généralisés et ciblés peut aider à rendre vos données plus accessibles et exploitables.

Les graphiques et les tableaux de bord sont des outils de choix pour comprendre les données de votre système, mais ils ne sont utiles que dans des contextes où un opérateur humain visualise la page. L'une des responsabilités les plus importantes d'un système de surveillance consiste à empêcher les membres de l'équipe de surveiller activement vos systèmes afin qu'ils puissent poursuivre des activités plus utiles. Pour que cela soit réalisable, le système doit pouvoir vous demander votre attention si nécessaire afin de pouvoir être sûr que vous serez informé des changements importants. Les systèmes de surveillance utilisent des seuils de métriques définis par l'utilisateur et des systèmes d'alerte pour y parvenir.

Le système d’alerte a pour but d’avertir de manière fiable les opérateurs lorsque les données indiquent un changement important et de les laisser seuls dans le cas contraire. Comme cela nécessite que le système sache ce que vous considérez comme un événement significatif, vous devez définir vos critères d'alerte. Les définitions d'alerte sont composées d'une méthode de notification et d'un seuil de mesure que le système évalue en permanence en fonction des données entrantes. Le seuil définit généralement une valeur moyenne maximale ou minimale pour une mesure sur une période spécifiée, tandis que la méthode de notification décrit comment envoyer l'alerte.

L'un des aspects les plus difficiles de l'alerte consiste à trouver un équilibre qui vous permette d'être réactif aux problèmes tout en évitant les alertes excessives. Pour ce faire, vous devez savoir quelles métriques sont les meilleures indications de problèmes réels, lesquels nécessitent une attention immédiate et quelles méthodes de notification conviennent le mieux à différents scénarios. Pour cela, le langage de définition de seuil doit être suffisamment puissant pour décrire correctement vos critères. De même, le composant de notification doit offrir des méthodes de communication adaptées à différents niveaux de gravité.

En commençant par le type d'alerte de priorité la plus élevée, lespages sont des notifications qui tentent d'attirer l'attention de toute urgence sur un problème critique du système. Cette catégorie d'alerte doit être utilisée pour les situations exigeant une résolution immédiate en raison de leur gravité. Le système de radiomessagerie nécessite un moyen fiable et agressif de contacter les personnes qui ont la responsabilité et le pouvoir de résoudre le problème.

Les pages doivent être réservées aux problèmes critiques de votre système. En raison du type de problèmes qu’ils représentent, il s’agit des alertes les plus importantes que votre système envoie. Les bons systèmes de radiomessagerie sont fiables, persistants et suffisamment agressifs pour ne pas être raisonnablement ignorés. Pour assurer une réponse, les systèmes de radiomessagerie incluent souvent une option permettant d'avertir une personne secondaire ou un groupe si la première page n'est pas acquittée dans un délai donné.

Parce que les pages sont, par nature, incroyablement perturbatrices, elles doivent être utilisées avec parcimonie: uniquement lorsqu'il est clair qu'il existe un problème inacceptable du point de vue de l'exploitation. Cela signifie souvent que les pages sont liées aux symptômes observés dans votre système à l'aide des techniques de boîte noire. Bien qu'il soit difficile de déterminer l'impact d'un nombre maximal de connexions sur un hôte Web principal, le fait que votre domaine soit inaccessible est beaucoup moins ambigu et peut nécessiter une page.

La réduction de la gravité estnotificationscomme les e-mails et les tickets. Celles-ci sont conçues pour rappeler de manière persistante que les opérateurs doivent enquêter sur une situation en développement lorsqu'ils sont en bonne position pour le faire. Contrairement aux pages, les alertes de type notification ne sont pas censées indiquer qu'une action immédiate est requise, elles sont donc généralement gérées par le personnel en activité plutôt que d'alerter un employé sur appel. Si les administrateurs de votre entreprise ne travaillent pas en permanence, les notifications doivent être alignées sur les situations pouvant attendre le jour ouvrable suivant.

Les tickets et les e-mails générés par la surveillance aident les équipes à comprendre le travail sur lequel elles doivent se concentrer lors de leur prochaine activité. Parce que les notifications ne doivent pas être utilisées pour des problèmes critiques affectant actuellement la production, elles reposent souvent sur des indicateurs de type boîte blanche permettant de prédire ou d'identifier les problèmes en évolution qui devront être résolus rapidement.

D'autres fois, les alertes de notification sont configurées pour surveiller le même comportement que les alertes de pagination, mais sont définies pour des seuils inférieurs, moins critiques. Par exemple, vous pouvez définir une alerte de notification lorsque votre application affiche une légère augmentation de la latence sur une période donnée et qu'une page correspondante soit envoyée lorsque la latence augmente de manière déraisonnable.

En général, les notifications sont plus appropriées dans les situations qui nécessitent une réponse, mais ne représentent pas une menace immédiate pour la stabilité de votre système. Dans ces cas, vous souhaitez attirer l'attention sur un problème afin que votre équipe puisse enquêter et atténuer lesbefore qu'il affecte les utilisateurs ou se transforme en un problème plus vaste.

Bien qu’il ne s’agisse pas techniquement d’une alerte, vous pouvez parfois souhaiter noter un comportement observé spécifique dans un endroit auquel vous pourrez facilement accéder ultérieurement sans le signaler immédiatement à quiconque. Dans ces situations, la configuration de seuils qui ne seront que des informationslog peut être utile. Ceux-ci peuvent être écrits dans un fichier ou utilisés pour incrémenter un compteur sur un tableau de bord au sein de votre système de surveillance. L'objectif est de fournir des informations facilement compilées à des fins d'enquête afin de réduire le nombre de requêtes que les opérateurs doivent construire pour collecter des informations.

Cette stratégie n'a de sens que pour les scénarios très peu prioritaires et ne nécessitant aucune réponse par eux-mêmes. Leur plus grande utilité consiste à corréler des facteurs liés et à résumer des données ponctuelles qui peuvent être référencées ultérieurement en tant que sources supplémentaires. Vous n'aurez probablement pas beaucoup de déclencheurs de ce type, mais ils pourraient être utiles dans les cas où vous vous retrouvez à rechercher les mêmes données à chaque fois qu'un problème survient. Les solutions de remplacement offrant les mêmes avantages sont les requêtes sauvegardées et les tableaux de bord d'investigation personnalisés.

Comme indiqué précédemment, les alertes basées sur des scénarios ayant un impact réel sur l'utilisateur sont les meilleures. Cela signifie analyser différents scénarios de dégradation des performances ou des défaillances et comprendre comment et à quel moment ils peuvent se transformer en couches avec lesquelles les utilisateurs interagissent.

Cela nécessite une bonne compréhension de la redondance de votre infrastructure, des relations entre les différents composants et des objectifs de disponibilité et de performances de votre entreprise. Votre objectif est de découvrir les métriques symptomatiques pouvant indiquer de manière fiable des problèmes présents ou imminents ayant un impact sur l'utilisateur.

Une fois les métriques symptomatiques identifiées, le prochain défi consiste à identifier les valeurs appropriées à utiliser comme seuils. Vous devrez peut-être recourir à des essais pour détecter les bons seuils pour certaines métriques.

Si disponible, vérifiez les valeurs historiques pour déterminer quels scénarios nécessitaient une correction dans le passé. Pour chaque métrique, il est bon de définir un seuil «d'urgence» qui déclenchera une page et un ou plusieurs seuils «canary» associés à une messagerie de priorité inférieure. Une fois les nouvelles alertes définies, demandez-leur si les seuils sont trop agressifs ou pas assez sensibles pour pouvoir ajuster le système de manière à ce qu'il corresponde mieux aux attentes de votre équipe.

En minimisant le temps nécessaire aux enquêteurs pour commencer une enquête sur les problèmes, vous vous aidez à résoudre les incidents plus rapidement. À cette fin, il est utile d'essayer de fournir un contexte dans le texte d'alerte afin que les opérateurs puissent comprendre rapidement la situation et commencer à travailler sur les prochaines étapes appropriées.

Les alertes doivent clairement indiquer les composants et les systèmes affectés, le seuil de métrique qui a été déclenché et l'heure à laquelle l'incident a commencé. L'alerte doit également fournir des liens pouvant être utilisés pour obtenir des informations supplémentaires. Il peut s’agir de liens vers des tableaux de bord spécifiques associés à la métrique déclenchée, de liens vers votre système de tickets si des tickets automatisés ont été générés ou de liens vers la page des alertes de votre système de surveillance où un contexte plus détaillé est disponible.

L'objectif est de donner à l'opérateur suffisamment d'informations pour guider sa réponse initiale et l'aider à se concentrer sur l'incident en question. Fournir toutes les informations dont vous disposez sur l'événement n'est ni nécessaire ni recommandé, mais fournir des détails de base avec quelques options pour la prochaine étape peut raccourcir la phase de découverte initiale de votre réponse.

Les alertes ne sont pas utiles si elles ne sont pas exploitables. Souvent, le fait de savoir si une alerte peut donner lieu à une action dépend du niveau de connaissances, de l'expérience et de la permission dont dispose le répondant. Pour les organisations d’une certaine taille, choisir la personne ou le groupe à envoyer est simple dans certains cas et ambigu dans d’autres. Le développement d’une rotation sur appel pour différentes équipes et la conception d’un plan d’escalade concret peuvent lever l’ambiguïté de ces décisions.

Les rotations sur appel devraient inclure un nombre suffisant d'individus capables d'éviter l'épuisement professionnel et la fatigue alerte. Il est préférable que votre système d'alerte inclue un mécanisme de planification des quarts de travail sur appel. Sinon, vous pouvez développer des procédures pour faire pivoter manuellement les contacts d'alerte en fonction de vos plannings. Vous pouvez avoir plusieurs rotations sur appel renseignées par les propriétaires de parties spécifiques de vos systèmes.

Un plan d'escalade est un deuxième outil permettant de s'assurer que les incidents concernent les bonnes personnes. Si votre personnel couvre vos systèmes 24 heures sur 24, il est préférable d'envoyer les alertes générées par le système de surveillance aux employés en poste plutôt que la rotation sur appel. Les intervenants peuvent ensuite effectuer eux-mêmes les mesures d'atténuation ou décider de mettre en page manuellement les opérateurs sur appel s'ils ont besoin d'une aide ou d'une expertise supplémentaire. Avoir un plan qui décrit quand et comment les problèmes sont remontés peut minimiser les alertes inutiles et préserver le sentiment d'urgence que les pages sont censées représenter.