The current logger configuration in zope2instance recipe is currently very limited under WSGI (due to the hardcoded wsgi template within the package). Since I have time and resource and some budget I would like to extend the zope2instance logging options the following way.
- for the event and access log we need support for FileHandler, RotatingFileHandler and TimedRotatingFileHandler (as available through Python's
- I would like to extend the zope2instance configuration by a new option
event-log-handler=s(same for access-log) which would directly map to the
classoption of the related handler section in wsgi.ini:
event-log-handler = FileHandler # default event-log-handler = logging.handlers.RotatingFileHandler event-log-handler = logging.handlers.TimedRotatingFileHandler
I would deprecate (or even remove) the options
event-log-old-files which are specific to the RotatingFileHandler.
Instead of hard-coded options for specific logger types I would prefer a more generic approach like
event-log-args = "when='h', interval=1, backupCount=10"
which would be used to construct the
args option of the
wsgi.ini file e.g.
[handler_accesslog] class = logging.handlers.RotatingFileHandler args = ('/home/ajung/sandboxes/ugent-portaal-plone-4x/var/log/instance-access.log','a', 5000, 5) level = INFO formatter = message
The generic approach would allow us to configure any arbitrary logger with arbitrary constructor as access and event logger.
I think this would cover most of the logging usecases.
I do not see any equivalent for the
access-log-custom options which are specific to the ZServer within a WSGI environment.
In order to provide a complete custom wsgi.ini configuration (if needed), the recipe should provide an optional option
wsgi_template = /path/to/my_wsgi.ini which would be used instead of the hard-coded WSGI template inside the recipe's code.
Mail logger: a mail logger (via
logging.handlers.SMTPHandler) could be configured in the same way. The current maillogger component for ZServer supports string interpolation for dynamic mail subjects (e.g. to include the
hostname within the subject). Email subjects in this configuration approach would be static unless there is a way to hook somewhere and somehow into email generation code).
Note: some people use external tools like
logrotate or approaches like mentioned in https://pypi.org/project/tha.logcheck/ but I do not personally like this kind of dependencies that are usually configured on the administration level by
root or by some administrator....but this is highly personal and depends on your operational requirements.