I have seen (and have been instructed to use) the moodle log as a place for logging the following:
General information for debugging REST API calls (info level)
External REST API call failures (warning / error level)
Configuration errors during schedule tasks (warning / error level)
For these kind of actions it feels like Moodle's events system is possibly not a perfect fit.
I say this for the following reasons:
1) AFAIK it's not possible to attribute a log level to an event and thus only write to the log if a specific level of sensitivity is required.
2) Events can be subscribed to - all I want to do is log something and not have subscriptions to the event.
3) The moodle log seems traditionally to be based around user activities as opposed to API call failures / etc..
So my thoughts are as follows:
Should it be possible to write to Moodle's log without having to use an event AND should it be possible to set a log level for the entry - i.e info/debug/warning/error/critical ? Is it worth creating a tracker ticket to modify core to allow for this ?
Or for this kind of logging requirement is it best to just roll your own (which I have done in the past using the PHP PSR logger package).
Opinions and thoughts on this would be greatly welcome.
This is something we've struggled with in our institution for a while too.
I think it's fair to say that the Moodle log system is for meaningful user events and that kind of thing, so instrumentation logging doesn't belong in there. The closest there is in Moodle is the debugging function in weblib, but there's no control over where the messages appear, and it can play havoc with unit tests if you try to use it for instrumentation.
I'd love to see a configurable PSR style log for the instrumentation side of things, but I'm not aware of anyone working on it. I definitely think it's worth creating a tracker issue.
This is something that's bugged me for quite a long time, and I got (probably rightly) dissuaded from using DEBUG_DEVELOPER as a mechanism to dump instrumentation measures.
I'd love to see some thing a bit more like unix-style verbosity, and allowing debugging statements to be re-directed to other places.
Part of the problem is that Moodle logging is primarily against educational activity. The logging (I really mean logging framework) for a forensic and performance basis (IMHO) isn't there.
There's an analogy in my mind that if you image Moodle as an F1 car, it's really good at producing the information that is displayed to the TV viewers, but it's no good at providing the real-time telemetry that would be used by the pit.
Have you enabled this: https://github.com/moodle/moodle/blob/master/config-dist.php#L349 (with PERFTOLOG)?
At times where you think you have idnetified a specific problem then you probably want a profiling tool to work out what is happening. https://docs.moodle.org/dev/Profiling_PHP / https://tjhunt.blogspot.com/2013/05/performance-testing-moodle.html
Thanks for the suggestions Tim. The problem is not so much about general PHP errors or profiling, it's more that there's nowhere to log operational info, warnings, errors or critical issues to a place that non-server admins can access.
Let me give you an example -
Developer creates a new local plugin which attempts to write data to a 3rd party via a REST API as part of a scheduled task.
On occasion the end point goes down due to issues with internet connectivity at both ends.
When this happens the developer wants to log this incident (which is not technically a PHP error but an operational error). The developer wants the Moodle admin (who doesn't have access to the server logs) to be able to see these issues in a log.
Also, for new site installs, the Moodle admin would like to be able to see all API calls made between moodle and the 3rd party. This is just so that they can make sure things are being sent as expected during the on-boarding phase.
So we have two different levels of log required here - error & info. With a PSR log you can specify the log levels and hence adjust the log sensitivity. There isn't anything available as far as I know in Moodle to do this. I guess logging a ticket as @Michael Aherne suggested is the way forward here.
In the example you give, I would log this to the PHP error log, using debbugging('...', DEBUG_NORMAL);
And, if it was really important, I might also log it to the Moodle log.
(And, I am not just saying this. Two days ago I did exactly this, for the SOAP API call one of our plugins makes to another OU system.)