Voici ce qu'en disent ceux qui savent.
Comment les outils de monitoring se sont adaptés pour relever le défi des différents changements technologiques, dans les pratiques et les besoins métiers ? Une démonstration d'outils permettant l'observabilité apportera des éléments de réponse.
Cette conférence organisée dans le cadre de l'Alenia Production Tour 2022 a rassemblé de nombreux DSI, leaders du monitoring et experts opérationnels, dont Wilfried Villisek Faucounau, Principal Engineer (devops, ops and SRE Lead) à la Société Générale, Dimitris Finas, Senior Technical Advisor Lightstep et Matthieu Chavaroc, IT and Business Operations Specialist chez Alenia.
Nous avons abordé des sujets tels que l'histoire du monitoring, l'observabilité, les métriques RED, le problème de l'arbre de Noël et le SLO avec les cas d'utilisation de Zalando et bien d'autres choses encore. Nous espérons que vous apprécierez cette conversation.
Matthieu Chavaroc, Alenia - Merci de vous être joints à nous aujourd'hui. Nous apprécions vraiment votre présence. Nous n'aurions pas pu organiser une conférence sur la production applicative sans y inclure le monitoring. Le monitoring est clé pour éviter les incidents et être capable de les détecter et de les résoudre aussi rapidement et efficacement que possible s'ils se produisent.
Pour développer ce sujet, permettez-moi de vous présenter Wilfred Villisek Faucounau. Il est DevOps, Ops et SRE à la Société Générale, et il discutera de l'évolution du monitoring et introduira le concept d'observabilité. Dimitris Finas, senior technical advisor chez Lightstep, présentera ensuite un exemple de mise en œuvre de l'observabilité.
Merci encore une fois de vous être joints à nous aujourd'hui, et nous espérons que vous trouverez cette conférence instructive et utile.
Wilfred Villisek Faucounau, Société Générale - Merci, Matthieu. Je suis très heureux d'être ici pour parler du monitoring. Je vais faire un petit historique du monitoring pour montrer que l'homme le fait depuis la nuit des temps. Nous mesurons le temps, la vitesse, le poids, les distances, etc. depuis longtemps.
Prenons un exemple simple : lorsque vous prenez votre voiture pour un voyage, la première chose que vous faites est de vérifier le niveau de carburant. Différents signaux sur le tableau de bord de la voiture vous indiquent l'état de votre système et si vous pouvez partir ou non. Il s'agit d'une étape permettant de vérifier que tout fonctionne. Il s'agit en fait d'un monitoring très avancé, que j'aimerais bien avoir dans ma propre application. Ensuite, vous avez l'indicateur de vitesse et ainsi de suite. Le monitoring est partout et tout le monde le pratique.
Mais qu'est-ce que cela signifie dans l'IT ? Cela signifie collecter, traiter, agréger et afficher en temps réel des données quantitatives sur un système, telles que le nombre et le type de requêtes, le nombre et le type d'erreurs, les temps de traitement et la durée de vie des serveurs. Telle est la définition tirée du livre du SRE de Google. Mais voyons d'où vient le monitoring dont nous disposons aujourd'hui.
Revenons aux années 80 et 90. À quoi ressemblaient les ordinateurs à cette époque ? Ils étaient en local, dans votre pièce, sur votre bureau. Ils n'étaient pas connectés entre eux et, en général, vous aviez un système très simple avec un seul utilisateur. Il n'y avait pas grand-chose à surveiller à l'époque : vous deviez surveiller votre stockage, votre mémoire, peut-être votre processeur si votre application était trop lente. Mais c'était très simple. Nous avions des outils très simples pour Linux et Windows, juste trois barres laides.
Ensuite, nous avons commencé à connecter tous ces systèmes au sein d'une entreprise. Différentes personnes dans l'entreprise avaient leur système connecté à un réseau. C'est à ce moment-là que nous avons dû commencer à mettre en place un monitoring plus avancé, car si vous utilisiez une application hébergée sur un autre système, comment pouviez-vous savoir si l'application ne fonctionnait pas ? Le problème provenait-il de votre système ou de l'autre système ? Nous devions également surveiller le matériel, les ressources système, etc. C'est alors que nous avons commencé à utiliser des outils tels que nmon, MTRG et Big Brother.
Maintenant que les ordinateurs sont connectés entre eux, quelle est la prochaine étape ? Au 21e siècle, c'est l'ère de l'internet et nous avons commencé à connecter le World Wide Web. Mais ce qui a vraiment changé à cette époque, c'est que l'internet est devenu un véritable lieu de business. De nouveaux protocoles et de nouvelles technologies sont apparus avec cette nouvelle technologie. Les sites web ont commencé à vendre des produits, et si le site web était en panne, c'était comme si votre magasin était fermé. Vous n'aviez pas de rentrées d'argent, les clients ne pouvaient rien faire d'autre que de trouver un concurrent, et vous pouviez faire faillite très rapidement. C'était le premier grand changement.
Avec l'internet, votre application est exposée à l'extérieur, elle tourne sur d'autres serveurs qui ne sont pas dans la même pièce. Comment savez-vous que votre application fonctionne correctement ? C'est très compliqué, et si elle ne fonctionne pas correctement, vous ne faites pas de business. C'est à ce moment-là que le monitoring est passé de quelque chose de très technique à quelque chose de plus orienté vers le business. C'est à ce moment-là que nous avons commencé à vérifier les logs, à faire des health checks, à envoyer des ping externes pour s'assurer que l'application fonctionne, et c'est également à ce moment-là que certaines mesures comme l'utilisation géographique, etc. sont entrées en jeu.
Le 21e siècle a apporté d'autres changements importants : l'arrivée du cloud et de la virtualisation. Nous exploitions certains systèmes et certaines applications, mais nous ne devions plus gérer l'infrastructure. Nous payions quelqu'un pour nous fournir ce service. Nous avions des accords de SLA avec eux, et s'il y avait un problème avec le matériel, ce n'était pas du tout notre problème. C'est pourquoi nous pouvions nous orienter encore plus vers un monitoring orienté applications, plutôt que vers quelque chose de très technique et orienté matériel. Le changement a été encore plus important avec la conteneurisation, où votre conteneur est censé fonctionner sur n'importe quel type d'infrastructure.
L'agilité, l'intégration continue, la livraison continue et le DevOps ont également constitué un très grand changement culturel. Il y a 10 ou 15 ans, les livraisons sur les très grosses applications se faisaient une fois par an, deux fois si nous avions de la chance. Aujourd'hui, nous avons des livraisons tous les mois, toutes les semaines, tous les jours, voire plusieurs fois par jour. Le système que nous devons monitorer est désormais en mouvement constant. Auparavant, si les paquets et l'infrastructure ne bougeaient pas, il n'était pas très compliqué de les surveiller. Nous n'avions pas besoin de systèmes de monitoring très compliqués. Mais maintenant que tout bouge en permanence, ce n'est plus la même chose. Nous avons une complexité accrue, une plus grande quantité de données, et ces applications bougent en permanence. Si un microservice de votre application tombe en panne, ce n'est peut-être pas un problème ; c'est peut-être juste un pépin. Il est donc difficile de comprendre et de savoir ce qui est normal ou non.
"Nous avons désormais un système interconnecté très complexe qui évolue et est mis à jour en permanence. Nous avons également une tolérance quasi nulle pour l'indisponibilité ou la dégradation de service puisque toutes les applications sont fortement interconnectées. Si nous ne fournissons pas le service, nous risquons de ne pas être payés. Enfin, nous avons une quantité extrêmement importante de données à traiter. C'est pourquoi le monitoring évolue vers l'observabilité". W. Villisek Faucounau, Société Générale
Pour résumer, voici les trois grandes étapes du monitoring :
Qu'est-ce que l'observabilité ? Je vais prendre un exemple très simple. Comment pensez-vous que je me sente en ce moment ? Un peu stressé ? Peut-être. Je parle vite, c'est vrai, mais je ne tombe pas et je marche normalement, je peux vérifier mes mains pour voir si je vais bien. Nous faisons la même chose avec les applications. Lorsque vous allez chez un médecin, il ne vous fait pas passer un scanner tout de suite, mais il vérifie vos données externes de base pour établir un diagnostic rapide. Nous faisons la même chose avec les applications en utilisant certains signaux clés de l'extérieur de l'application parce que nous ne pouvons plus entrer dans les détails. Dimitris va vous en faire la démonstration.
Dimitris Finas, LightStep - La première chose à savoir sur l'observabilité est qu'il s'agit d'un changement dans ce que vous mesurez. Lorsque vous faites de l'observabilité, vous regardez des signaux externes, et ce faisant, vous changez les signaux que vous surveillez, ce qui signifie qu'ils sont moins liés à l'infrastructure et plus liés à l'application et à l'expérience du client.
En règle générale, vous avez besoin de plus que les indicateurs USE : mesure de l'Utilisation, de la Saturation et du taux d'Erreur. Qu'est-ce que cela signifie ? Cela signifie que vous mesurez l'utilisation de votre CPU ; vous mesurez la saturation de votre disque ou la saturation de votre mémoire. Il s'agit de mesures d'utilisation typiques. Lorsque vous passez à l'observabilité, vous utilisez des mesures RED en plus des mesures USE. Vous mesurez toujours la saturation de votre infrastructure, mais vous y ajoutez le taux (Rate), l'Erreur et la Durée (c'est-à-dire la latence). Pourquoi ? Parce que le client perçoit deux choses. Il perçoit la latence. L'application est-elle lente à réagir ou réactive ? Et il perçoit le taux d'erreur. Est-ce que je vois une page d'erreur ? Ce sont les deux perceptions les plus importantes pour l'expérience de l'utilisateur. C'est pourquoi, lorsque Google a rédigé son livre blanc sur le SRE, il a défini les mesures RED comme des signaux d'or (golden signals) à utiliser comme méthode préférentielle.
"Rappelez-vous qu'il existe trois éléments importants que vous pouvez utiliser comme outil d'observabilité, à savoir les traces, les métriques et les logs. Nous les appelons les trois piliers de l'observabilité." D. Finas, Lightstep
Je pense que tout le monde connaît les métriques et les logs, alors je vais donner quelques détails sur les traces : c'est la façon de surveiller une transaction unique qui passe par tous vos services, de haut en bas, c'est donc une vue de bout en bout de votre transaction. Il y a une révolution avec l'observabilité, et cette révolution a un nom. Ce nom est OpenTelemetry.
Qu'est-ce que OpenTelemetry ? C'est un projet open-source que vous utilisez pour collecter, avec une technologie unique, toutes vos traces, métriques et logs. Le point important d'OpenTelemetry est qu'il doit être fiable, performant et indépendant des fournisseurs de logiciel. Et c'est pour cela qu'il est open source. Ce projet a été créé par mon entreprise, Lightstep, et Google. Il est aujourd'hui utilisé par Google pour toutes ses plateformes cloud, par AWS pour tous ses contrôles CloudWatch et par Microsoft pour Azure, ce qui signifie que tous les principaux fournisseurs de cloud public utilisent cette technologie open-source pour fournir leurs mesures à leurs clients. Cela s'explique notamment par le fait qu'elle ne dépend pas des fournisseurs et qu'elle est performante.
D'ailleurs, pour vous montrer l'importance de ce projet, il est le deuxième projet le plus actif de la CNCF. La CNCF est la Cloud Native Computing Foundation qui héberge tous les projets open-source liés aux composants critiques de l'infrastructure technologique mondiale. Le projet le plus important pour la CNCF est Kubernetes, suivi par OpenTelemetry.
Regardez Kubernetes d'il y a cinq ans et comparez-le à aujourd'hui : toutes les plateformes de microservices fonctionnent désormais sur Kubernetes. Je dirais qu'il en sera de même pour OpenTelemetry. Nous pouvons déjà voir qu'il est utilisé par tous les fournisseurs de cloud public. Même les outils de monitoring tels que Splunk, Dynatrace et Datadog contribuent désormais à ce projet parce qu'ils y voient un grand changement pour l'avenir, en particulier pour être agnostique vis-à-vis des fournisseurs.
Pour simplifier, OpenTelemetry peut être considéré comme l'agent unique qui les gouverne tous. Initialement, l'objectif était de tout collecter d'une seule manière afin que les utilisateurs puissent posséder leurs données et ne pas dépendre de solutions de monitoring propriétaires.
En termes d'architecture, cela signifie que lorsque vous collectez des données sur votre application ou autour de votre infrastructure, vous utilisez des agents OpenTelemetry. Cela fonctionne pour les applications modernes utilisant Kubernetes, mais aussi avec les machines virtuelles, les vCenters et d'autres technologies. À un moment donné, vous mettez toutes ces données sur un proxy qui est le collecteur, puis vous pouvez les envoyer à n'importe quel fournisseur, cela peut être Lightstep, Prometheus, Splunk, Honeycomb ou tout autre fournisseur compatible avec OpenTelemetry.
Cela signifie que si vous devez passer d'un fournisseur à un autre ou ajouter un nouveau fournisseur parce que vous voulez envoyer vos traces à lightstep et vos métriques à Prometheus, vous pouvez le faire avec seulement trois lignes d'un fichier YAML qui changera la configuration et enverra les données à la nouvelle cible. Vous n'avez pas besoin de changer quoi que ce soit d'autre ; vous n'avez pas besoin d'ajouter de nouveaux agents à votre infrastructure, vous n'avez qu'à définir une nouvelle cible dans votre collecteur proxy. C'est pourquoi tant de fournisseurs et d'utilisateurs l'utilisent déjà.
Pour vous donner un exemple, Zalando a choisi OpenTelemetry et Lightstep il y a trois ans au début du projet Ils l'ont utilisé pour 3 raisons principales :
Cette présentation est basée sur le témoignage de Heinrich Hartmann, qui est Head of SRE chez Zalando et nous a permis de partager ce contenu avec vous.
Zoomons sur l'architecture de Zalando. Zalando est une entreprise purement digital native qui vend des chaussures, des vêtements et de la mode, avec 5 000 microservices connectés les uns aux autres. Vous pouvez dire que vous n'êtes pas une entreprise digital native, mais si vous voulez faire une partie de ce qu'ils font, c'est possible. J'étais récemment dans une banque historique en Écosse, et ils m'ont dit que 95 % de leur informatique est "legacy", et qu'ils s'appuient principalement sur du "mainframe" pour leurs opérations les plus critiques. Les 5 % restants sont des microservices qui représentent plus de 3 000 conteneurs fonctionnant en production. Pensez-vous qu'il soit possible de surveiller 3 000 conteneurs et une application mobile critique sans les mêmes outils que Zalando ? C'est pourquoi, même s'ils ne sont pas des "digital natives", ils étaient vraiment intéressés par l'acquisition de cette capacité.
Lorsque Zalando a démarré, elle a acquis une capacité qui lui manquait, à savoir la traçabilité distribuée. Chaque fois qu'une transaction a lieu, elle souhaite retracer le parcours du client depuis le site web jusqu'aux API qui sont appelées au-delà de ce site. Pourquoi ? Pour contrôler l'expérience du client et les performances de leurs services. Cet objectif est généralement atteint grâce à des traces distribuées. Pourquoi est-ce intéressant ? C'est simple : avec les traces distribuées, vous pouvez rapidement identifier les erreurs et la latence. Il suffit de regarder la ligne rouge ou la ligne la plus longue pour trouver rapidement où se situe le problème.
Zalando a mis en place des traces distribuées au cours de sa première année d'utilisation du produit. Ensuite, ils ont mis en œuvre les mesures RED, qui indiquent le taux d'erreur, la latence (temps de réponse perçu par le client sur le front-end) et le débit, c'est-à-dire l'utilisation de l'application au fil du temps. En cas de pic d'erreur, il est possible de cliquer sur le point rouge représentant la transaction en erreur, d'afficher la trace et d'afficher la ligne rouge représentant l'endroit où se situe le problème.
Au-delà de ce tableau de bord, vous pouvez avoir un service ou une application, mais vous pouvez aussi avoir plusieurs applications ou plusieurs services.
Développons maintenant la manière dont Zalando a défini ses SLO. Au départ, Zalando avait 200 équipes de produits et définissait donc des SLO pour chaque produit, mais cela générait trop d'erreurs et était trop éloigné de l'activité de l'entreprise. La société a donc changé d'approche et mis en place ce que l'on appelle un "SLO pour les opérations métier critiques".
Qu'est-ce qu'une opération métier critique ? Il s'agit par exemple de "parcourir le catalogue", "voir les détails du produit", "ajouter à la liste de souhaits" et "payer". Ces opérations sont très visibles du point de vue du client, sont essentielles à l'activité de l'entreprise et sont limitées à un petit nombre.
"Zalando ne dispose que de 11 opérations métier critiques pour monitorer l'ensemble de l'entreprise. Pour chacune de ces opérations critiques, il y a un vice-président de Zalando qui est le propriétaire du SLO." D. Finas, Lightstep
Aussi simple et complexe que cela puisse paraître, pour définir le Business SLO, il suffit de regarder ce que le client recherche.
Aujourd'hui, Zalando met en œuvre la fonctionnalité la plus récente, baptisée adaptive paging.
Adaptive paging est une solution au "problème de l'arbre de Noël". Chaque fois qu'une alerte se produit, elle peut déclencher une cascade d'autres alertes à travers plusieurs services de la chaîne. Cela peut conduire à déclencher des centaines d'appels de conférence de crise et à passer beaucoup de temps à enquêter sur chaque service d'une chaîne.
Par exemple, le service de "réservation de stock" provoque une exception, ce qui est critique pour les SLO métier de l'entreprise car il est utilisé pour "passer des commandes". Le problème est que cette exception entraînera une exception sur le service "logistique", qui générera une exception sur le service "commande", ce qui aura un impact sur le service "caisse". Si vous appelez toutes les équipes pour ces différents services, vous aurez 100 personnes à bord, ce que personne ne souhaite.
Il y a quelques semaines, une banque écossaise a connu un problème similaire : elle a été alertée sur Twitter parce que son application de téléphonie mobile ne fonctionnait pas. Pour ce type d'incident, ils avaient jusqu'à 200 personnes mobilisées (ce sont de vrais chiffres). En fin de compte, ils ont découvert que c'était un service d'identité situé bien plus bas dans la chaîne qui était la source de ce problème.
Zalando a eu ce genre de problème parce qu'ils ont 200 équipes produit, et qu'il n'y a pas une seule équipe responsable de toute cette chaîne. Qu'ont-ils fait ? Ils ont extrait des exemples de traces liées à cette alerte.
La ligne rouge affichée est en fait un fichier JSON qui est analysé, et vous obtenez un attribut spécifique qui vous indique que l'erreur se trouve ici. C'est ainsi que Lightstep l'affiche en rouge. Ils vérifient donc cet attribut et savent exactement quel service correspond à la ligne la plus basse, au niveau le plus bas (la cause racine), et envoient l'alerte à cette équipe. Pour plus de 90 % de leurs cas d'utilisation, cela fonctionne très bien, et toutes les équipes apprécient vraiment cette fonctionnalité, simplement parce qu'il y a moins de personnes en alerte, et que c'est plus efficace.
Pour conclure, je voudrais dire que ce n'est pas de la magie et que ça ne prend pas une semaine. Le parcours que je vous ai montré pour Zalando leur a pris trois ans. Ils ont commencé simplement avec la traçabilité, puis avec les métriques, avant de passer à l'"adaptive paging" et aux SLO métier. Comme vous pouvez le constater, même pour les "digital natives", cela prend du temps. Il s'agissait également d'un changement culturel pour leurs ressources qui avaient l'habitude d'utiliser simplement des logs.
Deux derniers commentaires :
"Les meilleurs SLO sont probablement ceux qui sont visibles par vos clients" D. Finas, Lightsept
MA - Merci Dimitris ! Chez Alenia, nous sommes agnostiques quant à la solution technique à utiliser pour le monitoring. L'important ici est de comprendre la valeur de l'observabilité pour les systèmes complexes et en particulier pour les chaînes complexes. Que vous utilisiez Dynatrace, Lightstep ou Splunk, il est important d'obtenir cette visibilité et, comme Wilfried l'a dit, d'"observer " votre système et de baser vos conclusions sur les outputs de vos systèmes.
WVF - Il est également important d'impliquer l'équipe de développement lors de l'implémentation d'outils d'observabilité dans votre application. Si vous n'impliquez pas les développeurs dans le processus de production, vous ne parviendrez jamais à obtenir ce type de résultats. Et cela prend du temps. Dans mon application à la Société Générale, nous utilisons la stack Elastic. Nous avons ce type d'observabilité. Lorsque nous avons un problème, nous en avons la trace et nous savons directement d'où vient le problème. Mais il nous a fallu trois ou quatre ans pour que cela fonctionne, avec une forte implication des développeurs.
MA - Nous allons maintenant répondre aux questions. "Quelles seraient les premières étapes de l'observabilité ?
DF - Tout d'abord, il faut impliquer le métier. Essayez de simplifier les choses. N'ayez pas trop de SLO. Essayez plutôt de sélectionner le SLO le plus simple, même s'il existe plus de 50 services différents pour chaque SLO. Ce n'est pas un problème car, techniquement, nous sommes en mesure de résoudre ce problème ultérieurement
WVF - Vous devez expliquer au métier qu'il est essentiel d'investir dans ce type de processus. Dans mon travail, j'ai fait beaucoup de présentations au métier pour expliquer l'importance du monitoring dans le DevOps, et d'investir dans ces processus, même si l'application fonctionnait. C'est ainsi que l'on passe du monitoring technique au monitoring métier. Vous devez vraiment coopérer et travailler avec votre métier aussi étroitement que possible pour démystifier beaucoup de choses et vulgariser le sujet...
DF - ... et changer les métriques aussi, comme nous l'avons dit, en passant à RED pour mesurer le taux, l'erreur et la durée.
MA - C'est l'heure d'une nouvelle question : "qu'est-ce que l'observabilité ?"
DF - Je dirais que l'observabilité, c'est simplement le monitoring plus plus. Et d'ailleurs, cela vous donnera aussi la différence entre les traces et les métriques dans le monitoring. Les métriques sont typiques du monitoring; vous surveillez l'état. Vous voulez connaître l'état de votre système, est-il rouge ou vert ?
"Avec l'observabilité, vous avez tout ce que vous faites avec le monitoring, mais en plus, vous voulez comprendre ce qui se passe et quelle est la cause racine du problème ou quel est le comportement de votre application." D. Finas, Lightstep
C'est pourquoi, pour l'observabilité, vous devez également ajouter des traces (ou des logs, car la trace à la fin n'est qu'une structure de logs et c'est la même chose. C'est un fichier avec des horodatages, un contexte et tout le reste). C'est juste plus efficient.
Je vois une nouvelle question : "Qu'est-ce que Prometheus ?". C'est un outil qui permet d'afficher et de stocker des métriques dans la base de données. C'est un outil open-source qui est utilisé par presque tous les clients qui se lancent dans le monitoring de Kubernetes. C'est donc aussi un outil puissant et probablement l'un des projets les plus connus en open source.
MA - Question : "qui devrait mener l'effort de transformation ?"
DF - Je peux dire que pour les projets Lightstep, la plupart du temps, ce sont les Ops qui dirigent. Les premières personnes que nous rencontrons sont les SRE, mais les plus grands utilisateurs de la solution sont les développeurs. Cela peut sembler étrange, mais c'est en fait dû à la proportion de personnes. Dans de nombreuses entreprises, il y a probablement un SRE pour 10 développeurs, et ce que nous voyons chez Zalando, c'est qu'ils ont une équipe de SRE qui sont les propriétaires de cette solution, et ils ont plusieurs centaines de développeurs qui se connectent à l'application tous les jours.
MA - Voici une question à laquelle j'aimerais répondre : "Quels seraient les trois facteurs de succès à prendre en compte lors du passage du monitoring à l'observabilité ? Le premier facteur de succès est d'être plus efficace dans la détection et la résolution des incidents.
"En reprenant l'exemple de l'arbre de Noël que vous avez présenté, la mise en œuvre de l'observabilité vous permettrait de vous attaquer directement à la cause racine du problème au lieu d'impliquer 200 personnes dans le même incident." M. Chavaroc, Alenia
Cette fonction est particulièrement puissante lorsque vous avez une configuration de type "follow-the-sun" ou une astreinte en heure non ouvrée. Avec le monitoring "traditionnel", vous pouvez être appelé au milieu de la nuit pour un système de fichiers qui se remplit sur une machine qui n'est même plus utilisée.
"Lorsque vous mettez en œuvre l'observabilité, vous êtes appelé sur la base d'une violation du SLO. Ainsi, lorsqu'une alerte apparaît, cela signifie qu'il y a un réel impact direct sur le métier ou le client." M. Chavaroc, Alenia
Vous n'allez pas vous faire réveiller pour quelque chose d'inutile. Et c'est important, surtout pour les personnes qui travaillent dans la production.
DF - L'implication des développeurs est également cruciale, car sans eux, vous ne pouvez pas réussir dans ce domaine. Il faut donc les impliquer dans le processus. Au début, ils ne seront peut-être pas satisfaits parce qu'ils considèrent qu'il s'agit d'un sujet de production, mais une fois qu'ils l'auront utilisé, vous pourrez organiser un simple atelier en utilisant un scénario de "wargame" dans lequel vous simulerez des incidents et les laisserez les résoudre avec ou sans observabilité. Ils verront la différence et l'apprécieront.
Un autre facteur à prendre en compte est de commencer par les services et les applications les plus critiques de l'entreprise. Il ne s'agit pas d'un projet pour les applications moins critiques. Par exemple, Zalando a 5 000 microservices, dont seulement 3 000 sont connectés à la trace distribuée parce que les autres ne sont pas critiques pour leur activité. Il n'est pas nécessaire de voir la trace distribuée de tout.
WVF - Une chose que notre équipe est en train de faire, c'est de servir tous les environnements de non-production avec le même monitoring que la production. Nous considérons que les environnements de non-production sont presque aussi critiques que les environnements de production. Par exemple, si j'ai une correction de bug à livrer et que mon UAT ne fonctionne pas, je ne peux pas tester ma correction, ce qui aura un impact sur ma production. Dans notre équipe, nous avons exactement la même stack de monitoring dans chaque environnement, et je pense que c'est très important. Toutes les améliorations du monitoring passent par l'homologation et l'UAT avant d'être livrées en production. Pour moi, c'est donc une clé de la réussite que de considérer le monitoring comme aussi important que n'importe quel autre composant de votre système.
Question de l'auditoire : "Est-il possible d'implémenter OpenTelemetry sur des applications mainframe ? "
DF - Techniquement, c'est possible. L'un de nos clients l'a fait. Mais la plupart des clients ne le font pas parce qu'ils n'y sont pas obligés. L'instrumentation des couches legacy demande beaucoup d'efforts. Dans ce cas, Open Telemetry offre une notion appelée "service inféré". Il s'agit d'un service que l'on devine à partir du client qui s'y connecte. Par exemple, lorsque vous avez une transaction mainframe sur votre chaîne basée sur le SLO, vous la verrez comme un service inféré. Si le service inféré crée une erreur, vous la verrez de toute façon, ce qui signifie que vous aurez le taux d'erreur du service (code de retour), la latence du service (temps de réponse) et le nombre de transactions pour le service (chaque fois que le service est appelé).
La plupart du temps, nous n'installons pas d'agent sur ce type de technologie, et il en va de même pour les API externes que vous ne contrôlez pas, comme une API SWIFT ou une API de paiement externe. Vous connaissez le SLA de l'API, vous savez si elle renvoie une erreur, et c'est suffisant pour faire partie de votre plateforme d'observabilité.
MA - Merci beaucoup à vous tous. Si vous souhaitez approfondir ces sujets, vous pouvez nous contacter ici, nous serons heureux de poursuivre cette conversation.
