Comment avoir plusieurs flux de journaux dans Docker

Nous avons une application qui écrit trois types de journaux dans trois fichiers distincts: les journaux d'accès, les journaux d'application génériques et les journaux système. Le format (et le but) de ces journaux sont très différents. Et nous avons des gestionnaires de journaux distincts qui les envoient séparément à notre système de journalisation centralisé.

Sur la base du principe des journaux de traitement en tant que flux d'événements , nous envisageons de passer de l'utilisation de fichiers à la sortie standard. Bien que nous connaissions certains des avantages de cette approche, cela signifierait également que nous obtiendrions un flux fusionné des journaux de format différent, que nous aurions besoin de fractionner à nouveau avant de pouvoir les envoyer à notre système central (Kibana / Splunk / etc.), ou à l'intérieur.

Nous nous demandons s'il existe des outils ou des recommandations sur la façon d'aborder cette situation.

docker logging

— SztupY
source

Je ne pense pas que ça en vaille la peine. Pourquoi travailler plus dur pour fusionner puis diviser les flux de journaux, simplement à cause d'un "principe"? Les fichiers sont bons. Les fichiers fonctionnent. Cela semble trop ingénieux. Je dirais peut-être canaliser tous les journaux dans syslog, avec différentes balises, etc. mais je dois dire que si quelqu'un de mon équipe le suggérait, je serais .. déçu.

— Assaf Lavie

Parce que l'utilisation de fichiers a d'autres types de cauchemars de gestion, surtout s'ils sont générés à l'intérieur d'un conteneur Docker. Pour l'instant, il semble que les inconvénients du passage à stdout l'emportent sur les avantages de notre cas d'utilisation, mais nous avons déjà des problèmes avec notre approche basée sur les fichiers

— SztupY

Je ne connais pas les "cauchemars". Je sais que c'est ainsi que cela a été fait depuis un certain temps maintenant, et il existe de nombreux logiciels qui vous aident à le faire. Les fichiers journaux sont tournés, lus avec des points de contrôle - un fichier est une excellente abstraction pour cela. Je n'adhérerais pas à un principe qui me vend de nouveaux cauchemars par peur des vieux schémas familiers. Vos enregistrements de journal sont soit écrits dans un fichier, soit traités en mémoire (au moins tant qu'ils sont déplacés dans le conteneur). Bonne chance pour obtenir la fiabilité des fichiers journaux avec des répartiteurs et des fusions de flux en mémoire.

— Assaf Lavie

@AssafLavie Vous devriez l'écrire dans une réponse qui peut être votée. À mon humble avis, c'est un point de vue parfaitement valable.

— Dan Cornilescu

Je suis venu ici avec la même question. Le simple fait est que la fonctionnalité de journalisation intégrée de docker dépend de tout ce qui se passe sur stdout / stderr, d'où le pilote de journalisation et l'écosystème d'outils tiers qui se construisent autour de lui aussi. Je suis également tenté de vider tous mes journaux dans un volume hôte, mais je sais que je vais devoir continuer à revenir en arrière et à gérer cela lorsque mes conteneurs se déplacent vers k8s ou openshift ou gke ou autre chose, alors que si je suis le docker approche stdout ce sera beaucoup plus fluide. En attendant, je continuerai à chercher une réponse à cette question légitime

— Rhubarbe

Réponses:

Je suis toujours à la recherche d'une approche de fusion / fractionnement moi-même, mais en attendant, cette approche recommandée par la documentation de Kubernetes semble être une bonne solution: utilisez un conteneur de sidecar pour chacun de vos journaux séparés .

Un «sidecar» est un conteneur Docker que vous utilisez à côté d'un autre conteneur Docker pour travailler avec lui d'une manière ou d'une autre. Dans ce cas, pour chacun de vos trois journaux, vous auriez un conteneur séparé qui scanne ou enregistre les journaux et les renvoie vers stdout.

De cette façon, chacun de vos conteneurs log-sidecar a son propre docker-log à partir de sa propre sortie standard. Étant séparés comme celui-ci, vous pouvez utiliser des pratiques de docker standard (et kubernetes, etc.) pour séparer ou agréger. Voici ce que la page Kubernetes a à dire:

Cette approche vous permet de séparer plusieurs flux de journaux de différentes parties de votre application, dont certains peuvent ne pas prendre en charge l'écriture sur stdout ou stderr. La logique derrière la redirection des journaux est minime, ce n'est donc pas une surcharge importante. De plus, comme stdout et stderr sont gérés par le kubelet, vous pouvez utiliser des outils intégrés comme les journaux kubectl.

Les "flux de journaux séparés" proviennent du balisage intégré que docker applique aux journaux de différents conteneurs, décrit dans la documentation du docker ici:

L'option de journal des balises spécifie comment formater une balise qui identifie les messages de journal du conteneur. Par défaut, le système utilise les 12 premiers caractères de l'ID de conteneur. Pour remplacer ce comportement, spécifiez une option de balise

— Rhubarbe
source

Il convient de mentionner l'inconvénient de cette approche des conteneurs de log-side-car, citation: "Notez que, malgré une faible utilisation du processeur et de la mémoire, l'écriture de journaux dans un fichier puis leur diffusion sur stdout peut doubler l'utilisation du disque". Je me demande si quelqu'un essaie cette approche dans la pratique.

— yusong

L'idée de les fusionner en un seul flux juste pour les diviser plus tard semble douloureuse. Je n'ai pas eu de raison de le faire moi-même, mais voici où je commencerais:

Lorsque vous exécutez le conteneur Docker, créez un volume de sorte qu'il sera facile d'afficher / d'expédier les journaux de l'hôte.
Utilisez quelque chose comme remote_syslog2 pour envoyer les journaux à votre collecteur de journaux

Cela semble un peu moins qu'élégant de devoir également effectuer une configuration sur l'hôte, mais si vous utilisez quelque chose comme ansible où vous pouvez exécuter un playbook et le configurer pendant votre déploiement dans la boîte, cela ne devrait pas être trop mal.

— Bradym
source

Cette solution peut être combinée avec des canaux nommés, le seul problème avec les canaux nommés est qu'ils ne fonctionnent pas sur tous les systèmes en ce moment. Ils ne fonctionnent pas sur Mac

— Jens