Migrate logging system to log/slog #14778

New Issue

GiteaMirror · 2025-11-02T11:22:44-06:00

GiteaMirror commented

2025-11-02 11:22:44 -06:00

Originally created by @TheFox0x7 on GitHub (Jul 18, 2025).

Feature Description

if accepted supersedes: https://github.com/go-gitea/gitea/issues/21758
filing as separate proposal due to a slightly different scope with the same outcome and names specific provider instead of just outcome.

With the introduction of go 1.21 log/slog was added to standard library. It's a structured logging library that allows to log a message with a key-value pairs added to it for later processing. It provides two formatted loggers (plus built-in default) json and logfmt

Why slog instead of zerolog or zap? It's in the standard library. I don't have a strong reason for/against alternative libraries.

As for why I feel it's worth migrating:

Benefits

It is very helpful when making statistics from logs with tools like angle-grinder, loki and similar tools
It's easier to filter through logs as you can set more complex filters to narrow the search down to specific context or exclude noise instead of just grepping through (though that doesn't go away).
Easy to include and find context for the log, for example when logging error in caused by a user, userid can be added as an attribute to look for later, which could be helpful for abuse detection via logs.
Third party extensions (such as sampling or some specific sinks) are available.
Specific loggers can write to the same file separated with an attribute

Drawbacks

Requires modifying all log lines in current codebase from printf to structured. For the switch current logs could format the message with sprintf so the change wouldn't have to be done in one go but in chunks.
I believe support for adding, pausing and removing loggers would require custom handler or io.Writer.
It's a breaking change unless a custom handler to print old style is added.
Access logs might be an issue to port (if they would be ported to this at all).

Screenshots

No response

Originally created by @TheFox0x7 on GitHub (Jul 18, 2025). ### Feature Description if accepted supersedes: https://github.com/go-gitea/gitea/issues/21758 filing as separate proposal due to a slightly different scope with the same outcome and names specific provider instead of just outcome. With the introduction of go 1.21 log/slog was added to standard library. It's a structured logging library that allows to log a message with a key-value pairs added to it for later processing. It provides two formatted loggers (plus built-in default) json and logfmt Why slog instead of zerolog or zap? It's in the standard library. I don't have a strong reason for/against alternative libraries. As for why I feel it's worth migrating: ### Benefits - It is very helpful when making statistics from logs with tools like [angle-grinder](https://github.com/rcoh/angle-grinder), loki and similar tools - It's easier to filter through logs as you can set more complex filters to narrow the search down to specific context or exclude noise instead of just grepping through (though that doesn't go away). - Easy to include and find context for the log, for example when logging error in caused by a user, userid can be added as an attribute to look for later, which could be helpful for abuse detection via logs. - Third party extensions (such as sampling or some specific sinks) are available. - Specific loggers can write to the same file separated with an attribute ### Drawbacks - Requires modifying all log lines in current codebase from printf to structured. For the switch current logs could format the message with sprintf so the change wouldn't have to be done in one go but in chunks. - I believe support for adding, pausing and removing loggers would require custom handler or io.Writer. - It's a breaking change unless a custom handler to print old style is added. - Access logs might be an issue to port (if they would be ported to this at all). ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 11:22:44 -06:00

GiteaMirror commented

2025-11-02 11:22:45 -06:00

@TheFox0x7 commented on GitHub (Jul 20, 2025):

@wxiaoguang seeing that you refactored/touched logging last do you have any views on this?

@TheFox0x7 commented on GitHub (Jul 20, 2025): @wxiaoguang seeing that you refactored/touched logging last do you have any views on this?

GiteaMirror commented

2025-11-02 11:22:45 -06:00

@wxiaoguang commented on GitHub (Jul 20, 2025):

Thank you for the proposal. IMO it's more complicated than it looks, while at the moment I don't have time for it ...

@wxiaoguang commented on GitHub (Jul 20, 2025): Thank you for the proposal. IMO it's more complicated than it looks, while at the moment I don't have time for it ...

GiteaMirror commented

2025-11-02 11:22:45 -06:00

@TheFox0x7 commented on GitHub (Jul 20, 2025):

np. I'd like to implement this but (similar to otel) I figured it's better to talk this through before fully committing to it to avoid wasting time.

@TheFox0x7 commented on GitHub (Jul 20, 2025): np. I'd like to implement this but (similar to otel) I figured it's better to talk this through before fully committing to it to avoid wasting time.

GiteaMirror commented

2025-11-02 11:22:45 -06:00

@wxiaoguang commented on GitHub (Jul 20, 2025):

At the moment, my priorities are: make sure the code is maintainable and fix bugs, review and help to improve some PRs whose changes are clear, implement some widely-requested features.

For the "slog" migration: I am not sure whether there is a maintainable/feasible way to introduce it: whether the related PRs can be clear, how much end users would really need it or benefit from it (because many logs are just noises).

The Gitea's log system is really complicated, and there are many abuses, TBH I don't see how the "migration" would succeed at the moment.

If you'd really like to try, I think we need a progressive design & plan. As the first step, I think we need to decouple most CLI commands from the current logger, because most CLI commands should just output messages to stdout/stderr directly like normal POSIX programs, and the CLI commands should not be affected by the "logger" config options.

Update: "decouple most CLI commands from the current logger" is still very hard, due to the how the "setting" package uses the logger, and the "setting" package itself is also problematic.

@wxiaoguang commented on GitHub (Jul 20, 2025): At the moment, my priorities are: make sure the code is maintainable and fix bugs, review and help to improve some PRs whose changes are clear, implement some widely-requested features. For the "slog" migration: I am not sure whether there is a maintainable/feasible way to introduce it: whether the related PRs can be clear, how much end users would really need it or benefit from it (because many logs are just noises). ---- The Gitea's log system is really complicated, and there are many abuses, TBH I don't see how the "migration" would succeed at the moment. If you'd really like to try, I think we need a progressive design & plan. As the first step, I think we need to decouple most CLI commands from the current logger, because most CLI commands should just output messages to stdout/stderr directly like normal POSIX programs, and the CLI commands should not be affected by the "logger" config options. Update: "decouple most CLI commands from the current logger" is still very hard, due to the how the "setting" package uses the logger, and the "setting" package itself is also problematic.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14778