You could also probably easily adapt the Mailgraph.cgi tool to graph those additional stats.
http://people.ee.ethz.ch/~dws/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.

-Rob

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

--
Robert A. Pickering Jr.              SixDoes IT Solutions

"I just the other day got, an internet was sent by my staff at 10 o'clock in the morning on Friday and I just got it yesterday. Why? Because it got tangled up with all these things going on the internet commercially." -- Sen. Ted Stevens (R-Alaska)


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

Reply via email to