From a567774e7e84569d32521b5985c424ce99dc0f87 Mon Sep 17 00:00:00 2001 From: Florian Greinacher Date: Thu, 28 Mar 2024 17:17:22 +0100 Subject: [PATCH] docs(development): clarify logging principles (#28162) --- docs/development/best-practices.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/docs/development/best-practices.md b/docs/development/best-practices.md index e520c67c7a1255..3b1e3f265e085a 100644 --- a/docs/development/best-practices.md +++ b/docs/development/best-practices.md @@ -157,13 +157,11 @@ Avoid refactoring the code and tests at the same time, this can mask regression For `WARN`, `ERROR` and `FATAL` log messages use logger metadata. Also use logger metadata the result is a complex metadata object needing a multiple-line pretty stringification. -For `INFO` log messages inline the metadata into the log message. -Also inline the metadata if the metadata object is complex. +For `INFO` and `DEBUG` log messages inline the metadata into the log message where feasible. +It is OK to not inline metadata if it's complex, but in that case first think whether that much information really needs to be logged. `WARN`, `ERROR` and `FATAL` messages are often used in metrics or error catching services. -These log messages should have a consistent `msg` component, so they can be automatically grouped or associated. -Metadata that's separate from its message is hard for humans to read. -Try to combine the metadata into the message, unless it's too complex to do so. +These log messages should have a static `msg` component, so they can be automatically grouped or associated. Good: