Guys guys, nobody else talk? :PP
(it's just to test that the mailling list is not dead again sinse it was
quiet today)
Jorge
----- Original Message -----
From: "Jorge Bastos" <[EMAIL PROTECTED]>
To: "'DBMail mailinglist'" <[email protected]>
Sent: Thursday, September 13, 2007 9:46 AM
Subject: RE: [Dbmail] Log table
I agree Josh with some parts you wrote,
These log tables, are two different things, one for login/logout for
pop3/imap for statistics, and the 2nd for the delivered messages.
So having the possibility to have this "subsystem" where the sys admin can
chose, to enable/disable it, and if enable to chose to write to a
text/xml/ascii with separated with ";" file, or MySQL/PostGreSQL/SQLite,
and
when writing to one of the *SQL systems have the chance to define the
"host/user/pwd/database", so that can improve performance for things like
in
your case, the admin choses, or in the same server/database, or in
another,
and then the admin makes the server performance.
I have on the wiki this two ideas for 2.3x, with this discursion, we could
write all something like a final statement that fits for all (like Aaron
said) and then rearrange the things on this two pages.
My Sugestion is to start writing it here on the list emails and when
everybody approves it, including Paul and Aaron of course, let's put the
final results there.
People for who this king of function doesn't matter or don't want they
have
their problem resolved since this will have an on/off parameter.
http://dbmail.org/dokuwiki/doku.php?id=mail_trafic
http://dbmail.org/dokuwiki/doku.php?id=log_conn
Jorge
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Aaron Stone
Sent: quinta-feira, 13 de Setembro de 2007 5:05
To: DBMail mailinglist
Subject: Re: [Dbmail] Log table
This has been a great thread. I've read everything. I had been on the
side of a logging table, and I do think that this may be important, but
there have been excellent arguments for much, much more flexible hooks
to other reporting formats that I hadn't thought of at all.
I suspect a lot of this discussion will end once there's some good code
for us all to use, but until then, keep the ideas rolling (and let's
wiki some of these proposals, too!).
Aaron
On Thu, 2007-09-13 at 08:14 +1000, Josh Marshall wrote:
Hi All,
I'm actually happy that my small protest generated a lot of discussion
(I don't want to call it arguments) - it has pointed out that one
person's idea might not fit all, but at least with a number of differing
opinions it is easier to make a decision on the best option.
My mail log is over 300Mb per day. I have three mail servers connecting
to a MySQL server that is fault tolerant thanks to heartbeat and drbd.
My bottleneck is the MySQL server. By adding these logs to the MySQL
server I believe my customers are going to suffer performance issues,
whether it be due to the constant inserts (remember inserts are more
costly than updates) or due to the increase of data space on the server.
There have been suggestions in this thread that we log more data to the
database than is currently going to the logfile, so my 300Mb per day
could increase to maybe 1Gb depending on the level of data going in for
statistics.
I really do like the idea of a plugin for the statistics, so that I can
choose to log these to a file, to a mysql or postgres database. If I can
send these to a different mysql database then I am less concerned about
it being a performance issue (especially if the inserts were set to not
wait for the database to complete the transaction). If the fields and
operations that were logged were able to be selected in a fine-grain
manner then we could all get the data we require. As long as this
doesn't take a lot of development effort and doesn't have the potential
to introduce a lot of new bugs then I see this as an improvement to the
software that would be useful to administrators of smaller installations.
Please don't get me wrong, I do get annoyed at being asked to wade
through 2 million log lines to find out information for a customer, and
I do think that the statistics in dbmail would be useful for some. But
it is still not going to contain all the information one needs,
especially since a lot of the questions are "why was my message bounced"
or "did this message get delivered externally" which in my case is
Postfix's job, and they don't log to the same database. So I have to go
to the logfiles anyway, or run a log watcher that places data into a
mysql table for me.
Regards,
Josh.
Paul J Stevens wrote:
>
> I kind of agree with Vladimir and Josh: though I understand the
> usefulness of wiz-bang usage statistics I don't see stuffing all that
> information in the dbmail database as good design.
_______________________________________________
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
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
