0
Fork 0
mirror of https://github.com/project-zot/zot.git synced 2024-12-30 22:34:13 -05:00
zot/pkg/log/guidelines.md
Ramkumar Chinchani b196369ea4
docs: add logging guidelines (#1884)
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
2023-10-04 12:29:46 -07:00

1.4 KiB

Log Guidelines

Logs from zot can be pushed to the popular ELK stack and therefore they become one of the service level indicators (SLI). It is therefore important to set guidelines about how we log in this project.

Log Levels

Depending on whether a log message is useful in development or production, set the appropriate level. Development code should use DEBUG level.

Message Format

We use structured logs (currently via the zerolog library).

  1. Use lower-case strings by default

  2. The "message" field should not have any formatting strings

For example,

log.Info().Msg(fmt.Sprintf("this is a %s message", "test"))

So that exact string matches are possible on the "message" field.

All parameters should be specified separately as part of the log.

For example,

log.Info().Str("stringParam", "stringValue").Msg("static message")

Separate components

Instead of:

log.Info().Msg("module: message")

use:

log.Info().Str("module", "module").Msg("message")

OR if you want to a reusable logger then:

log.Info().With().Str("module", "module1").Logger().Msg("message")

Errors

Not all errors are really errors.

For example, lookup a cache (fast path) and it throws a not-found error, and we expect to handle it and perform a slow path lookup. Instead of logging the lookup failure at ERROR level, it may be more appropriate to log at DEBUG level and then handle the error.