Bring runtime log level changing to the backoffice (using Serilog's LoggingLevelSwitch?)

[JasonElkin]

Serilog supports changing the logging level at runtime.

It would be great if this could be implemented in Umbraco so we could change the logging level via the backoffice. Changing the logging level on the fly would be a great help in debugging problems without having to make config changes, trigger restarts/deployments etc.

[nul800sebastiaan]

That sounds like an excellent idea indeed! If we could add a dropdown here to do the switch then that could work really nicely!

I don't know if @warrenbuckley has some more thoughts on this as he implemented the current logging dashboard to begin with?

What happens when the app restarts and reads the config file again? I think it will revert to the previous situation unless the dropdown also updates the config file. However, config changes would probably be overwritten on next deploy.

So I guess it would be really good to note, when switching: this is a temporary log level change, it will revert to something when the app recycles and might not survive a deploy.

[JasonElkin]

Thanks @nul800sebastiaan dropdown there sounds good.

It's probably best that the level is reset after a deployment/recycle. Logging is not free and I can imagine it being set to debug to solve a problem then forgotten about, using extra resources for no good reason.

I wondered whether even waiting for the next recycle might be too long? We could add a "Reset to after " option in the UI so that a task can be scheduled to change it back to what it was.

[nathanwoulfe]

What about similar to Cloudflare, where turning on debug is automatically turned off after five (10?) minutes? No need for an additional input, just make the operation time limited...

[nul800sebastiaan]

That's all nice and good but the next question: "I want to monitor something that happens every 2 hours, can I please get an input for the number of minutes?"

I would say make it clear this won't survive a recycle or deploy, warn that logs are going to start filling up diskspace.

If that is actually going to give loads of problems, we should talk about additional options. Keep it simple, learn and iterate.

[nathanwoulfe]

True true - would expect too that users with access to the log viewer would be admin/technical types, so should understand the implications of changing log levels.

[warrenbuckley]

This sounds a good idea and was something I considered at the time, however I can’t remember why I didn’t implement it 🤔

[nul800sebastiaan]

In summary, yes, we'd love this feature!

To summarize:

• A dropdown where the current log level is now displayed, to change to a different log level
• Add a warning when increasing the log level that the added verbosity will lead to a lot more disk activity and larger files
• Add some information saying: this will revert again when the app restarts or if you deploy (maybe both of these could be under an ℹ icon?)
• Don't worry about automatically reverting for now

For the messages, maybe try

ℹ Note this is temporary (when hovered/clicked, explain)
⚠This leads to extra disk activity (when hovered/clicked, explain)

[nul800sebastiaan]

I thought I'd be able to convert this whole discussion to a feature request, but I guess it's only one of the comments, which is fine, I just linked the new up-for-grabs feature request to this discussion for the full details 👍 #10484

[nul800sebastiaan]

I'll lock this conversation and anything new can be added to the related issue.