{"id":93294,"date":"2020-09-05T07:42:58","date_gmt":"2020-09-05T05:42:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi"},"modified":"2020-09-05T07:42:58","modified_gmt":"2020-09-05T05:42:58","slug":"logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","title":{"rendered":"Journalisation dans Kubernetes : comment collecter, stocker, analyser et traiter les journaux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nous allons examiner les bases de la journalisation dans Docker et Kubernetes, puis nous \u00e9tudierons deux outils que l'on peut utiliser en production : Grafana Loki et la pile EFK (Elasticsearch + Fluent Bit + Kibana).<\/p>\n

<\/p>\n

Le contenu de l'article est un extrait de la conf\u00e9rence ouverte de l'\u00e9cole \u00ab Slyurm \u00bb<\/a><\/noindex>. Si vous \u00eates int\u00e9ress\u00e9 et qu'il y a une n\u00e9cessit\u00e9 de production, vous pouvez suivre une formation compl\u00e8te - inscrivez-vous au cours sur La surveillance et la journalisation de l'infrastructure dans Kubernetes<\/a><\/noindex>.<\/em><\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/a><\/noindex><\/p>\n

Journalisation dans Docker<\/h2>\n

<\/p>\n

Au niveau de Kubernetes, les applications sont lanc\u00e9es dans des pods, mais \u00e0 un niveau inf\u00e9rieur, elles fonctionnent g\u00e9n\u00e9ralement dans Docker. Il est donc n\u00e9cessaire de configurer la journalisation de mani\u00e8re \u00e0 collecter les journaux des conteneurs. Les conteneurs sont lanc\u00e9s par Docker \u2014 il faut donc comprendre comment la journalisation fonctionne au niveau de Docker.<\/p>\n

<\/p>\n

J'esp\u00e8re que chaque lecteur sait que les journaux des applications doivent \u00eatre \u00e9crits sur stdout\/stderr, et non \u00e0 l'int\u00e9rieur du conteneur. Docker Daemon agr\u00e8ge les journaux, et il ne traite que ceux qui sont envoy\u00e9s \u00e0 stdout\/stderr. De plus, enregistrer les journaux \u00e0 l'int\u00e9rieur du conteneur pose des probl\u00e8mes : le conteneur gonfle en raison de la croissance des journaux (car il n'y a probablement pas de Logrotate dans le conteneur), et Docker Daemon n'est pas au courant de ce journal.<\/p>\n

<\/p>\n

Docker dispose de plusieurs pilotes de journalisation ou plugins pour collecter les journaux des conteneurs. Dans la version gratuite, Docker Community Edition (CE), il y a moins de pilotes de journalisation que dans la version commerciale Docker Enterprise Edition (EE).<\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

Je n'ai jamais utilis\u00e9 Docker EE dans la pratique : chez Southbridge, nous essayons de nous en tenir \u00e0 des solutions Open Source, et la plupart des fonctionnalit\u00e9s suppl\u00e9mentaires de Docker EE ne sont pas n\u00e9cessaires pour les clients. <\/p>\n

<\/p>\n

Pilotes de journalisation dans Docker CE :<\/p>\n

<\/p>\n

local<\/strong> \u2014 enregistrement des journaux dans des fichiers internes de Docker Daemon ;
\njson-file<\/strong> \u2014 cr\u00e9ation d'un fichier json-log dans le dossier de chaque conteneur ;
\njournald<\/strong> \u2014 envoi des journaux vers journald.<\/p>\n

<\/p>\n

Les param\u00e8tres de journalisation dans Docker se trouvent dans le fichier daemon.json. <\/p>\n

<\/p>\n

Dans le champ \u00ab log-driver \u00bb, on indique le plugin, et dans le champ \u00ab log-opts \u00bb \u2014 ses param\u00e8tres. L'exemple ci-dessus indique le plugin \u00ab json-file \u00bb, la limite de taille des journaux \u2014 \u00ab max-size \u00bb : \u00ab 10m \u00bb ; la limite du nombre de fichiers (param\u00e8tres de rotation) \u2014 \u00ab max-file \u00bb : \u00ab 3 \u00bb ; ainsi que les valeurs qui seront ajout\u00e9es aux journaux.<\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

Certains param\u00e8tres du pilote de journalisation peuvent \u00eatre d\u00e9finis via l'outil en ligne de commande. C'est pratique si un conteneur sp\u00e9cifique doit \u00eatre lanc\u00e9 avec un autre pilote de journalisation. <\/p>\n

<\/p>\n

Voici \u00e0 quoi ressemble le sch\u00e9ma de journalisation dans Docker :<\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

Comment le sch\u00e9ma fonctionne : le pilote de journalisation, par exemple json-file, cr\u00e9e des fichiers. Des collecteurs de journaux (Rsyslog, Fluentd, Logagent et d'autres) collectent ces fichiers et les transmettent pour stockage dans Elastic, Sematext ou d'autres syst\u00e8mes de stockage.<\/p>\n

<\/p>\n

Particularit\u00e9s de la journalisation dans Kubernetes<\/h2>\n

<\/p>\n

Sch\u00e9matiquement, la journalisation dans Kubernetes se pr\u00e9sente ainsi : il y a un pod, \u00e0 l'int\u00e9rieur duquel un conteneur est en cours d'ex\u00e9cution, et le conteneur envoie les journaux vers stdout\/stderr. Ensuite, Docker cr\u00e9e un fichier et enregistre les journaux, qui peuvent ensuite \u00eatre tourn\u00e9s.<\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

Examinons les particularit\u00e9s de la journalisation dans Kubernetes.<\/p>\n

<\/p>\n

Conserver les journaux entre les d\u00e9ploiements<\/strong>. C'est une condition obligatoire pour une configuration correcte de la journalisation. Si les logs ne sont pas conserv\u00e9s entre les d\u00e9ploiements, lors de la sortie d'une nouvelle version de l'application, les logs pr\u00e9c\u00e9dents seront \u00e9cras\u00e9s, et le red\u00e9marrage du conteneur entra\u00eenera \u00e9galement une perte des logs. Kubernetes dispose d'une option \u2014previous, qui permet de consulter les logs de l'application avant le dernier red\u00e9marrage du Pod, mais pas plus loin.<\/p>\n

<\/p>\n

Agr\u00e9g\u00e9 les journaux de toutes les instances<\/strong>. Si les microservices sont h\u00e9berg\u00e9s dans le cloud, le fournisseur cloud est responsable du contr\u00f4le du syst\u00e8me. Si les microservices fonctionnent sur leur propre mat\u00e9riel, il est n\u00e9cessaire de collecter les journaux des conteneurs ainsi que les journaux du syst\u00e8me.<\/p>\n

<\/p>\n

Auparavant, il n'y avait pas d'outils pratiques pour recueillir les journaux tant du syst\u00e8me que des microservices. En g\u00e9n\u00e9ral, un outil recueillait les journaux syst\u00e8me (par exemple, Rsyslog), et un autre recueillait les journaux de Docker (comme journal-bit en configurant le pilote de journalisation Docker sur journald). Ils ont tent\u00e9 d'utiliser journal-bit pour collecter les journaux des conteneurs (o\u00f9 le pilote de journalisation Docker sp\u00e9cifie d'\u00e9crire les journaux dans journald) et ceux du syst\u00e8me (dans CentOS 7, systemd et journald sont d\u00e9j\u00e0 pr\u00e9sents). La solution fonctionne, mais n'est pas id\u00e9ale. Si les journaux sont nombreux, journal-bit commence \u00e0 ralentir, des messages se perdent.<\/p>\n

<\/p>\n

Les exp\u00e9riences ont continu\u00e9 - et une autre m\u00e9thode a \u00e9t\u00e9 trouv\u00e9e. Dans CentOS 7, les principaux journaux syst\u00e8me (messages, audit, secure) sont dupliqu\u00e9s dans var-log sous forme de fichiers. Dans Docker, il est \u00e9galement possible de configurer la sauvegarde des journaux dans des fichiers json. Par cons\u00e9quent, ces fichiers de CentOS 7 et de Docker peuvent \u00eatre collect\u00e9s ensemble.<\/p>\n

<\/p>\n

Avec le temps, la solution ELK Stack est devenue populaire. C'est une combinaison de plusieurs outils : Elasticsearch, Logstash et Kibana.<\/p>\n

<\/p>\n

Elasticsearch stocke les journaux des conteneurs, Logstash collecte les journaux des instances, Kibana permet de traiter les journaux re\u00e7us et d'en tracer des graphiques. Pendant un certain temps, l'ELK Stack a \u00e9t\u00e9 utilis\u00e9 activement, mais \u00e0 mon avis, son temps est r\u00e9volu. Je vous expliquerai plus tard pourquoi.<\/p>\n

<\/p>\n

Ajouter des m\u00e9tadonn\u00e9es<\/strong>. Les pods, applications et conteneurs peuvent \u00eatre ex\u00e9cut\u00e9s n'importe o\u00f9. De plus, une application peut avoir plusieurs instances. Les journaux sont enregistr\u00e9s dans un format unique, et nous devons comprendre quelle r\u00e9plique il s'agit, quel Pod les \u00e9crit et dans quel namespace il se trouve. C'est pourquoi il est n\u00e9cessaire d'ajouter des m\u00e9tadonn\u00e9es aux journaux.<\/p>\n

<\/p>\n

Analyser les journaux<\/strong>. Il est amusant de constater que les co\u00fbts de maintenance des syst\u00e8mes de journalisation et de surveillance peuvent d\u00e9passer ceux de l'application principale. Lorsque des dizaines et des centaines de milliers de journaux se produisent par seconde, cela semble logique, mais il est n\u00e9anmoins essentiel de conna\u00eetre les limites. Un moyen de trouver ces limites est l'analyse des journaux. <\/p>\n

<\/p>\n

En g\u00e9n\u00e9ral, il n'est pas n\u00e9cessaire de collecter et de stocker tous les journaux, il faut envoyer au stockage uniquement une partie \u2014 par exemple, les journaux avec le statut \u00ab warning \u00bb ou \u00ab error \u00bb. S'il s'agit de journaux nginx ou de contr\u00f4leurs d'entr\u00e9e, seuls ceux dont le statut est diff\u00e9rent de 200 doivent \u00eatre envoy\u00e9s au stockage. Toutefois, ce n'est pas un conseil universel : si vous construisez des analyses bas\u00e9es sur les journaux Nginx, il est \u00e9vident qu'il vaut la peine de les collecter. <\/p>\n

<\/p>\n

Il est d\u00e9conseill\u00e9 de filtrer les journaux sans r\u00e9flexion, car les donn\u00e9es filtr\u00e9es peuvent ne pas suffire pour une analyse normale. D'autre part, il est possible que l'analyse doive se faire non pas au niveau de la journalisation, mais au niveau de la collecte des m\u00e9triques. Cela \u00e9viterait d'avoir \u00e0 stocker des centaines de milliers de lignes avec le code 200. L'une des approches consiste \u00e0 obtenir des informations sur le trafic et les erreurs \u00e0 partir des m\u00e9triques des contr\u00f4leurs d'entr\u00e9e. <\/p>\n

<\/p>\n

En g\u00e9n\u00e9ral, il faut bien r\u00e9fl\u00e9chir \u00e0 ce que vous souhaitez stocker et pendant combien de temps, sinon il y aura une situation o\u00f9 le syst\u00e8me de journalisation consommera plus de ressources que le projet principal.<\/p>\n

<\/p>\n

Il n'existe pas encore de solution standard pour la journalisation<\/strong>. Contrairement \u00e0 la surveillance, o\u00f9 il y a une solution pr\u00e9dominante, Prometheus, il n'y a pas de norme en mati\u00e8re de journalisation. <\/p>\n

<\/p>\n

Dans le cadre de cette conf\u00e9rence, nous examinerons deux outils : l'un populaire et l'autre en pleine croissance. En plus de ceux-ci, il en existe d'autres, mais nous ne les aborderons pas dans cet article.<\/p>\n

<\/p>\n

Compte tenu de toutes les sp\u00e9cificit\u00e9s examin\u00e9es ci-dessus, la journalisation dans Kubernetes peut maintenant \u00eatre repr\u00e9sent\u00e9e sous la forme d'un sch\u00e9ma :<\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

Il reste le journal du conteneur, la rotation, mais appara\u00eet un agent collecteur qui recueille les journaux et les envoie au stockage (dans le sch\u00e9ma \u2014 vers le Logging Backend). L'agent fonctionne sur chaque n\u0153ud et est g\u00e9n\u00e9ralement ex\u00e9cut\u00e9 dans Kubernetes.<\/p>\n

<\/p>\n

Examinons maintenant les outils de journalisation.<\/p>\n

<\/p>\n

Grafana Loki<\/h2>\n

<\/p>\n

Grafana Loki<\/a><\/noindex> est apparu r\u00e9cemment, mais il est d\u00e9j\u00e0 devenu assez connu. Ses avantages : installation facile, consommation minimale de ressources, pas besoin d'installer Elasticsearch, car il stocke les donn\u00e9es dans une TSDB (base de donn\u00e9es de s\u00e9ries temporelles). Dans l'article pr\u00e9c\u00e9dent, j'ai mentionn\u00e9 que Prometheus stocke des donn\u00e9es dans ce type de base, et c'est l'une des nombreuses similitudes entre les deux produits. Les d\u00e9veloppeurs affirment m\u00eame que Loki est le \u00ab Prometheus du monde de la journalisation \u00bb.<\/p>\n

<\/p>\n

Une petite parenth\u00e8se sur la TSDB pour ceux qui n'ont pas lu. l'article pr\u00e9c\u00e9dent<\/a><\/noindex>: La TSDB excelle dans la t\u00e2che de stockage d'un grand nombre de donn\u00e9es, de s\u00e9ries temporelles, mais elle n'est pas con\u00e7ue pour un stockage \u00e0 long terme. Si, pour une raison quelconque, vous devez conserver les journaux plus de deux semaines, il est pr\u00e9f\u00e9rable d'organiser leur transfert vers une autre base de donn\u00e9es.<\/p>\n

<\/p>\n

Un autre avantage de Loki est que les donn\u00e9es sont visualis\u00e9es \u00e0 l'aide de Grafana. C'est tr\u00e8s pratique : dans Grafana, nous consultons les donn\u00e9es de surveillance et l\u00e0 m\u00eame, en connectant Loki, nous consultons les journaux. Des graphiques peuvent \u00eatre construits \u00e0 partir des journaux.<\/p>\n

<\/p>\n

L'architecture de Loki ressemble \u00e0 ceci : <\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

\u00c0 l'aide de DaemonSet, un agent - Promtail ou Fluent Bit - est d\u00e9ploy\u00e9 sur tous les serveurs du cluster. L'agent collecte les journaux. Loki les r\u00e9cup\u00e8re et les stocke dans la TSDB. Les journaux sont imm\u00e9diatement compl\u00e9t\u00e9s par des m\u00e9tadonn\u00e9es, ce qui est pratique : il est possible de filtrer par Pods, namespaces, noms de conteneurs et m\u00eame par labels.<\/p>\n

<\/p>\n

Instructions d'installation de Loki<\/a><\/noindex><\/p>\n

<\/p>\n

Loki fonctionne dans une interface connue de Grafana. Loki a m\u00eame son propre langage de requ\u00eates, appel\u00e9 LogQL - qui ressemble par son nom et sa syntaxe \u00e0 PromQL dans Prometheus. L'interface de Loki propose des suggestions de requ\u00eates, il n'est donc pas obligatoire de les conna\u00eetre par c\u0153ur.<\/p>\n

<\/p>\n

Documentation du langage LogQL<\/a><\/noindex><\/p>\n

<\/p>\n

\"Journalisation
\nLoki dans l'interface Grafana<\/em><\/p>\n

<\/p>\n

En utilisant des filtres, dans Loki, vous pouvez trouver des codes (\u00ab 400 \u00bb, \u00ab 404 \u00bb et tout autre) ; consulter les journaux de l'ensemble du n\u0153ud ; filtrer tous les journaux contenant le mot \u00ab erreur \u00bb. Si vous cliquez sur un journal, une carte s'ouvrira avec toutes les informations sur l'\u00e9v\u00e9nement.<\/p>\n

<\/p>\n

Loki dispose de suffisamment d'outils pour extraire les journaux n\u00e9cessaires, m\u00eame si, honn\u00eatement, techniquement, il pourrait y en avoir plus. Actuellement, Loki \u00e9volue rapidement et gagne en popularit\u00e9. <\/p>\n

<\/p>\n

Elastic + Fluent Bit + Kibana (EFK Stack)<\/h2>\n

<\/p>\n

La pile EFK est un outil de journalisation plus classique et tout aussi populaire. <\/p>\n

<\/p>\n

Au d\u00e9but de l'article, nous avons mentionn\u00e9 l'ELK (Elasticsearch + Logstash + Kibana), mais cette pile est devenue obsol\u00e8te en raison de Logstash, qui est peu performant et gourmand en ressources. \u00c0 la place, on a commenc\u00e9 \u00e0 utiliser Fluentd, plus l\u00e9ger et plus performant, et apr\u00e8s un certain temps, il a \u00e9t\u00e9 \u00e9paul\u00e9 par Fluent Bit<\/a><\/noindex> \u2014 un agent de collecte encore plus l\u00e9ger et plus performant. <\/p>\n

<\/p>\n

Selon les d\u00e9veloppeurs, Fluent Bit est plus de 100 fois meilleur en performance que Fluentd : \u00ab l\u00e0 o\u00f9 Fluentd consomme 20 Mo de RAM, Fluent Bit ne consommera que 150 Ko \u00bb \u2014 citation directe de la documentation. En tenant compte de cela, Fluent Bit a \u00e9t\u00e9 utilis\u00e9 plus fr\u00e9quemment.<\/p>\n

<\/p>\n

Fluent Bit a moins de fonctionnalit\u00e9s que Fluentd, mais il couvre les besoins fondamentaux, c'est donc ce que nous utilisons principalement.<\/p>\n

<\/p>\n

Le sch\u00e9ma de travail de la pile EFK : l'agent collecte les journaux de tous les pods (g\u00e9n\u00e9ralement, c'est un DaemonSet, lanc\u00e9 sur tous les serveurs du cluster) et les envoie \u00e0 un stockage (Elasticsearch, PostgreSQL ou Kafka). Kibana se connecte au stockage et extrait toutes les informations n\u00e9cessaires.<\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

Kibana<\/a><\/noindex> pr\u00e9sente les informations dans une interface web conviviale. Il y a des graphiques, des filtres et bien plus encore.<\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

Il est possible de cr\u00e9er des tableaux de bord complets \u00e0 partir des journaux.<\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

Fonctionnalit\u00e9s de Fluent Bit<\/h2>\n

<\/p>\n

\u00c9tant donn\u00e9 que Fluent Bit est en g\u00e9n\u00e9ral moins connu que Logstash, examinons-le un peu plus en d\u00e9tail. Fluent Bit peut \u00eatre logiquement divis\u00e9 en 6 modules, et certains modules peuvent \u00eatre \u00e9tendus avec des plugins qui augmentent les capacit\u00e9s de Fluent Bit.<\/p>\n

<\/p>\n

\"Journalisation<\/p>\n

<\/p>\n

Module d'entr\u00e9e<\/strong> collecte les journaux \u00e0 partir de fichiers, de services systemd et m\u00eame de tcp-socket (il suffit d'indiquer l'endpoint, et Fluent Bit commencera \u00e0 s'y connecter). Ces fonctionnalit\u00e9s sont suffisantes pour collecter les journaux du syst\u00e8me ainsi que des conteneurs.<\/p>\n

<\/p>\n

En production, nous utilisons le plus souvent les plugins tail<\/a><\/noindex> (il peut \u00eatre dirig\u00e9 vers un dossier contenant les journaux) et systemd<\/a><\/noindex> (il peut \u00eatre configur\u00e9 pour sp\u00e9cifier \u00e0 partir de quels services collecter les journaux).<\/p>\n

<\/p>\n

Module Parser<\/strong> met les journaux au format standard. Par d\u00e9faut, les journaux Nginx se pr\u00e9sentent sous forme de cha\u00eene. Avec un plugin, cette cha\u00eene peut \u00eatre convertie en JSON : il est possible de d\u00e9finir des champs et leurs valeurs. Travailler avec du JSON est beaucoup plus simple qu'avec des journaux sous forme de cha\u00eene, car cela offre des options de tri plus flexibles.<\/p>\n

<\/p>\n

Module Filter<\/strong>. \u00c0 ce niveau, les journaux inutiles sont filtr\u00e9s. Par exemple, seuls les journaux avec la valeur \"warning\" ou avec certaines \u00e9tiquettes sont envoy\u00e9s au stockage. Les journaux s\u00e9lectionn\u00e9s sont mis en m\u00e9moire tampon.<\/p>\n

<\/p>\n

Module Buffer<\/strong>. Fluent Bit dispose de deux types de m\u00e9moire tampon : un tampon en m\u00e9moire et un tampon sur disque. Le tampon est un espace de stockage temporaire pour les logs, utile en cas d'erreurs ou de pannes. Tout le monde souhaite \u00e9conomiser sur la RAM, c'est pourquoi on choisit g\u00e9n\u00e9ralement le tampon sur disque. Cependant, il faut garder \u00e0 l'esprit que, avant d'\u00eatre envoy\u00e9s sur disque, les logs sont tout de m\u00eame d\u00e9charg\u00e9s en m\u00e9moire.<\/p>\n

<\/p>\n

Module Routing\/Sortie<\/strong> contient des r\u00e8gles et des adresses pour l'envoi des logs. Comme mentionn\u00e9 pr\u00e9c\u00e9demment, il est possible d'envoyer des logs vers Elasticsearch, PostgreSQL ou, par exemple, Kafka. <\/p>\n

<\/p>\n

Il est int\u00e9ressant de noter que les logs de Fluent Bit peuvent \u00eatre envoy\u00e9s \u00e0 Fluentd. \u00c9tant donn\u00e9 que le premier est plus l\u00e9ger et moins fonctionnel, il peut collecter les logs et les envoyer \u00e0 Fluentd, o\u00f9, avec l'aide de plugins suppl\u00e9mentaires, ceux-ci peuvent \u00eatre trait\u00e9s et envoy\u00e9s vers des stockages.<\/p>\n

<\/p>\n

Si vous envisagez d'utiliser Elasticsearch...<\/p>\n

Enfin, deux conseils pour ceux qui pr\u00e9voient d'utiliser Elasticsearch comme stockage de logs en production. <\/p>\n

    \n
  1. Configurez des alertes avec ElastAlert<\/a><\/noindex>. Ce programme extrait des messages importants du flux g\u00e9n\u00e9ral des logs et envoie des alertes par email ou par d'autres canaux. Cependant, tout r\u00e9cemment, une triste nouvelle est tomb\u00e9e concernant la potentielle cessation d'activit\u00e9 du projet<\/a><\/noindex><\/em>.<\/li>\n
  2. Faites tourner les logs \u00e0 l'aide de l'application Curator<\/a><\/noindex> ou via l'API d'Elasticsearch. Elastic fait actuellement de grands pas vers la gestion de la dur\u00e9e de vie des index sans utiliser d'outils externes. En g\u00e9n\u00e9ral, il n'a pas de sens de conserver les logs longtemps : il est peu probable qu'un log soit n\u00e9cessaire apr\u00e8s deux semaines \u2014 s'il est vraiment critique, il aura certainement \u00e9t\u00e9 trait\u00e9 dans ce d\u00e9lai. En dernier recours, les anciens logs peuvent \u00eatre archiv\u00e9s et envoy\u00e9s quelque part pour un stockage \u00e0 long terme. J'ai entendu parler de logs particuliers qui, selon la loi, doivent \u00eatre conserv\u00e9s jusqu'\u00e0 5 ans. Personnellement, je ne me suis jamais retrouv\u00e9 dans cette situation, mais je ne consid\u00e9rerais pas ce type d'information comme des logs ordinaires, et il est m\u00eame possible que je les conserve s\u00e9par\u00e9ment.<\/li>\n<\/ol>\n

    \n<\/p><\/blockquote>\n

    La suite \u00e0 venir\u2026<\/p>\n

    <\/p>\n

    Auteur : Marsel Ibraev, administrateur Kubernetes certifi\u00e9, ing\u00e9nieur pratiquant chez Southbridge<\/a><\/noindex>, conf\u00e9rencier et d\u00e9veloppeur de cours Slurm<\/a><\/noindex>.<\/em><\/p>\n

    Source : habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0420\u0430\u0437\u0431\u0435\u0440\u0451\u043c \u043e\u0441\u043d\u043e\u0432\u044b \u043b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Docker \u0438 Kubernetes, \u0430 \u0437\u0430\u0442\u0435\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0434\u0432\u0430 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0436\u043d\u043e \u0441\u043c\u0435\u043b\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435: Grafana Loki \u0438 \u0441\u0442\u0435\u043a EFK (Elasticsearch + Fluent Bit + Kibana). \u041c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u0432\u044b\u0436\u0438\u043c\u043a\u0430 \u0438\u0437 \u043e\u0442\u043a\u0440\u044b\u0442\u043e\u0439 \u043b\u0435\u043a\u0446\u0438\u0438 \u0448\u043a\u043e\u043b\u044b \u00ab\u0421\u043b\u0451\u0440\u043c\u00bb. \u0415\u0441\u043b\u0438 \u0435\u0441\u0442\u044c \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u0438 \u0442\u0435\u043c \u0431\u043e\u043b\u0435\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0441\u0442\u044c \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u043e\u0439\u0442\u0438 \u043f\u043e\u043b\u043d\u043e\u0435 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u2014 \u0437\u0430\u043f\u0438\u0441\u044b\u0432\u0430\u0439\u0442\u0435\u0441\u044c \u043d\u0430 \u043a\u0443\u0440\u0441 \u043f\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93295,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93294","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Journalisation dans Kubernetes : comment collecter, stocker, analyser et traiter les logs | ProHoster","description":"Nous examinerons les bases de la journalisation dans Docker et Kubernetes, puis nous \u00e9tudierons deux outils que vous pouvez utiliser en production : Grafana Loki et la pile EFK (Elasticsearch + Fluent Bit + Kibana)..","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 Kubernetes: \u043a\u0430\u043a \u0441\u043e\u0431\u0438\u0440\u0430\u0442\u044c, \u0445\u0440\u0430\u043d\u0438\u0442\u044c, \u043f\u0430\u0440\u0441\u0438\u0442\u044c \u0438 \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u043b\u043e\u0433\u0438 | ProHoster","og:description":"\u0420\u0430\u0437\u0431\u0435\u0440\u0451\u043c \u043e\u0441\u043d\u043e\u0432\u044b \u043b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Docker \u0438 Kubernetes, \u0430 \u0437\u0430\u0442\u0435\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0434\u0432\u0430 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0436\u043d\u043e \u0441\u043c\u0435\u043b\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435: Grafana Loki \u0438 \u0441\u0442\u0435\u043a EFK (Elasticsearch + Fluent Bit + Kibana)..","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-05T05:42:58+00:00","article:modified_time":"2020-09-05T05:42:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"93294","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:50:29","updated":"2022-09-27 18:43:48","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/93294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=93294"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/93294\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/93295"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=93294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=93294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=93294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}