Technique

L'importance des métadonnées pour l'observabilité de vos déploiements Kubernetes

Cet article a été publié à l'origine sur le site tfir.io.

Kubernetes est un système populaire d'orchestration des conteneurs constituant le cœur des projets de la Cloud Native Computing Foundation. Il automatise le déploiement, le cycle de vie et le fonctionnement des conteneurs, des applications conteneurisées et des pods, c'est-à-dire des groupes comprenant un conteneur ou plusieurs. Tout comme chacune de ces charges de travail, la plateforme peut générer des données d'événement. Différents types de données sont associés à ces procédures. Par exemple, les logs vont de simples messages de débogage jusqu'à des logs d'accès au serveur web détaillés qui fournissent des informations sur les transactions. Les indicateurs, également nommés données temporelles, sont des valeurs numériques mesurées régulièrement. Il peut s'agir notamment du nombre d'opérations instantanées par seconde, du taux d'accès au cache, du nombre de clients consultant votre site ou encore d'informations basiques comme la part du processeur ou de la mémoire utilisée par un conteneur au cours des cinq dernières secondes.

Grâce à l'observabilité, ces logs et indicateurs sont interrogeables, enregistrés habituellement dans un datastore en corrélation et souvent associés à des données de trace d'application. Ces dernières, appelées aussi informations sur le monitoring des performances applicatives, indiquent le temps de fonctionnement des applications ou des services, les systèmes avec lesquels ils interagissent, leur mode d'interaction et toute erreur éventuelle. Les logs et les indicateurs fournissent une vue détaillée d'une application, tandis que les informations sur le monitoring des performances applicatives reflètent le fonctionnement des applications.  

Ensemble, les données de trace d'application, les indicateurs et les logs peuvent diminuer le temps moyen de détection et de résolution des erreurs ou des incidents. Cependant, au fur et à mesure de l'évolution des modèles de déploiement des applications (à l'instar des déploiements Kubernetes), il devient très important de comprendre où surviennent les événements dans un environnement dynamique. C'est là que les métadonnées entrent en jeu.

En quoi consistent les métadonnées ?

Selon la définition du Larousse, les métadonnées sont des données servant à caractériser une autre donnée, physique ou numérique, un concept relativement simple. Les métadonnées se trouvent dans de nombreux endroits courants. Par exemple, la page hébergeant cet article de blog contient des métadonnées. Elles comprennent des balises SEO, c'est-à-dire des indices qui permettent à différents navigateurs de formater correctement la page, et des mots-clés pour décrire la page. De la même manière, une photo enregistrée sur votre appareil portable contient de nombreuses métadonnées dont voici un extrait :

ExifTool Version Number         : 11.11 
File Name                       : 60398459048__A20828DD-FAA4-4133-BA1F-059DEC9E7332.jpeg 
Directory                       : . 
File Size                       : 2.8 MB 
File Modification Date/Time     : 2020:02:21 08:30:01-05:00 
File Access Date/Time           : 2020:02:21 08:30:23-05:00 
File Inode Change Date/Time     : 2020:02:21 08:30:22-05:00 
MIME Type                       : image/jpeg 
JFIF Version                    : 1.01 
Acceleration Vector             : -0.03239090369 -0.9104139204 -0.3862404525 
Exif Byte Order                 : Big-endian (Motorola, MM) 
Make                            : Apple 
Camera Model Name               : iPhone XS 
Orientation                     : Rotate 90 CW 
X Resolution                    : 72 
Y Resolution                    : 72 
Exif Image Width                : 4032 
Exif Image Height               : 3024

Vous vous demandez peut-être en quoi connaître le type MIME d'une photo prise avec un smartphone peut vous aider à améliorer vos initiatives d'observabilité. Concrètement, les métadonnées d'une image ne vous permettent pas d'atteindre cet objectif. Elles ne sont pas conçues pour cela. En revanche, disposer de ce type d'informations devrait vous donner une idée des avantages des métadonnées. Celles de votre smartphone vous permettent de filtrer en fonction de la taille, de l'orientation ou de la stabilité lors de la prise de la photo. (D'après les données ci-dessus, ce dernier point peut encore être grandement amélioré.) Passons en revue les éléments qui vont vous aider à corréler et consulter vos données d'observabilité, principalement les logs, les indicateurs et les données de trace d'application provenant de votre environnement.  

Tendances des déploiements de matériel et de logiciels

Il est loin le temps où des applications monolithiques étaient installées sur des serveurs physiques à vocation unique dans un seul centre de données. Ces systèmes exploitent toujours des charges de travail dédiées, ce qui ne pose aucun problème. De nombreux produits et applications utilisés à grande échelle requièrent toute la puissance disponible. Toutefois, dans le secteur, les modèles de déploiement du matériel et des logiciels tendent, en règle générale, à se tourner vers des microservices et des conteneurs.

trends-increasingly-complex-systems.png

Ce changement n'est pas révolutionnaire : plusieurs modèles de déploiement de logiciels fonctionnent souvent en parallèle dans les organisations, tout comme divers modèles de matériel. Les machines virtuelles ou les instances de cloud exécutent des applications d'architecture orientée services ou des serveurs/clients, tandis que les conteneurs exécutent des images pour leurs microservices, orchestrés par Kubernetes ou Docker. Dans bien des cas, les applications et les services d'un modèle de déploiement exploitent les services d'un autre : un nouveau microservice sophistiqué peut tout à fait continuer à utiliser une base de données hébergée sur un serveur physique.

Les métadonnées deviennent donc encore plus importantes en regard de la nature de ces systèmes hétérogènes. Au fur et à mesure de l'utilisation de conteneurs, de pods et de microservices programmés de manière dynamique, il est encore plus difficile de déterminer quel système d'un centre de données exécute une application. En effet, cette dernière peut aussi s'exécuter sur quatre autres serveurs. 

C'est là que les métadonnées relatives à l'emplacement entrent en jeu. Il ne s'agit pas de déterminer la latitude et la longitude (même si cela pourrait s'avérer utile), mais plutôt un schéma d'adresse qui pourrait, en toute logique, vous permettre de savoir d'où vient une information en particulier, qu'il s'agisse d'un log, d'un indicateur ou d'une donnée de trace d'application.  

Caractéristiques de l'infrastructure

L'emplacement, un élément primordial

Les informations dont vous avez besoin varient selon votre configuration. Cependant, une planification est essentielle. La quantité de données que vous pouvez récupérer dépend de l'exécution d'une tâche spécifique. Par exemple, s'il s'agit d'une application monolithique installée sur un serveur physique, vous ne pourrez pas obtenir les détails des pods Kubernetes, ce qui n'est pas un problème. Notre objectif est de vous fournir des indices permettant de connaître l'emplacement des exécutions. Nous vous expliquons pourquoi un peu plus loin dans cet article.

En tenant compte de l'emplacement, nous souhaitons mettre en place une hiérarchie des métadonnées jusqu'au niveau de l'application exécutant physiquement la tâche.  

Centre de données

Les métadonnées des centres de données doivent comprendre un identifiant unique, comme le nom d'une ville. Cette information peut manquer de précision quand il s'agit de fournisseurs cloud. Toutefois, des analogies peuvent être tissées. Dans ce scénario, nous pouvons tirer parti du fournisseur cloud et de la région où est basé le centre de données, par exemple "GCP", "europe-ouest1" et "zone de disponibilité b".

Si vos centres de données sont composés de niveaux dédiés, comme des hôtes spécifiques réservés à la production ou au test ou bien qui sont utilisés par plusieurs projets, ces informations doivent être ajoutées à vos métadonnées.  Vous pouvez les considérer comme des sections cloisonnées de votre centre de données ou comme un centre de données contenu dans un autre.

Informations de l’hôte

Que vos données soient exécutées sur un serveur physique, virtualisé ou sur cloud, vous disposez régulièrement de certaines informations sur l'hôte. En effet, ce dernier est doté d'attributs pour son nom, sa ou ses adresses IP, le modèle du matériel ou le type d'instance utilisé, le stockage et la mémoire RAM configurés, voire les informations relatives au système d'exploitation. Vous pouvez même inclure des informations plus précises, comme l'emplacement de l'hôte (l'étage, le rack, la rangée, voire l'étagère dans le centre de données). Tout un rack peut être endommagé par une mauvaise alimentation ou un câblage inapproprié.

Détails de l'application

Vous disposez maintenant de suffisamment d'informations pour identifier l'emplacement de chaque tâche exécutée au niveau de l'hôte uniquement. Or, chaque hôte peut exécuter plusieurs services ou applications. Dans ce cas, il est essentiel d'ajouter le niveau correspondant de métadonnées. Pour ne pas vous dérouter avec des informations trop techniques, nous n'entrerons pas trop dans les détails et vous présentons le scénario le plus complexe dans lequel des microservices sont orchestrés par Kubernetes. Il devrait être plutôt simple de l'appliquer à des environnements virtualisés et à des applications physiques.

Les conteneurs de Kubernetes et de Docker mettent automatiquement à disposition un certain niveau de métadonnées, qui doivent être incluses. A minima, il est essentiel d'inclure le nom du conteneur ou du pod, l'image ou la version sur laquelle est basé le conteneur et l'heure de début. Dans l'idéal, il est recommandé d'inclure le nom du réseau ainsi que l'adresse IP, mais aussi les quotas de stockage, de mémoire et de réseau. Remarquez-vous le parallèle avec les informations de l'hôte ? Les conteneurs et les machines virtuelles sont des hôtes exécutés sur un autre hôte. Il est donc logique de vouloir en extraire les mêmes informations.

Il est également possible de faire les mêmes analogies avec un environnement virtualisé. Un hôte virtuel dispose du même niveau de détails, à savoir un nom, une adresse IP, mais aussi des limites de stockage et de mémoire.

Dans notre exemple, nous nous retrouvons face à un dilemme : nous disposons de noms de champs dupliqués identiques. Or, nous voulons conserver une hiérarchie. Dans ce cas, les métadonnées de l'hôte sont à un niveau supérieur qu'un conteneur ou une machine virtuelle.

├── NYC DC 1 
│   ├── Host 1 
│   │   ├── vm 1 
│   │   ├── vm 2 
│   │   └── vm 3 
│   └── Host 2 
│       ├── vm 1 
│       └── vm 2 
└── NYC DC 2 
    └── Host 1 
        ├── vm 1 
        ├── vm 2 
        ├── vm 3 
        └── vm 4

La nécessité de saisir des valeurs dans différents espaces de noms prévisibles semble plutôt évidente pour s'assurer que ces noms n'entrent pas en conflit. Le plus simple est de les saisir en tant que paires clé-valeur. Par exemple, les métadonnées pour "vm 2" sur l'hôte 1 ("Host 1) dans notre NYC DC 1 pourraient inclure les éléments suivants.

dc.name: "NYC DC 1" 
dc.floor: 2 
<other dc fields> 
host.name:  "Host 1" 
host.IP: … 
host.available_memory_mb: 16384 
vm.name: "vm 1" 
vm.IP: …

En matière de hiérarchie, les conteneurs présentent une situation un peu différente, étant donné qu'un cluster Kubernetes peut gérer des hôtes. Dans ce cas, nous nous intéressons aux informations sur l'emplacement d'un conteneur ou pod spécifique, mais aussi aux métadonnées d'orchestration correspondantes, comme expliqué ci-dessus. Voyons maintenant comment les métadonnées nous permettent de bénéficier d'une meilleure observabilité de nos applications.

Observabilité de l'application

Maintenant que vous savez gérer pleinement les éléments exécutés sur vos systèmes, nous pouvons vous apprendre à recueillir les données réelles. (N'oubliez pas que les métadonnées décrivent d'autres données.) Les trois piliers de l'observabilité sont les logs, les indicateurs et les données de trace d'application (aussi appelées informations sur le monitoring des performances applicatives). Les données de disponibilité peuvent être considérées comme un quatrième pilier. Lors de la collecte des logs et des indicateurs, nous souhaitons les rassembler à chaque niveau de notre écosystème, comme l'illustre le schéma ci-dessous, qui comprend des informations sur les types de données d'observabilité à recueillir pour chaque abstraction.

what-to-monitor.png

Par exemple, nous voulons collecter les logs, les indicateurs et les données de disponibilité de chaque hôte ou élément de réseau dans nos centres de données, mais aussi ajouter les informations sur le monitoring des performances applicatives pour les services et les applications.

Nous enrichissons toutes ces informations à l'aide des métadonnées correspondantes pour chaque niveau en vue d'améliorer la visibilité de nos applications, de notre infrastructure et de l'ensemble de notre écosystème. Dans ce but, nous utilisons différentes méthodes : nous pouvons les envoyer avec chaque événement ou trace, ce qui permet de mener des recherches rapides et de filtrer, ou nous stockons les métadonnées provenant des parties statiques de notre écosystème, puis les référençons de manière croisée ultérieurement. La seconde méthode pourrait permettre de gagner un peu d'espace. Toutefois, elle entraîne des risques d'obsolescence, en particulier dans les écosystèmes dynamiques.

Organisation des données

Maintenant, nous pouvons ventiler nos données d'observabilité enrichies de métadonnées en fonction des facettes de notre choix, et pas seulement pour étudier des logs ou des informations sur le monitoring des performances applicatives spécifiques. Par exemple, nous pouvons répartir les informations d'utilisation actuelle du processeur par hôte et par service.

infra-viewer.png

Nous pouvons aussi afficher ce même paramètre sur une période précise.

metrics-explorer.png

Ainsi, nous pouvons choisir les informations que nous souhaitons réorganiser afin de traiter des questions auxquelles nous ne pourrions pas répondre autrement, notamment les suivantes :

  • Mon centre de données situé aux États-Unis est-il surutilisé par rapport à mon centre de données basé en EMEA ?
  • Certains racks de mon écosystème rencontrent-ils plus d'erreurs que d'autres ?
  • Puis-je recycler certaines infrastructures de développement pour la mise en production ?
  • Sur quels hôtes physiques les conteneurs ou les pods de mon application d'e-commerce sont-ils exécutés ?
  • Pourquoi les photos prises avec mon smartphone sont-elles toujours floues ?

Conclusion

Les métadonnées apportent une nouvelle dimension à votre analyse : vous pouvez agréger, répartir et réorganiser vos données de nouvelles manières afin de trouver des réponses à vos questions relatives à vos activités et à vos opérations. Concernant la solution que vous utilisez pour vos initiatives d'observabilité, assurez-vous qu'elle peut évoluer en parallèle de vos besoins et tient compte des métadonnées interrogeables et consultables, comme Elastic Common Schema. Ainsi, vous savez que vos métadonnées sont utilisées conformément à vos attentes.