[PLU-25] Support for optional logging to file

[kbergha]

I installed this plugin today in trial mode, and after taking it for a test run, I have the following feature request:

Would you consider adding support for optional (limited) logging to file as well as to the DB?

I guess I'd modify _saveRecord() after the record has been saved in services/AuditService, and add a call to Craft::info() or Craft::getLogger()->log(some-params), and set the category parameter to "audit".

This will only happen if the user/admin has configured the plugin to also log to file.

I could probably do a first version as a PR if you want, and the idea is not terrible?

Why? Because we want to have a central place for audit logs from our different systems, and are using ELK-stack to do this.

New configs for plugin:

• Log to file (boolean, default to false)
• File log category (string, default to "audit")
• File log level (?) - or hardcode to INFO?.

Limitations:

• It' probably not a good idea to try to log the whole serialized "snaphot" (?).
• Pruning won't work for file logs.
• Any other?

_PLU-25

[sjelfull]

Totally makes sense, and it's something I have considered, along with possibly adding different logging "drivers".

Agree its not a great idea to log the whole snapshot, but it could possibly configurable to have a list of attributes/a callable that lets you configure what if any data should be logged to files.

Pruning could be added too at some point, maybe via a console command instead.

[kbergha]

Cool.

I don't think drivers are needed as long as you're using the vanilla Craft::info()/warn()/error() or Craft::getLogger() functions.

Then you can configure whatever you need for logging inside config/app.php. See https://www.yiiframework.com/doc/guide/2.0/en/runtime-logging#log-targets for details. It's very flexible, you could filter out audit messages to your own "driver"/"target", as is done for the yii\db\*-stuff in the Yii-docs in the link above.

I need something like this for my current project asap, and started to make a mini-plugin earlier today just to get back into Craft plugin development (https://github.com/kbergha/craft-revisjonsspor). It's just scaffolding from pluginfactory.io for now, but I'll work on it in the next few days. This won't be published to the plugin store - at least not without your permission.

If I develop what I need there first, you can take a look at it and copy the relevant stuff into your plugin (I might have to change the license first)? Or I can make a PR when I feel a bit more confident about the whole Craft plugin system? Or do you want to do it all by your lonesome?

;o)

[JoshCoady]

If you enable logging to file, it would allow doing some other interesting things, like logging to AWS CloudWatch Logs. Because if you log to file, you can set on the system the file name to be logged to as a symlink to std out and if you are running Craft as a service on AWS you can configure it to send everything from std out to CloudWatch. Then log retention can be dealt with on the AWS end and need not be a concern for the plugin.

That's what I would do if this had log to file in addition to DB. DB would prune after 30 days and provide immediate access to recent changes. Changes over 30 days would be available forever via CloudWatch.

[caldini-projects]

The use case described above to enable monitoring by AWS Cloudwatch would be super helpful.