Les évolutions de la supervision

Photo by Pixabay from Pexels

TL;DR: La supervision est passée d'un outil de niveau 1 à une solution qui doit gérer des applications distribuées. Désormais, l'arrêt d'un composant est plus lié à une évolution ou un test qu'à un fait qui impacte les utilisateurs. Cet article est une synthèse des besoins de la supervision à l'ère des cloud natives.

Développer des applications qui tirent parti du cloud, les "cloud natives" est motivé par de nouveaux besoins des organisations et des utilisateurs. Par exemple, vous voudrez pouvoir mettre à jour des composants pour répondre à une vulnérabilité "zero-day", des contraintes réglementaires ou à des nouveaux usages. Vous voudrez pouvoir mixer des langages pour tirer le meilleur parti des compétences ou pour être plus efficaces pour traiter un problème donné. Vous voudrez suivre des indicateurs métiers pour avoir des retours. Pour tout ça, les applications s'appuient sur un arsenal de techniques. La supervision est touchée de plein fouet par ces changements. Elle est aussi plus essentielle que jamais.

Des nouveaux indicateurs

La transformation la plus radicale est certainement liée aux fondamentaux de la supervision, à savoir les mesures et les alertes. Si vous avez le malheur de travailler sur cette nouvelle génération d'applications avec des équipes de supervision qui n'ont pas évolué, vous savez de quoi il s'agit. Ce qui est critique pour certains systèmes comme l'arrêt d'un composant est une simple information pour une application cloud. Une livraison ? Un test ? Il faut mesurer les impacts, les symptômes et revoir entièrement le système d'alertes. Le crash ou le dysfonctionnement d'un service pourra sans doute être traité demain, à moins que...

La supervision est plus fondamentale que jamais et en même temps, elle doit être revue dans son coeur.

My Philosophy on Alerting explique ce phénomène et ses limites. Pour y répondre, de nouvelles approches, les signaux LTES de Google SRE, la méthode USE de Brendan Gregg ou la méthode RED de Tom Wilkie, sont apparues.

Supervision et services

Un second changement drastique dans la supervision est la nécessité de comprendre ce qu'est un service. En effet, une alerte doit être émise lorsqu'un service souffre de dysfonctionnements. cela implique que ce qui constitue ce service est appréhendé par la supervision. Or il se peut que les 3 composants qui constituent un service soient tous remplacés dans 20 secondes. Et si celui-ci est supprimé parce que ses fonctionnalités sont prises en charge par un autre service ?

Il existe typiquement différentes façons de voir un service selon qu'on le regarde de l'extérieur, comme une boite noire, ou qu'on l'observe de l'intérieur, en boite blanche :

  • Le fait que les API soient au coeur des services cloud natives facilite leur observation en mode boîte noir. Si vous supervisez un load-balancer ou si vous testez un service vous aurez une assez bonne vision de son fonctionnement. Cela étant cette approche ne s'applique pas pour tous les services, typiquement un "worker" qui récupère et traite des évènements n'entre pas forcément dans ce modèle. D'autre part, l'approche boite noire à de nombreuses limites que seule l'approche boite blanche permet de dévérouiller. Vous ne verrez pas l'équilibre de la charge entre les composants d'un service en l'observant de l'extérieur.
  • Permettre l'observation en mode boite blanche d'une infrastructure dynamique suppose une collaboration bien établie entre l'application et la supervision. C'est d'autant plus le cas si vos composants utilisent des langages différents. Une approche populaire consiste à mettre en place un référentiel dynamique, une registry, dans laquelle les services s'enregistrent. C'est une des raisons pour lesquelles les applications labélisent leurs composants dans les services des fournisseurs Cloud ou de logiciels de découverte dynamique comme Consul, Zookeeper ou Etcd. Cela permet à la supervision de comprendre ce qu'est un service, son niveau de criticité, l'équipe en charge. La difficulté ne s'arrête pas là puisque la supervision doit être capable de récupérer les mesures clé ainsi que les règles d'alertes. Autrement dit, la supervision doit s'adapter aux besoins des applications.

Ainsi si les systèmes "classiques" de supervision peuvent facilement collecter de nouvelles mesures et changer les modes d'alerte, ils sont souvent mal armés pour s'intégrer à des reférentiels ou traiter de conditions plus avancées quoique fondamentales dans ce nouveau monde. Comment créer une condition qui alerte s'il n'y a pas, au moins, 2 instances actives pour un service" ? Comment la supervision peut-elle découvrir automatiquement une nouvelle mesure créé pour une nouvelle fonctionnalité ? La supervision doit pouvoir agréger des mesures. Elle doit être programmable de manière simple. Elle doit être accessible depuis tous les langages ou au moins tous vos langages présents et futurs.

Fragmentation

Comme si ce n'était pas assez compliqué les applications et les équipes se fragmentent. Vous allez faire appel à un système externe pour certaines fonctions stratégiques et pourtant clé à leur fonctionnement. Ainsi vous pouvez déléguer l'authentification à un tier ; Vous vous appuyerez certainement sur des services "managés" chez d'autres tiers. Les composants se spécialisant, une application qui avait 2 ou 3 composants va désormais en avoir une dizaine...

Autre phénomène de fragmentation, le "you build it, you run it" que l'on entend dans les nouvelles approches de développement et qui supposent que les personnes en charge de la supervision changent en fonction du composant, y compris au sein de la même organisation. Il faut que votre outil de supervision le prenne en compte.

Enfin, les composants eux-mêmes sont multipliés pour assurer la disponibilité, la gestion de la charge, assurer une sécurité inter-site ou des approches multi-tenant.

De nouveaux usages

Loin de réduire le périmètre, la supervision a de nouveaux usages qui la rend d'autant plus importante. Par exemple:

  • Elle peut servir de "feedback loop" dans les les processus de "CI/CD" pour valider le fonctionnement des nouveaux composants et sécuriser les mises en production progressives
  • Elle peut servir d'outil pour déclencher les mécanismes d'"autoscaling" sur la base d'indicateurs plus complexes qu'un simple seuil de CPU
  • Elle peut alimenter des systèmes qui consolident et historisent les données
  • Elle peut servir au pilotage métier, surtout si vos indicateurs évoluent

Un monde en évolution

Alors que la supervision était devenue ennuyeuse avec quelques produits que l'on retrouve partout, l'arrivée de ces nouveaux besoins a rapidement transformé le paysage de la supervision. Celle-ci fait désormais partie d'un domaine plus vaste qui est celui de l'"observabilité" et qui regroupe avec elle la gestion des logs et la gestion de traces distribuées.

La supervision n'est plus seulement un problème d'outil mais de créer un cadre dans lequel les services applicatifs s'inscrivent. Il s'agira par exemple pour que vos services soient supervisés :

  • Qu'ils s'exécutent sur un environnement
  • Qu'ils déploient un certain nombre de "tags", "labels" ou "annotations"
  • Qu'ils exposent des points d'accès dans lesquels ils exposent des mesures
  • Qu'ils publient les règles d'agrégation des métriques
  • Qu'ils publient des rapports qui permettent aux "bons" utilisateurs de visualiser leur fonctionnement

Dans certains des articles à venir, vous trouverez des exemples de mise en oeuvre de supervision. Gardez à l'esprit que c'est une collaboration entre l'application et son écosystème et qu'ils bénéficient d'outils

Et pour ceux qui pensent qu'il y a de la magie ou, pire, qu'il faut y ajouter de l'intelligence artificielle, voici ce que les équipes Google écrivent sur le sujet dans leur livre que l'on pourrait traduire par "SRE: Comment Google fait fonctionner ses systèmes en production":

In general, Google has trended toward simpler and faster monitoring systems, with better tools for post hoc analysis. We avoid "magic" systems that try to learn thresholds or automatically detect causality. [...]

Similarly, to keep noise low and signal high, the elements of your monitoring system that direct to a pager need to be very simple and robust. Rules that generate alerts for humans should be simple to understand and represent a clear failure.

Google SRE, Chapter 6: Monitoring Distributed Systems

Easyteam DevOps

Easyteam DevOps