Qu’est-ce que l’observabilité et pourquoi est-ce important ? –

L’observabilité est une caractéristique des systèmes logiciels qui offrent une visibilité approfondie sur leurs opérations internes. Posséder une bonne observabilité facilite une résolution plus rapide des problèmes en aidant les équipes d’exploitation à identifier la cause des problèmes.

La définition la plus simple d’un logiciel « observable » est un système qui vous permet de déduire son état interne en observant les sorties qu’il produit. Si votre système ne peut pas fournir ces sorties, il ne sera pas entièrement observable.

Considérez une plate-forme logicielle qui semble fonctionner plus lentement que la normale. À première vue, vous n’avez pas suffisamment d’informations pour déterminer la cause du ralentissement. Mais si le système émettait des métriques de performance pour chaque étape de son exécution, vous pourriez immédiatement identifier le composant avec un problème. L’observabilité du système est désormais renforcée.

L’observabilité n’est-elle pas la même chose que la surveillance ?

L’observabilité n’est pas la même chose que la surveillance, bien que les deux concepts soient étroitement liés. Les bonnes pratiques de surveillance contribuent à un système observable. Ils ne fournissent pas de garantie d’observabilité. Inversement, un système pourrait être raisonnablement observable sans une pile de surveillance à part entière.

La surveillance en termes DevOps fait généralement référence à l’utilisation de plusieurs métriques prédéfinies pour identifier quand un système fonctionne conformément aux attentes. Les métriques couvertes sont généralement liées à l’utilisation des ressources (utilisation du processeur, débit du réseau), mais peuvent également faire apparaître des données de base sur les opérations de votre système (nombre de requêtes provoquant un 500 code d’erreur).

L’observabilité va un peu plus loin et nécessite une instrumentation plus nuancée. Contrairement à la surveillance, elle est couplée à votre système et à ses caractéristiques, plutôt qu’à l’environnement environnant.

Un système surveillé vous indique que le 500 le nombre d’erreurs est élevé et les utilisateurs rencontrent des problèmes. Un observé le système signale que votre microservice d’authentification expire, de sorte que les sessions utilisateur ne sont pas restaurées et que votre passerelle émet un 500 en dernier recours.

Comment les systèmes deviennent-ils observables ?

Décomposons les différences entre les deux exemples ci-dessus. Dans une approche traditionnelle, vous déploieriez sur votre serveur et configureriez la surveillance, peut-être en utilisant les alertes de métriques de votre fournisseur de cloud. Si un problème a été détecté, vous pouvez aller inspecter les journaux du serveur pour détecter les problèmes.

Ce modèle est déjà observable dans une certaine mesure. L’utilisation moderne de « observabilité » en dit cependant un peu plus. Les journaux d’erreurs du serveur fournissent généralement le résultat final mais pas les états qui l’ont provoqué. Pour qu’un système soit vraiment observable, vous devez être capable de déterminer la séquence d’états internes qui ont conduit à une sortie particulière, sans avoir à passer trop de temps à collecter manuellement les informations.

Il existe trois principaux « piliers » d’observabilité, dont un bon suivi. L’attention portée aux trois piliers devrait aboutir à un système observable qui aide efficacement au diagnostic des problèmes.

Métriques et surveillance

Un système observable doit fournir des mesures constantes pour des métriques prédéfinies. Les meilleures métriques sont celles qui présentent des informations exploitables concernant votre application et ses performances, pas nécessairement des graphiques génériques de CPU et de mémoire.

Enregistrement

Le deuxième pilier de l’observabilité est la journalisation. Cela décrit une approche de journalisation plus structurée qu’une écriture de base lorsqu’une erreur se produit. Les journaux doivent être hautement intégrés dans votre système afin que chaque événement soit enregistré dans un service de journalisation centralisé. Les journaux eux-mêmes doivent être structurés de manière standardisée, afin que les outils de visualisation des journaux puissent les indexer et les formater automatiquement.

Tracé

Le dernier pilier est le traçage. Les traces capturent tout ce qui se passe au cours d’une exécution particulière du programme. Cela vous donne les informations dont vous avez besoin pour reproduire la séquence exacte des événements qui ont conduit à un problème. Le traçage est particulièrement important pour les systèmes distribués où une seule requête peut toucher une douzaine de microservices ou plus. Il n’est pas réaliste de se fier uniquement aux journaux de service, car vous ne pourrez pas voir ce qui est arrivé à la demande une fois qu’elle se sera terminée avec chaque service. Une trace au niveau de la requête est plus efficace pour identifier les problèmes.

Vous pouvez commencer à rendre un système plus observable en vous assurant de couvrir les trois piliers. N’oubliez pas que « l’observabilité » n’est pas une chose spécifique – c’est un trait d’un système, pas un seul attribut. Il y a de fortes chances que votre système soit déjà « observable » via des métriques de base et des journaux d’erreurs, mais il peut encore avoir une faible « observabilité » si vous ne pouvez pas déterminer facilement la cause première des erreurs.

L’observabilité arrête-t-elle les erreurs ?

Il convient de noter que l’observabilité n’est pas destinée à éliminer les bogues et les erreurs. Au lieu de cela, c’est en fait une acceptation que des problèmes peuvent et vont se produire. Plutôt que de supposer que votre système est infaillible, l’observabilité vous encourage à prévoir l’impensable. Si vous étiez confronté à une panne, auriez-vous les outils nécessaires pour en trouver la cause ?

Pour utiliser une analogie automobile, c’est la différence entre un témoin de contrôle du moteur et le logiciel de diagnostic du fabricant. Aussi indésirables et improbables que cela puisse être, des dysfonctionnements sur la route se produisent. La plupart des personnes sans équipement spécialisé voient un voyant d’avertissement générique. Un automobiliste ou un technicien dédié aura les outils pour lire la cause de cette lumière.

Revenons maintenant au cloud. Un écran de métriques rouges n’aidera pas beaucoup lors d’une panne. Semblable à la façon dont un mécanicien de véhicule peut lire les diagnostics, votre système doit être plus profondément observable afin que vous puissiez rapidement déterminer ce qui ne va pas sans regarder les écrous et les boulons. Il est important de prévoir les catastrophes pour ne pas être pris au dépourvu.

L’observabilité est continue

Maintenir une bonne observabilité nécessite une maintenance continue. Vous devrez évaluer votre instrumentation au fur et à mesure que vous ajoutez de nouveaux services. Sinon, vous pouvez involontairement créer des vides dans vos journaux et traces dans lesquels les demandes disparaissent.

Vous pouvez identifier les lacunes dans votre mise en œuvre de l’observabilité en interrogeant le système et en vérifiant que vous pouvez obtenir les réponses dont vous avez besoin. Vous devriez penser aux informations dont vous auriez besoin pour commencer à résoudre un problème. Pourriez-vous y accéder lors d’une panne, sans intervention manuelle prolongée ?

Un système véritablement observable devrait pouvoir utiliser l’un des trois piliers pour répondre aux questions posées par les deux autres. Pourquoi l’utilisation de la mémoire est-elle dans la zone dangereuse ? Pourquoi une erreur a-t-elle été enregistrée dans les journaux du service d’authentification ? Dans ces deux cas, les deux autres piliers devraient être votre première escale pour trouver la réponse.

Résumé

L’observabilité est un mot inventé qui peut parfois sembler vague et opaque. En pratique, l’utilisation moderne du terme fait référence à quelque chose d’assez simple : l’unisson de la surveillance, de la journalisation et du traçage pour vous aider à déduire l’état interne d’un système à partir de ses sorties.

Une bonne observabilité est vitale pour les architectures distribuées où les fonctionnalités sont réparties entre les microservices. Un système inobservable devient un trou noir qui aspire les demandes mais ne fournit rien en retour. Cela compromettra votre capacité à répondre aux problèmes et pourrait amener les utilisateurs à signaler des problèmes avant que vous n’en ayez connaissance.

À l’inverse, un système observable vous aide à garder une longueur d’avance sur les rapports d’erreur. Le temps de résolution est minimisé car le système attendra déjà avec les informations dont vous avez besoin.