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
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 Gir
Merci à tous pour vos retours, je regarde ça ASAP ! :-)
F00b4rch
Le 1 août 2017 à 10:36, Nathan delhaye 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 rsysl
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 ta
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,
nom de F00b 4rch
Date : mardi 1 août 2017 à 09:06
À : "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
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-s
Bonjour,
Pour info j'ai privilégié UDP de mon côté pour les syslogs.
Également j'ai vite été limité niveau vitesse avec le mode list de redis (perte
de log constaté). Je suis en mode channel. (1 Milliard de log par jour)
Si besoin je peux fournir les conf.
My2cts.
Nicolas Girardi.
> Le 30 mars
Bonsoir à tous,
j'ai eu beaucoup de demande en off pour avoir quelques infos sur ce qui
a été fait. J'ai mis des infos sur un github :
https://github.com/opendocnet/elk/wiki/Infrastructure-Elasticsearch-Logstash-Kibana
C'est sans prétention, c'est juste histoire d'avoir une trace de tous
les éch
Après avoir lu vos mails, il semblerait que j'ai un peu sous estimé le
projet sur la partie scalable et perf.
Je vais tester :
- rsyslog en natif
- fluentd en alternative avec logstash (info Stéphane Cottin)
- kafka (info Raphael Mazelier)
- [Client rsyslog] --> [logstash shipper (redis pour
Tout dépend ce que tu veux logguer et combien de temps, mais chez nous
on utilise un mix d'un peu tout en fonction des besoins :
- logbeam -> redis <- ELK (quand on a de l'applicatif legacy) : très
consommateur, logbeam est correct, logstash horrible, Kibana très
pratique (mais attention aux v
Bonjour;
C'est que j'ai mis en place.
[Client rsyslog] --> [logstash shipper (redis pour la perf) --> logstash
indexer] --> [ES]
Ca fonctionne parfaitement.
J´index un demi milliard de log (srv, fw, mysql queries) par jour.
A+
Nicolas Girardi.
> Le 6 févr. 2017 à 15:01, fr...@jack.fr.eu.org a
Le 06/02/2017 à 16:27, Stéphane Cottin a écrit :
fluentd est une alternative possible à logstash, beaucoup + léger.
Intéressant !
Un peu HS aussi, mais petit retour d'EX ELK :
Après avoir utilisé pendant pas mal de temps ELK, on en est revenu car
la base devenait énorme. Je l'ai sûrement
J'aime bien avoir la main mon infra car j'ai le temps pour bien bosser.
La doc semble intéressante.
On Mon, 6 Feb 2017 15:28:41 +0100
Pierre De Paepe wrote:
> Bonjour,
>
> (Désolé pour la pub, mais vous verrez, elle a du sens).
>
> Nous proposons chez OVH la stack ELK avec l'hébergement dédié
fluentd est une alternative possible à logstash, beaucoup + léger.
Chez nous on envoi tout ce qui est applicatif directement à fluentd en
json et au format natif lorsque c'est possible, et sinon au format
syslog pour les apps legacy.
De même pour nginx , haproxy, etc ... qui supportent syslog
Cette technique me convient. J'ai plus qu'a versionner et push de la
conf dans /etc/rsyslog.d/ et restart. J'aime bien cette technique.
On Mon, 6 Feb 2017 15:01:36 +0100
fr...@jack.fr.eu.org wrote:
> Mon idée pour l'instant (qui n'est pas fini de concevoir, et donc pas
> en prod), c'est d'utilis
Lu en diagonal:
http://www.rsyslog.com/doc/v8-stable/tutorials/reliable_forwarding.html
http://www.rsyslog.com/doc/v8-stable/configuration/modules/imrelp.html
On 06/02/2017 15:50, Alexandre wrote:
> J'avais vu cette méthode ou le logstash peut écouter directement sur le
> 514 et capter l'info. Je
J'avais vu cette méthode ou le logstash peut écouter directement sur le
514 et capter l'info. Je ne sais pas si c'est mieux de configurer le
rsyslog en mode serveur et de donner les logs à manger à logstash.
D'ailleurs en cas de coupure réseau, rsyslog bufferise un peu ?
Alex.
On Mon, 6 Feb 2017
Bonjour,
(Désolé pour la pub, mais vous verrez, elle a du sens).
Nous proposons chez OVH la stack ELK avec l'hébergement dédié de vos
logstash(s) sous le nom "Logs Data Platform".
Page produit: https://www.ovh.com/fr/data-platforms/logs/
Doc logstash dédié:
https://docs.ovh.com/gb/en/mobile-host
Mon idée pour l'instant (qui n'est pas fini de concevoir, et donc pas en
prod), c'est d'utiliser rsyslog sur toutes les machines
Sur un serveur centralisé, je récupére l'ensemble des logs, format
"classique", et je pousse les informations que je juge nécessaire dans ELK
Les avantages:
- rsyslog e
On utilise aussi bien rsyslog que syslog-ng les 2 ont le même genre de
fonctionnalités (ex : insertion sql, mais ça mange du cpu ...)
mais on peut aussi configurer le syslog original pour renvoyer les
message au format syslog (!) vers un ou plusieurs serveurs dédié a cette
tache.
Le 06/02/2017 à
Le 06/02/2017 à 14:44, Alexandre a écrit :
> Bonjour à tous,
>
> je pense que se sujet a été abordés plusieurs fois mais je n'ai pas
> trouvé d'informations.
>
> Nous souhaitons centraliser nos logs (applicatifs, systèmes ...). Nous
> avons maquetté une solution standard avec Elasticsearh + Logs
Bonjour ,
il me semble que la solution que vous pourrez trouver dans
https://www.artofmonitoring.com/ est adaptee
vous ne pourrez pas l'utiliser "as is" mais je pense que vous pourrez
vous en inspirer .
Je recommande la lecture de ce livre a tous
Bonne journee
IS
On 2017-02-06 14:44, Al
Bonjour à tous,
je pense que se sujet a été abordés plusieurs fois mais je n'ai pas
trouvé d'informations.
Nous souhaitons centraliser nos logs (applicatifs, systèmes ...). Nous
avons maquetté une solution standard avec Elasticsearh + Logstash +
Kibana. Le trio fonctionne très bien, nous créons
24 matches
Mail list logo
