-
Use a file to write the events to. There are several drawbacks here;
- Filesystem permissions. When you deploy your app, you will have to take care to remember to give the webserver permission to write to the file. And to be extra sure, you’d have to write code which checks whether you can write to the file and issue a warning when you can’t. This adds complexity and is likely a cause for deployment issues.
- Accidental deletion. You could accidentally delete the custom logfile and loose your records. This might be inconvenient.
- Custom logformat. You’d have to come up with a custom (machine readable?) text format to write the events to your file. When you have to change the log format, there’s no convenient way to migrate old records. When you want to do some kind of analysis on the logs, you’d have to parse the records. This leads to more code and more complexity. Complexity is bad.
-
Use a database table. Create your own database table and log the events there. None of the drawbacks listed above apply. It doesn’t add a lot of complexity. Automate the creation and deletion of the table using a plugin hook and you have a reasonably reliable log system I think.
-
Send an e-mail. Depending on the relevance of the logs, you could always opt for this method. I figure you’d probably want to send an e-mail in case of a failure anyway.
-
Use the OS logger. When you use the syslog function in PHP, you can write events to the system logger (syslog on Unix, Event Log on Windows NT). Configuring a user defined syslog complicates deployment.
Finally; you should consider if you want to log the normal case and exceptions, or only exceptions. Jeff Atwood did a good writeup about this.
Hope this helps!