Cloud
Ceci est la première partie d'un blog en deux parties, dans le prochain billet nous décrirons comment nous faisons de l'observabilité et de la gestion chez Public Cloud Managed Services pour nos clients dans le cadre de notre offre de Services Manager.
Nos clients dépendent de plus en plus d'architectures distribuées pour consommer des prestations pour services applicatifs. On assiste à une diversification sans cesse croissante de l'infrastructure et des applications en ce qui concerne leur lieu d'hébergement et leur mode de communication. Ce phénomène s'est accentué au cours des dernières années, en raison des grands progrès réalisés dans la facilité d'adoption des nuages. D'un côté du spectre, les clients choisissent l'emplacement et la catégorie de leurs ressources en fonction des prix, des caractéristiques et des exigences de conformité au sein d'un même fournisseur de cloud public ; de l'autre, ils se tournent vers des architectures multi-cloud ou de cloud hybride pour conduire leur transformation numérique, améliorer leur agilité, passer du CapEx à l'OpEx, etc.
Ces tendances ont suscité des avancées à la fois en matière d'observabilité et de monitoring. Mais au juste, qu'est-ce que le monitoring et qu'est-ce que l'observabilité? Oui, ils sont très différents, et cela m'agace lorsque j'entends ou lis que le monitoring est remplacé par l'observabilité ; ce n'est pas le cas, en fait l'observabilité améliore et amplifie le monitoring. Laisse-moi t'expliquer un peu.
L'une des meilleures explications sur le monitoring et l'observabilité que j'ai lues a été fournie par Morgan Willis, un opérateur ancienneté cloud chez AWS.
"Le monitoring est l'acte de recouvrement des prestations. Quels types de prestations nous recouvrons, ce que nous faisons avec les données, et si ces données sont facilement analysées ou disponibles, c'est une autre histoire. C'est là que l'observabilité entre en jeu. L'observabilité n'est pas un verbe, ce n'est pas quelque chose que tu fais. Au lieu de cela, l'observabilité est plutôt un terrain d'un système."
D'après cette explication, les outils tels que CloudWatch, Azure Monitor, X-Ray et App Insights peuvent être classés dans la catégorie des outils de monitoring ou de traçage. Ils nous permettent de récupérer des prestations et des métriques sur notre système et d'envoyer des alertes en cas d'erreurs et d'incidents. Par conséquent, le monitoring est une partie active de la collecte des données qui nous aideront à évaluer la santé de notre système et la façon dont ses différents composants fonctionnent ensemble. Une fois que nous avons mis en place une surveillance qui recueille en permanence les journaux, les sorties du système, les métriques et les traces, notre système devient observable.
Ma compréhension de ce que signifie le monitoring a continuellement évolué au cours de ma carrière ; actuellement, j'aime considérer le monitoring comme la partie ingestion de données de l'ETL (extract, transform, load). Cela signifie que tu rassembles des données provenant de sources multiples (journaux, traces, métriques) et que tu les mets dans un magasin de données. Une fois que toutes ces données sont disponibles, un analyste compétent peut en tirer des enseignements et construire de magnifiques tableaux de bord qui racontent une histoire que ces données véhiculent. C'est la partie observabilité - obtenir des insights à partir des prestations collectées, et les plateformes d'observabilité telles qu'Elasticsearch Kibana jouent le rôle d'un analyste compétent. Elles te fournissent des visualisations et des informations sur la santé de ton système.
L'observabilité, issue de la théorie du contrôle, mesure à quel point tu peux comprendre les états internes d'un système à partir de ses sorties externes. L'observabilité utilise l'instrumentation pour
Il s'agit de télémétrie, pas d'observabilité.
fournissent des informations qui facilitent le monitoring. En d'autres termes, la surveillance est ce que tu fais une fois qu'un système est observable. Sans un certain niveau d'observabilité, le monitoring est impossible.
Il s'agit de télémétrie et non d'observabilité.
Très souvent, je remarque la tendance à confondre l'observabilité avec la télémétrie. Ou, du moins, avec des interfaces utilisateur peu intégrées, construites au-dessus de silos de télémétrie, comme le montre le schéma ci-dessus. Dans cette formulation, l'observabilité est en quelque sorte expliquée comme la simple coexistence d'un outil de métrique, d'un outil de journalisation et d'un outil de traçage.
En bref : ne confonds pas la coexistence des métriques, du traçage/APM et de la journalisation avec l'" observabilité. "
Comme la plupart des mauvaises idées qui prennent de l'ampleur, il y a ici un grain de vérité : en particulier, que les traces, les métriques et les journaux ont tous une place dans la solution. Mais ils ne sont pas le produit ; ils ne sont que les données brutes. La télémétrie.
L'anatomie de l'observabilité.
La première couche est la télémétrie ; nous ne pouvons pas avoir d'observabilité sans les données brutes de télémétrie. En fonction de l'infrastructure et des moyens d'exploitation disponibles, il existe de nombreuses options d'outils pour recueillir la télémétrie brute. L'objectif principal de la première couche doit toujours être d'obtenir l'accès à une télémétrie de haute qualité.
La deuxième couche est celle du stockage ; il ne s'agit pas seulement de la façon dont nous stockons les données, mais aussi de la durée de ce stockage. Lorsque l'on considère les magasins de données pour l'observabilité, trouver le bon solde peut s'avérer être une situation difficile. Fondamentalement, si nous voulons manipuler efficacement des données à haut débit (par exemple, comptabiliser 100 % de tous les messages passés dans une appli mise à l'échelle, ou même prendre des mesures infra de haute fidélité comme la charge du processeur ou l'utilisation de la mémoire par conteneur), nous devons enregistrer des statistiques dans une base de données de séries temporelles. Sinon, nous gaspillons trop d'argent pour transférer et stocker des événements individuels. Et bien que certains puissent suggérer que tu peux échantillonner les événements, pour les données à basse fréquence cachées dans le firehose à haute fréquence, tu peux passer complètement à côté. Cette situation appelle à la création d'une base de données dédiée aux séries temporelles (TSDB) : un magasin de données conçu spécifiquement pour la conservation, l'indexation et l'interrogation de statistiques de séries temporelles comme celles-ci.
Et pourtant ! Si nous voulons manipuler des données de grande cardinalité (par exemple des tags par client, des identifiants uniques pour une infrastructure éphémère, ou des fragments d'URL), une TSDB est un désastre absolu. L'explosion de la cardinalité des tags s'accompagne d'une explosion des séries de spécifications uniques, et donc d'une explosion des coûts. Traditionnellement, il s'agissait d'une base de données de journalisation, bien qu'il soit plus sage de construire autour d'une base de données de transaction distribuée et orientée vers le traçage (nous y reviendrons plus tard) qui permet de faire d'une pierre deux coups (journalisation et traçage).
Néanmoins, trouver des bases de données transactionnelles et de séries de spécifications à la pointe de la technologie est nécessaire mais pas suffisant. Pour que l'observabilité se fasse sans heurt, la couche de données doit également être intégrée et faire l'objet de références croisées, de préférence dans le cadre d'une intégration approfondie.
Les défis ci-dessus peuvent parfois rendre l'observabilité difficile et parfois, elle peut sembler insaisissable. Cela nous amène à la troisième couche, les valeurs réelles ; dans le domaine de la gestion des produits, on les appellerait simplement les résultats commerciaux et ils constituent une partie essentielle de la proposition de valeur lorsque nous vendons l'observabilité et le monitoring à nos clients.
En fin de compte, la télémétrie, qu'elle soit en mouvement ou au repos, n'a pas de valeur intrinsèque. Ce sont seulement les flux de travail et les applications construites dessus qui peuvent avoir de la valeur. Pourtant, dans la présentation conventionnelle de " l'observabilité sous forme de métriques, de journaux et de traces", nous ne savons même pas quel problème nous sommes en train de résoudre ! Et encore moins comment nous le résolvons.
Lorsqu'il s'agit d'applications logicielles modernes et distribuées, il existe deux problèmes primordiaux qui méritent d'être résolus grâce à l'observabilité:
En conclusion, le monitoring et l'observabilité vont de pair ; l'un ne remplace pas l'autre, mais ensemble, ils permettent et améliorent les résultats commerciaux définis.
Pour plus d'informations, visite le site de Swisscom Public Cloud Services. Tu peux aussi nous rejoindre en contactant nos experts ici pour t'aider à donner le coup d'envoi de tes solutions sur le cloud.
Ceci est la première partie d'un blog en deux parties, dans le prochain billet nous décrirons comment nous faisons de l'observabilité et de la gestion chez Public Cloud Managed Services pour nos clients dans le cadre de notre offre de services Manager.
DevOps Engineer
Trouve ton travail ou le monde de la carrière qui te convient. Dans lequel tu veux participer à la création et te développer.
Ce que tu en fais, c'est ce qui nous définit.
