Module: Event Logging

All files from this thread

File Name	File Size		Posted by	Date
event_logging-1.0.9.zip	32.5 KB	open | download	Oliver Riesen-Mallmann	09/10/2015	Read message
event_logging-1.0.9.tar.gz	24.7 KB	open | download	Oliver Riesen-Mallmann	09/10/2015	Read message

I am using Phorum 5.2.7 and wondered why my weekly Phorum database backups for a single phorum installation have already grown to about 3.3 GB!

So I checked which table was the biggest and saw, that the _event_logging table had already collected about 4.500.000 (!) entries, although I had set up "Maximum amount of stored event logs" to 500 (Debug level, every event option checked).

Is this a known issue?

Regards, Ulf Dunkel

hmm, deletion of logs seems to be only done on checking the logviewer in the module settings.
guess its to expensive to run on each pageview.
Maybe maurice can comment on this further.

---

Thomas Seifert

Thomas is right. Handling that at log time makes the module do more queries on the front end than I'd want it to. If you do not look at the logs, then better disable the module completely.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

Quote
Maurice Makaay
If you do not look at the logs, then better disable the module completely.

As a sys admin I disagree with this statement. On many of programs I have logging enabled to store a couple days worth of data. If everything runs smoothly, I never look at the data. However, if there is an issue, I generally hear about it within that day or two before the log data gets deleted. Then I can confidently open the logs, knowing the data I need will be there. I don't have a ready idea for how to balance the overhead with the need for a certain period of logs, except to have the option of saving X days of logs and deleting any older logs on every common.php load. It might be overhead, but it should be spread out some.

---

Joe Curia (aka Azumandias)
Modules: l0Admin Mass Email00000000l000000Automatic Time Zones000ll.l00000Enhanced Custom Profiles0.00Google Calendar0000l.l000000Post Previews
000000000Admin Security Suite000000000000Check Modules for Upgrades0000External Authentication000000Group Auto-Email00000.00000Private Message Alerts
000000000Attachment Download Counter0000Custom Attachment Icons000ll.ll00Favorite Forums000000.00000Highlighted Search Terms0000Self-Delete Posts Option
000000000Attachment Watermarks0l00000000Custom Language Database00l.l.0Forum Lockdown00000.00000Ignore Forums0000000000000Threaded Tree View
000000000Automatic Message Pruning00.llll.00Easy Color Scheme Manager0l.l00Forum Subscriptions0000lll000Moderated User Group
Templates:lGeneric Integration000000000 0000Simple Rounded000000 00000000Tabbed Emerald

Hi Maurice,

of course I already switched the module OFF for now and also cleared the relevant MySQL table. But - the option to set up a maximum amount is rather irritating if it isn't used somehow, isn't it?

I would appreciate if the log stuff would not be written to the MySQL table but instead into something like the well-known log files in Apache. Is this a better approach or is writing to physical files on the servers hard drive even more "expensive" in terms of load and time?

Regards, Ulf Dunkel

Writing it to the database is by far the best option, since it won't cause trouble with file permissions and best of all: it makes the logs searchable through SQL queries. When logging to files (e.g. to the apache error log by spitting out log messages on STDERR), we'd loose the opportunity to view the log messages easily through the admin interface. And being able to view log messages in there was one of the big goals, because we get questions all the time for which we'd love to see logging, but where the user does not know how to get to the PHP logging.

@Azumandias: I agree, but since the module does currently not clean up the logs, my statement stands. When we make changes to do some cleanup on other occasions as well, then it's of course okay to let the logs flow.
With 4.5 million entries, it looks like the module's logging info isn't really used though.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

@Maurice: I agree with your explanations. :-)

Regards, Ulf Dunkel

Maybe write a cronjob that gets run once a day to remove entries older then X days?

I am a longtime contributor to these forums but have been absent since about version 5.2.9 :-(.
I have recently upgraded and that went very smoothly, thank you Phorum team!

However, last night I installed the StopPhorumSpam module and noticed it did logging, so I enabled the Event Logger.
This morning my server had crashed as the phorum_event_logging table had eaten up all my disk quota.
Like the OP, I had assumed that setting a maximum number of events to log would prevent that from happening.
I've had to spend about an hour on the phone with my provider to get a temporary quota high enough to repair all my corrupted tables and optimise phorum_event_logging back to a sane number of records.

I'm in no way complaining about this, I just want to warn other users to be careful.

Also, I think the module popup help text should be reworded:

Quote
Phorum help text
Maximum amount of stored event logs
This option configures the maximum amount of event logs that can be stored in the database at a given time. If the amount of event logs grows larger than this configured maximum, then old entries will be automatically cleaned up.

I feel it should be made clearer that "automatically" actually means "when you view the logs".

Also, I would like some advice on how I can still use the event logger without having to worry about disk space.
Does anybody have a script I can use with a cronjob that hooks into the maximum log value set by the user and truncates the table to that value?

Thank you,

/\dam

--
My notable Phorum sites:
Movie Deaths Database - "review comments" system mostly powered by Phorum
Learn Chinese! - integrated forum quiz




Edited 1 time(s). Last edit at 10/12/2012 11:16AM by sheik.

"Maximum amount of stored event logs" is the number of events that are stored, not the amount of storage to use.

I feel it should be made clearer that "automatically" actually means "when you view the logs". - this works, I keep a max of 500 events and the old ones do get dropped off (this results in a 1.6M table size).