Bonsoir tout le monde,
pour ce qui de l'utilisation de rrd comme système de stockage, on peut
oublier cette solution. L'intitulé des chaque variable (DS) est limité à
19 caractères
(en anglais sur le site officiel : "A /ds-name/ must be 1 to 19
characters long in the characters [a-zA-Z0-9_].").
Donc, on est re-parti pour du bricolage :
voici un synopsis :
Sur postfix (facile)
1) parse du mail.log sur le serveur postfix pour chaque domaine
2) mail du résultat (dans un fichier) vers un compte "gestionnaire"
Sur OBM (plus tordu)
3) lecture du message et rapatriement du fichier dans un rep de stockage
pour le format du nom de fichier, j'étais parti sur quelque chose du style :
[domain]:[alias]:annee:nr_semaine:mois:jour.txt pour les stats quotidiennes
[domain]:[alias]:annee:nr_semaine.txt pour les stats hebdo
[domain]:[alias]:annee:mois.txt pour les stats mensuelles
[domain]:[alias]:annee.txt pour les stats annuelles.
Pas besoin de bases de données
Reste, maintenant, l'avis des dev. OBM surtout au retour des vacances :-\
A plus,
Pascal
Pascal salaun a écrit :
GARCIA a écrit :
Quoting Pascal salaun :
Bonjour tout le monde en ce samedi radieux pluvieux,
je vais aborder2 points :
1) Les scripts de stats :
je me suis conformé aux directives , et donc pas de connexion au SGBD,
pas de liens symboliques.... d'où la dernière mouture des 3 scripts
de stats.
J'en ai profité pour raccourcir un peu le nom ;-)
Par ailleurs, je dois traiter des stats par utilisateur (nb et volume
émis). Est-ce que vous auriez un moyen, une piste pour rapatrier le
résultat vers OBM ?
Munin, dans ce cas précis, n'est pas adéquat. Les logs seraient du
style :
user nb_emis vol_emis
karl.marx 1 4973
wolfgang.mozart 4 413491
dave.brubeck 2 6733
roger.gicquel 5 98180
lamere.denis 7 1906032
pierre.labbe 14 3047238
....
 Non, actuellement je ne vois comment faire, les propositions sont les biens
venus, le but étant de trouver un moyen qui ne ressemble pas à du bricolage.
 En effet munin ne se porte pas pour cela:
 - faire un graphe pour tout les user va devenir illisible
 - faire un graphe par utilisateur serait mieux, mais bon ça va en générer
beaucoup
 Dans quoi voulez-vous stocker ces données? Voulez-vous utiliser une base
rrd? Comment voulez-vous présenter les stats à l'écran?
Bonsoir,
je vais quand même regarder d'un peu plus près munin et sa façon de
stocker les datas (dans ses rrd).
c'est le seul canal ouvert entre postfix et OBM (je pars du principe
qu'il y a un pitbull entre postfix,cyrus & obm)
C'est juste une question de temps.
@+ et bon courage pour la 2.3
Pascal
2) Un bug que j'ai rencontré au boulot, et que j'ai reproduit chez moi
:
la mise à jour incrémentale via le fichier update.pl déconne quand la
table Deleted fait référence à un user inconnu.
Pour reproduire le bug :
- j'ai créé un user via OBM, mais je n'ai pas 'commiter'
- dans la base SQL, j'ai ajouté une entrée :
mysql> insert into Deleted
(`deleted_domain_id`,`deleted_user_id`,`deleted_table`,`deleted_entity_id`)
values ('2','2','UserObm','1000'); //2 =userid d'un admin existant , 2=
un domain_id existant, le user nr 1000 n'existe pas
et en console j'ai lancé le script : ./update.pl --domain 2
--incremental
=> résultat : pas d'entrée dans la table de Prod, la table Updated
tjrs alimentée... enfin bref le bo....el
Sur ce, bon week-end à toutes et tous.
Pascal
--Â
sylvain garcia
_______________________________________________
Obm mailing list
[email protected]
http://www.list.aliasource.fr/mailman/listinfo/obm
------------------------------------------------------------------------
_______________________________________________
Obm mailing list
[email protected]
http://www.list.aliasource.fr/mailman/listinfo/obm
_______________________________________________
Obm mailing list
[email protected]
http://www.list.aliasource.fr/mailman/listinfo/obm
