Option to configure UPTIME_KUMA_LOG_FORMAT: json or text

[fsteinke]

📑 I have found these related issues/pull requests

• Checked and didn't find similar issue

🏷️ Feature Request Type

Settings

🔖 Feature description

It would be very helpful for us to have an ENV_VAR to configure the logging format directly.
To be clear, a general option to switch between the current "text" logs and logs in "json" would already be a great benefit.

✔️ Solution

Extend Logger implementation with a e.g. UPTIME_KUMA_LOG_FORMAT variable that can be set to "text" or "json" with "text" being the default, similar to the implementation of UPTIME_KUMA_HIDE_LOG.

Instead of logging to console as

console.error(timePart, modulePart, levelPart, msgPart);

with the value set to "json" the logging could log like this:

console.error(
  JSON.stringify(
    "timestamp": timePart,
    "module": modulePart,
    "level": levelPart,
    "message": msgPart
  )
);

❓ Alternatives

We have considered that this functionality would be possible by a log management solution, but a direct choice and configuration of the logFormat seems to us like a quick and valuable option to avoid further transformations in upstream solutions for the logs produced by kuma.

📝 Additional Context

n/a

[CommanderStorm]

Shure, reasonable.
Doing this needs the following PRs to work fully:

• chore:unified our logging infrastructure to only use log.XYZ #4392
• chore:addressing of simple deprecations surrounding Settings and log #4391

If you want to provide a PR to have json as an alternative log output, our contribution guide is here: https://github.com/louislam/uptime-kuma/blob/dd75890364fe9cbdfbef6119da6c126234fa6044/CONTRIBUTING.md

[fsteinke]

@CommanderStorm is there something else, that can be done here to support or is there a chance to get #5118 reviewed, merged and release in the next days? 😉

[CommanderStorm]

Released is a bit of a taller task.
The concrete reasons are listed in #4500.
Currently, the 2.0.0-beta.0 release is blocked by:

• Error: Invalid label name when using non-ASCII characters in tags #5096
• writing a changelog that highlights what has changed and highlights why some of the more interesting changes were made (performance, db, email-templating).
• adding a database migration for existing data and retention Last part of 2.0 (Update database migration and history retention) #5075

If you want to help, going through the PRs and writing a changelog would be appreciated, but that is a lot of work.