Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

log-level-overrides does not permit spaces in value string #1063

Open
patanne opened this issue Mar 21, 2024 · 1 comment
Open

log-level-overrides does not permit spaces in value string #1063

patanne opened this issue Mar 21, 2024 · 1 comment
Labels
🪲 bug Something isn't working

Comments

@patanne
Copy link

patanne commented Mar 21, 2024

I would like to leave the logging level of the server on INFO. However having an entry for server stats every hour is a little too much noise. So for "server stats" I want to set the level to WARN. The log-level-overrides entry should be this, but doing so causes the server load to fail:

"message=Server stats -> warn"

In digging through the code I found the following regex in ntfy/cmd/app.go, line 31:

(?i)^([^=\s]+)(?:\s*=\s*(\S+))?\s*->\s*(TRACE|DEBUG|INFO|WARN|ERROR)$

The culprit is "\S+". Changing the regex to this works, if this is a bug:

(?i)^([^=\s]+)(?:\s*=\s*(.+))?\s*->\s*(TRACE|DEBUG|INFO|WARN|ERROR)$

You as the authors of the code may have done this on purpose because multiple words (and the whitespace that comes with them) could break search logic deeper in the code. Is this a bug or a choice?

@patanne patanne added the 🪲 bug Something isn't working label Mar 21, 2024
@mpeter50
Copy link

mpeter50 commented May 1, 2024

This issue is even worse in the default configuration, where the long line of statistics is printed to the log every minute.

While the server stats log messages cannot be filtered, an other option is to set the manager-interval config value.
The docs say this about it:

Interval in which the manager prunes old messages, deletes topics and prints the stats.

The default value of it is 1 minute, but if you increase it to an hour or a day, it might be less of a problem.
Actually, for me filtering the messages would have been the workaround, this (less frequent stats logging) is the solution I was looking for.

If you make use of this, don't forget that this also affects the execution of cleanup operations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🪲 bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants