Centralisation de logs applicatif Docker/Rancher
Bonjour, Nous sommes en train de monter une nouvelle infra complètement «dockerisé» avec rancher (et actuellement cattle en orchestrateur, on kubernetes après). Je souhaiterai savoir si certains d'entre vous avait déjà mis en place une solution de centralisation de logs sous du clustering micro-services (plus particulièrement du log applicatif du STDOUT des conteneurs). Je compte monter un ELK mais peut-être avez vous vos propres retours d'XP ? J'ai peur qu'avec ce type de solution on s'éloigne de l'idéologie d'applicatif conteneurisée. Je prends tout, docs, articles, témoignages... Merci à vous, F00b4rch
Bonjour, De notre côté sur Kubernetes nous utilisons ceci https://crondev.com/elk-stack-kubernetes/ Concrètement cela lance : - Un elasticsearch (il n’y a pas je crois la notion de scale out, un seul nœud est lancé et je pense qu’il faut une petite adaptation à base de sidecars pour permettre le clustering et l’ajout de nouveaux nœuds à la volée) - Un Kibana (automatiquement plugué sur l’elasticsearch grâce à une ConfigMap savamment formatée) - *DES* filebeats (C’est un Daemon Set donc il en lance 1 par minion Kubernetes, avec un montage bindé sur /var/log/containers et /var/log/pods et /var/lib/docker/containers) - Un logstash Coup de bol c’est bien dans ces deux premiers emplacements que STDOUT est logué sur les minions. Logstash est automatiquement configuré avec Grok pour mettre les bons indexes et les bons fields en accord avec le formatage des logs faits par les Kubelets. Pensez à éditer le YML de déploiement d’ElasticSearch : il n’est pas production ready et vous perdrez toutes les données embasées à chaque reboot du container puisqu’il vous laisse le soin d’y ajouter ce qu’il manque pour placer les données dans un volume persistant. L’avantage c’est que c’est natif, on ne touche pas aux containers et micro services tournant sur le cluster pour les rendre capable de shipper leur logs, c’est filebeat qui le fait en allant fouiner dans les emplacements ou les STDOUT sont logués sur les minions. Cela nous satisfait presque totalement ; il reste des applications qui loguent dans /var/log à l’intérieur du container au lieu de STDOUT et nous n’avons pas encore de solution aussi élégante pour ce cas de figure (sans toucher au code source des applications). Cordialement, Hugo CLARIA Directeur des Solutions Hébergées • 06.68.41.15.22 • h.claria@naitways.com<mailto:h.claria@naitways.com> Naitways SAS 20 rue Rouget de Lisle 92130 Issy-Les-Moulineaux : 01.84.16.85.30 (support heure ouvrées) : 01.83.64.04.27 (urgence, noc) www.naitways.com<http://www.naitways.com/> De : FRsAG <frsag-bounces@frsag.org> au nom de F00b 4rch <f00b4rch@gmail.com> Date : mardi 1 août 2017 à 09:06 À : "frsag@frsag.org" <frsag@frsag.org> Objet : [FRsAG] Centralisation de logs applicatif Docker/Rancher Bonjour, Nous sommes en train de monter une nouvelle infra complètement «dockerisé» avec rancher (et actuellement cattle en orchestrateur, on kubernetes après). Je souhaiterai savoir si certains d'entre vous avait déjà mis en place une solution de centralisation de logs sous du clustering micro-services (plus particulièrement du log applicatif du STDOUT des conteneurs). Je compte monter un ELK mais peut-être avez vous vos propres retours d'XP ? J'ai peur qu'avec ce type de solution on s'éloigne de l'idéologie d'applicatif conteneurisée. Je prends tout, docs, articles, témoignages... Merci à vous, F00b4rch
Hello! De mon côté, j'ai abandonné les filebeats, topbeast et autre metricsbeats. J'ai constaté du leak dans le temps donc j'ai viré ca. Un bon vieux syslog-ng (ou rsyslog si tu aime les features avancées ET la configuration vomitive) et un input syslog tcp sur logstash fait 10e6 fois mieux le taf et tu dispose de features sympa genre la possibilité de buffering sur le container source si le logstash de destination est down pour maintenance restart ou autre joyeuseté. C'est un peu plus de taf à la source, mais ca t'augmente bien la flexibilité par la suite A+ ! Le 1 août 2017 à 09:24, Hugo CLARIA <h.claria@naitways.com> a écrit :
**DES** filebeats (C’est un Daemon Set donc il en lance 1 par minion Kubernetes, avec un montage bindé sur /var/log/containers et /var/log/pods et /var/lib/docker/containers)
-- Nathan Delhaye
Merci à tous pour vos retours, je regarde ça ASAP ! :-) F00b4rch Le 1 août 2017 à 10:36, Nathan delhaye <contact@nathan-delhaye.fr> a écrit :
Hello!
De mon côté, j'ai abandonné les filebeats, topbeast et autre metricsbeats. J'ai constaté du leak dans le temps donc j'ai viré ca.
Un bon vieux syslog-ng (ou rsyslog si tu aime les features avancées ET la configuration vomitive) et un input syslog tcp sur logstash fait 10e6 fois mieux le taf et tu dispose de features sympa genre la possibilité de buffering sur le container source si le logstash de destination est down pour maintenance restart ou autre joyeuseté.
C'est un peu plus de taf à la source, mais ca t'augmente bien la flexibilité par la suite
A+ !
Le 1 août 2017 à 09:24, Hugo CLARIA <h.claria@naitways.com> a écrit :
**DES** filebeats (C’est un Daemon Set donc il en lance 1 par minion Kubernetes, avec un montage bindé sur /var/log/containers et /var/log/pods et /var/lib/docker/containers)
-- Nathan Delhaye
Salut, Y'a un eu thread complet sur le sujet cette année, consulte les archives, y'a plein d'info Pour ma part: - elasticsearch en backend, graylog en frontend - chaque serveur dispose d'un rsyslog configuré correctement - docker log dans syslog On 01/08/2017 09:06, F00b 4rch wrote:
Bonjour,
Nous sommes en train de monter une nouvelle infra complètement «dockerisé» avec rancher (et actuellement cattle en orchestrateur, on kubernetes après).
Je souhaiterai savoir si certains d'entre vous avait déjà mis en place une solution de centralisation de logs sous du clustering micro-services (plus particulièrement du log applicatif du STDOUT des conteneurs).
Je compte monter un ELK mais peut-être avez vous vos propres retours d'XP ? J'ai peur qu'avec ce type de solution on s'éloigne de l'idéologie d'applicatif conteneurisée.
Je prends tout, docs, articles, témoignages...
Merci à vous,
F00b4rch
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
j'avais beaucoup échangé avec la liste pour trouver une solution : - rsyslog en natif - fluentd en alternative avec logstash (info Stéphane Cottin) - kafka (info Raphael Mazelier) - [Client rsyslog] --> [logstash shipper (redis pour la perf) --> logstash indexer] --> [ES] (info Nicolas Girardi) https://ianunruh.com/2014/05/monitor-everything-part-2.html - shipper les logs avec filebeat (info Michel Blanc) https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html https://www.elastic.co/guide/en/beats/filebeat/current/configuring-ingest-no... - beats (info Pierrick Chovelon) https://www.elastic.co/products/beats A l'époque graylog n'était pas compatible ELK 5.X, du coup je suis resté sur une infra très standard : https://github.com/opendocnet/elk/wiki/Infrastructure-Elasticsearch-Logstash... Il manque beaucoup de chose, mais ca peut dégrossir les choses et tu peux l'adapter à ton besoin. On souhaite aussi dockeriser notre environnement. N'hésite pas à partager ton expérience. Alex. On Tue, 1 Aug 2017 09:06:06 +0200 F00b 4rch <f00b4rch@gmail.com> wrote:
Bonjour,
Nous sommes en train de monter une nouvelle infra complètement «dockerisé» avec rancher (et actuellement cattle en orchestrateur, on kubernetes après).
Je souhaiterai savoir si certains d'entre vous avait déjà mis en place une solution de centralisation de logs sous du clustering micro-services (plus particulièrement du log applicatif du STDOUT des conteneurs).
Je compte monter un ELK mais peut-être avez vous vos propres retours d'XP ? J'ai peur qu'avec ce type de solution on s'éloigne de l'idéologie d'applicatif conteneurisée.
Je prends tout, docs, articles, témoignages...
Merci à vous,
F00b4rch
En aparté, graylog supporte ES 5.X (etc) depuis aujourd'hui :p https://www.graylog.org/blog/98-announcing-graylog-v2-3-0 On 01/08/2017 16:43, Alexandre wrote:
A l'époque graylog n'était pas compatible ELK 5.X, du coup je suis resté sur une infra très standard :
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
participants (5)
-
Alexandre -
F00b 4rch -
frsag＠jack.fr.eu.org -
Hugo CLARIA -
Nathan delhaye