Re: [FRnOG] [TECH] Stack de logs / netflow
A titre personnel j’ai laissé tomber ELK. Il y avait à intervalle régulier des soucis et le support s’emmêlait lui même les pinceaux sur des soucis de cohérence des valeurs remontées. J’utilise ntopng, il existe une version communautaire et la version payante la plus conséquente coûte 1000€. Le support est top et dispo via telegram. Ntopng sait aussi intégrer du SNMP ou du syslog. Dans le cas du syslog il démultiplexe les informations pour les organiser par émetteur. Jérôme. > Le 28 avr. 2020 à 23:12, Raphael Mazelier a écrit : > > Bonsoir, > > Tu parles de deux choses complètement différentes : la centralisation de logs > d'équipements et la collection de flow réseaux. > > Pour les logs la plupart des équipements ne savent encore que parler syslog, > mais ce n'est pas le problème. Ensuite tu dois choisir une solution pour > ingérer, découper, classer, stocker et exploiter ces logs. > > Coté stockage en open source Elasticsearch est omniprésent pour le stockage > des logs (ce qui peut faire sens, vu qu'il s'agit souvent de stocker des > documents textes indexés et de faire des recherches). Ce n'est clairement pas > le plus performant mais c'est un standard connu. Ensuite vient le choix de > l'ingestion et de l'interface de visualisation. > > La stack E(L|F)K est la plus présente, mais à titre personnel ce n'est pas ma > préféré (n'étant pas un grand fan de Kibana, ni de logstash, ni de Fluent). > Pour un usage modéré j'ai plutôt de bon souvenir de graylog. A noter qu'il > existe des alternatives plus jeune mais prometteuses (voir Loki de la cncf). > Ensuite Splunk très bien, mais cher. > > Pour les flows je dirais que c'est encore plus ouvert. J'ai personnellement > mis en place beaucoup de solutions autour de pmacct > message broker > > agrégateur > tsdb (ou base rapide) homemade. C'est un peu de travail à mettre > en place néanmoins. > > Il existe beaucoup de solutions commerciales peu chère qui font le boulot. > > -- > Raphael Mazelier > >> On 28/04/2020 11:38, Christian d'Autume wrote: >> Bonjour la liste, >> >> >> On lance des réflexions chez nous pour refondre notre stack de >> centralisation de logs (type syslog, voir netflow); et regardons un peu ce >> qui se fait principalement en opensource. >> >> >> Vous auriez des retours d'expériences sur des appliances types elk / splunk, >> pour un parc hétérogène (~700 équipements: nxos, ftd, ios, asa, juniper ...) >> ? >> >> >> En vous remerciant d'avance pour vos retours. >> >> >> Christian >> >> >> >> --- >> Liste de diffusion du FRnOG >> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cc09a5e07c76a4f6bb12808d7ebb8dbe3%7C84df9e7fe9f640afb435%7C1%7C0%7C637237051496875395sdata=EmWuy4YzvVTxWCeLW7MYQdq8wsZWaNF3GSbW%2B6h%2B0og%3Dreserved=0 > > > --- > Liste de diffusion du FRnOG > https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7Cc09a5e07c76a4f6bb12808d7ebb8dbe3%7C84df9e7fe9f640afb435%7C1%7C0%7C637237051496875395sdata=EmWuy4YzvVTxWCeLW7MYQdq8wsZWaNF3GSbW%2B6h%2B0og%3Dreserved=0 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Le mar. 28 avr. 2020 à 23:09, Quentin Grandemange < quentin.grandema...@gmail.com> a écrit : > En revanche, je ne comprends pas pourquoi on parle souvent de Grafana mais > jamais de Kibana dans l'histoire (bien que dans la stack ELK). > Il y a une différence fondamentale entre les deux produits qui m'échappe ? > Oui, à la base Grafana ne sait afficher que des graphiques (time-series) et peut pour se faire se baser sur différents backends (graphite, influxdb, prometheus, elasticsearch...). Dans les dernières versions, Grafana peut aussi afficher des logs (provenant d'elasticsearch, de loki...), mais sa construction actuelle fait qu'il n'est pas adapté pour "fouiller" dans ceux-ci par exemple en ajoutant de plus en plus de filtres pour remonter jusqu'à un évènement précis. Kibana, quant à lui, est à l'origine conçu pour fouiller dans les logs, et il sait aussi afficher graphiquement des time-series basées sur des agrégations temporelles de valeurs provenant de ces mêmes logs. Ca le rend plus souple que Grafana sur ce point, mais en revanche il ne sait se baser que sur elasticsearch. Le choix s'oriente donc selon l'usage qu'on compte en faire: plus orienté log ou plus orienté métrique. Sachant que même si la stack ELK sait faire les deux, les métriques seront d'un ordre de grandeur plus performantes sous prometheus/influxdb (et donc Grafana) que sous elasticsearch (et donc Kibana). Pour ma part j'utilise les deux, chacun dans sa spécialité. Hervé BRY Administrateur Système Geneanet (http://www.geneanet.org) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
On 28/04/2020 13:21, Remi Desgrange wrote: Il est vrais que les outils de la stack ELK bouffe beaucoup (trop) de ressources. Mais quand tu a beaucoup de données, La JVM tu t'y retrouve. C'est pas pour rien que les stacks big data tourne sur la JVM (le log de 700 équipements c'est pas du big data, on est d'accord). Étant dans le milieu de la bigdata depuis peu, je ne suis pas sur que la raison profonde du choix de la JVM soit la performance. Je crois que c'est plutôt affaire écosystème (la plupart des frameworks sont ecris en Java/Scala), et que c'est avant tout car ces langages ont une certaine expressivité qui manquent à des langages plus bas niveau, et donc qu'il serait extrêmement pénible de manipuler des structures de données complexes dans des lesdits langages. (Il y aussi énormément de python mais la on ne parle même plus de performances.) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
On 28/04/2020 12:47, Xavier Beaudouin wrote: Okay rrdtool ne permet pas d'avoir des stats journalières précises a plus d'un mois mais donnent largement ce qu'il faut pour avoir des métriques d'utilisation d'une plateforme. Il y a un truc qui est vrai dans ce que tu dis c'est que toutes les solutions actuelles à base d'elastisearch, ou tsdb c'est la difficulté à gérer de l'historique long et le downsampling. (parfois il m'arrive de regretter rrd pour ce point précis pas pour le reste). Alors pourquoi utiliser un machin en java qui est un OS sur un autre OS alors qu'on pourrais utiliser des API normales d'un OS (oui la libc... / libthread). Pour faire un parallèle : nginx vs apache voila ce que j'en pense (hormis les problèmes de licences et de FUD liées au modele de dev). Pour le coup je ne comprends pas trop l'analogie. Nginx est plus simple et plus performant qu'Apache. Je vois Nginx comme un gros framework orienté web et perf (mais c'est peut être parce que j'ai codé des modules nginx). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Bonsoir, Tu parles de deux choses complètement différentes : la centralisation de logs d'équipements et la collection de flow réseaux. Pour les logs la plupart des équipements ne savent encore que parler syslog, mais ce n'est pas le problème. Ensuite tu dois choisir une solution pour ingérer, découper, classer, stocker et exploiter ces logs. Coté stockage en open source Elasticsearch est omniprésent pour le stockage des logs (ce qui peut faire sens, vu qu'il s'agit souvent de stocker des documents textes indexés et de faire des recherches). Ce n'est clairement pas le plus performant mais c'est un standard connu. Ensuite vient le choix de l'ingestion et de l'interface de visualisation. La stack E(L|F)K est la plus présente, mais à titre personnel ce n'est pas ma préféré (n'étant pas un grand fan de Kibana, ni de logstash, ni de Fluent). Pour un usage modéré j'ai plutôt de bon souvenir de graylog. A noter qu'il existe des alternatives plus jeune mais prometteuses (voir Loki de la cncf). Ensuite Splunk très bien, mais cher. Pour les flows je dirais que c'est encore plus ouvert. J'ai personnellement mis en place beaucoup de solutions autour de pmacct > message broker > agrégateur > tsdb (ou base rapide) homemade. C'est un peu de travail à mettre en place néanmoins. Il existe beaucoup de solutions commerciales peu chère qui font le boulot. -- Raphael Mazelier On 28/04/2020 11:38, Christian d'Autume wrote: Bonjour la liste, On lance des réflexions chez nous pour refondre notre stack de centralisation de logs (type syslog, voir netflow); et regardons un peu ce qui se fait principalement en opensource. Vous auriez des retours d'expériences sur des appliances types elk / splunk, pour un parc hétérogène (~700 équipements: nxos, ftd, ios, asa, juniper ...) ? En vous remerciant d'avance pour vos retours. Christian --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Bonsoir, Quelque chose qui n'a pas grand chose à voir avec vos dernières discutions mais m'étant récemment renseigné là dessus (collection de log réseau, y compris telemetry) je vois 2 grandes solutions : D'un côté la stack ELK et de l'autre Prometeus/Grafana. En revanche, je ne comprends pas pourquoi on parle souvent de Grafana mais jamais de Kibana dans l'histoire (bien que dans la stack ELK). Il y a une différence fondamentale entre les deux produits qui m'échappe ? oO Bonne soirée à tous, Quentin Le mar. 28 avr. 2020 à 15:08, Sébastien 65 a écrit : > Ce fut une des premières pistes... Mais je voulais pour le futur pouvoir > intégrer une solution de détection flood/ddos sur l'existant très > facilement sans devoir tout "casser" et également avoir quelqu'un au bout > du tél/mail en cas de problème ou besoin. > > > De : David Ponzone > Envoyé : mardi 28 avril 2020 14:59 > À : Sébastien 65 > Cc : Christian d'Autume ; frnog-t...@frnog.org < > frnog-t...@frnog.org> > Objet : Re: [FRnOG] [TECH] Stack de logs / netflow > > Et ntop-ng avec tous les plugins payants ne faisaient pas le boulot ? > > > Le 28 avr. 2020 à 14:57, Sébastien 65 a écrit : > > > > J'ai passé beaucoup de temps à analyser des produits et consulter pour > dire que le produit n'est pas excessif comparé à d'autres solutions... > > > > Chez nous cela a nécessité de passer un peu hors produit étagère du fait > de la nécessité d'utiliser un de nos dev interne. L'avantage de PRAGMA est > qu'ils ont su gérer cette spécificité et adapter leur produit à notre > plate-forme. > > > > Ils ont plusieurs produits et prestations, mon besoin et celui de > Christian ne sont pas identiques, le prix ne sera pas en phase.. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Ce fut une des premières pistes... Mais je voulais pour le futur pouvoir intégrer une solution de détection flood/ddos sur l'existant très facilement sans devoir tout "casser" et également avoir quelqu'un au bout du tél/mail en cas de problème ou besoin. De : David Ponzone Envoyé : mardi 28 avril 2020 14:59 À : Sébastien 65 Cc : Christian d'Autume ; frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] Stack de logs / netflow Et ntop-ng avec tous les plugins payants ne faisaient pas le boulot ? > Le 28 avr. 2020 à 14:57, Sébastien 65 a écrit : > > J'ai passé beaucoup de temps à analyser des produits et consulter pour dire > que le produit n'est pas excessif comparé à d'autres solutions... > > Chez nous cela a nécessité de passer un peu hors produit étagère du fait de > la nécessité d'utiliser un de nos dev interne. L'avantage de PRAGMA est > qu'ils ont su gérer cette spécificité et adapter leur produit à notre > plate-forme. > > Ils ont plusieurs produits et prestations, mon besoin et celui de Christian > ne sont pas identiques, le prix ne sera pas en phase.. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Et ntop-ng avec tous les plugins payants ne faisaient pas le boulot ? > Le 28 avr. 2020 à 14:57, Sébastien 65 a écrit : > > J'ai passé beaucoup de temps à analyser des produits et consulter pour dire > que le produit n'est pas excessif comparé à d'autres solutions... > > Chez nous cela a nécessité de passer un peu hors produit étagère du fait de > la nécessité d'utiliser un de nos dev interne. L'avantage de PRAGMA est > qu'ils ont su gérer cette spécificité et adapter leur produit à notre > plate-forme. > > Ils ont plusieurs produits et prestations, mon besoin et celui de Christian > ne sont pas identiques, le prix ne sera pas en phase.. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
J'ai passé beaucoup de temps à analyser des produits et consulter pour dire que le produit n'est pas excessif comparé à d'autres solutions... Chez nous cela a nécessité de passer un peu hors produit étagère du fait de la nécessité d'utiliser un de nos dev interne. L'avantage de PRAGMA est qu'ils ont su gérer cette spécificité et adapter leur produit à notre plate-forme. Ils ont plusieurs produits et prestations, mon besoin et celui de Christian ne sont pas identiques, le prix ne sera pas en phase.. De : David Ponzone Envoyé : mardi 28 avril 2020 14:36 À : Sébastien 65 Cc : Christian d'Autume ; frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] Stack de logs / netflow Et en gros (© Génération Z), c’est cher ? > Le 28 avr. 2020 à 14:30, Sébastien 65 a écrit : > > Bonjour Christian, > > Chez nous on utilise une solution big data telemetry éditée par PRAGMA > Innovation. > Notre usage est d'avoir une appli capable de collecter notre trafic IN/OUT > sur nos routeurs backbone afin de pouvoir tirer des graphs et infos > pertinentes au travers d'un dashboard... > > L'appli permet également de te faire tes propres requêtes afin d'extraire les > informations dont tu souhaites. J'ai sollicité le support (très réactif) pour > des demandes de graph customs pour permettre une analyse de certains > comportements. > > https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pragma-innovation.fr%2Fpragma-analytics-software-suite-description%2Fdata=02%7C01%7C%7Ce833ded8a5b1433497fe08d7eb70c9aa%7C84df9e7fe9f640afb435%7C1%7C0%7C637236741952872130sdata=FYU1M%2BGX%2F6wUyrBEfbAOdVfjP3GFxwwPR%2FHPQ%2BIy%2F4A%3Dreserved=0 > https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pragma-innovation.fr%2Fcas-dusage-telemetrie-ip%2Fdata=02%7C01%7C%7Ce833ded8a5b1433497fe08d7eb70c9aa%7C84df9e7fe9f640afb435%7C1%7C0%7C637236741952882130sdata=TAZGuGjeFS6A6uJCSePBN9kTdVh3KaBFJrzi1gChurE%3Dreserved=0 > > Si besoin je peux te transmettre les coordonnées du contact qui a piloté > l'intégration/suivi sur notre infra. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Quelqu'un aurait testé https://www.elastic.co/beats/packetbeat ? (en remplacement d'elastiflow) On Tue, Apr 28, 2020 at 11:58:10AM +0200, Remi Desgrange wrote: > Log ou métrique ? Pour transformer les logs en métriques, logstash et > surement le plus flexible. Mais ça bouffe masse CPU. > > Pour netflow sur étagère : https://github.com/robcowart/elastiflow mais > attention, si tu a 700 routeur/sw tu ne pourra pas avoir une grosse rétention > ou alors va falloir sortir le gros gros cluster de bécanes. Sachant d'ES ne > sais pas tirer partie de bécanes avec +64Go de RAM (JVM heap toussa) t'es > parti sur au moins 5/7 bécanes > OpenNMS refond sa stack petit à petit, et a pondu newts pour les métriques : > http://opennms.github.io/newts/ malheureusement pas eu le temps de testé mais > basé sur cassandra, donc forcement avec une base "rock solid". Si des gens > ont des retours ça m'intéresse. > Pour ta volumétrie j'ai peur qu'InfluxDB soit incapable de faire quoi que ce > soit (les mauvaises langue diront qu'il est incapable de base). > https://thanos.io/ est à essayer (prometheus avec stockage long terme dans de > l'object storage, par exemple dans minio). mais ça demande de setup des > exporter et d'en écrire si t'a pas ce que tu veux (c'est en Go). Changement > de paradigme, bref, le changement est pas que technique. > côté visu Grafana reste le maitre incontesté car tu peux aggréger différentes > métriques qui viennent de différentes sources et les corréler (du SQL d'une > DB cliente quelconque avec ton monitoring par exemple) > J'ai tendance à déconseiller les bon vieux nagios/observium/librenms/monit > qui fonctionne mais scale mal et qui stocke les métriques dans RRD ce qui > rend la corrélation au mieux très pénible, au pire impossible. Sans parler > des setup HA à base de *** infame comme corosync ou NFS.. > Cordialement/Best Regards, Rémi Desgrange > > On Apr 28 2020, at 11:38 am, Christian d'Autume wrote: > > Bonjour la liste, On lance des réflexions chez nous pour refondre notre > > stack de centralisation de logs (type syslog, voir netflow); et regardons > > un peu ce qui se fait principalement en opensource. Vous auriez des retours > > d'expériences sur des appliances types elk / splunk, pour un parc > > hétérogène (~700 équipements: nxos, ftd, ios, asa, juniper ...) ? En vous > > remerciant d'avance pour vos retours. Christian --- > > 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] Stack de logs / netflow
Et en gros (© Génération Z), c’est cher ? > Le 28 avr. 2020 à 14:30, Sébastien 65 a écrit : > > Bonjour Christian, > > Chez nous on utilise une solution big data telemetry éditée par PRAGMA > Innovation. > Notre usage est d'avoir une appli capable de collecter notre trafic IN/OUT > sur nos routeurs backbone afin de pouvoir tirer des graphs et infos > pertinentes au travers d'un dashboard... > > L'appli permet également de te faire tes propres requêtes afin d'extraire les > informations dont tu souhaites. J'ai sollicité le support (très réactif) pour > des demandes de graph customs pour permettre une analyse de certains > comportements. > > http://www.pragma-innovation.fr/pragma-analytics-software-suite-description/ > http://www.pragma-innovation.fr/cas-dusage-telemetrie-ip/ > > Si besoin je peux te transmettre les coordonnées du contact qui a piloté > l'intégration/suivi sur notre infra. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Stack de logs / netflow
Bonjour Christian, Chez nous on utilise une solution big data telemetry éditée par PRAGMA Innovation. Notre usage est d'avoir une appli capable de collecter notre trafic IN/OUT sur nos routeurs backbone afin de pouvoir tirer des graphs et infos pertinentes au travers d'un dashboard... L'appli permet également de te faire tes propres requêtes afin d'extraire les informations dont tu souhaites. J'ai sollicité le support (très réactif) pour des demandes de graph customs pour permettre une analyse de certains comportements. http://www.pragma-innovation.fr/pragma-analytics-software-suite-description/ http://www.pragma-innovation.fr/cas-dusage-telemetrie-ip/ Si besoin je peux te transmettre les coordonnées du contact qui a piloté l'intégration/suivi sur notre infra. Sébastien De : frnog-requ...@frnog.org de la part de Christian d'Autume Envoyé : mardi 28 avril 2020 11:38 À : frnog-t...@frnog.org Objet : [FRnOG] [TECH] Stack de logs / netflow Bonjour la liste, On lance des réflexions chez nous pour refondre notre stack de centralisation de logs (type syslog, voir netflow); et regardons un peu ce qui se fait principalement en opensource. Vous auriez des retours d'expériences sur des appliances types elk / splunk, pour un parc hétérogène (~700 équipements: nxos, ftd, ios, asa, juniper ...) ? En vous remerciant d'avance pour vos retours. Christian --- Liste de diffusion du FRnOG https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C7306057131ab4cc6fb0e08d7eb57f5ec%7C84df9e7fe9f640afb435%7C1%7C0%7C637236635326671290sdata=T8RR3Jn5fX3k80WhQRb4oDi8M9YuYwra7%2BnZkG8%2BQQg%3Dreserved=0 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Il est vrais que les outils de la stack ELK bouffe beaucoup (trop) de ressources. Mais quand tu a beaucoup de données, La JVM tu t'y retrouve. C'est pas pour rien que les stacks big data tourne sur la JVM (le log de 700 équipements c'est pas du big data, on est d'accord). Si tu essai de faire de grosses agrégations dans grafana, ça va exploser, mais dans ce cas, c'est à ton dataplane de faire le downsampling (time bucket et compagnie). rrd est très bien pour avoir 1 graph mais te permet pas de requêter les données et de les corréler. Perso je reviendrais pas à un temps ou tu ouvre 4 fois la même page de graph pour pouvoir regarder toi même l'iowait, le CPU, et le réseau... Si certain arrive à être productif avec des technos du 16ème siècle, franchement je leur tire mon chapeau parce que moi je suis vraiment trop bête pour ça. Toute les actions que je fais sur un monitoring m'amène une chose et une seule : diminuer la charge cognitive au maximum pour avoir à réfléchir le moins possible quand a(ux) action(s) à réaliser. Le plus complexe dans tous ces systèmes (même rrd) c'est d'arriver à sélectionner qu'elle info est pertinente et laquelle ne l'est pas. Et là on sort du champ technique :-) > Alors pourquoi utiliser un machin en java qui est un OS sur un autre OS alors > qu'on pourrais utiliser des API normales d'un OS (oui la libc... / libthread). Libre à toi d'utiliser un unikernel https://github.com/cloudius-systems/osv Et attend j'ai pas encore parlé de Warp10 XD https://www.warp10.io/ Et tkt pas des gens sont en train de recoder toutes ces stacks en Rust Cordialement/Best Regards, Rémi Desgrange On Apr 28 2020, at 12:47 pm, Xavier Beaudouin wrote: > Hello, >> Sachant d'ES ne sais pas tirer partie de bécanes avec +64Go de RAM > (JVM >> heap toussa) t'es parti sur au moins 5/7 bécanes >> > > Les dernières > versions d'ES sont capables d'utiliser plus de RAM: une > grande partie des > données ont été sortie du heap JVM pour passer sur du > memory mapping. Ca > permet entre autres de s'affranchir de la "limite" de la > JVM liée à la > compression de pointeurs qui fait qu'au delà de 32Go de heap > on est souvent > perdant en espace utile, les pointeurs n'étant plus > compressés, ainsi que > de limiter les problèmes de freezes liés au garbage > collector. > La > contention sur ES est plus au niveau du CPU, dont l'utilisation est > assez > linéaire par rapport à la quantité de données indexées. Je ne sais pas si je > suis devenu un vieux con aigri ou rétrograde, mais quand je vois des > discussion ou on parle de 5/7 becannes avec +64Go de RAM pour stocker de > métriques qui seront rarement utilisées a plus d'un trimestre je suis assez > dubitatif de la débauche de jus, de place en DC et de consommation de > silicium plutôt peu optimisées... Surtout que entre ES / Cassandra et ses > amis, ont quand même un language plus que peu efficace en gestion de ram, > gc(), et de concurrence CPU. Okay rrdtool ne permet pas d'avoir des stats > journalières précises a plus d'un mois mais donnent largement ce qu'il faut > pour avoir des métriques d'utilisation d'une plateforme. Après il y a des > trucs qui scalent plus que d'autres, mais un rrdcached sur du zfs avec lz4 + > un peu de ram (et sauvés a coup de zfs send/receive) suffisent largement a > mon goût et est TRÈS facilement scalable pour s'en prendre plein la > tronche avec bcp moins de machines et de CPU. Après je ne parles pas des > navigateurs qui explosent quand on demande des stats sur 50 machine d'un coup > consolidées via Grafana Alors pourquoi utiliser un machin en java qui est > un OS sur un autre OS alors qu'on pourrais utiliser des API normales d'un OS > (oui la libc... / libthread). Pour faire un parallèle : nginx vs apache > voila ce que j'en pense (hormis les problèmes de licences et de FUD liées au > modele de dev). /Xavier --- Liste de diffusion du > FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Hello, >> Sachant d'ES ne sais pas tirer partie de bécanes avec +64Go de RAM (JVM >> heap toussa) t'es parti sur au moins 5/7 bécanes >> > > Les dernières versions d'ES sont capables d'utiliser plus de RAM: une > grande partie des données ont été sortie du heap JVM pour passer sur du > memory mapping. Ca permet entre autres de s'affranchir de la "limite" de la > JVM liée à la compression de pointeurs qui fait qu'au delà de 32Go de heap > on est souvent perdant en espace utile, les pointeurs n'étant plus > compressés, ainsi que de limiter les problèmes de freezes liés au garbage > collector. > La contention sur ES est plus au niveau du CPU, dont l'utilisation est > assez linéaire par rapport à la quantité de données indexées. Je ne sais pas si je suis devenu un vieux con aigri ou rétrograde, mais quand je vois des discussion ou on parle de 5/7 becannes avec +64Go de RAM pour stocker de métriques qui seront rarement utilisées a plus d'un trimestre je suis assez dubitatif de la débauche de jus, de place en DC et de consommation de silicium plutôt peu optimisées... Surtout que entre ES / Cassandra et ses amis, ont quand même un language plus que peu efficace en gestion de ram, gc(), et de concurrence CPU. Okay rrdtool ne permet pas d'avoir des stats journalières précises a plus d'un mois mais donnent largement ce qu'il faut pour avoir des métriques d'utilisation d'une plateforme. Après il y a des trucs qui scalent plus que d'autres, mais un rrdcached sur du zfs avec lz4 + un peu de ram (et sauvés a coup de zfs send/receive) suffisent largement a mon goût et est TRÈS facilement scalable pour s'en prendre plein la tronche avec bcp moins de machines et de CPU. Après je ne parles pas des navigateurs qui explosent quand on demande des stats sur 50 machine d'un coup consolidées via Grafana Alors pourquoi utiliser un machin en java qui est un OS sur un autre OS alors qu'on pourrais utiliser des API normales d'un OS (oui la libc... / libthread). Pour faire un parallèle : nginx vs apache voila ce que j'en pense (hormis les problèmes de licences et de FUD liées au modele de dev). /Xavier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Le mar. 28 avr. 2020 à 11:58, Remi Desgrange a écrit : > Sachant d'ES ne sais pas tirer partie de bécanes avec +64Go de RAM (JVM > heap toussa) t'es parti sur au moins 5/7 bécanes > Les dernières versions d'ES sont capables d'utiliser plus de RAM: une grande partie des données ont été sortie du heap JVM pour passer sur du memory mapping. Ca permet entre autres de s'affranchir de la "limite" de la JVM liée à la compression de pointeurs qui fait qu'au delà de 32Go de heap on est souvent perdant en espace utile, les pointeurs n'étant plus compressés, ainsi que de limiter les problèmes de freezes liés au garbage collector. La contention sur ES est plus au niveau du CPU, dont l'utilisation est assez linéaire par rapport à la quantité de données indexées. Hervé BRY Administrateur Système Geneanet (http://www.geneanet.org) --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Stack de logs / netflow
Bonjour, PI : Il y a eu une discussion en début 2019 sur le même sujet [Analyser de traffic] https://www.mail-archive.com/search?q=+Analyser+de+traffic=frnog%40frnog.org Xavier -Message d'origine- De : Christian d'Autume Envoyé : mardi 28 avril 2020 11:38 À : frnog-t...@frnog.org Objet : [FRnOG] [TECH] Stack de logs / netflow Bonjour la liste, On lance des réflexions chez nous pour refondre notre stack de centralisation de logs (type syslog, voir netflow); et regardons un peu ce qui se fait principalement en opensource. Vous auriez des retours d'expériences sur des appliances types elk / splunk, pour un parc hétérogène (~700 équipements: nxos, ftd, ios, asa, juniper ...) ? En vous remerciant d'avance pour vos retours. Christian --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Log ou métrique ? Pour transformer les logs en métriques, logstash et surement le plus flexible. Mais ça bouffe masse CPU. Pour netflow sur étagère : https://github.com/robcowart/elastiflow mais attention, si tu a 700 routeur/sw tu ne pourra pas avoir une grosse rétention ou alors va falloir sortir le gros gros cluster de bécanes. Sachant d'ES ne sais pas tirer partie de bécanes avec +64Go de RAM (JVM heap toussa) t'es parti sur au moins 5/7 bécanes OpenNMS refond sa stack petit à petit, et a pondu newts pour les métriques : http://opennms.github.io/newts/ malheureusement pas eu le temps de testé mais basé sur cassandra, donc forcement avec une base "rock solid". Si des gens ont des retours ça m'intéresse. Pour ta volumétrie j'ai peur qu'InfluxDB soit incapable de faire quoi que ce soit (les mauvaises langue diront qu'il est incapable de base). https://thanos.io/ est à essayer (prometheus avec stockage long terme dans de l'object storage, par exemple dans minio). mais ça demande de setup des exporter et d'en écrire si t'a pas ce que tu veux (c'est en Go). Changement de paradigme, bref, le changement est pas que technique. côté visu Grafana reste le maitre incontesté car tu peux aggréger différentes métriques qui viennent de différentes sources et les corréler (du SQL d'une DB cliente quelconque avec ton monitoring par exemple) J'ai tendance à déconseiller les bon vieux nagios/observium/librenms/monit qui fonctionne mais scale mal et qui stocke les métriques dans RRD ce qui rend la corrélation au mieux très pénible, au pire impossible. Sans parler des setup HA à base de *** infame comme corosync ou NFS.. Cordialement/Best Regards, Rémi Desgrange On Apr 28 2020, at 11:38 am, Christian d'Autume wrote: > Bonjour la liste, On lance des réflexions chez nous pour refondre notre stack > de centralisation de logs (type syslog, voir netflow); et regardons un peu ce > qui se fait principalement en opensource. Vous auriez des retours > d'expériences sur des appliances types elk / splunk, pour un parc hétérogène > (~700 équipements: nxos, ftd, ios, asa, juniper ...) ? En vous remerciant > d'avance pour vos retours. Christian --- Liste de > diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
