Article de blog invité de Dave Josephsen, développeur évangéliste chez Librato Librato fournit une solution complète pour surveiller et comprendre les métriques qui ont un impact sur votre entreprise à tous les niveaux de la pile.

L'hypothèse sous-jacente à tous les systèmes de surveillance est l'existence d'une entité que nous ne pouvons pas totalement contrôler. Une chose que nous avons créée, comme un avion, ou même une chose qui existe simplement grâce à une biologie miraculeuse, comme le corps humain. Une chose qui serait parfaite, mais sans son interaction avec la réalité analogique et sale de l'espace physique ; ce terrain de jeu de l'entropie et du chaos où la meilleure ingénierie que nous puissions gérer finit par dérailler sous l'effet du temps, des erreurs humaines et du hasard.

Surveillez ce que vous ne pouvez pas contrôler

Les avions et les corps sont des systèmes. Non seulement nous nous attendons à ce qu'ils fonctionnent d'une manière particulière, mais nous disposons de modèles mentaux bien définis qui décrivent leurs caractéristiques opérationnelles : des hypothèses simples sur leur fonctionnement, qui correspondent à des indicateurs mesurables nous permettant de qualifier ces systèmes de « bons » ou de « mauvais ». Les pneus d'avion doivent maintenir une pression de 60 psi, le cœur humain doit battre entre 40 et 100 battements par minute. Le client JDBC ne devrait jamais nécessiter plus de 150 connexions à la base de données.

C'est pourquoi Nous surveillons : pour obtenir un retour d'information en boucle fermée sur les caractéristiques opérationnelles de systèmes que nous ne pouvons pas entièrement contrôler, afin de nous assurer qu'ils fonctionnent dans les limites prévues. Fondamentalement, la surveillance est un problème de traitement du signal ; par conséquent, tous les systèmes de surveillance sont des systèmes de traitement du signal. Certains systèmes de surveillance échantillonnent et génèrent des signaux à partir de mesures réelles, tandis que d'autres collectent et traitent les signaux pour effectuer des tâches telles que la visualisation, la détection de comportements anormaux, l'alerte et la notification.

Vous trouverez ci-dessous un schéma, certes simplifié, décrivant le fonctionnement des systèmes de surveillance d'éléments tels que le cœur humain et la pression d'huile des avions (en laissant de côté, bien sûr, le fonctionnement interne plus ésotérique du cœur humain, impossible à surveiller). On y voit des capteurs générer un signal qui alimente les différents composants fournissant un retour d'information sur le fonctionnement du système aux opérateurs humains.

Cependant, trop souvent, ce que nous voyons dans la conception des systèmes de surveillance informatique ressemble à la figure ci-dessous, où plusieurs capteurs sont utilisés pour générer des signaux en double pour chaque composant qui génère un type de rétroaction différent.

Les raisons de l'émergence de ce modèle anti-modèle sont multiples, mais la plupart se résument à une dissonance cognitive entre les différents services informatiques. Chacun d'eux estime surveiller pour une raison différente et nécessite donc des outils d'analyse différents. Les équipes d'exploitation et de développement, par exemple, peuvent considérer que la surveillance des indicateurs du système d'exploitation est fondamentalement différente de celle des applications, et chacune implémente donc sa propre suite d'outils de surveillance pour répondre à des besoins qu'elle considère comme exclusifs. Pour les indicateurs du système d'exploitation, les opérations peuvent penser qu'il est nécessaire de disposer de données d'état à la minute près pour générer des alertes, tandis que le développement se concentre sur des indicateurs de performance à la seconde résolution pour visualiser les performances de ses applications.

En réalité, les deux équipes partagent la même exigence : un signal de télémétrie qui fournira un retour d'information en boucle fermée des systèmes qui les intéressent, mais comme chacune implémente une chaîne d'outils différente pour répondre à cette exigence, elles finissent par créer des signaux redondants, pour alimenter différents outils.

Des signaux disparates produisent des résultats imprévisibles

Lorsque différentes sources de données sont utilisées pour les alertes et les graphiques, l'une ou l'autre peut générer des faux positifs ou négatifs. Chacune peut surveiller des indicateurs subtilement différents sous le même nom, ou un même indicateur de manière subtilement différente. Lorsqu'un ingénieur est réveillé au milieu de la nuit par une alerte provenant d'un tel système et que le retour de visualisation ne concorde pas avec celui des notifications d'événements, un problème déjà détecté précaire,   stressant La situation est encore plus confuse et un temps précieux est perdu à examiner un système de surveillance ou un autre.

En fin de compte, la fiabilité de la source importe peu. Même si l'on parvient à décrypter la source avec les efforts considérables d'investigation nécessaires, il est peu probable qu'une mesure corrective significative puisse être prise pour synchroniser le comportement des sources à l'avenir. Conséquence inévitable : les ingénieurs commenceront à ignorer les deux systèmes de surveillance, car aucun n'est fiable.

Corriger les faux positifs causés par des sources de données disparates ne consiste pas à améliorer un système de surveillance peu fiable, mais plutôt à faire en sorte que deux systèmes de surveillance peu fiables concordent systématiquement. Si nous utilisions deux ECG différents sur le même patient – l'un pour la visualisation, l'autre pour la notification – et que le résultat était peu fiable, nous reconcevrions probablement le système pour qu'il fonctionne sur un signal commun et nous efforcerions de le rendre aussi précis que possible. Autrement dit, la solution la plus simple consiste simplement à alerte sur ce que vous voyez .

Synchronisez vos alertes et visualisations sur un signal commun  

Être alerté sur ce que vous voyez ne nécessite pas que tous les membres de l'organisation utilisent le même outil de surveillance pour collecter les données métriques qui les intéressent, cela nécessite seulement que les systèmes de traitement et de notification utilisent un signal d'entrée commun.
La méthode spécifique permettant d'obtenir un signal d'entrée commun dépend des outils utilisés dans votre organisation. Si vous utilisez Nagios/Ganglia, par exemple, vous pouvez modifier Nagios pour qu'il génère des alertes sur les données collectées par Ganglia, au lieu de collecter un flux de données métriques de Ganglia pour la visualisation et un signal différent de Nagios pour les alertes.

Librato et PagerDuty constituent un excellent choix pour le traitement centralisé des signaux de télémétrie de tous les collecteurs de données utilisés dans votre organisation. Grâce à une intégration clé en main avec AWS et Heroku, et à la prise en charge de près de 100 outils de surveillance open source, récepteurs de journaux, bibliothèques d'instrumentation et démons, configurer vos outils actuels pour transmettre des métriques à Librato est un jeu d'enfant.

En combinant Librato et PagerDuty, tous les ingénieurs, quelle que soit leur équipe, peuvent facilement traiter, visualiser et corréler les événements de vos signaux de télémétrie, ainsi qu'envoyer des notifications et des escalades qui reflètent les données de ces visualisations. Vos ingénieurs peuvent utiliser les outils de leur choix, tout en s'assurant que les signaux émis par ces outils permettent de fournir un feedback efficace et rapide à tous les membres de l'organisation. Inscrivez-vous pour recevoir un Essai gratuit de Librato aujourd'hui et apprenez à intégrer PagerDuty avec Librato .