Examinons les bases de la journalisation dans Docker et Kubernetes, puis examinons deux outils qui peuvent être utilisés en toute sécurité en production : Grafana Loki et la pile EFK (Elasticsearch + Fluent Bit + Kibana).
Le matériau de l'article est une compression de . S'il y a une envie, et plus encore s'il y a un besoin de production, vous pouvez suivre une formation complète - inscrivez-vous à un cours sur .
Journalisation Docker
Au niveau Kubernetes, les applications s'exécutent dans des pods, mais à un niveau inférieur, elles s'exécutent toujours normalement dans Docker. Par conséquent, vous devez configurer la journalisation de manière à collecter les journaux des conteneurs. Les conteneurs sont lancés par Docker, ce qui signifie que vous devez comprendre comment la journalisation est organisée au niveau Docker.
J'espère que chaque lecteur le sait : les journaux d'application doivent être écrits dans stdout / stderr, et non à l'intérieur du conteneur. Les journaux sont agrégés par Docker Daemon, et cela fonctionne exactement avec les journaux qui sont envoyés à stdout/stderr. De plus, l'écriture de journaux à l'intérieur du conteneur pose de nombreux problèmes : le conteneur gonfle à partir du journal croissant (puisqu'il n'y a probablement pas de Logrotate dans le conteneur), et le démon Docker n'est pas au courant de ce journal.
Docker dispose de plusieurs pilotes ou plugins de journalisation pour collecter la journalisation des conteneurs. La version gratuite Docker Community Edition (CE) a moins de pilotes de journalisation que la version commerciale Docker Enterprise Edition (EE).
Je n'ai jamais utilisé Docker EE dans la pratique : chez Southbridge, nous essayons de nous en tenir aux solutions Open Source, et les clients n'ont pas besoin de la plupart des fonctionnalités supplémentaires de Docker EE.
Logger les pilotes dans Docker CE :
locales - écriture de journaux dans les fichiers internes du démon Docker ;
fichier json - créer json-log dans le dossier de chaque conteneur ;
journal - envoi des logs à journald.
Les paramètres de journalisation Docker se trouvent dans le fichier daemon.json.
Le champ "log-driver" spécifie le plugin, et le champ "log-opts" spécifie ses paramètres. Dans l'exemple ci-dessus, le plugin "json-file" est spécifié, la limite de taille du journal est "max-size": "10m" ; limite du nombre de fichiers (paramètres de rotation) — "max-file": "3" ; ainsi que les valeurs qui seront attachées aux logs.
Certains paramètres du pilote de journal peuvent être définis via l'utilitaire de ligne de commande. Ceci est utile si un conteneur distinct doit être exécuté avec un pilote de journal différent.
Voici à quoi ressemble le schéma de journalisation dans Docker :
Fonctionnement du schéma : un pilote de journalisation tel que json-file crée des fichiers. Les collecteurs de journaux (Rsyslog, Fluentd, Logagent et autres) collectent ces fichiers et les transfèrent vers le stockage dans Elastic, Sematext ou d'autres stockages.
Fonctionnalités de la journalisation dans Kubernetes
Simplifié, le schéma de journalisation dans Kubernetes ressemble à ceci : il y a un pod, un conteneur y est exécuté, le conteneur envoie les journaux à stdout / stderr. Docker crée ensuite un fichier et écrit des journaux, qu'il peut ensuite faire pivoter.
Considérez les fonctionnalités de journalisation dans Kubernetes.
Enregistrer les journaux entre les déploiements. Il s'agit d'une condition préalable pour des paramètres de journalisation corrects. Si vous n'enregistrez pas les journaux entre les déploiements, lorsqu'une nouvelle version de l'application est publiée, les journaux de la précédente seront écrasés, le rechargement du conteneur entraînera également une perte de journaux. Kubernetes a la clé --previous, elle vous permet de visualiser les journaux d'application avant le dernier redémarrage du pod, mais pas plus loin.
Agréger les journaux de toutes les instances. Si les microservices sont hébergés dans les clouds, le fournisseur de cloud est responsable du contrôle du système. Si les microservices se trouvent sur leur propre matériel, en plus des journaux des conteneurs, vous devez également collecter les journaux système.
Auparavant, il n'existait aucun outil pratique pour collecter les journaux du système et des microservices. Habituellement, un outil collectait les journaux système (par exemple, Rsyslog), le second - les journaux de Docker (par exemple, journal-bit avec le pilote de journal Docker configuré sur journald). Nous avons essayé d'utiliser journal-bit - collecter les journaux à la fois des conteneurs (indiquez dans le pilote de journal Docker que vous devez écrire des journaux dans journald) et du système (CentOS 7 a déjà systemd et journald). La solution fonctionne, mais pas parfaite. S'il y a beaucoup de journaux, journal-bit commence à être décalé, les messages sont perdus.
Les expériences se sont poursuivies - et un autre moyen a été trouvé. Dans CentOS 7, les principaux journaux système (messages, audit, sécurisé) sont dupliqués dans le var-log sous forme de fichiers. Docker peut également être configuré pour enregistrer les journaux dans des fichiers json. En conséquence, ces fichiers de CentOS 7 et Docker peuvent être assemblés.
Au fil du temps, la solution ELK Stack est devenue populaire. C'est une combinaison de plusieurs outils : Elasticsearch, Logstash et Kibana.
Elasticsearch stocke les journaux des conteneurs, Logstash collecte les journaux des instances, Kibana vous permet de traiter les journaux reçus et de créer des graphiques basés sur eux. ELK Stack est activement utilisé depuis un certain temps, mais, à mon avis, son temps passe. Je vous dirai pourquoi plus tard.
Ajouter des métadonnées. Les pods, les applications et les conteneurs peuvent être exécutés n'importe où. De plus, une application peut avoir plusieurs instances. Les journaux sont écrits dans le même format, et nous devons comprendre de quel type de réplique il s'agit, quel pod l'écrit, dans quel espace de noms il se trouve. C'est pourquoi les journaux doivent ajouter des métadonnées.
Analyser les journaux. C'est drôle, mais le coût de maintenance d'un système de journalisation et de surveillance peut dépasser le coût de l'application principale. Lorsque vous avez des dizaines et des centaines de milliers de journaux qui volent par seconde, cela semble naturel, mais vous devez toujours connaître la ligne. Une façon de trouver ce bord est d'analyser les journaux.
En règle générale, vous n'avez pas besoin de collecter et de stocker tous les journaux, vous n'avez besoin d'envoyer qu'une partie pour le stockage - par exemple, les journaux avec le statut "avertissement" ou "erreur". Si nous parlons de nginx ou de journaux de contrôleur d'entrée, seuls ceux dont le statut est différent de 200 peuvent être envoyés pour stockage.Mais ce n'est pas un conseil universel : si vous construisez d'une manière ou d'une autre des analyses basées sur les journaux Nginx, alors ils valent évidemment la peine d'être collectés.
Le filtrage inconsidéré des journaux n'est pas recommandé, car les données filtrées peuvent ne pas être suffisantes pour une analyse normale. D'un autre côté, peut-être que l'analyse devrait être effectuée non pas au niveau de la journalisation, mais au niveau de la collecte des métriques. Ensuite, vous n'avez pas besoin de stocker des centaines de milliers de lignes avec le code 200. Une approche consiste à obtenir des informations sur le trafic et les erreurs à partir des métriques des contrôleurs d'entrée.
En général, ici, vous devez bien réfléchir: que voulez-vous stocker et pendant combien de temps, sinon une situation se produira lorsque le système de journalisation prendra plus de ressources que le projet principal.
Il n'existe pas encore de solution standard pour la journalisation. Contrairement à la surveillance, où il existe une solution Prometheus la plus courante, il n'y a pas de norme en matière de journalisation.
Dans cette conférence, nous examinerons deux outils : l'un est populaire et le second gagne en popularité. En plus d'eux, il y en a d'autres, mais dans cet article, nous ne les aborderons pas.
Compte tenu de toutes les fonctionnalités décrites ci-dessus, la journalisation dans Kubernetes peut désormais être représentée de la manière suivante :
Le journal du conteneur reste, rotation, mais un agent collecteur apparaît, qui récupère les journaux et les envoie pour stockage (dans le diagramme - dans le Logging Backend). L'agent s'exécute sur chaque nœud et est généralement exécuté sur Kubernetes.
Considérons maintenant les outils de journalisation.
Grafana Loki
est apparu récemment, mais est déjà devenu assez célèbre. Ses avantages : facile à installer, consomme peu de ressources, ne nécessite pas l'installation d'Elasticsearch, car il stocke les données dans TSDB (time series database). Dans le dernier article, j'ai écrit que Prometheus stocke les données dans une telle base de données, et c'est l'une des nombreuses similitudes entre les deux produits. Les développeurs prétendent même que Loki est "Prométhée pour le monde de l'exploitation forestière".
Une petite parenthèse sur TSDB pour ceux qui n'ont pas lu : TSDB fait un excellent travail de stockage de grandes quantités de données, de séries chronologiques, mais n'est pas conçu pour le stockage à long terme. Si, pour une raison quelconque, vous devez stocker les journaux pendant plus de deux semaines, il est préférable de configurer leur transfert vers une autre base de données.
Un autre avantage de Loki est que Grafana est utilisé pour la visualisation des données. C'est très pratique : dans Grafana on regarde les données de monitoring et au même endroit, en connectant Loki, on regarde les logs. Les journaux peuvent être utilisés pour créer des graphiques.
L'architecture de Loki ressemble à ceci :
À l'aide de DaemonSet, un agent est déployé sur tous les serveurs du cluster - Promtail ou Fluent Bit. L'agent collecte les journaux. Loki les récupère et les stocke dans sa TSDB. Les métadonnées sont immédiatement ajoutées aux journaux, ce qui est pratique : vous pouvez filtrer par pods, espaces de noms, noms de conteneurs et même étiquettes.
Loki s'exécute dans l'interface familière de Grafana. Loki a même son propre langage de requête appelé LogQL, dont le nom et la syntaxe sont similaires à PromQL dans Prometheus. L'interface Loki a des invites avec des requêtes, il n'est donc pas nécessaire de les connaître par cœur.
Loki dans l'interface Grafana
À l'aide de filtres, Loki peut trouver des codes ("400", "404" et tout autre); afficher les journaux de l'ensemble du nœud ; filtrer tous les journaux contenant le mot "error". Si vous cliquez sur le journal, une carte avec toutes les informations sur l'événement s'ouvrira.
Il existe suffisamment d'outils dans Loki qui vous permettent d'extraire les journaux nécessaires, même si, pour être honnête, techniquement, il pourrait y en avoir plus. Maintenant, Loki se développe activement et gagne en popularité.
Élastique + Bit Fluent + Kibana (pile EFK)
La pile EFK est un outil de journalisation plus classique mais tout aussi populaire.
Au début de l'article, ELK (Elasticsearch + Logstash + Kibana) était mentionné, mais cette pile est obsolète en raison du Logstash peu productif et en même temps gourmand en ressources. Au lieu de cela, ils ont commencé à utiliser Fluentd, plus léger et plus productif, et après un certain temps, il est venu à la rescousse. - un agent-collecteur encore plus léger et encore plus productif.
Selon les développeurs, Fluent Bit est plus de 100 fois plus performant que Fluentd : « là où Fluentd consomme 20 Mo de RAM, Fluent Bit consommera 150 Ko » - une citation directe de la documentation. En regardant cela, Fluent Bit est devenu plus largement utilisé.
Fluent Bit a moins de fonctionnalités que Fluentd, mais il couvre les principaux besoins, nous utilisons donc principalement Fluent Bit.
Fonctionnement de la pile EFK : l'agent collecte les journaux de tous les pods (généralement un DaemonSet exécuté sur tous les serveurs du cluster) et les envoie au stockage (Elasticsearch, PostgreSQL ou Kafka). Kibana se connecte au référentiel et y récupère toutes les informations nécessaires.
présente des informations dans une interface Web conviviale. Il y a des graphiques, des filtres et plus encore.
Les journaux peuvent être utilisés pour créer des tableaux de bord entiers.
Fonctionnalités Fluent Bit
Étant donné que Fluent Bit est généralement moins entendu que Logstash, examinons-le de plus près. Fluent Bit peut être logiquement divisé en 6 modules, et des plugins peuvent être attachés à certains des modules qui étendent les capacités de Fluent Bit.
Module d'entrée collecte les journaux des fichiers, des services systemd et même de tcp-socket (il vous suffit de spécifier un point de terminaison, et Fluent Bit commencera à y aller). Ces fonctionnalités sont suffisantes pour collecter les journaux du système et des conteneurs.
En production, on utilise le plus souvent des plugins (il peut être défini sur un dossier avec des journaux) et (on peut lui dire à partir de quels services collecter les journaux).
Module analyseur apporte les journaux à une vue commune. Par défaut, les journaux Nginx sont une chaîne. À l'aide du plugin, cette chaîne peut être convertie en JSON : définissez les champs et leurs valeurs. JSON est beaucoup plus facile à utiliser qu'un journal de chaînes car il existe des options de tri plus flexibles.
Module de filtrage. A ce niveau, les journaux inutiles sont éliminés. Par exemple, les journaux sont envoyés pour stockage uniquement avec la valeur « avertissement » ou avec certaines étiquettes. Les journaux sélectionnés sont mis en mémoire tampon.
Module tampon. Fluent Bit possède deux types de tampon : un tampon mémoire et un tampon disque. Un tampon est un stockage temporaire des journaux qui est nécessaire en cas d'erreurs ou de pannes. Tout le monde veut économiser sur la RAM, donc ils choisissent généralement un tampon de disque. Mais gardez à l'esprit qu'avant d'aller sur le disque, les journaux sont toujours déchargés en mémoire.
Module de routage/sortie contient des règles et des adresses pour l'envoi de journaux. Comme déjà mentionné, les journaux peuvent être envoyés à Elasticsearch, PostgreSQL ou, par exemple, Kafka.
Fait intéressant, les journaux peuvent être envoyés de Fluent Bit à Fluentd. Étant donné que le premier est plus léger et moins fonctionnel, vous pouvez collecter des journaux à travers lui et les envoyer à Fluentd, et déjà là, avec l'aide de plugins supplémentaires, ils peuvent être traités et envoyés vers des stockages.
Si vous envisagez d'utiliser Elasticsearch…
Enfin, deux conseils pour ceux qui envisagent d'utiliser Elasticsearch comme référentiel de journaux en production.
- Configurez des alertes avec . Ce programme isole les messages importants du flux général de journaux et émet des alertes à leur sujet dans le courrier ou un autre canal. C'est vrai, il n'y a pas si longtemps .
- Faire pivoter les journaux avec l'application ou des appels à l'API Elasticsearch. Elastic lui-même, en principe, prend désormais des mesures importantes pour gérer la durée de vie des index sans utiliser d'outils tiers. En général, il ne sert à rien de conserver des journaux pendant une longue période : il est peu probable qu'un journal soit nécessaire après deux semaines - s'il est vraiment critique, il sera certainement résolu en deux semaines. Dans les cas extrêmes, les anciens journaux peuvent être archivés et envoyés quelque part pour un stockage à long terme. J'ai entendu parler de journaux spéciaux qui doivent être conservés jusqu'à 5 ans en vertu de la loi. Personnellement, je n'ai pas rencontré cela, mais je n'assimilerais pas ces informations à des journaux ordinaires, et peut-être même les stockerais-je séparément.
A suivre ...
Auteur : Marcel Ibraev, administrateur Kubernetes certifié, ingénieur en exercice dans l'entreprise , conférencier et concepteur de cours .
Source: habr.com
