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.commailto: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.comhttp://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)
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/
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 :
-
Alexandre -
F00b 4rch -
frsag＠jack.fr.eu.org -
Hugo CLARIA -
Nathan delhaye