Une vision vers l'observabilité dans la pratique

L'une des principales tendances de l'infrastructure logicielle en 2019 est l' observabilité .

Il a récemment attiré beaucoup d'attention.

Qu'est-ce que l'observabilité?

Il y a beaucoup de discussions et de blagues sur ce terme. Par exemple:

• Pourquoi l'appeler surveillance? Ce n'est plus assez sexy.
• Observabilité, parce que le changement de marque d'Ops en DevOps n'était pas assez mauvais, maintenant ils détruisent également la surveillance.
• Le nouveau Chuck Norris de DevOps.
• Je suis un ingénieur qui peut aider à surveiller les autres ingénieurs de l'organisation.
• > Génial, voici 80 000 $.
• Je suis un architecte qui peut aider à assurer l'observabilité des applications basées sur des conteneurs natifs du cloud.
• > Génial! Voici 300 000 $!

Cindy sridharan

Quelle est la différence entre le suivi et l'observabilité s'il y en a un?

Rétrospective ...

Il y a des années, nous exécutions principalement nos logiciels sur des serveurs physiques. Nos applications étaient des monolithes construits sur LAMP ou d'autres piles. La vérification de la disponibilité était aussi simple que l'envoi de pings réguliers et la vérification de l'utilisation du processeur / disque pour votre application.

Changement de paradigme

Le principal changement de paradigme est venu des domaines de l'infrastructure et de l'architecture. Les architectures cloud, les microservices, Kubernetes et les infrastructures immuables ont changé la façon dont les entreprises construisent et exploitent leurs systèmes.



Grâce à l'adoption de ces nouvelles idées, les systèmes que nous avons construits sont devenus de plus en plus distribués et éphémères.

Les infrastructures de virtualisation, de conteneurisation et d'orchestration sont chargées de fournir des ressources de calcul et de gérer les défaillances crée une couche d'abstraction pour le matériel et la mise en réseau.

Le passage à l'abstraction du matériel sous-jacent et de la mise en réseau signifie que nous devons nous concentrer sur la garantie que nos applications fonctionnent comme prévu dans le contexte de nos processus commerciaux.

Qu'est-ce que la surveillance?

La surveillance est aux opérations essentiellement ce que le test est au développement de logiciel. En fait, les tests vérifient le comportement des composants du système par rapport à un ensemble d'entrées dans un environnement en bac à sable, généralement avec un grand nombre de composants simulés.



Le problème principal est que la quantité de problèmes possibles dans la production ne peut en aucun cas être couverte par des tests. La plupart des problèmes dans un système mature et stable sont des inconnus inconnus qui sont liés non seulement au développement logiciel lui-même, mais aussi au monde réel.

Black Box vs. Surveillance de la boîte blanche

Il existe deux approches de surveillance.

Dans le cas de la surveillance de la boîte noire, nous traitons le système ou des parties de celui-ci comme une boîte noire et les testons à l'extérieur. Cela peut signifier la vérification des appels API, du temps de chargement ou de la disponibilité des différentes parties du système. Dans ce cas, la quantité d'informations et de contrôle sur le système est limitée.



La surveillance de la boîte blanche fait référence à la situation, où nous tirons des informations des internes du système. Ce n'est pas une idée révolutionnaire, mais elle a récemment attiré beaucoup d'attention.



Ainsi, l'observabilité n'est qu'un autre nom pour la surveillance de la boîte blanche? Pas tout à fait.

Pourquoi nous avons besoin d'un nouveau type de surveillance

Souvent, une distinction est faite entre la surveillance et le concept d'observabilité, ce dernier étant défini comme quelque chose qui recueille les données sur l'état de l'infrastructure / des applications et les traces de performances d'une manière ou d'une autre (https://thenewstack.io/monitoring-and -observabilité-quelle-est-la-différence-et-pourquoi-est-ce-important /).

Ou, selon honeycomb.io :

• «Vous vérifiez l'état et les comportements de vos systèmes par rapport à une ligne de base connue, pour déterminer si quelque chose ne se comporte pas comme prévu.»
• "Vous pouvez écrire des chèques Nagios pour vérifier qu'un tas de choses sont dans les bons seuils connus."
• «Vous pouvez créer des tableaux de bord avec Graphite ou Ganglia pour regrouper des ensembles de graphiques utiles.»
• «Tous ces outils sont formidables pour comprendre les inconnues connues de votre système.»

Un vaste écosystème de produits tels que New Relic, HP et AppDynamics a évolué. Tous ces outils sont parfaitement adaptés à la surveillance de bas niveau et de niveau intermédiaire ou pour démêler les problèmes de performances.

Cependant, ils ne peuvent pas gérer les requêtes sur les données avec une cardinalité élevée et fonctionnent mal en cas de problèmes liés à des problèmes d'intégration tiers ou au comportement de grands systèmes complexes avec des essaims de services fonctionnant dans des environnements virtuels modernes.

Pourquoi les tableaux de bord sont inutiles

En fait, ils ne le sont pas. Mais seulement si vous savez quand et où regarder. Sinon, il vaut mieux regarder YouTube.

Les tableaux de bord ne sont pas mis à l'échelle.

Imaginez une situation où vous avez un tas de mesures liées à votre infrastructure (par exemple, cpu_usage / quotas de disque) et aux applications (par exemple, JVM allocation_speed / GC Runs), etc. Le nombre total de ces mesures peut facilement atteindre des milliers ou des dizaines de milliers. Tous vos tableaux de bord sont verts, mais un problème se produit alors dans un service d'intégration tiers. Vos tableaux de bord sont toujours verts, mais les utilisateurs finaux sont déjà affectés.

Vous décidez d'ajouter des contrôles de services d'intégration tiers à votre surveillance et d'obtenir un ensemble supplémentaire de mesures et de tableaux de bord sur votre téléviseur. Jusqu'au prochain cas.

Lorsqu'on lui demande pourquoi les clients ne peuvent pas ouvrir un site, la réponse ressemble souvent à ceci:



La spaghettification des tableaux de bord

Bien que l'adoption de la télémétrie de différentes parties du système soit une pratique courante, elle se termine généralement par un tas de spaghettis dessinés sur un tableau de bord.

Ce sont les métriques opérationnelles de GitLab qui sont ouvertes au public.

Et ce n'est qu'une petite partie de toute une armée de tableaux de bord



Cela ressemble à une tapisserie où il est facile de perdre le fil.

Agrégation de journaux

Les outils d'agrégation de journaux tels que ELK Stack ou Splunk sont utilisés par la grande majorité des sociétés informatiques modernes. Ces instruments sont incroyablement utiles pour l'analyse des causes profondes ou l'autopsie. Ils peuvent également être utilisés pour surveiller certaines conditions qui peuvent être dérivées de votre flux de journaux.

Cependant, cela a un coût. Les systèmes modernes génèrent d'énormes quantités de journaux et une augmentation de votre trafic peut épuiser vos ressources ELK ou augmenter le taux de facturation de Splunk sur la lune.

Il existe certaines techniques d'échantillonnage qui peuvent réduire la quantité de journaux dits ennuyeux de plusieurs ordres de grandeur et sauver tous ceux anormaux. Il peut donner un aperçu de haut niveau sur le comportement normal du système et une vue détaillée de tout événement problématique.

Des journaux à un modèle d'événements

Habituellement, les lignes de journal reflètent les événements qui se produisent dans le système. Par exemple, établir une connexion, s'authentifier, interroger la base de données, etc. L'exécution de toutes les phases signifie qu'un travail est terminé. L'événement de définition en tant que travail logique peut être considéré comme faisant partie des objectifs de niveau de service liés à un service particulier. Par «service», j'entends non seulement les services logiciels, mais aussi certains appareils physiques, tels que les capteurs ou autres machines du monde IoT.

Il est également très complémentaire des principes de conception pilotés par domaine. L'isolement et le partage des responsabilités entre les services ou les domaines rendent les événements spécifiques à chaque travail dans chaque partie du système.

Par exemple, les événements du service de connexion peuvent être séparés par succès_logins, échec_logins avec leur propre contexte dynamique.

Les métriques et les événements doivent construire une histoire autour des processus dans le système.

Les événements peuvent être échantillonnés de telle manière que dans le cas d'un comportement normal du système, seule une fraction d'entre eux est stockée et tous les événements problématiques sont stockés tels quels. Les événements sont agrégés et stockés en tant qu'indicateurs de performance clés en fonction des objectifs de services particuliers.

Il peut rassembler des métriques d'objectifs de service et leurs métadonnées associées qui tirent parti des connexions entre les problèmes sur une base momentanée.

Écrit avec une cardinalité élevée à l'esprit, ces données révèlent les inconnues-inconnues dans le système.

Est-ce une forme d'instrumentation logicielle? Oui Cependant, lorsque vous comparez les quantités de données provenant de la journalisation au niveau du débogage et de l'instrumentation complète, la division des journaux en événements permet de boire dans un tuyau d'incendie dans l'environnement de production sans être noyé dans les données et les coûts.

«Définir un événement comme un travail pourrait être considéré comme lié aux objectifs d'un service particulier.»

Pourquoi nous ne sommes pas prêts pour des solutions d'IA complètes

L'IA est un bon mot à la mode pour attirer les investissements des startups. Cependant, le diable est toujours dans les détails.

1. Reproductibilité

Le problème d'un système entièrement basé sur l'apprentissage automatique (l'approche dite de l'intelligence artificielle complète) est que, parce qu'il apprend constamment de nouveaux comportements, il n'y a pas de reproductibilité. Si vous voulez comprendre pourquoi, par exemple, une condition a entraîné une alerte, vous ne pouvez pas l'examiner, car les modèles ont déjà changé. Toute solution qui repose sur l'apprentissage constant du comportement est confrontée à ce problème.

Il est essentiel d'optimiser le système lui-même lorsque vous utilisez des données ou des mesures très granulaires, mais il est très difficile de le faire sans reproductibilité.

2. Consommation de ressources

Pour tout type d'apprentissage automatique constant, vous avez besoin d'une quantité importante de ressources de calcul. Habituellement, cela prend la forme d'ensembles de données de traitement par lots. Dans le cas de certains produits, les exigences minimales pour le traitement de 200 000 mesures sont v32CPU et 64 Go de RAM. Si vous souhaitez doubler le nombre de mesures, vous avez besoin d'une autre machine qui répond aux mêmes exigences.

3. Vous ne pouvez pas encore faire évoluer l'automatisation complète de l'apprentissage en profondeur

Selon une thèse de maîtrise rédigée par Samreen Hassan Massak (pas encore terminée), le processus de formation pour des milliers de mesures prend des jours de temps CPU ou des heures de temps GPU. Vous ne pouvez pas le faire évoluer sans faire exploser votre budget.

4. Vitesse

Des solutions comme Amazon Forecast qui fonctionnent comme des services de traitement par lots qui ingèrent des données et attendent la fin du calcul ne sont pas adaptées à cela.

5. Clarté

D'après l'expérience de Google:

«Les règles qui détectent le plus souvent les incidents réels doivent être aussi simples, prévisibles et fiables que possible.»

landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems

Lorsque les modèles ou les règles changent constamment, vous perdez la compréhension du système et cela fonctionne comme une boîte noire.

Anomalies = alertes?

Disons que vous avez des milliers de mesures et si vous voulez avoir une bonne observabilité, vous devez collecter des données hautement cardinales. Chaque battement de cœur du système générera des fluctuations statistiques dans votre essaim de métriques.

https://berlinbuzzwords.de/15/session/signatures-patterns-and-trends-timeseries-data-mining-etsy

Les principales leçons qui peuvent être tirées du projet Kale d'Etsy:



Les alertes sur les anomalies de métriques conduiront éventuellement à des quantités massives d'alertes et à un travail manuel avec des seuils et des filtres artisanaux.

Pourquoi nous avons besoin d'une approche de streaming

L'obtention de l'observabilité et la mise en lumière des inconnus-inconnus nécessitent des données très granulaires qui peuvent être classées par centres de données, versions de construction, services, plates-formes et types de capteurs. Les agréger dans n'importe quelle combinaison est combinatoire par sa nature.

Même si vous concevez soigneusement vos métriques et événements, vous finirez éventuellement par en avoir une assez grande quantité. Lorsque vous travaillez sur cette échelle en temps réel, les requêtes régulières ou les travaux par lots auront une latence et des frais généraux importants.

Choses à considérer

Toute opération effectuée sur un flux infini de données est tout à fait une entreprise d'ingénierie. Vous devez gérer les implications relatives aux systèmes distribués.



Tout en surveillant les événements, les objectifs de niveau de service ou les KPI à un niveau élevé, vous devez être réactif et ne pas interroger constamment vos données, mais opérer à la place sur un flux qui peut évoluer horizontalement et atteindre un débit et une vitesse élevés sans consommer une quantité écrasante de ressources.

Certains frameworks de streaming, tels qu'Apache Storm, Apache Flink et Apache Spark, sont orientés vers le traitement de tuple et non vers le traitement de série chronologique.

Il y a également des problèmes avec la sémantique des systèmes distribués.

Disons que vous avez beaucoup de déploiements dans différents centres de données. Vous pouvez avoir un problème de réseau et l'agent stockant vos métriques KPI ne peut pas les transmettre. Après un certain temps - disons 3 minutes - l'agent envoie ces données au système. Et ces nouvelles informations devraient déclencher une action basée sur cette condition. Devrions-nous stocker cette fenêtre de données en mémoire et vérifier les conditions non seulement en arrière mais aussi en avant dans le temps? Quelle doit être la taille de cette fenêtre de désynchronisation? Opérer sur des milliers de métriques en temps réel rend ces questions très importantes. Vous ne pouvez pas tout stocker dans la base de données dans le cas de systèmes de traitement de flux sans perdre en vitesse.

L'analyse de flux en temps réel des données de séries chronologiques dans les systèmes distribués est délicate, car les événements concernant le comportement du système peuvent être hors service et les conditions qui pourraient émerger à partir de ces données dépendent de l'ordre des événements. Cela signifie qu'une sémantique au moins une fois peut être obtenue facilement, mais quand une seule fois peut être beaucoup plus difficile.

Caractéristiques souhaitables d'une stratégie de surveillance selon le classeur Google SRE

• «La conception moderne implique généralement la séparation de la collecte et de l'évaluation des règles (avec une solution comme le serveur Prometheus), le stockage des séries chronologiques à long terme (InfluxDB), l'agrégation des alertes (Alertmanager) et le tableau de bord (Grafana).»
• «Les systèmes basés sur les journaux de Google traitent de gros volumes de données hautement granulaires. Il existe un certain délai inhérent entre le moment où un événement se produit et celui où il est visible dans les journaux. Pour les analyses qui ne sont pas urgentes, ces journaux peuvent être traités avec un système de traitement par lots, interrogés avec des requêtes ad hoc et visualisés avec des tableaux de bord. Un exemple de ce flux de travail serait d'utiliser Cloud Dataflow pour traiter les journaux, BigQuery pour les requêtes ad hoc et Data Studio pour les tableaux de bord. »
• "En revanche, notre système de surveillance basé sur des métriques, qui recueille un grand nombre de métriques de chaque service chez Google, fournit des informations beaucoup moins granulaires, mais en temps quasi réel. Ces caractéristiques sont assez typiques d'autres systèmes de surveillance basés sur des journaux et des métriques, bien qu'il y ait des exceptions, telles que les systèmes de journaux en temps réel ou les métriques à haute cardinalité. »
• «Dans un monde idéal, la surveillance et l'alerte du code devraient être soumises aux mêmes normes de test que le développement du code. Alors que les développeurs de Prometheus discutent du développement de tests unitaires pour la surveillance, il n'existe actuellement aucun système largement adopté qui vous permette de le faire. »
• «Chez Google, nous testons notre surveillance et nos alertes à l'aide d'un langage spécifique au domaine qui nous permet de créer des séries chronologiques synthétiques. Nous écrivons ensuite des assertions basées sur les valeurs d'une série chronologique dérivée, ou sur le statut de tir et la présence d'étiquettes d'alertes spécifiques. »

Un grand merci aux Charity Majors et Cindy Sridharan
Merci à sigrid maasen pour son aide