Se connecter
Inscription
Mot de passe perdu
Supprimer un message
Bonjour,
Je m’attelle tout doucement à un projet de monitoring réseau.
En informatique, cela se prononce 'LAMP'.
(ou plutôt 'LAPP', puisque PostgreSQL est présenti ici plutôt que MySQL)
Le nerf de la guerre: les I/O et la fluidité de l'interface en général.
Les questions pour lesquelles je serais ravis de partager vos expériences/conseils/remarques:
I. La structure de la DB:
a.) Le choix de PostgreSQL jsutement: est-ce que les outils libres SQL sont valables?
On dit souvent que des recherches sont plus rapides sur des flat-files, la complexité ici est de permettre une dimension en plus: l’agrégation des données.
b.) L’agrégation justement: bien que je ne l'ai jamais fait, il semble que l'on peut rendre une DB 'vivante' avec des triggers et des nested routines, qui spontanément vont faire du 'house-keeping' des données, soit directement à l'insert, soit plus tard, selon une date/durée d'expiration.
Est-ce intéressant? efficace? Mieux vaut tout laisser en granularité maximale et laisser la partie 'query & display' faire les arrangements?
II. Le support HW:
c.) Bien que l'idée soit de partir d'un serveur "moyen" ici sous la main (raid-SAS, 10aine de Go RAM, 4/8 cores), je me demande s'il y a moyen de gagner en I/O autrement.
J'ai découvert (ici même) qu'il y avait moyen de balancer toute la DB en RAM au boot. Malin? Bricolage? limitation?
Est-il possible de ne mettre en RAM unquement qu'une partie (table des données du jour, par ex.) ?
Y a-t-il des nouvelles révolutions en la matière? (les fameux clouds? le faite de taper 2 de nos serveurs ensemble, en //?)
III. L'affichage graphique:
d.) Je pensais me diriger vers du PHP pour le scripting des pages, est-ce trop lent? moyen de tunner apache pour le faire mieux/plus vite?
Il vaut mieux basculer en CGI (C/C++ ou Python)?
e.) Puis un affichage des données qui permette une manipulation des données/graphes assez sexy (genre les pages de bourses, le flash en moins). On avait opté pour SVG (à l'extrême, chaque pixel est potentiellement un objet cliquable), mais c'est lourd, laid et peu compatible.
L'idée est d'utiliser des standards, plutôt que des produits, il semblerait que les nouvelles générations d'HTML/5 et CSS soient aussi (si pas plus) sexy que du flash?
IV. Émission de rapports automatisée:
f.) Ici les rapports sont clairement statiques (pondre des PDFs en scripts, ça je vois), et plus sobres qu'une belle page web, du coup est- ce intéressant de repartir de la même interface que le web afin de faire des 'screenshot' virtuels, ou bien on peut se contenter d'un petit système plus léger, sans ré-écrire la partie extraction/présentation ?
Merci beaucoup pour vos commentaires/conseils sur un (ou plusieurs) point(s) !
Je m’attelle tout doucement à un projet de monitoring réseau.
En très bref: il s'agit de sniffer des paquets à différents endroits et de les stocker, consolider, agréger et présenter.
Cette dernière présentation se fait de manière passive (dashboard), interactive (graphes clickables/zoomables) et automatisée (rapport PDFs émis daily, weelky, nightly,..)
Cela fait bcp de données (=paquets IP), mais pas très lourdes (on ne garde qu'une signature du header+timestamp+endroit où il a été vu)
Cette dernière présentation se fait de manière passive (dashboard), interactive (graphes clickables/zoomables) et automatisée (rapport PDFs émis daily, weelky, nightly,..)
Cela fait bcp de données (=paquets IP), mais pas très lourdes (on ne garde qu'une signature du header+timestamp+endroit où il a été vu)
En informatique, cela se prononce 'LAMP'.
(ou plutôt 'LAPP', puisque PostgreSQL est présenti ici plutôt que MySQL)
L'idée est qu'un utilisateur qui se connecte à l'interface arrive d'abord sur une page de type 'dashboard' avec un apperçu de l'état du réseau (latence, capacité, volume,..) assez générique, après, on peut imaginer des onglets avec des graphes plus interactif qui permettent de remonter dans le temps, zoomer, drill-down,...
Le nerf de la guerre: les I/O et la fluidité de l'interface en général.
Les questions pour lesquelles je serais ravis de partager vos expériences/conseils/remarques:
I. La structure de la DB:
a.) Le choix de PostgreSQL jsutement: est-ce que les outils libres SQL sont valables?
On dit souvent que des recherches sont plus rapides sur des flat-files, la complexité ici est de permettre une dimension en plus: l’agrégation des données.
b.) L’agrégation justement: bien que je ne l'ai jamais fait, il semble que l'on peut rendre une DB 'vivante' avec des triggers et des nested routines, qui spontanément vont faire du 'house-keeping' des données, soit directement à l'insert, soit plus tard, selon une date/durée d'expiration.
Est-ce intéressant? efficace? Mieux vaut tout laisser en granularité maximale et laisser la partie 'query & display' faire les arrangements?
II. Le support HW:
c.) Bien que l'idée soit de partir d'un serveur "moyen" ici sous la main (raid-SAS, 10aine de Go RAM, 4/8 cores), je me demande s'il y a moyen de gagner en I/O autrement.
J'ai découvert (ici même) qu'il y avait moyen de balancer toute la DB en RAM au boot. Malin? Bricolage? limitation?
Est-il possible de ne mettre en RAM unquement qu'une partie (table des données du jour, par ex.) ?
Y a-t-il des nouvelles révolutions en la matière? (les fameux clouds? le faite de taper 2 de nos serveurs ensemble, en //?)
III. L'affichage graphique:
d.) Je pensais me diriger vers du PHP pour le scripting des pages, est-ce trop lent? moyen de tunner apache pour le faire mieux/plus vite?
Il vaut mieux basculer en CGI (C/C++ ou Python)?
e.) Puis un affichage des données qui permette une manipulation des données/graphes assez sexy (genre les pages de bourses, le flash en moins). On avait opté pour SVG (à l'extrême, chaque pixel est potentiellement un objet cliquable), mais c'est lourd, laid et peu compatible.
L'idée est d'utiliser des standards, plutôt que des produits, il semblerait que les nouvelles générations d'HTML/5 et CSS soient aussi (si pas plus) sexy que du flash?
IV. Émission de rapports automatisée:
f.) Ici les rapports sont clairement statiques (pondre des PDFs en scripts, ça je vois), et plus sobres qu'une belle page web, du coup est- ce intéressant de repartir de la même interface que le web afin de faire des 'screenshot' virtuels, ou bien on peut se contenter d'un petit système plus léger, sans ré-écrire la partie extraction/présentation ?
Merci beaucoup pour vos commentaires/conseils sur un (ou plusieurs) point(s) !
