Au fur et à mesure que les outils et les pratiques de l'informatique cloud arrivent à maturité, il devient de plus en plus nécessaire de les intégrer dans les environnements de gestion et de surveillance existants. Cela signifie qu'il faut intégrer les outils cloud native, comme Prometheus - le second projet open source intégré à la CNCF après Kubernetes - ou le plus récent OpenTelemetry, aux règles de surveillance et aux tableaux de bord déjà en vigueur dans l'entreprise. Rappelons que Prometheus est un outil d'observabilité ( collecte, stockage et requête) qui utilise un modèle métrique conçu pour répondre à ses propres besoins, alors qu'OpenTelemetry traduit de nombreux modèles de données différents en un seul cadre (collecte sans stockage ni requête). Ces différences fondamentales reflètent la complexité des systèmes - Prometheus est un modèle simple qui est souvent exposé dans le texte, tandis qu'OpenTelemetry est une série plus complexe de trois modèles qui utilise un format binaire pour la transmission. S'appuyer sur ces outils existants est la clé de l'adoption, car les équipes dev/cloud-ops ont déjà construit des workloads autour d'interfaces familières. La mise en place de la surveillance et de la gestion est une priorité, car le temps passé à construire de nouvelles interfaces et intégrations est du temps qui pourrait être mieux utilisé pour maintenir les applications et les services en fonctionnement. 

Il y a aussi un autre défi à relever, car le cloud nécessite une nouvelle couche IT comprenant les dernières plateformes hébergeant les applications cloud de l'entreprise. Celles-ci posent toutefois leurs propres problèmes de gestion et de surveillance, car il faut suivre l'utilisation des ressources et l'upscaling, en veillant à ce que les nœuds applicatifs supplémentaires fonctionnent correctement. Bien que ces outils, en particulier Kubernetes, soient accompagnés de leurs propres services de surveillance, il est essentiel qu'ils soient intégrés à l'infrastructure existante et à la surveillance des applications. Heureusement, l'adoption de Prometheus avec le stockage de séries temporelles répond à ce besoin de collecter et analyser les données et les journaux d'événements.

Zoom sur Azure Monitor pour Prometheus

Lors de son événement Build du mois dernier, Microsoft annoncé la disponibilité générale de librairies de séries temporelles Prometheus dans Azure Monitor. Dévoilé à l'origine à l'automne 2022, ce service managé apporte Prometheus à Azure Monitor et Managed Grafana, donnant accès à des outils de visualisation open source familiers ainsi qu'aux propres outils de surveillance des conteneurs de Microsoft. L'intégration de Prometheus à Azure Monitor est une évidence. Bien que Microsoft dispose de sa « propre » distribution Kubernetes (AKS), il s'agit d'une implémentation gérée de la plateforme open source, qui dispose donc de toutes les mêmes API et de la prise en charge de tous les outils K8's standard. Il a toujours été possible d'exécuter ses propres instances Prometheus dans Azure : une approche qui fonctionne bien pour les systèmes relativement petits, sans nécessité de passer à la mise à l'échelle de quoi que ce soit d'autre que l'application en tant que tel. Mais les choses se compliquent avec les déploiements AKS à plus grande échelle, où les entreprises doivent les appliquer à leur stockage en devant faire face à des contraintes de haute disponibilité.

L'exécution de Kubernetes au sein d'un secteur réglementé pose d'autres problèmes, car les entreprises devront tenir compte de la manière dont les exigences en matière de conservation des données affectent leur environnement Prometheus. Le passage à un service Prometheus managé simplifie la situation, car Microsoft fournit des outils automatisant une grande partie du processus de mise à l'échelle et de sécurisation des données, et s'assure de sa mise à jour et qu'il fonctionne avec les derniers correctifs. Les entreprises n'ont donc pas besoin de prendre en compte le workload associé à la gestion de Prometheus : il suffit d'écrire, de lire et d'analyser les données qui y sont stockées. Aucune limitation d'usage d'Azure Monitor pour Prometheus s'applique, tous les outils et scripts PromQL existants pouvant être utilisés avec Azure garantissant que toutes les règles élaborées autour des données Prometheus continueront à fonctionner. Au niveau code, la version managée de Prometheus d'Azure ressemble à n'importe quel autre endpoint Prometheus, avec la même prise en charge de l'ingestion de données et des requêtes. Cette approche permet ainsi de migrer d'autres environnements Kubernetes vers Azure en garantissant que les mesures considérées par l'entreprise comme importantes restent accessibles.

Prometheus monté à l'échelle dans Azure

Comme Prometheus géré par Azure repose sur son stockage, il peut être utilisé pour des applications sur site. Cela permet d'utiliser Monitor et Grafana comme un moyen unifié pour surveiller les clusters Kubernetes sur site et hébergés dans le cloud, tout en continuant à prendre en charge le code PromQL existant. Comme Managed Prometheus est conçu pour prendre en charge plusieurs clusters, Microsoft note que l'usage courant est une instance séparée par région Azure. Les requêtes fonctionnent entre les régions, ce qui rend possible la création de tableaux de bord personnalisés dans Grafana ou dans Azure Monitor. La firme de Redmond a conçu son service Prometheus pour qu'il soit évolutif et résilient, avec un mode haute disponibilité exécutant des collecteurs sur chaque nœud de l'infrastructure Kubernetes. Parallèlement, à l'instar d'autres services gérés par Azure, les données sont stockées dans une zone choisie et répliquées dans une autre. Ainsi, l'environnement Prometheus localisé à l'ouest des États-Unis sera disponible à l'Est du pays. Une façon de garantir que même en cas d'incident majeur sur un datacenter ou en cas de panne de son datacenter, les métriques seront stockées sur cette dernière.

Premiers pas dans avec Prometheus dans AKS

Il est assez facile d'activer le service Prometheus pour l'utiliser avec AKS. Pour cela il faut commencer par créer un espace de travail Monitor pour stocker ses mesures. Ensuite connecter ses instances Kubernetes à Prometheus, soit directement, soit par l'intermédiaire de Container Insights. Une fois qu'un espace de travail est créé il peut être connecté à Azure Managed Grafana pour mettre en place des tableaux de bord et des visualisations. Azure Monitor hébergera les règles et les alertes, qui sont écrites en PromQL et utilisées pour déclencher des actions ou envoyer des notifications. Managed Prometheus est une source d'événements prise en charge pour KEDA (Kubernetes Event-driven Autoscaling), de sorte que des règles pour gérer la mise à l'échelle en dehors du modèle de base de Kubernetes axé sur les ressources pourront être utilisées. La configuration d'un cluster AKS pour utiliser le service est relativement simple, et les options de livraison directe et Container Insights installent toutes deux une version conteneurisée de l'agent Azure Monitor, qui recueille les mesures  d'un cluster et de tous les nœuds en cours d'exécution. Ce dernier est soumis à une limitation : Il doit utiliser l'authentification d'identité managée en place. Une bonne pratique à suivre si l'entreprise compte utiliser AKS avec d'autres services Azure.

Microsoft a automatisé une grande partie du processus de configuration de l'agent de surveillance pour les conteneurs Linux - Azure Monitor le configurera et le déploiera si nécessaire. Si l'entreprise recourt à des conteneurs Windows avec AKS, il faudra pour le moment configurer manuellement une grande partie du service de surveillance, y compris l'exécution de YAML et de configmaps fournis par Microsoft. Une fois l'agent déployé, kubectl pourra vérifier qu'il fonctionne sur des pools de nœuds. Les paramètres par défaut pour la collecte de métriques devraient suffire pour la plupart des applications. L'éditeur fournit une longue liste de métriques et de cibles disponibles, ainsi que des tableaux de bord fournis automatiquement dans Grafana (pour lequel le code source est disponible sur GitHub). Il sera ensuite possible d'ajouter ses propres tableaux de bord et règles pour gérer vos applications cloud native comme on l'entend.

Une tarification raisonnable

De manière utile, la version managée de Prometheus peut même fonctionner en tant qu'endpoint pour le dernier support OpenCost d'Azure. Il est également disponible dans le cadre de l'outil Container Insights existant, et peut donc être rapidement ajouté aux clusters surveillés en tant que nouvelle source pour Azure Managed Grafana. De cette façon, le compte de l'entreprise sera automatiquement approvisionné avec un ensemble d'exemples de tableaux de bord pour commencer et peuvent être utilisés comme base de départ. Les prix sont raisonnables, l'ingestion commençant à 0,16 $ pour 10 millions d'échantillons et les requêtes à 0,001 $ pour 10 millions d'échantillons traités. Il n'y a pas de frais de stockage supplémentaires et les données sont conservées pendant 18 mois.

En plus de fonctionner avec AKS et les instances Kubernetes hébergées des entreprises, Prometheus fonctionne avec Azure Arc-hosted Kubernetes, fournissant un support aux déploiements cloud et edge. Le rôle de Kubernetes dans ce dernier cas devenant de plus en plus important, la prise en charge d'Arc est une option intéressante pour exécuter K8's sur des serveurs internes. De nombreux points sont appréciables dans ces annonces de Microsoft qui continue de jouer ses atouts tout en restant proche des racines open source de l'écosystème Kubernetes. Le résultat débouche sur un outil qui reste familier mais fonctionnant d'une telle manière pour se concentrer sur les résultats visés et non sur la gestion d'une plateforme de métriques. Et au final, tout le monde pourrait bien y gagner.