Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow enabling franz-go logging from kafka package #540

Open
endorama opened this issue Aug 9, 2024 · 2 comments
Open

Allow enabling franz-go logging from kafka package #540

endorama opened this issue Aug 9, 2024 · 2 comments

Comments

@endorama
Copy link
Member

endorama commented Aug 9, 2024

The kafka package does not initialize franz-go logging nor exposes a way to do this. This means there is no way for callers to enable franz-go logging.

Goal

Allow enabling franz-go logging from kafka package callers.

inge4pres added a commit that referenced this issue Aug 12, 2024
The current `metricsHook` struct that collects metrics based on Kafka
hooks is not equipped to also report details of _why_ connection errors
are caused.

--- Details

We provide a new struct that implements a (single, for now) kgo Hook
dedicated to logging errors during the broker connection phase.
The struct can be iterated in the future to implement other monitoring
hooks, providing logging utilities where the metrics would have too high
cardinality.

The proposed design adds the new logger hook behind the
`CommonConfig.DisableTelemetry` flag (similarly to the metrics hook).
This can be improved and it is not a perfect solution, but it has to be
done this way until a bigger refactor is done to expose the
`CommonConfig.hook` fieldin some way.

The more idiomatic, but also more expensive, solution would be to allow
exporting franz-go logs into the Logger.
This is mentioned in #540

---------

Signed-off-by: inge4pres <[email protected]>
Co-authored-by: Edoardo Tenani <[email protected]>
@inge4pres
Copy link
Contributor

Clarification: when we decide to pursue logging the entirety of messages from franz-go, we can remove what's been added in #541.
If we want to make both approach co-exists, it would be sensible to somehow configure franz-go logging, meaning:

  • log level
  • filters to include/exclude entries at ingestion time

The previous note is assuming that we want to reduce the amount of data stored in our logging infrastructure, or at least limit to what's actually useful.

@raultorrecilla
Copy link

moving this from it105 to 109

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants