Thank you all.
(elements of this post use Linux-based examples and thus require translation/generalisation to cover other OpSys)
Unfortunately, I do not have a GitHub (or any other Microsoft, Apple, …) ID. Otherwise I should follow @_az’s recommendation.
@schoen’s summary applies: in log analysis the principle is to manage by exception - we are really only interested in a log-entry when it reports ‘failure’. The exception to this is ‘statistics’, which I can only imagine would be (in this example) “4/4 Certificates are current”.
I can’t categorically state that when a Let’s Encrypt certificate is due for replacement and if the certbot-auto operation fails, what is (not) included in such a log-entry. It is apparent that the certificate name is not included in ‘no update needed’ situations (and it will be a while before I can view the log covering an ‘update-needed-and-worked-happily’ scenario).
Kudos to the authors, in that I have only experienced one ‘log-able’ error with the Let’sEncrypt routine/regime, and that was due to updating certbot before CentOS7 was ready - hence moving to certbot-auto. That problem was notified by a cron alert, and thus wouldn’t/didn’t get as far as the letsencrypt log!
Now, back to the ‘problem’ and proposing a solution:
i) I recommend that EVERY log entry include the name of the certificate to which it pertains, ie that the current “cerbot.cli” or “certbot.renewal” (becomes more specific); when possible/applicable. This will enable/ease log post-processing and administrative reporting.
(further)
ii) I recommend the inclusion of a switch in the (/etc/letsencrypt/)cli.ini configuration file to allow administrators to select a logging level, ie to be able to exclude DEBUG communications. This will reduce the volume of log-entries (a somewhat weak justification!), and improve readability for more mature installations. (cli.ini should be installed with the ‘maximum setting’ and alteration be a user-choice and require deliberate (SysAdmin) user-action).
NB recommendation (i) is likely a more appropriate solution (in this scenario) than, but may have the effect of reducing use-cases for the “failure hook” proposal.
Thanks for the good work and for effecting wider security across the web!
=dn