Scheme out Logging

[Branchverse]

Von Kobis Präsentation

PDF FILE of pres: Observability.pdf

I would overwrite the nestjs Logger, and create a JSON format like this:

• [ ] Question: Since logging might become extensive at some point I would reduce names here in particular?

{
 tStart: Date // This should act as an id and be passed down to every following call
 tNow: Date // To also be able to track how long an entire request and substeps needs I would from the 2nd on always pass the current time to be compared to the start time. This enables 2 things, looking for loggings at a particular time, and analysing performance
 level: Enum // log, error, verbose, debug, info
 location: String // The handler or service location
 message: String // The message relevant for the log/error
 payload: Object // A relevant payload
}

@LarsFlieger @coffemakingtoaster Ihr seid hier mehr beteiligt pls input

[coffeemakingtoaster]

@Branchverse

Using tStart as a way to identify a request throughout the entire application?Afaik there are better implementations for tracing. For calculating a stat of 'time within system' this however would be a nice property to have...but lets not use it as an id. If we want to do tracing properly we should either use premade solutions or implement a middleware that attaches a uuid to incoming requests.

I fail to see the need for seperate payload and message fields. If you intend payload to equal the parameters passed by the user then we seriously have to think about privacy measures. I would rather we group these under a "data" property which by default only has a message tag but can be extended if needed.

"Overwrite the logger"? Depending on your intentions with the format you described it may be smarter to extend the logger. Otherwise log messages within the terminal may be hard to read and therefore debug

[Branchverse]

Reasonable, was thinking that tStart as an ID is specific enough since it is unlickely to get the same one by sending fast requests