search

Azure / azure-sdk-for-java

This repository is for active development of the Azure SDK for Java. For consumers of the SDK we recommend visiting our public developer docs at https://docs.microsoft.com/java/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-java.
MIT License
2.32k stars 1.97k forks source link

Enable structured JSON logging for SLF4J `2.0.0`+ #39991

Open vcolin7 opened 5 months ago

vcolin7 commented 5 months ago 
### Tasks
- [ ] Add code to check whether SLF4J `2.0.0`+ is being used to use its the new APIs
- [ ] Determine how we want to JSON structured logging to look like
- [ ] Adapt code to newly determined standard
lmolkova commented 5 months ago

Determine how we want to JSON structured logging to look like

There are two options:

  1. Don't change anything for SLF4J 2.0. As a result, SLF4J 2.0 providers would get string message (which happens to be structured json) and won't see individual key-value-pairs

    • Pros: when writing logs to file/console, the default formatter would print log message as a whole.
    • Cons: when writing logs to structured destinations, the message will remain a string and will need additional parsing when querying data

  2. Leverage the structure and use SLF4J 2.0 addKeyValue methods to provide the context to the SDLF4J

    • Pros: when writing logs to structured destinations, users will get better experience
    • Cons: when writing to file/console, the default formatters will NOT include any context. And would just print the message

The middle ground: E.g. we want to record the following log: connectionId=foo, error.type=canceled, message="Connection attempt failed"

With SLF4J 1.7 we record message as {"connectionId":"foo", "error.type":"canceled", "message":"Connection attempt failed"} With SLF4J 2.0 we record structured things and a formatted message like

slf4JLogger.atInfo()
  .addKeyValue("connectionId", "foo")
  .addKeyValue("error.type", "canceled")
  .addKeyValue("message", "Connection attempt failed")
  .log("{\"connectionId\":\"foo\", \"error.type\":\"canceled\", \"message\":\"Connection attempt failed\"}")

This would be a default behavior resulting in:

It'd result in duplication and we can consider letting users to configure it.

My proposal is to do 1.5 eventually, but stick with option 1 for now until we have any feedback/scenario for option 1.5.

By doing option 1, we effectively do 

slf4JLogger.atInfo()
  .log("{\"connectionId\":\"foo\", \"error.type\":\"canceled\", \"message\":\"Connection attempt failed\"}")

and 

  .addKeyValue("connectionId", "foo")
  .addKeyValue("error.type", "canceled")
  .addKeyValue("message", "Connection attempt failed")

is purely incremental change.