Re: [FRnOG] [TECH] Collecteur de logs réseau

[Nathan delhaye]

Le mar. 20 nov. 2018 à 09:22, Duchet Rémy  a écrit :

> Par ici on gère avec ELK. Les logs sont insérés avec le minimum de
> traitement, et ensuite c'est un ou plusieurs daemon qui vont utiliser les
> API d'ELK pour extraire les infos avec des requêtes particulières et gérer
> le nombre d'occurrence pour déclencher des actions.
> C'est stable et très rapide malgré la volumétrie, et ça permet de gérer
> pas mal de scénario.
>
> Rémy
>


Hello,

@job on utilise également de l'ELK et je plussoie.

Petit warning pour les gens qui s'amuseraient à déployer ça autre part que
sur du bare-metal, ES est assez gourmant en IOPS quand tu scale-up. Donc
sur une infra ou les IOPS sont chères (a peu près tous les clouds
publics...) ça peux être un problème.

Pour 400 logs/sec en moyenne avec des pics à 15k logs/sec sur 3 nodes avec
des disques capés à 3000 iops ça passe juste. Et quand on a besoin de lire
sur une durée un peu longue (1 semaine par ex) ça galère un peu (~10 sec /
req).

@job-1 j'avais mis ça sur 3 serveurs avec des disques Nvme 150kIOps et 32GB
de RAM et après un peu de tunning et avec la bonne politique de rétention
(Voir: Elastic curator),  je n'en ai plus jamais entendu parler, le truc
ronronnais dans son coin.

-- 
Nathan Delhaye

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[fayçal noushi]

+1 Pour ELK (avec Fluentd au lieu de Logstash). Ca marche assez bien pour
de grands volumes
Comme alternative à leurs modules X-Pack, y a des plugins opensource type
Elastalert/Sentinl...
Je l'utilise pour des logs système, réseau et applicatifs sur différents
indexes. Ca se passe assez bien jusque là :)



On Tue, Nov 20, 2018 at 8:22 AM Duchet Rémy  wrote:

> Par ici on gère avec ELK. Les logs sont insérés avec le minimum de
> traitement, et ensuite c'est un ou plusieurs daemon qui vont utiliser les
> API d'ELK pour extraire les infos avec des requêtes particulières et gérer
> le nombre d'occurrence pour déclencher des actions.
> C'est stable et très rapide malgré la volumétrie, et ça permet de gérer
> pas mal de scénario.
>
> Rémy
>
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Raphael Mazelier
> Envoyé : lundi, 19 novembre 2018 18:38
> À : frnog@frnog.org
> Objet : Re: [FRnOG] [TECH] Collecteur de logs réseau
>
>
>
> > * "port_x_connected=false"
> > * "port_x_disconnection_count=42"
> > * "user_x_logged=true"
> > * "user_x_login_count=666"
>
> C'est l'idée oui.
>
> >
> > Soit parce qu'on a pas le contrôle sur le générateur de l'événement
> > (équipement fermé) soit parce qu'on pense que ça n'est pas à
> > l'application instrumenté de se souvenir des événements -nombre
> > d'authentification- pour les transformer en métriques).
> >
> > Donc je me demande si vous n'auriez pas 2/3 suggestions de solution
> > (logiques ou logicielles) à ce "problème"...
> >
>
> Je n'ai pas trouvé, mais cela semble assez trivial de coder un snmptrap to
> prometheus. Ca doit pouvoir se coder en 100 lignes de python ou go.
>
> Cdt,
>
> --
> Raphael Mazelier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
NOUSHI Fayçal
GSM : +212 661 56 03 37

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Collecteur de logs réseau

[Duchet Rémy]

Par ici on gère avec ELK. Les logs sont insérés avec le minimum de traitement, 
et ensuite c'est un ou plusieurs daemon qui vont utiliser les API d'ELK pour 
extraire les infos avec des requêtes particulières et gérer le nombre 
d'occurrence pour déclencher des actions.
C'est stable et très rapide malgré la volumétrie, et ça permet de gérer pas mal 
de scénario.

Rémy 

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Raphael 
Mazelier
Envoyé : lundi, 19 novembre 2018 18:38
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Collecteur de logs réseau



> * "port_x_connected=false"
> * "port_x_disconnection_count=42"
> * "user_x_logged=true"
> * "user_x_login_count=666"

C'est l'idée oui.

> 
> Soit parce qu'on a pas le contrôle sur le générateur de l'événement 
> (équipement fermé) soit parce qu'on pense que ça n'est pas à 
> l'application instrumenté de se souvenir des événements -nombre
> d'authentification- pour les transformer en métriques).
> 
> Donc je me demande si vous n'auriez pas 2/3 suggestions de solution 
> (logiques ou logicielles) à ce "problème"...
> 

Je n'ai pas trouvé, mais cela semble assez trivial de coder un snmptrap to 
prometheus. Ca doit pouvoir se coder en 100 lignes de python ou go.

Cdt,

--
Raphael Mazelier


---
Liste de diffusion du FRnOG
http://www.frnog.org/


smime.p7s
Description: S/MIME cryptographic signature

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Raphael Mazelier]

* "port_x_connected=false"
* "port_x_disconnection_count=42"
* "user_x_logged=true"
* "user_x_login_count=666"


C'est l'idée oui.



Soit parce qu'on a pas le contrôle sur le générateur de l'événement
(équipement fermé) soit parce qu'on pense que ça n'est pas à
l'application instrumenté de se souvenir des événements -nombre
d'authentification- pour les transformer en métriques).

Donc je me demande si vous n'auriez pas 2/3 suggestions de solution
(logiques ou logicielles) à ce "problème"...



Je n'ai pas trouvé, mais cela semble assez trivial de coder un snmptrap 
to prometheus. Ca doit pouvoir se coder en 100 lignes de python ou go.


Cdt,

--
Raphael Mazelier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Kirth Gersen]

 +1 pour ne pas confondre 'time series" (TSDB) fait pour accumuler des metrics 
(compteurs,etc) genre utilisation cpu ou température avec l'indexation et le 
stockage de logs (document database).

Sinon pour convertir des logs en metrics, il y a mtail  ( 
https://github.com/google/mtail ) ou grok-exporter ( 
https://github.com/fstab/grok_exporter )

mtail est particulièrement simple et efficace, on peut matcher la chaine 'Port 
x disconnected' par exemple pour extraire le 'x' et en faire un metric.

On Mon, Nov 19, 2018 at 2:39 AM DUVERGIER Claude 
mailto:frnog...@claude.duvergier.fr>> wrote:
Je m'incruste...

> Comme je disais il ne faut pas. Il faudrait plutôt commencer par
> transformer tes logs/déclencheurs en métriques. Après tout devient
> plus clair.

Je suis assez d'accord avec cette idée mais il n'est pas toujours aisé
de transformer un message d'événement :
* "Port x disconnected"
* "User x logged-in"
* etc.

En métrique :
* "port_x_connected=false"
* "port_x_disconnection_count=42"
* "user_x_logged=true"
* "user_x_login_count=666"

Soit parce qu'on a pas le contrôle sur le générateur de l'événement
(équipement fermé) soit parce qu'on pense que ça n'est pas à
l'application instrumenté de se souvenir des événements -nombre
d'authentification- pour les transformer en métriques).

Donc je me demande si vous n'auriez pas 2/3 suggestions de solution
(logiques ou logicielles) à ce "problème"...

--
Duvergier Claude

Le 18/11/2018 à 17:41, Raphael Mazelier a écrit :
>
>>
>> Pas d'accord. ES est tellement plus gourmand, en stockage, IO et CPU,
>> par rapport à une time-series basique, que c'est totalement
>> disproportionné.
>
> Désolé mon petit José mais je crois qu'on confond un peu tout la ;)
>
> ES et une TSDB ce sont bien évidement deux type d'outils complètement
> différends qui sont parfois employé/dévoyé de leur fonction originale.
>
>
> En très gros résumé :
>
> - on stocke des métriques dans un tsdb et on fait des graphs et de
> l'alerting avec. Prometheux/Influxdb sont les candidats du moment.
>
> - on on stocke des documents indexés dans ES, parfait pour stocker des
> logs structurés et faire des queries dedans.
>
> Ce qui embrouille tout c'est que l'on essaye de faire des graphs et de
> l'alerting avec des logs, ce qui est théoriquement assez faux.
>
>>
>> C'est pratique à mettre en place et exploitable à petite échelle, mais
>> à mon avis pas satisfaisant dès que tu as une vraie prod. Et je suis
>> vraiment preneur d'avis dessus, vu que je vais devoir y bosser à
>> nouveau prochainement.
>
> ES est le truc le plus scalable du monde. Je connais des petites société
> smart qui exploitent sereinement des clusters de plusieurs Peta.
>
>>
>> Reste à assurer la corrélation d’évènements, et le déclenchement
>> d'alertes sur certains combos, mais là on rentre dans du compliqué.
>> Tendance obligatoirement du code custom. Sauf si vous avez trouvé
>> autre chose ?
>
> Comme je disais il ne faut pas. Il faudrait plutôt commencer par
> transformer tes logs/déclencheurs en métriques. Après tout devient plus
> clair.
>
> Cdt,
>
> --
> Raphael Mazelier
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[DUVERGIER Claude]

Je m'incruste...

> Comme je disais il ne faut pas. Il faudrait plutôt commencer par
> transformer tes logs/déclencheurs en métriques. Après tout devient
> plus clair.

Je suis assez d'accord avec cette idée mais il n'est pas toujours aisé
de transformer un message d'événement :
* "Port x disconnected"
* "User x logged-in"
* etc.

En métrique :
* "port_x_connected=false"
* "port_x_disconnection_count=42"
* "user_x_logged=true"
* "user_x_login_count=666"

Soit parce qu'on a pas le contrôle sur le générateur de l'événement
(équipement fermé) soit parce qu'on pense que ça n'est pas à
l'application instrumenté de se souvenir des événements -nombre
d'authentification- pour les transformer en métriques).

Donc je me demande si vous n'auriez pas 2/3 suggestions de solution
(logiques ou logicielles) à ce "problème"...

-- 
Duvergier Claude

Le 18/11/2018 à 17:41, Raphael Mazelier a écrit :
> 
>>
>> Pas d'accord. ES est tellement plus gourmand, en stockage, IO et CPU,
>> par rapport à une time-series basique, que c'est totalement
>> disproportionné.
> 
> Désolé mon petit José mais je crois qu'on confond un peu tout la ;)
> 
> ES et une TSDB ce sont bien évidement deux type d'outils complètement
> différends qui sont parfois employé/dévoyé de leur fonction originale.
> 
> 
> En très gros résumé :
> 
> - on stocke des métriques dans un tsdb et on fait des graphs et de
> l'alerting avec. Prometheux/Influxdb sont les candidats du moment.
> 
> - on on stocke des documents indexés dans ES, parfait pour stocker des
> logs structurés et faire des queries dedans.
> 
> Ce qui embrouille tout c'est que l'on essaye de faire des graphs et de
> l'alerting avec des logs, ce qui est théoriquement assez faux.
> 
>>
>> C'est pratique à mettre en place et exploitable à petite échelle, mais
>> à mon avis pas satisfaisant dès que tu as une vraie prod. Et je suis
>> vraiment preneur d'avis dessus, vu que je vais devoir y bosser à
>> nouveau prochainement.
> 
> ES est le truc le plus scalable du monde. Je connais des petites société
> smart qui exploitent sereinement des clusters de plusieurs Peta.
> 
>>
>> Reste à assurer la corrélation d’évènements, et le déclenchement
>> d'alertes sur certains combos, mais là on rentre dans du compliqué.
>> Tendance obligatoirement du code custom. Sauf si vous avez trouvé
>> autre chose ?
> 
> Comme je disais il ne faut pas. Il faudrait plutôt commencer par
> transformer tes logs/déclencheurs en métriques. Après tout devient plus
> clair.
> 
> Cdt,
> 
> -- 
> Raphael Mazelier
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Raphael Mazelier]

Pas d'accord. ES est tellement plus gourmand, en stockage, IO et CPU, 
par rapport à une time-series basique, que c'est totalement 
disproportionné.


Désolé mon petit José mais je crois qu'on confond un peu tout la ;)

ES et une TSDB ce sont bien évidement deux type d'outils complètement 
différends qui sont parfois employé/dévoyé de leur fonction originale.



En très gros résumé :

- on stocke des métriques dans un tsdb et on fait des graphs et de 
l'alerting avec. Prometheux/Influxdb sont les candidats du moment.


- on on stocke des documents indexés dans ES, parfait pour stocker des 
logs structurés et faire des queries dedans.


Ce qui embrouille tout c'est que l'on essaye de faire des graphs et de 
l'alerting avec des logs, ce qui est théoriquement assez faux.




C'est pratique à mettre en place et exploitable à petite échelle, mais à 
mon avis pas satisfaisant dès que tu as une vraie prod. Et je suis 
vraiment preneur d'avis dessus, vu que je vais devoir y bosser à nouveau 
prochainement.


ES est le truc le plus scalable du monde. Je connais des petites société 
smart qui exploitent sereinement des clusters de plusieurs Peta.




Reste à assurer la corrélation d’évènements, et le déclenchement 
d'alertes sur certains combos, mais là on rentre dans du compliqué. 
Tendance obligatoirement du code custom. Sauf si vous avez trouvé autre 
chose ?


Comme je disais il ne faut pas. Il faudrait plutôt commencer par 
transformer tes logs/déclencheurs en métriques. Après tout devient plus 
clair.


Cdt,

--
Raphael Mazelier



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Jérôme Nicolle]

Plop,

Le 16/11/2018 à 14:42, Raphael Mazelier a écrit :

ES est parfait pour cela


Pas d'accord. ES est tellement plus gourmand, en stockage, IO et CPU, 
par rapport à une time-series basique, que c'est totalement disproportionné.


C'est pratique à mettre en place et exploitable à petite échelle, mais à 
mon avis pas satisfaisant dès que tu as une vraie prod. Et je suis 
vraiment preneur d'avis dessus, vu que je vais devoir y bosser à nouveau 
prochainement.


Reste à assurer la corrélation d’évènements, et le déclenchement 
d'alertes sur certains combos, mais là on rentre dans du compliqué. 
Tendance obligatoirement du code custom. Sauf si vous avez trouvé autre 
chose ?


@+

--
Jérôme Nicolle
+33 6 19 31 27 14


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Collecteur de logs réseau

[Xavier ROCA]

C'était pour illustré un truc open source super simple et visuel, Monsieur le 
Windowphobe.
Il te reste juste à le porter sous ta distri préféré :)
Ou effectivement à te contenter d'un simple collecteur comme syslog-ng, l'autre 
avait l'air dans faire quand même un peu plus.
Tu peux aussi durci ton Windows en faisant ta version via Embedded/IoT, je vois 
déjà d'ici ton éruption cutané :))

Ou alors un truc plus complet que demandé comme Icinga 2, c'est sympa avec ses 
REST API, Modules, intégrations, CLI ...


-Message d'origine-
De : David Ponzone  
Envoyé : samedi 17 novembre 2018 10:12
À : Xavier ROCA 
Cc : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Collecteur de logs réseau

Euh…moi et Windows, c’est compliqué :)
Et puis ça, je peux le faire avec un syslog-ng/rsyslog, qui ne tombera JAMAIS 
(allez, une fois tous les 5/10 ans).


> Le 16 nov. 2018 à 13:54, Xavier ROCA  a écrit :
> 
> Salut David,
> 
> Et pourquoi pas un syslog opensource du style :
> https://sourceforge.net/projects/syslogserverwindows/
> pas testé
> 
> sur des besoins simple c'est largement suffisant. Je trouve juste qu'il 
> toujours un truc dans ceux que j'ai pu tester.
> C'est bien de recevoir une alerte sur certains log mais ce qui serait sympa 
> ce serait d'avoir aussi une alerte si on ne revoit rien de la part d'un 
> équipement sur une période donnée..
> Et avec de l'auto apprentissage ce serait fabuleux ...
> 
> Xavier
> 
> 
> -Message d'origine-
> De : David Ponzone  Envoyé : vendredi 16 
> novembre 2018 10:18 À : frnog-tech  Objet : 
> [FRnOG] [TECH] Collecteur de logs réseau
> 
> Je me pose des questions existentielles pour trouver LE collecteur de logs 
> réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
> faible et peu critique.
> J’utilisais un peu Splunk Free, mais depuis une mise à jour récente, ils 
> montrent des signes de vouloir rendre la version free useless. En plus, j’ai 
> perdu les données existantes pendant l’opération, ce qui m’a enlevé toute 
> envie de bosser avec eux.
> Le nom qui vient ensuite, c’est ELK (ou Graylog), mais j’ai un peu peur de 
> l’usine à gaz basée sur Java. Dans mon cas, ça doit être outil, pas un truc 
> qui prend du temps à maintenir.
> Et je me demande si l’usage en VM est envisageable (d’après leur doc, on 
> parle plutôt de baremetal et SSD).
> En OpenSource, j’ai rien vu d’autres qui m’a sauté aux yeux.
> 
> En SaaS, il y a Papertrail qui semble sympathique, avec un pricing 
> progressif, et une version free pas trop limitée pour débuter.
> Et Logz.io <http://logz.io/>, qui permet de disposer d’ELK, sans se prendre 
> la tête avec. La version Free a le mérite d’exister pour tester, mais 
> ensuite, le premier palier tarifaire est un peu brutal.
> 
> Si vous avez d’autres suggestions….
> SI certains ont envie de me donner envie de me lancer dans ELK, je 
> suis tout ouïe :)
> 
> PS: je sais que cela a déjà été abordé, mais ça bouge dans le domaine 
> (fin de Logscape, rachat de Rocana par Splunk, etc…)
> 
> Merci
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[David Ponzone]

Ouais, j’avais pas pensé à LibreNMS, pourtant j’en ai un.
Faut dire que depuis qu’il tourne, entre les updates automatiques qui cassent 
tout, et les snmpwalk un peu verbeux, je suis pas encore décidé à aller à fond 
dans le truc.

Mais je viens de tester l’envoi de syslog dedans, et ça remonte nickel.



> Le 16 nov. 2018 à 13:38, guénolé Delanoë  a écrit :
> 
> Hello,
> 
> Observium correspond bien a ton besoin, tu peux créer, matcher des patterns 
> (regex) puis notifier à partir de tes syslogs. Pour un faible volume de log, 
> Observium est une bonne solution. LibreNMS (open source) semble proposer les 
> mêmes fonctionnalités.
> 
> Concernant ELK, j'ai moi même fait des tests sur plusieurs VMs, ormi des 
> crash à cause du manque de RAM (merci java) j'avais une solution assez stable 
> et rapide à mettre en place. Le gros plus d'ElasticStack (ELK) c'est, bien 
> entendu, les graphs et les fonctionnalités avancées comme la corrélation de 
> log, les modules de machine learning etc.
> 
> Si tu as du temps à prendre pour t'amuser à faire des jolies graph/dashboard, 
> d'ElasticStack va incontestablement t'aider dans l'analyse de log mais si tu 
> veux juste monter un petit serveur regarde Observium/libreNMS.
> 
> My 2 cents
> G.D
> De : frnog-requ...@frnog.org <mailto:frnog-requ...@frnog.org> 
> mailto:frnog-requ...@frnog.org>> de la part de 
> David Ponzone mailto:david.ponz...@gmail.com>>
> Envoyé : vendredi 16 novembre 2018 10:18
> À : frnog-tech
> Objet : [FRnOG] [TECH] Collecteur de logs réseau
>  
> Je me pose des questions existentielles pour trouver LE collecteur de logs 
> réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
> faible et peu critique.
> J’utilisais un peu Splunk Free, mais depuis une mise à jour récente, ils 
> montrent des signes de vouloir rendre la version free useless. En plus, j’ai 
> perdu les données existantes pendant l’opération, ce qui m’a enlevé toute 
> envie de bosser avec eux.
> Le nom qui vient ensuite, c’est ELK (ou Graylog), mais j’ai un peu peur de 
> l’usine à gaz basée sur Java. Dans mon cas, ça doit être outil, pas un truc 
> qui prend du temps à maintenir.
> Et je me demande si l’usage en VM est envisageable (d’après leur doc, on 
> parle plutôt de baremetal et SSD).
> En OpenSource, j’ai rien vu d’autres qui m’a sauté aux yeux.
> 
> En SaaS, il y a Papertrail qui semble sympathique, avec un pricing 
> progressif, et une version free pas trop limitée pour débuter.
> Et Logz.io <http://logz.io/> <http://logz.io/ <http://logz.io/>>, qui permet 
> de disposer d’ELK, sans se prendre la tête avec. La version Free a le mérite 
> d’exister pour tester, mais ensuite, le premier palier tarifaire est un peu 
> brutal. 
> 
> Si vous avez d’autres suggestions….
> SI certains ont envie de me donner envie de me lancer dans ELK, je suis tout 
> ouïe :)
> 
> PS: je sais que cela a déjà été abordé, mais ça bouge dans le domaine (fin de 
> Logscape, rachat de Rocana par Splunk, etc…)
> 
> Merci
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ <http://www.frnog.org/>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[David Ponzone]

Euh…moi et Windows, c’est compliqué :)
Et puis ça, je peux le faire avec un syslog-ng/rsyslog, qui ne tombera JAMAIS 
(allez, une fois tous les 5/10 ans).


> Le 16 nov. 2018 à 13:54, Xavier ROCA  a écrit :
> 
> Salut David,
> 
> Et pourquoi pas un syslog opensource du style :
> https://sourceforge.net/projects/syslogserverwindows/
> pas testé
> 
> sur des besoins simple c'est largement suffisant. Je trouve juste qu'il 
> toujours un truc dans ceux que j'ai pu tester.
> C'est bien de recevoir une alerte sur certains log mais ce qui serait sympa 
> ce serait d'avoir aussi une alerte si on ne revoit rien de la part d'un 
> équipement sur une période donnée..
> Et avec de l'auto apprentissage ce serait fabuleux ...
> 
> Xavier
> 
> 
> -Message d'origine-
> De : David Ponzone  
> Envoyé : vendredi 16 novembre 2018 10:18
> À : frnog-tech 
> Objet : [FRnOG] [TECH] Collecteur de logs réseau
> 
> Je me pose des questions existentielles pour trouver LE collecteur de logs 
> réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
> faible et peu critique.
> J’utilisais un peu Splunk Free, mais depuis une mise à jour récente, ils 
> montrent des signes de vouloir rendre la version free useless. En plus, j’ai 
> perdu les données existantes pendant l’opération, ce qui m’a enlevé toute 
> envie de bosser avec eux.
> Le nom qui vient ensuite, c’est ELK (ou Graylog), mais j’ai un peu peur de 
> l’usine à gaz basée sur Java. Dans mon cas, ça doit être outil, pas un truc 
> qui prend du temps à maintenir.
> Et je me demande si l’usage en VM est envisageable (d’après leur doc, on 
> parle plutôt de baremetal et SSD).
> En OpenSource, j’ai rien vu d’autres qui m’a sauté aux yeux.
> 
> En SaaS, il y a Papertrail qui semble sympathique, avec un pricing 
> progressif, et une version free pas trop limitée pour débuter.
> Et Logz.io <http://logz.io/>, qui permet de disposer d’ELK, sans se prendre 
> la tête avec. La version Free a le mérite d’exister pour tester, mais 
> ensuite, le premier palier tarifaire est un peu brutal.
> 
> Si vous avez d’autres suggestions….
> SI certains ont envie de me donner envie de me lancer dans ELK, je suis tout 
> ouïe :)
> 
> PS: je sais que cela a déjà été abordé, mais ça bouge dans le domaine (fin de 
> Logscape, rachat de Rocana par Splunk, etc…)
> 
> Merci
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[David Ponzone]

Purée, j’étais tout excité en allant sur le site, c’était peut-être LA solution 
miracle , mais ça semble très orienté serveurs:
auto-discovery d’un serveur en installant un agent.

Je vois pas comment envoyer du syslog.

J’ai raté un truc ?


> Le 17 nov. 2018 à 09:59, Stéphane Rivière  a écrit :
> 
> Le 16/11/2018 à 10:18, David Ponzone a écrit :
>> Je me pose des questions existentielles pour trouver LE collecteur de logs 
>> réseau (collecte et envoi d’alertes à 
> 
> Alors oui, c'est saas...
> https://www.livemon.com
> Dev par un pilier du bar@ovh.
> 
> C'était juste pour compléter le panorama...
> 
> https://pascal.developpez.com/actu/127870/La-startup-francaise-LiveMon-mise-sur-Free-Pascal-pour-son-developpement-qu-est-ce-qui-justifie-ce-choix
> 
> -- 
> Stéphane Rivière
> Ile d'Oléron - France
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Stéphane Rivière]

Le 16/11/2018 à 10:18, David Ponzone a écrit :
Je me pose des questions existentielles pour trouver LE collecteur de logs réseau (collecte et envoi d’alertes à 


Alors oui, c'est saas...
https://www.livemon.com
Dev par un pilier du bar@ovh.

C'était juste pour compléter le panorama...

https://pascal.developpez.com/actu/127870/La-startup-francaise-LiveMon-mise-sur-Free-Pascal-pour-son-developpement-qu-est-ce-qui-justifie-ce-choix

--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[David Ponzone]

Maxime,

merde, je suis sur FRLawOG ? :)

Pas d’inquiétude, je sais ce que je vais enregistrer, et ça concerne pas les 
clients.
Et si ça devait les concerner, je me rapprocherai d’OVH dont les juristes ont 
forcément pris en compte la problématique non ?


> Le 16 nov. 2018 à 16:19, Maxime DERCHE  a écrit :
> 
> Bonjour,
> 
> Le 16/11/2018 à 15:55, David Ponzone a écrit :
>> Pattern de logs, oui.
>> 
>> Je pense que je vais tester logstash comme aggrégateur de syslog 
>> Cisco/Mikrotik/Juniper/… vers une stream unique GELF à destination de 
>> l’offre Graylog en SaaS d’OVH, qui a le bon goût d’avoir un pricing 
>> progressif sans singularités (ça va de 1€ à 9€/mois, oui oui, 90k€…), 
>> parfait pour un petit besoin.
> 
> Outch, un traitement de logs en SaaS...
> 
> Je peux me tromper, car les logs sont peut-être anonymisés avant traitement, 
> ce
> qui le sort du cadre du RGPD. Mais on traite rarement des logs anonymisés : la
> technique en a besoin pour recouper des sources d'emmerdes, et le business en 
> a
> besoin pour recouper des sources de brouzouf.
> 
> En imaginant qu'il y a des adresses IP et autre éléments d'identification
> directs ou indirects, et en imaginant que vous justifiiez le traitement par un
> consentement ou la nécessité en vue de l'exécution d'un contrat (dûment signé 
> au
> préalable, sinon il faut un avenant pour chaque client), il reste qu'en tant 
> que
> Responsable de Traitement, vous devrez :
>  * expliciter une finalité claire, justifiée et (presque) invariable dans 
> votre
> Registre des Traitements ;
>  * obtenir d'OVH (sous-traitant du traitement) de quoi justifier des mesures
> prises en vue de protéger les données, et annexer ce papier au Registre des
> Traitements.
> 
> Pour un simple test, ou un petit besoin, c'est déjà très lourd comme 
> préalable,
> non ?
> 
> 
> Bien cordialement,
> -- Maxime DERCHE
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Maxime DERCHE]

Bonjour,

Le 16/11/2018 à 15:55, David Ponzone a écrit :
> Pattern de logs, oui.
> 
> Je pense que je vais tester logstash comme aggrégateur de syslog 
> Cisco/Mikrotik/Juniper/… vers une stream unique GELF à destination de l’offre 
> Graylog en SaaS d’OVH, qui a le bon goût d’avoir un pricing progressif sans 
> singularités (ça va de 1€ à 9€/mois, oui oui, 90k€…), parfait pour un 
> petit besoin.

Outch, un traitement de logs en SaaS...

Je peux me tromper, car les logs sont peut-être anonymisés avant traitement, ce
qui le sort du cadre du RGPD. Mais on traite rarement des logs anonymisés : la
technique en a besoin pour recouper des sources d'emmerdes, et le business en a
besoin pour recouper des sources de brouzouf.

En imaginant qu'il y a des adresses IP et autre éléments d'identification
directs ou indirects, et en imaginant que vous justifiiez le traitement par un
consentement ou la nécessité en vue de l'exécution d'un contrat (dûment signé au
préalable, sinon il faut un avenant pour chaque client), il reste qu'en tant que
Responsable de Traitement, vous devrez :
  * expliciter une finalité claire, justifiée et (presque) invariable dans votre
Registre des Traitements ;
  * obtenir d'OVH (sous-traitant du traitement) de quoi justifier des mesures
prises en vue de protéger les données, et annexer ce papier au Registre des
Traitements.

Pour un simple test, ou un petit besoin, c'est déjà très lourd comme préalable,
non ?


Bien cordialement,
-- Maxime DERCHE


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Kirth Gersen]

l’agrégateur a la mode c'est https://www.fluentd.org/  (une des briques du 
https://www.cncf.io/projects/ ). voir ensuite les 'output' ou plugins qui 
conviendrai.

cdt

On Fri, Nov 16, 2018 at 3:56 PM David Ponzone 
http://gmail.com>> wrote:
Pattern de logs, oui.

Je pense que je vais tester logstash comme aggrégateur de syslog 
Cisco/Mikrotik/Juniper/… vers une stream unique GELF à destination de l’offre 
Graylog en SaaS d’OVH, qui a le bon goût d’avoir un pricing progressif sans 
singularités (ça va de 1€ à 9€/mois, oui oui, 90k€…), parfait pour un petit 
besoin.


> Le 16 nov. 2018 à 14:42, Raphael Mazelier 
> mailto:r...@futomaki.net>> a écrit :
>
> On 16/11/2018 10:18, David Ponzone wrote:
>> Je me pose des questions existentielles pour trouver LE collecteur de logs 
>> réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
>> faible et peu critique.
>
> Pour la collecte de log d'équipements réseaux tu n'as globalement pas le 
> choix d'utiliser le protocole syslog pour envoyer.
>
> Hormis les outils SAAS voici ce que je connais.
>
> En pur collecteur tu peux utiliser rsyslog/logstash/fluentd.
> Ensuite tu veux sans doute stocker tes logs dans un format qui permet 
> l'analyse. ES est parfait pour cela.
>
> Pour la gui Kibana evidement.
>
> Si tu veux une solution plus intégré essaye Graylog2, personnelement je 
> trouve cela assez sympa.
>
> En revanche pour l'alerting je ne sais pas ce que tu veux faire ?
> Alerting sur les trap snmp ? Alerting sur des patterns de logs ?
>
>
>
> Cdt,
>
> --
> Raphael Mazelier
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[David Ponzone]

Pattern de logs, oui.

Je pense que je vais tester logstash comme aggrégateur de syslog 
Cisco/Mikrotik/Juniper/… vers une stream unique GELF à destination de l’offre 
Graylog en SaaS d’OVH, qui a le bon goût d’avoir un pricing progressif sans 
singularités (ça va de 1€ à 9€/mois, oui oui, 90k€…), parfait pour un petit 
besoin.


> Le 16 nov. 2018 à 14:42, Raphael Mazelier  a écrit :
> 
> On 16/11/2018 10:18, David Ponzone wrote:
>> Je me pose des questions existentielles pour trouver LE collecteur de logs 
>> réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
>> faible et peu critique.
> 
> Pour la collecte de log d'équipements réseaux tu n'as globalement pas le 
> choix d'utiliser le protocole syslog pour envoyer.
> 
> Hormis les outils SAAS voici ce que je connais.
> 
> En pur collecteur tu peux utiliser rsyslog/logstash/fluentd.
> Ensuite tu veux sans doute stocker tes logs dans un format qui permet 
> l'analyse. ES est parfait pour cela.
> 
> Pour la gui Kibana evidement.
> 
> Si tu veux une solution plus intégré essaye Graylog2, personnelement je 
> trouve cela assez sympa.
> 
> En revanche pour l'alerting je ne sais pas ce que tu veux faire ?
> Alerting sur les trap snmp ? Alerting sur des patterns de logs ?
> 
> 
> 
> Cdt,
> 
> --
> Raphael Mazelier
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Raphael Mazelier]

On 16/11/2018 13:41, cam.la...@azerttyu.net wrote:

Salut

Et un solution à base de prometheus ça ne le ferait pas ? ça semble
plus léger que le trio ELK tout en couvrant (j'ai l'impression) le
même besoin.

Km



Nope prometheus c'est un scrapeur de métriques. Pas plus pas moins ;)

--
Raphael Mazelier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Raphael Mazelier]

On 16/11/2018 10:18, David Ponzone wrote:

Je me pose des questions existentielles pour trouver LE collecteur de logs 
réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
faible et peu critique.


Pour la collecte de log d'équipements réseaux tu n'as globalement pas le 
choix d'utiliser le protocole syslog pour envoyer.


Hormis les outils SAAS voici ce que je connais.

En pur collecteur tu peux utiliser rsyslog/logstash/fluentd.
Ensuite tu veux sans doute stocker tes logs dans un format qui permet 
l'analyse. ES est parfait pour cela.


Pour la gui Kibana evidement.

Si tu veux une solution plus intégré essaye Graylog2, personnelement je 
trouve cela assez sympa.


En revanche pour l'alerting je ne sais pas ce que tu veux faire ?
Alerting sur les trap snmp ? Alerting sur des patterns de logs ?



Cdt,

--
Raphael Mazelier



---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Collecteur de logs réseau

[Xavier ROCA]

Salut David,

Et pourquoi pas un syslog opensource du style :
https://sourceforge.net/projects/syslogserverwindows/
pas testé

sur des besoins simple c'est largement suffisant. Je trouve juste qu'il 
toujours un truc dans ceux que j'ai pu tester.
C'est bien de recevoir une alerte sur certains log mais ce qui serait sympa ce 
serait d'avoir aussi une alerte si on ne revoit rien de la part d'un équipement 
sur une période donnée..
Et avec de l'auto apprentissage ce serait fabuleux ...

Xavier


-Message d'origine-
De : David Ponzone  
Envoyé : vendredi 16 novembre 2018 10:18
À : frnog-tech 
Objet : [FRnOG] [TECH] Collecteur de logs réseau

Je me pose des questions existentielles pour trouver LE collecteur de logs 
réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
faible et peu critique.
J’utilisais un peu Splunk Free, mais depuis une mise à jour récente, ils 
montrent des signes de vouloir rendre la version free useless. En plus, j’ai 
perdu les données existantes pendant l’opération, ce qui m’a enlevé toute envie 
de bosser avec eux.
Le nom qui vient ensuite, c’est ELK (ou Graylog), mais j’ai un peu peur de 
l’usine à gaz basée sur Java. Dans mon cas, ça doit être outil, pas un truc qui 
prend du temps à maintenir.
Et je me demande si l’usage en VM est envisageable (d’après leur doc, on parle 
plutôt de baremetal et SSD).
En OpenSource, j’ai rien vu d’autres qui m’a sauté aux yeux.

En SaaS, il y a Papertrail qui semble sympathique, avec un pricing progressif, 
et une version free pas trop limitée pour débuter.
Et Logz.io <http://logz.io/>, qui permet de disposer d’ELK, sans se prendre la 
tête avec. La version Free a le mérite d’exister pour tester, mais ensuite, le 
premier palier tarifaire est un peu brutal.

Si vous avez d’autres suggestions….
SI certains ont envie de me donner envie de me lancer dans ELK, je suis tout 
ouïe :)

PS: je sais que cela a déjà été abordé, mais ça bouge dans le domaine (fin de 
Logscape, rachat de Rocana par Splunk, etc…)

Merci


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[Jonas Termeau]

Sinon il y a Loginsight de VMWare : 
https://www.vmware.com/fr/products/vrealize-log-insight.html

Jonas Termeau 
Sysop / Sysadmin 




- Mail original -
De: "David Ponzone" 
À: "frnog-tech" 
Envoyé: Vendredi 16 Novembre 2018 10:18:00
Objet: [FRnOG] [TECH] Collecteur de logs réseau

Je me pose des questions existentielles pour trouver LE collecteur de logs 
réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
faible et peu critique.
J’utilisais un peu Splunk Free, mais depuis une mise à jour récente, ils 
montrent des signes de vouloir rendre la version free useless. En plus, j’ai 
perdu les données existantes pendant l’opération, ce qui m’a enlevé toute envie 
de bosser avec eux.
Le nom qui vient ensuite, c’est ELK (ou Graylog), mais j’ai un peu peur de 
l’usine à gaz basée sur Java. Dans mon cas, ça doit être outil, pas un truc qui 
prend du temps à maintenir.
Et je me demande si l’usage en VM est envisageable (d’après leur doc, on parle 
plutôt de baremetal et SSD).
En OpenSource, j’ai rien vu d’autres qui m’a sauté aux yeux.

En SaaS, il y a Papertrail qui semble sympathique, avec un pricing progressif, 
et une version free pas trop limitée pour débuter.
Et Logz.io <http://logz.io/>, qui permet de disposer d’ELK, sans se prendre la 
tête avec. La version Free a le mérite d’exister pour tester, mais ensuite, le 
premier palier tarifaire est un peu brutal.

Si vous avez d’autres suggestions….
SI certains ont envie de me donner envie de me lancer dans ELK, je suis tout 
ouïe :)

PS: je sais que cela a déjà été abordé, mais ça bouge dans le domaine (fin de 
Logscape, rachat de Rocana par Splunk, etc…)

Merci


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Collecteur de logs réseau

[cam.la...@azerttyu.net]

Salut

Et un solution à base de prometheus ça ne le ferait pas ? ça semble
plus léger que le trio ELK tout en couvrant (j'ai l'impression) le
même besoin.

Km


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Collecteur de logs réseau

[guénolé Delanoë]

Hello,


Observium correspond bien a ton besoin, tu peux créer, matcher des patterns 
(regex) puis notifier à partir de tes syslogs. Pour un faible volume de log, 
Observium est une bonne solution. LibreNMS (open source) semble proposer les 
mêmes fonctionnalités.


Concernant ELK, j'ai moi même fait des tests sur plusieurs VMs, ormi des crash 
à cause du manque de RAM (merci java) j'avais une solution assez stable et 
rapide à mettre en place. Le gros plus d'ElasticStack (ELK) c'est, bien 
entendu, les graphs et les fonctionnalités avancées comme la corrélation de 
log, les modules de machine learning etc.

Si tu as du temps à prendre pour t'amuser à faire des jolies graph/dashboard, 
d'ElasticStack va incontestablement t'aider dans l'analyse de log mais si tu 
veux juste monter un petit serveur regarde Observium/libreNMS.

My 2 cents
G.D

De : frnog-requ...@frnog.org  de la part de David 
Ponzone 
Envoyé : vendredi 16 novembre 2018 10:18
À : frnog-tech
Objet : [FRnOG] [TECH] Collecteur de logs réseau

Je me pose des questions existentielles pour trouver LE collecteur de logs 
réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
faible et peu critique.
J’utilisais un peu Splunk Free, mais depuis une mise à jour récente, ils 
montrent des signes de vouloir rendre la version free useless. En plus, j’ai 
perdu les données existantes pendant l’opération, ce qui m’a enlevé toute envie 
de bosser avec eux.
Le nom qui vient ensuite, c’est ELK (ou Graylog), mais j’ai un peu peur de 
l’usine à gaz basée sur Java. Dans mon cas, ça doit être outil, pas un truc qui 
prend du temps à maintenir.
Et je me demande si l’usage en VM est envisageable (d’après leur doc, on parle 
plutôt de baremetal et SSD).
En OpenSource, j’ai rien vu d’autres qui m’a sauté aux yeux.

En SaaS, il y a Papertrail qui semble sympathique, avec un pricing progressif, 
et une version free pas trop limitée pour débuter.
Et Logz.io <http://logz.io/>, qui permet de disposer d’ELK, sans se prendre la 
tête avec. La version Free a le mérite d’exister pour tester, mais ensuite, le 
premier palier tarifaire est un peu brutal.

Si vous avez d’autres suggestions….
SI certains ont envie de me donner envie de me lancer dans ELK, je suis tout 
ouïe :)

PS: je sais que cela a déjà été abordé, mais ça bouge dans le domaine (fin de 
Logscape, rachat de Rocana par Splunk, etc…)

Merci


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Collecteur de logs réseau

[David Ponzone]

Je me pose des questions existentielles pour trouver LE collecteur de logs 
réseau (collecte et envoi d’alertes à minima), pour un volume relativement 
faible et peu critique.
J’utilisais un peu Splunk Free, mais depuis une mise à jour récente, ils 
montrent des signes de vouloir rendre la version free useless. En plus, j’ai 
perdu les données existantes pendant l’opération, ce qui m’a enlevé toute envie 
de bosser avec eux.
Le nom qui vient ensuite, c’est ELK (ou Graylog), mais j’ai un peu peur de 
l’usine à gaz basée sur Java. Dans mon cas, ça doit être outil, pas un truc qui 
prend du temps à maintenir.
Et je me demande si l’usage en VM est envisageable (d’après leur doc, on parle 
plutôt de baremetal et SSD).
En OpenSource, j’ai rien vu d’autres qui m’a sauté aux yeux.

En SaaS, il y a Papertrail qui semble sympathique, avec un pricing progressif, 
et une version free pas trop limitée pour débuter.
Et Logz.io , qui permet de disposer d’ELK, sans se prendre la 
tête avec. La version Free a le mérite d’exister pour tester, mais ensuite, le 
premier palier tarifaire est un peu brutal.

Si vous avez d’autres suggestions….
SI certains ont envie de me donner envie de me lancer dans ELK, je suis tout 
ouïe :)

PS: je sais que cela a déjà été abordé, mais ça bouge dans le domaine (fin de 
Logscape, rachat de Rocana par Splunk, etc…)

Merci


---
Liste de diffusion du FRnOG
http://www.frnog.org/