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) !

Pour la question sur PHP : ça convient parfaitement, aucun problème de lenteur !

Pour la question sur l'affichage sexy des graphiques : utilise une lib JS du style http://www.highcharts.com/

Pour la génération de PDF : une méthode simple consiste à appeler le moteur de webkit en shell : http://code.google.com/p/wkhtmltopdf/ Testé et approuvé, ça marche très bien

Sinon tu peux aussi utiliser un outil de reporting spécialisé tel que Jasper ou Birt... Le gros avantage est de pouvoir rendre tes rapports en différents formats de présentation (html, pdf... ) et aussi d'exporter au format Excel (ça les utilisateurs adorent).

OV> merci! Il semble en effet que PHP puisse rester dans la course (ouf!), mais l'idée serait d'utiliser un framework qui utilise les ORM, non?
Zend? cake? symphony? on parle d'une 10aine de pages, peut-êter qu'il ne faut pas sortir la bombe nucléaire non plus?

Les 2 frameworks du moment sont Zend Framework et Symfony.

Symfony est sorti en 2.0 il n'y a pas longtemps, ZF sortira en 2.0 normalement d'ici la fin de l'année.

Concernant l'ORM, il y a Doctrine 2 qui est sorti il y a quelques temps qui est l'ORM le plus puissant pour PHP. Malgré qu'il soit conçu par une partie de l'équipe de Symfony, il peut s'utiliser aussi bien avec ZF qu'avec Symfony.

Personnellement j'ai toujours utilisé ZF, que je trouve assez puissant. Il fournit un "mini" orm utilisant les patterns row data gateway et table data gateway (ça ressemble à active record), donc assez basique et classique; tandis que doctrine 2 utilise le pattern data mapper. L'avantage de Doctrine 2 est qu'il ne se contente pas d'un mappage classique (càd : une ligne en base = une classe php, chaque champ de la table = une propriété de la classe), il te permet de faire du vrai orienté objet.
Attention Doctrine 2 n'a rien à voir avec la version 1, la philosophie est complètement différente, ce n'est pas du tout compatible.

Même pour une dizaine de page c'est toujours utile un framework, car il y aura forcément des bouts de code communs, et plutôt que de faire un système maison, autant utiliser des outils qui sont optimisés pour ça. Maintenant les frameworks demandent évidemment un apprentissage, le simple fait d'en utiliser ne garantit aucunement d'avoir un code propre Mais ça c'est valable pour n'importe quelle techno

Et n'oublie pas d'utiliser git pour versionner tes sources

Code igniter semble super pour un "petit" développement ORM...
http://codeigniter.com/

Mais faut voir jusqu'à quel stade on ne va pas s'y sentir à
l'étroit et regretter l'investissement en temps d'un symphony...

Maintenant, effectivement Doctrine2 semble devenir la norme, faudrait peut-être choisir un FW qui le respecte...

Doctrine 2 peut s'utiliser avec n'importe quel framework php, voir même sans framework

Oui, cela se mélangeait un peu dans ma tête entre FrameWork, DBAL, MVC et ORM.
Il me parait évident que du ORM/DBAL va me/nous simplifier la vie (je vais re-écrire pour la Xème fois une librairie d'appel à des fonctions SQL)

Par contre, dans notre (petit) cas, je ne sais pas si on se paierait le luxe d'un MVC/Framework: on n'a clairement pas bcp de page à présenter, cela dit, on peut vite gagner en temps, clareté, maintenance et re-utilisation de code avec un FW.

Le plus léger, simple et rapide (disent-ils) c'est Code Igniter.
Il semble bien documenter.

Après, c'est un peu l'oeuf et la poule: je commence par quoi?
J'écris mes tables SQL ?
Je fais mes classes ORM?
Rah que d'excitation et de download et de lecture en vue!

Avec Doctrine 2, tu dois d'abord créer tes classes, et ensuite il y a un script à appeler qui va transformer tes classes en tables sql

ové> Yep trouvé! Merci encore...
M'amuse comme un fou!
Après je verrais si je veux un Framework.
Reste toutes les question SQL (HW/SW), mais faudrait un jour que je tombe sur un pros de la question...

Détaille

Bah prends un café, cornichon! relis mes points I. et II.

Ah oui OK

Je ne suis pas spécialiste DBA, mais si tu utilises le moteur InnoDB de MySQL tu bénéficies d'un support SQL bien plus avancé qu'avec l'antique MyISAM. A voir pour ton usage si c'est suffisant. Je pense que postgresql est plus adapté pour de grosses bases, ou des besoins avancés, mais InnoDB devrait suffire pour une base "simple".
http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

MySQL n'est pas dans la course (même après lecture de ton très bon comparatif)
Il s'agit uniquement de tunner-sa-mère à PostgreSQL.

Tu veux prendre ton pied à configurer postgresql hein, avoue

Euh, juste pour savoir, tu estimes à combiens d'insertion de records/heure active?

ové> héhé, quand on est pas gamer, on trouve d'autres justification pour faire du perf-p0rn !

gizmo> Bonne question et probablement bon point de départ: nos tables (de paquets) sont bien plus longue que large (une 20aine de champs en largeur: timestamp, signature, tos,...) mais en longueur...biggre, imagine que tu gardes une entrée pour chaque paquet vu sur le gateway d'une TRES grosse boite en ne gardant que le port 80,25,443 et 110. (c'est un exemple) Bref, VMT bcp.

J'en avais presque oublié le sujet du projet Dans ces cas-là une DB n'est ptêt pas la meilleure solution

Un bon p'tit prog en asm ?

En effet, il y en a ici qui remettent en question la validité d'une DB pour des flat-files (teeeellement plus performants)
Je peux tout entendre, j'aime mieux avoir des chiffres.
Mais rien ne compteras plus que nos chiffres/benchmark..bref, y a du boulot.

Honnêtement là je ne suis pas spécialiste, je ne saurais t'aider à faire le bon choix

Et sinon qqun a déjà joué avec des Reporting Tools opensource?
Genre le Crystal report c'est le pied?