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
