Auteur Sujet: Monitoring bande passante par AS  (Lu 3769 fois)

0 Membres et 1 Invité sur ce sujet

Symbol

  • AS52075 Wifirst
  • Expert
  • *
  • Messages: 210
Monitoring bande passante par AS
« Réponse #24 le: 27 janvier 2017 à 11:01:51 »
Raphael : C'est vieux mais ça fait le job pas mal avec un volume maitrisé. C'est pas l'outil d'analyse idéal, mais c'est un outil assez simple et pas trop gourmand pour avoir une vue synthétique de ta répartition. Après si on veut aller plus loin, entre ELK et Wanguard il y a des choses intéressantes à faire, notamment dans le détail des infos qui ne se limitera pas aux AS.
Par rapport à du rrd, pmacct + database + whatever, ça permet notamment de voir autre chose que "tel AS fait tel traf et ça passe par tel IX", ce qui est bien mais insuffisant.
En l'occurrence on pourra voir qui a lancé un DDoS avec quel protocole vers quels clients depuis quels IPs et/ou quels AS, avoir des infos détaillées par IP, protocoles, tailles de paquets, quel est l'AS avec lequel il serait intéressant de peerer (pas l'AS source ni destination, mais celui du milieu), bref tout ce qu'on n'a pas dans un rrd mais qui peut s'extraire en SQL avec des SELECT.


Quand InfluxDB gobe beaucoup de données et que tu lui demandes une requête assez complexe il se retrouve vite en "Out of memory".
Évidemment ce n'est pas forcèment pertinent pour une beigebox hébergée sous la table de la cuisine, ça dépend du besoin.
Et bien sûr il y a les solutions payantes ; voire externalisées (Kentik ou autres Deepfield).

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 538
  • La Madeleine (59)
Monitoring bande passante par AS
« Réponse #25 le: 27 janvier 2017 à 11:52:42 »
Ce n'est pas les mêmes outils :)

D'un côté, tu as un truc qui récupère les flow, et en fait un traitement qui est connu a priori
De l'autre, tu as un truc qui récupère et stock les flow, et qui appliquent des traitements a posteriori

L'un est spécifique et efficace, l'autre est beaucoup plus onéreux mais générique

Citer
quel est l'AS avec lequel il serait intéressant de peerer (pas l'AS source ni destination, mais celui du milieu)
J'ai commit un truc pour ça dans l'as-stats, c'est pratique pour le sortant, mais pifométrique pour l'entrant :s

Citer
Évidemment ce n'est pas forcèment pertinent pour une beigebox hébergée sous la table de la cuisine, ça dépend du besoin.
Avec ou sans choucroute, la cuisine ?   ;D ;D

raf

  • AS60032 Expert Coriolis Telecom
  • Expert
  • *
  • Messages: 436
Monitoring bande passante par AS
« Réponse #26 le: 27 janvier 2017 à 16:44:25 »
Synack, tu veux dire qu'il crée un RRD par AS, même si tu n'a échangé qu'un paquet avec cet AS et que tu n'aura plus d'autres échange ensuite ?
Des qu'il detecte du trafic avec un AS, il cree le RRD correspondant a l'AS.

Avec les mises à jour toutes les 5 minutes, cela doit générer pas mal d'E/S.
Pas tant que ca. Il met a jour uniquement les RRD correspondant aux AS avec lesquels il y a eu du trafic echange dans l'intervale.

Avec un RRD de 1 Mo, cela fait 50 Go écrit toutes les 5 minutes, j'ai bon ? (a moins qu'il soit possible de mettre à jour le RRD sans le ré-écrire complètement ?)
Pas tout a fait (voir plus haut).

J'ai mis en place mon AS-stats des que j'ai eu du netflow utilisable (nouveaux routeurs "internet border"), il y a environ 3 mois. Depuis, le nombre de RRD n'arrete pas d'augmenter. Je n'ai pas encore touche les 50K de Synack, mais je ne suis pas loin. Selon bgp.potaroo.net ca devrai plafonner vers 55K.

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 687
Monitoring bande passante par AS
« Réponse #27 le: 27 janvier 2017 à 17:59:51 »
Pour être plus précis j'en suis à 55690 RRD à ce jour (en un peu plus d'un an), donc ça doit être ça effectivement.

ut0mt8

  • AS49477 e-TF1
  • Expert
  • *
  • Messages: 99
  • Boulognes(92)
    • AS49477 Responsable Infrastructure eTF1
Monitoring bande passante par AS
« Réponse #28 le: 27 janvier 2017 à 18:11:46 »
InfluxDB vs RRDtool : ce n'est pas la même chose, et je pense InfluxDB sera beaucoup plus lourd.

RRDtool moyenne, ce que Influx ne fait pas (comme le dit Jack, la taille est fixe) ?

Quand InfluxDB gobe beaucoup de données et que tu lui demandes une requête assez complexe il se retrouve vite en "Out of memory".

Alors ce n'est pas la meme chose dans le sens ou rrdtool est un outil à la fois de stockage de tsdb et de rendering de graph.
Il permet aussi l'aggregation à la volée.

Influxdb (ou prometheus) c'est une bdd orienté tsdb. Evidement c'est aberrant de mettre toutes les données brutes de flow dedans.
Il faut mettre des métriques :) et après cela se passe niquel (surtout que c'est fait pour) . A noter que Influx gere aussi l'historisation ou aggregation via les continuous query.

L'immense avantage de ces outils moderne c'est :

- une vrai gui avec grafana qui permet de créer des graphs ultra simplement, de les templater, etc...
- le fait que tu n'as pas besoin de définir tes métriques à l'avance;

Donc oui dans un sens ca peut etre plus long à mettre en place (encore que c'est surtout l'habitude) que rrd, mais après quel confort.
(et franchement celui qui a déjà essayer de faire des graph dans rrd ne peux pas me dire le contraire, c'est long et relou)






ut0mt8

  • AS49477 e-TF1
  • Expert
  • *
  • Messages: 99
  • Boulognes(92)
    • AS49477 Responsable Infrastructure eTF1
Monitoring bande passante par AS
« Réponse #29 le: 27 janvier 2017 à 18:15:49 »

Raphael : C'est vieux mais ça fait le job pas mal avec un volume maitrisé. C'est pas l'outil d'analyse idéal, mais c'est un outil assez simple et pas trop gourmand pour avoir une vue synthétique de ta répartition. Après si on veut aller plus loin, entre ELK et Wanguard il y a des choses intéressantes à faire, notamment dans le détail des infos qui ne se limitera pas aux AS.

ELK clairement mauvaise idée. Stocker des flows dans un moteur d'indexation ?!. Le E et L de ELK sont une vaste blague. Elastisearch est utlisé comme bdd, et Logstash (du ruby dans du java qu'est ce qui pourrais mal se passer ?) est juste un truc affreux et pas performant.
Wanguard c'est super bien pour avoir une vue rapide de ton réseau quand tu as zero temps (et c'est pas cher). Par contre l'immense probleme c'est que cela stocke dans rrd et que tu ne peux pas exporter / utiliser les données collectés ou aggréges (des fois que tu veuilles faire de l'alerting ou autre).

Bref pas la solution pour moi.

ut0mt8

  • AS49477 e-TF1
  • Expert
  • *
  • Messages: 99
  • Boulognes(92)
    • AS49477 Responsable Infrastructure eTF1
Monitoring bande passante par AS
« Réponse #30 le: 27 janvier 2017 à 18:19:34 »
Par rapport à du rrd, pmacct + database + whatever, ça permet notamment de voir autre chose que "tel AS fait tel traf et ça passe par tel IX", ce qui est bien mais insuffisant.
En l'occurrence on pourra voir qui a lancé un DDoS avec quel protocole vers quels clients depuis quels IPs et/ou quels AS, avoir des infos détaillées par IP, protocoles, tailles de paquets, quel est l'AS avec lequel il serait intéressant de peerer (pas l'AS source ni destination, mais celui du milieu), bref tout ce qu'on n'a pas dans un rrd mais qui peut s'extraire en SQL avec des SELECT.


Voila bien gentiment. Et influx/prometheus sont tres tres performant, il faut faire juste attention a ce que l'on mets dedans :) comme une BDD quoi.
A refaire d'ailleurs je ferais du prometheus car cela gère l'alerting directement.

Synack

  • AS16080 Rentabiliweb Telecom
  • Expert
  • *
  • Messages: 687
Monitoring bande passante par AS
« Réponse #31 le: 27 janvier 2017 à 18:24:23 »
ELK clairement mauvaise idée. Stocker des flows dans un moteur d'indexation ?!. Le E et L de ELK sont une vaste blague. Elastisearch est utlisé comme bdd, et Logstash est juste un truc affreux et pas performant. Bref.
Wanguard c'est super bien pour avoir une vue rapide de ton réseau quand tu as zero temps (et c'est pas cher). Par contre l'immense probleme c'est que cela stocke dans rrd et que tu ne peux pas exporter / utiliser les données collectés ou aggréges (des fois que tu veuilles faire de l'alerting ou autre).

Bref pas la solution pour moi.

Pour être franc j'ai pas vraiment creusé le sujet encore pour ELK & co, c'est dans la pile des projets après d'autres choses plus prioritaires.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 538
  • La Madeleine (59)
Monitoring bande passante par AS
« Réponse #32 le: 29 mars 2017 à 09:17:35 »
Influxdb (ou prometheus) c'est une bdd orienté tsdb. Evidement c'est aberrant de mettre toutes les données brutes de flow dedans.
Il faut mettre des métriques :) et après cela se passe niquel (surtout que c'est fait pour) . A noter que Influx gere aussi l'historisation ou aggregation via les continuous query.

Bof, j'suis en train d'essayer les outils, grandement motivé par ton retour d'expérience
Je suis plutôt déçu par influxdb : j'essaie de faire de stats par IP, il semble incapable de gérer une telle cardinalité .. :s
(j'ai monté les limites, mais du coup il oom avec 10GB dédié ..)

M'enfin

ut0mt8

  • AS49477 e-TF1
  • Expert
  • *
  • Messages: 99
  • Boulognes(92)
    • AS49477 Responsable Infrastructure eTF1
Monitoring bande passante par AS
« Réponse #33 le: 29 mars 2017 à 22:56:03 »
Si tu injecte toutes les couples d'IPs oui ca va faire trop de métriques.
Ce n'est pas fait pour. J'ai bien dit de ne pas mettre tout les flows dedans :)

Ceci dit maintenant je suis plutôt prometheus. Ca fait la meme chose mais le langage est encore plus puissant (par contre moins optimisé retention, mais qui a envie de conserver ses métriques de flows longtemps ?)
Je vais poster mes scripts pmacct => amqp => prometheus. => tjours grafana parce que c'est bien.

 

Mobile View