Comment tirer le meilleur parti des logs issus des containers

Le défi posé par les logs issus des containers

Parce que les cycles de vie sont courts, ces données sont plus difficiles à stocker. Les containers, ces entités apatrides (stateless), ne sont pas conçus à l’origine pour conserver des informations persistantes. Par exemple, si les logs sont liés au container lui-même, l’arrêt de celui-ci mettra généralement fin à la collecte des logs également. Pire, si le container est détruit, sauf protection contraire, les informations récoltées seront effacées à moins d’avoir paramétré une exportation vers une ressource de stockage.

La collecte de fichiers journaux depuis des containers doit prendre en compte plusieurs niveaux. Pour exécuter une application containerisée, un développeur a besoin de gérer trois environnements : le container, le moteur du container, comme le daemon Docker, et le système d’exploitation de l’hôte partagé. Pour extraire correctement des logs de cette architecture, il faut identifier et corréler les événements dans ces trois environnements. Ce n’est qu’en suivant cette procédure que les développeurs peuvent remonter à la source d’un problème.

Plus de sécurité, plus de complexité. Les vulnérabilités identifiées des OS peuvent affecter tous les containers parce qu’ils partagent le même kernel. Pour renforcer la sécurité de ces composants, certaines entreprises les exécutent au sein de VM. Cependant, cela augmente la complexité de l’observabilité. Les administrateurs doivent suivre les informations tirées du moteur de containerisation, du container et de l’hôte, mais aussi de la VM et de l’hyperviseur associé.

Quatre options pour gérer les logs

Pour gérer les logs issus des trois environnements cités plus haut, quatre techniques sont efficaces suivant votre utilisation. Voici leurs caractéristiques.

La gestion de logs basée sur l’application. Dans ce cas, l’application à l’intérieur du container gère ses propres logs. Par exemple, une application Java peut utiliser l’utilitaire Apache Log4j afin de produire ces fameuses entrées et les envoyer à un serveur centralisé distant. Cette méthode ressemble beaucoup à celles employées pour surveiller des applications monolithiques. Les nouveaux venus dans le monde de Kubernetes et Docker apprécieront.

Cependant, cette approche ne « voit » pas vraiment l’environnement du conteneur, de sorte que la journalisation contourne à la fois le système d’exploitation et le moteur. Et comme l’utilitaire d’enregistrement fonctionne à l’intérieur du container lui-même, il ajoute de la charge et réduit potentiellement les performances de l’application. En outre, l’outil d’enregistrement est configuré par défaut pour un stockage local non persistant. Dans ce cas-là, les enregistrements sont perdus lorsque le conteneur est détruit, à moins que les administrateurs ne les transfèrent vers un emplacement persistant.

La gestion de logs basée sur un volume. Cette caractéristique éphémère des données peut être contournée en allouant un espace de stockage à ces registres. Un moteur, tel que Docker, prend en charge le stockage de volume dans une zone de répertoire, qui est mise de côté et mappée spécifiquement pour ce moteur. Cela permet de centraliser les logs issus de l’ensemble des environnements. Les administrateurs peuvent ensuite copier ou sauvegarder les données à des fins d’analyses ou de sécurisation. Le seul inconvénient de la fonction de volume est que la zone de stockage est configurée pour un moteur correspondant ; le déplacement des containers peut provoquer la perte des données.

Les logs natifs de Docker. Une autre façon de transmettre les données de journalisation pour corrélation et analyse est d’utiliser un pilote ou un service natif à Docker. Le pilote de logging associé transmet les événements de chaque container à une instance syslog sur un système hôte.

Ce pilote recueille les logs à partir des chemins stdout et stderr, pour les sorties et les erreurs. Il offre un moyen simple et direct de les centraliser sans avoir à les manipuler directement.

Un container dédié à la collecte des logs. Les exemples ci-dessus concernent des services conçus pour saisir et transmettre les logs de manière persistante. Une autre approche consiste à coupler cette collecte avec un container dédié que les administrateurs gèrent depuis le moteur lui-même. Le container de logs peut prendre en charge de nombreux autres de ses camarades pour recevoir, agréger, stocker et transmettre les informations à une application ou à un service pour analyse. Par exemple, un container peut exécuter un outil tel que logspout pour capturer les données stdout et stderr de n’importe quel container sur le système hôte, puis transmettre ces données à un service syslog distant.

Cette technique est adaptée aux architectures de microservices. Son principal avantage : la mobilité. Il est possible de déplacer des containers d’un système à l’autre sans se soucier des dépendances particulières.

Les meilleures pratiques pour gérer les registres

Il n’existe pas une méthode unique pour aborder la gestion des logs issus des containers. En revanche, il convient de s’appuyer sur plusieurs bonnes pratiques.

Évaluez les effets sur les performances. Chaque approche de gestion des logs de containers implique des compromis en termes de commodité et de performance applicative. Avant de choisir la méthode qu’il vous convient testez-les pour éviter les effets négatifs sur l’exécution de l’application sous-jacente.

Envisagez les outils sensibles aux logs. La vitesse et le caractère éphémère des containers peuvent rendre difficile leur gestion depuis les logiciels d’observabilité. Évaluez des outils centralisés, tels que Docker App for Sumo Logic et cAdvisor de Google, conçus pour fonctionner avec des moteurs de containers afin de surveiller et de gérer ces composants stateless.

Maximisez les intégrations. Idéalement, un outil de surveillance et de gestion des containers devrait s’intégrer à une multitude de plateformes et de moteurs pour extraire des logs dans des infrastructures complexes. Cela permet de réduire le nombre d’outils nécessaires à la prise en charge de l’environnement et d’obtenir des corrélations et des analyses plus complètes. Des outils tels que Sumo Logic permettent des dizaines d’intégrations, notamment avec Docker, Kubernetes et Amazon Elastic Kubernetes Service.

Adoptez l’analytique. Chercher des moyens d’utiliser les données et les mesures pour l’analyse et le dépannage. Par exemple, un outil permet de capturer et de corréler les erreurs, tandis qu’un outil de surveillance permet de suivre des éléments tels que les actions des containers, les pannes et la mémoire/CPU.

Définissez des politiques de conservation et de suppression des logs. Les logs peuvent consommer beaucoup d’espace de stockage, mais leur valeur diminue avec le temps. Cela signifie que leur conservation à long terme entraîne généralement des rendements décroissants. Il faut donc gérer efficacement les espaces de stockage alloués en fonction des besoins réglementaires de l’entreprise, afin d’éviter des factures démesurées.

Sécurisez les logs. Ces registres contiennent souvent des informations sensibles relatives à l’infrastructure informatique, telles que les noms d’hôtes, les chemins d’accès aux répertoires, les variables d’environnement et les adresses IP. Dans la mesure du possible, utilisez des identifiants d’accès et le chiffrement pour protéger ces fichiers.

Séparez l’infrastructure de surveillance. Placez une infrastructure de logging dans un environnement qui est à la fois logiquement et physiquement séparé des applications surveillées. Lorsque l’observabilité est déployée dans le même environnement que les applications, les mêmes problèmes qui affectent les applications peuvent affecter la gestion des logs – et rendre la plateforme d’observance inutilisable. En outre, il convient de déployer l’outil ou la plateforme d’observabilité dans une configuration en cluster afin d’assurer une meilleure résilience et une meilleure disponibilité.