Ceci est le cinquième article de la série couvrant mon voyage dans le monde de l’observabilité native du cloud. Si vous avez manqué l’un des articles précédents, revenez à l’introduction pour une mise à jour rapide.
Après avoir posé les bases de cette série dans l’article initial, j’ai passé un peu de temps dans le deuxième article à partager qui sont les acteurs de l’observabilité. J’ai également discuté des équipes dans lesquelles ces joueurs se trouvent dans ce monde d’o11y natif du cloud. Pour le troisième article, j’ai regardé la discussion en cours autour de la surveillance piliers contre étapes. Dans le quatrième article, j’ai parlé de garder vos options ouvertes avec les normes open source.
En tant que développeur depuis mes débuts dans l’informatique, il a été très intéressant d’explorer les complexités d’o11y cloud-native. La surveillance des applications va bien au-delà de la simple écriture et du déploiement de code, en particulier dans le monde natif du cloud. Une chose demeure la même : la maintenance de l’architecture de votre organisation nécessite toujours à la fois une vision vigilante et une compréhension des standards ouverts disponibles.
Dans ce cinquième article, je vais examiner les choix architecturaux que vous pourriez rencontrer lorsque les anciennes applications monolithiques et les outils de surveillance font toujours partie du paysage de l’infrastructure d’une organisation.
Après avoir couvert les vertus des normes ouvertes et des normes moins officielles couramment adoptées dans le monde de l’open source, il est maintenant temps de voir comment ce même effet a été appliqué à la surveillance des applications et des services plus anciens.
Pas tous natifs du cloud
Toutes les architectures cloud ne peuvent prétendre exécuter uniquement des charges de travail cloud natives ou Kubernetes. Beaucoup ont encore des composants, des services ou des applications plus anciens qui s’exécutent comme des monolithes. Ces monolithes ne sont pas divisés en microservices, ne s’adaptent pas automatiquement dans un monde de conteneurs et peuvent même ne pas fonctionner du tout dans un conteneur.
Cela ne vous empêche pas de les surveiller d’une manière ou d’une autre, comme vous le feriez pour vos charges de travail natives du cloud. Dans le passé, cela pouvait être fait à l’aide de l’un des outils de gestion des performances des applications (APM), mais cela nécessitait souvent plusieurs outils.
Il y a tellement d’options utilisées au fil des ans, et contrairement à la croyance populaire, toutes les architectures n’ont pas cessé de surveiller leurs monolithes. Nous découvrirons toujours les coins sombres de l’infrastructure vieillissante qui utilise des outils que nous pensions ne jamais revoir à la lumière du jour.
Explorons quelques-unes des options que vous êtes plus susceptibles de rencontrer comme exemples de la façon dont nous pouvons initialement fusionner ces efforts vieillissants dans notre plate-forme d’observabilité native du cloud.
Certaines options (de vieillissement)
Bien que vous puissiez trouver presque tout sous le soleil encore en cours d’exécution dans les coins les plus anciens de certaines architectures d’infrastructure, il sera difficile de tous les couvrir. Dans la section suivante, par exemple, je ne parlerai pas de Nagios. Il peut être intégré de la même manière que les options que je vais couvrir ci-dessous et je choisis de me concentrer sur des exemples que vous êtes plus susceptible de rencontrer en premier.
Maintenant que nous avons réglé cela, explorons certaines des solutions que vous rencontrerez pour surveiller des solutions et des infrastructures monolithiques plus traditionnelles : Graphite, StatsDet collecté.
Graphite
Il s’agit d’un projet open source publié pour la première fois en 2008 qui fournissait un système de surveillance des métriques de séries chronologiques. Il était innovant en ce sens qu’il offrait une approche originale basée sur le réseau pour ingérer et gérer les données de métriques de systèmes externes sans utiliser le protocole SNMP.
L’architecture de base pousse les métriques des cibles de surveillance à l’aide d’un client. Ce client doit comprendre que le serveur central collectant les métriques n’est pas toujours en mesure de recevoir et d’ingérer les données envoyées. Le serveur ingère et stocke les données de séries chronologiques vous permettant de les interroger pour créer vos tableaux de bord de surveillance. Les métriques sont transmises au serveur Graphite en texte brut ou sous la forme d’un ensemble binaire de métriques utilisant son propre protocole. Pour un aperçu plus approfondi de la plate-forme Graphite, vous trouverez ici un aperçu de l’architecture et des concepts.
Si vous rencontrez cette plate-forme, il existe des options disponibles dans le projet open source Prometheus, où vous pouvez tirer parti de l’exportateur Graphite. Cela vous donne la possibilité d’intégrer vos applications monolithiques existantes et vos métriques d’infrastructure dans vos efforts cloud-native o11y sans effort de migration immédiat.
StatsD
À une certaine époque, StatsD était la solution de surveillance la plus populaire pour instrumenter le code et ainsi exposer les métriques d’application personnalisées. Il est open source et vous permet d’exposer l’intérieur de vos applications monolithiques et est très étroitement lié aux concepts d’Application Performance Monitoring (APM).
Les développeurs instrumentent leur code à l’aide de bibliothèques clientes pour le langage qu’ils utilisent. Il existe un démon central StatsD en cours d’exécution qui extrait les métriques, génère des métriques agrégées et les relaie vers un backend de surveillance ou de création de graphiques (un favori étant Graphite). Il utilise un protocole de communication Fire-and-Forget connu sous le nom d’UDP, ce qui signifie une faible surcharge de communication. Il était très avantageux d’avoir le démon de métriques détaché de l’application et donc de ne jamais planter ou d’affecter les performances de l’application.
StatsD propose également des options disponibles à partir du projet open source Prometheus lorsque vous cherchez à intégrer cette infrastructure monolithique existante dans vos efforts cloud-native o11y. L’intégration initiale à l’aide de l’exportateur StatsD de l’écosystème Prometheus évite la nécessité d’un effort de migration immédiat.
collecté
Il s’agit d’une autre solution de collecte de données de métriques avec une architecture de plugin de plus de 100 options. Certains plugins collectd courants sont le processeur, la mémoire, l’utilisation du disque, l’agrégation, le trafic réseau, NGnix, MySQL, etc. en tant qu’appareils embarqués. Il doit être installé sur chaque machine qu’il surveille car il utilise un mécanisme push pour envoyer ses métriques à un système backend tel que Graphite.
L’intégration de collectd dans vos plans de modernisation peut également, vous l’aurez deviné, être réalisée à l’aide de l’exportateur collectd. Cela vous donne à nouveau le temps de tirer parti de l’infrastructure monolithique existante dans votre stratégie o11y native du cloud, en gagnant du temps pour planifier l’éventuelle voie de migration encore nécessaire.
Ouvrir la voie vers le cloud natif
Quel est exactement le point commun entre les trois exemples évoqués ci-dessus lorsque nous cherchons à intégrer des plates-formes et des outils d’infrastructure de surveillance vieillissants dans notre stratégie o11y native du cloud ? Ils ont tous la possibilité d’être d’abord intégrés à l’aide de solutions de surveillance open source pour les environnements natifs du cloud.
Heureusement pour nous, il existe de nombreuses options pour s’assurer que vous pouvez atténuer ces anciennes dépendances sans les déchirer et les remplacer. Le monde open source nous donne la possibilité d’ingérer des plates-formes de métriques, des API et d’autres composants plus anciens à l’aide d’un vaste écosystème d’exportateurs. Cela vous donne le temps d’amener vos monolithes dans le monde natif du cloud.
Ensuite, je prévois de commencer à explorer un nouveau projet appelé Perses. Il s’agit d’un projet de tableau de bord de métriques open-source prometteur et c’est là que je commencerai à acquérir une expérience pratique dans mon parcours cloud native o11y.