proposal: improve logging

[muir]

Is your feature request related to a problem? Please describe. Implementing op and rp integrations I had lots of bugs. I only found those bugs by adding 100s of prints to the code.

Describe the solution you'd like After xop is released (should be in a couple weeks or less), I would like to add logging everywhere. This will require changing many function signatures because either a *xop.Log or a context.Context would need to be passed to every function that wants to log and many functions do not currently have a context parameter.

Xop is the right choice because:

• It has a mechanism to redact strings and models and thus can, for example, log a JWT but without it's signature.
• Xop can easily change logging level based on environment variables and thus be silent or minimal when not debugging
• Xop's performance is very good (better than zap, on par with zerolog).
• Xop supports tracing and thus can potentially allow allow an authentication process to be followed across servers and time

Describe alternatives you've considered

Xop is not the right choice because:

• it's young
• it doesn't have connectors to other loggers yet (coming soon, but not yet)

Additional context

[muhlemmer]

We can already look into adding context where required, while the exact way of implementing logging is being investigated. #309 is meant to split the change of context and logging.

[muhlemmer]

The Go ecosystem is full of different loggers. Some better than others. Developers often have different opinions on this subject. I feel that it is not the place of a library to make a fixed decision on a log implementation.

Yes, xop looks like a good choice for the above reasons, but our zitadel product already build on logrus for example. There might be reasons to change that, but that could take some time after any decision is taken. Meanwhile, we (urgently) need to improve the situation around logging.

Inspired by jackc/pgx, which offers a general logging interface and adapters towards the major logging libraries that are available, I've looked around to the possibility if we can provide something similar.

https://github.com/go-logr/logr seems to be a very valid option to achieve a similar solution:

• Defines an interface which can be used inside the oidc framework;
• Can be put inside a context.Context and safely retrieved;
• Implementations for most major loggers;
• It is a mature package, used by many.
• It is reasonable maintained. Last commit 3-dec-2022, and some PRs that are WIP by the developers.

By using logr we give power to the package users to make their own decisions on a logger. Also, I shouldn't be much work to create an adapter for xop.

[muhlemmer]

CC @zitadel/engineers, @fforootd

[muhlemmer]

logr proposal was accepted during internal meeting. This issue is replaced by user story #379.