That's what i got this night ..... Graph is zoomed because i dont have a full daily period yet ....
http://img225.imageshack.us/my.php?image=policydstatisticsfb6.jpg Seems i'll have to tweak colors, but the idea is OK and running ! Does anybody here thinks this would be a great idea ? Cami, would you accept a patch for this idea ? If yes, i can try .... Leonardo Rodrigues Magalhães escreveu: > Now i have to wait some hours and see what is going to happen in > business hours :) > > Get me one or two week day and i'll probably post what i got :) > > Robert A. Pickering Jr. escreveu: > >> You could also probably easily adapt the Mailgraph.cgi tool to graph >> those additional stats. >> http://people.ee.ethz.ch/~dws/software/mailgraph/ >> <http://people.ee.ethz.ch/%7Edws/software/mailgraph/> >> >> It's already parsing for "spam", "rejected", "bounced", "received", >> and "sent". Shouldn't be too hard to extend it to handle the policyd >> stats. Or even just completely change it to only do the policyd >> stats, and create a separate tool that graphs just policyd. >> >> Frankly, I just use the plain mailgraph to see a nice comparison of >> life before policyd and life after (very low spam, reduced received >> messages, and very high number of rejects). However, I can see how it >> would be nice to see what it's doing with all the lists. >> >> >> On Jan 7, 2007, at 7:49 PM, Leonardo Rodrigues Magalhães wrote: >> >> >>> Hi Cami, >>> >>> I'm rewatching my logfiles and rebuilding my whitelist and blacklist >>> dnsnames entries. >>> >>> While i was doing that, i was thinking of maybe an easy way of >>> monitoring policyd accept/blocking of messages, basically for getting >>> this information and throwing at some Cacti/RRDTool graphic. I noticed i >>> wouldnt be able to do that easy: i would have to grep log, count things >>> ...... it's possible, but it would have high cost, because i deal with >>> some BIG logfiles ... even rotating them daily, they get pretty big. >>> Grepping them every 5 minutes wouldnt be nice for I/O. And i dont want >>> that :) >>> >>> So, i was thinking of maybe getting policyd a new feature .... a >>> statistics table that would hold basically two columns: one for the >>> action name (whitelist_dnsname, blacklist_dnsname, greylist=new, >>> greylist=update, blacklist_helo, throttle actions and all the others) >>> and other column for an integer/big-integer counter, that would always >>> receive +1 when that action happens. That could be done in a single >>> query: update statistics_table set count=count+1 when >>> action_name='something'. >>> >>> With this table, which i dont think would be that hard to implement, >>> some easy perl/PHP script could be written for grabbing the information >>> and making some monitoring graphs build VERY easily. >>> >>> Updating tables always have some I/O cost ..... but as this being a >>> very small table, even we have 40-50 actions, i doubt it would increase >>> I/O in a noticable way. But of course, this can be easily be a >>> configurable option. >>> >>> What do you think on that ??? >>> >>> >>> -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email [EMAIL PROTECTED] My SPAMTRAP, do not email it ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ policyd-users mailing list policyd-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/policyd-users
