That's why this is important to be dbmail job.

Nothing else will give you the login/logout and extra information I said.

 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Anne
Sent: quarta-feira, 12 de Setembro de 2007 12:19
To: DBMail mailinglist
Subject: Re: [Dbmail] Log table

 

I said *such a tool* is the only correct way to get the stats you want.
If it doesn't exist (which would surprise me), I suggest you make one :-)




That doesn't give me the information I want.

Where's the login/logout information? Dates, times, etc?

 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Anne
Sent: quarta-feira, 12 de Setembro de 2007 11:58
To: DBMail mailinglist
Subject: Re: [Dbmail] Log table

 

We use "mailgraph" for mail statistics.
This tool extracts data from the logfiles and keeps its own database.
http://mailgraph.schweikert.ch/

IMHO such a tool is the only correct way to get the stats you want.
dbmail should *not* be used for storing metadata!

Anne





The point is:

For delivered messages, if you want to confirm something two weeks ago, with
syslog you won't be able to get that information.

My server has some high traffic during the day, and my syslog files get
around 80MB a day, I delete them every Saturday night, there it goes the
logging information.

A syslog file with 80MB of data, will represent in a 10 or less in a MySAM
table.

 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Marc Dirix
Sent: quarta-feira, 12 de Setembro de 2007 11:05
To: DBMail mailinglist
Subject: Re: [Dbmail] Log table

 

 

A server with that kind of simultaneous logins will not be a P4 3.0GHZ with
HT and 1GB of RAM for sure.

 

Please stop assuming that the key to add more scalability is to throw more
(expensive) hardware at it.

DBMail already is pretty generous in the harddisk space it takes, adding
more to it will slow it down exponentially.

 

Although I can see the point in having more database statistics in the sort
of "last_login, total_bytes, total_messages", dissagree implementing

this in a growing table fashion.

 

But agree with Josh and Vladimir and Paul: we do *not* want to replace
syslog, syslog is in general sufficient for admins to look into
mailproblems.

 

 

Marc

 

 
 



  _____  



 
 
  
 
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
  

 

 



  _____  



 
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
  

 

_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Reply via email to