L’observabilité dans le cloud

Share this post:

Que les requêtes affluent et que les alertes restent silencieuses !

(Bénédiction SRE* traditionnelle 😊)

On assiste depuis quelque temps à des débats passionnés autour de la surveillance des systèmes. C’est une conséquence de l’importance que revêt désormais le sujet, mais aussi d’un problème auquel on se trouve confronté. En effet la surveillance « traditionnelle » passe difficilement à l’échelle dans les systèmes distribués modernes en général, et le cloud en particulier.

Il faut désormais répondre aux défis de l’agilité posés par le métier et les pratiques DevOps associées au cloud.

Pour s’adapter à ces nouvelles réalités, le monitoring traditionnel mue vers les concepts et techniques plus évolués d’« observabilité ». C’est une course à la montre et un pari que les acteurs du monitoring/observabilité sont condamnés à gagner – condition nécessaire au succès du « move to cloud » chez nos clients.

Le monitoring traditionnel, pilier de la surveillance des systèmes

On rappelle que le monitoring traditionnel est l’observation de l’évolution du système dans le temps, afin de savoir si chaque élément du système (application, BDD, réseau, disque etc.) fonctionne correctement.

Une large palette d’outils existe sur le marché, que l’on retrouve sous l’appellation APM (Application Performance Monitoring). Ils couvrent la collecte, la persistance, l’analyse et la visualisation des données télémétriques que sont les métriques, les évènements, les logs et les traces (désignées souvent par le sigle MELT).

Certains APM sont généralistes et manipulent toutes les données MELT, tandis que d’autres spécialisés dans le traitement de certains types de données. Les APM produisent des tableaux de bord, qui sont le moyen privilégié des équipes opérations (OPS) pour la surveillance des systèmes. Ces tableaux de bord présentent pour chaque élément du système les 4 « golden signals » que sont : la Latence, les Erreurs, le Trafic et la Saturation (LETS). Les « golden signals » nous alertent d’un problème avant qu’il ne devienne grave.

Le monitoring traditionnel fonctionne généralement en silos. Il emploie des outils spécialisés par type d’élément du système qui ne communiquent pas entre eux. Il est très efficace dans l’anticipation des pannes prévisibles, connues et attendues (on parle parfois de « known unknowns » – par exemple : « alerte-moi lorsque le CPU dépasse un seuil »). Sa limite est que nous ne savons pas imaginer tous les types de pannes qui pourraient survenir, et encore moins évaluer leur probabilité d’occurrence.

Le monitoring traditionnel utilise principalement une approche « en décalé » : enregistrons tout, nous verrons plus tard l’usage que nous ferons des données collectées. Le problème est que, parfois, « plus tard » c’est « trop tard » – et la quantité de données collectées est telle qu’il est difficile de les exploiter d’une manière efficace.

Malgré ces limites, le monitoring traditionnel reste irremplaçable, et les APM ont encore de beaux jours devant eux.

Les systèmes modernes et la limite des APM

Fondamentalement différents de leurs prédécesseurs, les environnements cloud natifs et les systèmes hautement distribués en général, peuvent être complexes à observer et à exploiter.

Complexité technique : les architectures techniques cloud sont composées d’une multitude de couches, de composants d’infrastructure, d’agents diverses et variés, de composants de sécurité etc. La diversité et le nombre potentiel des disfonctionnements et des pannes de tous ces éléments du système se retrouvent littéralement démultipliés par un facteur 100. Surveiller tous ces éléments par des méthodes classiques devient donc plus qu’un défi.

Complexité de l’architecture applicative : les applications « Cloud-Natives » sont désormais basées sur des myriades de microservices, pouvant aller de quelques conteneurs à plusieurs milliers voire, plusieurs dizaines de milliers. Comprendre les problèmes de disponibilité et de performance dans de telles conditions pose des défis inédits aux méthodes traditionnelles de surveillance.

Diversité du stack technologique des applications : les applications peuvent être basées sur des microservices « polyglottes », à savoir, des microservices développés avec des langages de programmation différents et/ou des stack technologiques différents. Par conséquent, au lieu d’utiliser juste une manière de collecter les données télémétriques, les outils APM doivent très probablement en avoir plusieurs. D’où, le problème de consolidation des données collectées car potentiellement dans des formats différents, placées dans des endroits différents (le cas des logs par exemple) ou encore utilisant, potentiellement, des horloges différentes.

Nécessité de traçabilité « de bout en bout » : dans une application basée sur des microservices qui collaborent entre eux, une requête parcoure potentiellement plusieurs microservices lors de son exécution. En cas d’erreur, l’APM doit retracer un chemin entre différents microservices pour nous aider à comprendre où et pourquoi l’erreur s’est produite.

Changements fréquents de la topologie du système : prenons l’exemple des pods Kubernetes. Le pod est par nature un composant « short lived » (éphémère), qui peut à tout moment être supprimé ou recréé par Kubernetes. Son nombre d’instances (réplicas) peut être revu à la hausse ou à la baisse. Il peut être déplacé par Kubernetes sur un autre nœud, donc, arrêté, relancé, reconnecté à la BDD, etc. Il peut également « crasher », comme tout runtime et comme les applications monolithiques – mais, contrairement à ces dernières, le crash d’un pod n’est pas un évènement exceptionnel (cela dépend de la criticité de l’application, de la fréquence des crashs etc.). Pour tout cela, il est difficile pour un APM traditionnel de suivre efficacement les changements de topologie du système et de consolider les données télémétriques.

Agilité fonctionnelle accrue : les applications doivent être capables d’évoluer de plus en plus fréquemment pour répondre aux besoins du marché. Le métier et les DEV veulent publier rapidement et fréquemment leurs nouvelles fonctionnalités en production, tandis que les OPS cherchent la stabilité du système. Les évolutions fréquentes de l’application multipliant inévitablement les bugs et autres dysfonctionnements, il est impératif que les outils APM permettent la diminution du MTTR  (Mean Time To Repair) afin de faire face.

L’aspect humain : Aussi compétents et dévoués soient-ils, les OPS peuvent être submergés par la surcharge de travail engendrée par la complexité des systèmes distribués et des environnements cloud. Les outils devraient pouvoir les assister (notamment, en automatisant les tâches manuelles répétitives) mais ce n’est pas vraiment le cas des outils APM traditionnels.

« Incident Fatigue » : La « fatigue des alertes » se produit lorsqu’un nombre écrasant d’alertes submerge les équipes OPS – ce qui est souvent le cas dans les environnements cloud. A fortiori, une proportion importante d’alertes sont de « fausses alertes ». Cela provoque un phénomène de « désensibilisation » des OPS entraînant des réponses retardées, voire des alertes ratées ou ignorées.

L’observabilité, futur des opérations

L’observabilité s’inscrit dans les mouvements plus larges que sont le DevOps, le SRE, le Cloud natif ou encore le Platform Engineering. Elle vient du monde scientifique, plus précisément de la théorie du contrôle et des systèmes d’autorégulation. Théorie selon laquelle, un système est observable si son état interne peut être introspecté et déduit en analysant uniquement son état externe ; en d’autres termes, en analysant certaines données en sorties du système – données dites télémétriques – collectées à l’aide des capteurs. In fine, l’observabilité permet de réduire le temps moyen de résolution (MTTR) des incidents, et surtout, contribue à les éviter.

A l’instar des autres concepts du type <xxx>bilités (réutilisabilité, maintenabilité, testabilité etc.) l’observabilité est aussi une propriété du système ainsi qu’un objectif dans la quête continue de son amélioration.

L’observabilité n’est pas un nouveau paradigme et n’est pas en rupture par rapport au monitoring traditionnel. L’observabilité utilise toujours des outils APM dans l’accomplissement de sa mission ; mais, elle n’est pas uniquement une question d’outils et de mesures, elle va plus loin en introduisant de nouvelles approches dans la surveillance des systèmes, des approches que l’on peut qualifier de « holistiques ».

A la différence du monitoring traditionnel, l’observabilité ne se contente pas de constater les pannes mais pose des questions plus vastes : Quelle est la santé globale du système ? Comment une panne s’est produite ? Pourquoi s’est-elle produite ? Pour y répondre, elle se propose de surveiller le système dans sa globalité et sur toutes les couches de l’architecture technique et applicative.

Une plateforme d’observabilité se veut plus proactive que le monitoring traditionnel. Elle vise à anticiper voire empêcher les pannes, au lieu d’être dans la réaction après leur déclenchement.

L’observabilité est une approche dynamique – capable de prendre en compte d’une manière quasi-instantanée les changements du système (et notamment sa topologie).

L’analyse des données télémétriques se fait pratiquement en temps réel. Cela implique une collecte et une analyse intelligente et adaptées à des signaux spécifiques, pour avoir immédiatement des indices sur les causes des pannes et leur correction.

L’observabilité permet une meilleure compréhension des systèmes complexes. Elle offre parfois des réponses à des problèmes auxquels nous n’avons pas pensés. C’est ce que l’on appelle « unknown unknowns » (« nous ne savons pas que nous ne savons pas… »).

Dernières tendances de l’observabilité « avancée »

IA

L’intelligence artificielle est une tendance de fond en général. Elle trouve sa place dans le domaine de l’observabilité des systèmes et en particulier dans la détection et la résolution des pannes. L’IA rend l’observabilité véritablement exploitable.

Des outils tels que Dynatrace ou IBM Cloud Pak for Watson AIOps sont dotés de capacités IA et d’apprentissage non supervisé. Ces outils sont capables d’exploiter de nombreuses sources de données télémétriques et d’utiliser l’IA pour identifier les causes possibles d’anomalie.

Autres utilisations de l’IA dans le domaine de l’observabilités : l’autoadaptation des seuils pour la détection des anomalies ; le regroupement des anomalies liées à un seul problème ; le filtrage des fausses alarmes pour mitiger les « alert storming » (cause fréquente du phénomène de « incident fatigue ») ; la découverte automatique des dépendances entre les composants.

Observabilité Full-stack

C’est la capacité d’introspecter toute la pile technologique et identifier tout ce qui pourrait affecter l’expérience utilisateur. Elle repose sur une vue complète de toutes les données télémétriques, agrégées dans une source unique de vérité.

Visibilité de bout en bout

C’est un traçage distribué qui permet la visibilité de bout en bout des requêtes. Crucial dans un environnement cloud où on doit sans cesse naviguer entre l’infrastructure, la plateforme Kubernetes, les fonctions/serverless, les microservices, les BDD, les solutions open source. La visibilité du parcours de bout en bout d’une requête permet aux équipes OPS d’identifier plus rapidement et de manière proactive les problèmes de performances ou autres.

Données contextuelles

Tandis que les données télémétriques nous aident à comprendre l’état interne du système, les données contextuelles nous fournissent des « métadatas ». A savoir : des informations supplémentaires sur l’environnement d’exécution de l’application, ses paramètres de configuration etc. Tout cela de manière dynamique, car toutes ces informations peuvent, potentiellement, changer d’un instant à l’autre.

Conclusion

Collecter des données télémétriques reste relativement simple. Produire des déductions utiles, dissiper le bruit qui les accompagne, leur donner un sens, est plus ardu.

L’observabilité apporte du sens et du contexte aux données collectées – deux éléments désormais indispensables à la résolution rapide des incidents, à leur anticipation et leur prévention.

*SRE (Site Reliability Engineering) est une approche d’ingénierie logicielle pour l’exploitation informatique.