Use original fork of kafka_exporter

[marctc]

For some reason, we are using a fork of kafka exporter that is not the original exporter. This cause issues like #502 where we are lagging behind of new version of kafka exporter.

[marctc]

cc @gaantunes as you where the original author of the integration

[hainenber]

I tried going back to original version and realize the reason of using forked one is due to the original isn't usable as library 😞

I think, we may want to fork another version from danielqsj/kafka_exporter (original) and re-add commits from davidmparrott/kafka_exporter (currently used). In that way, we can sync upstream updates and still retain the ability to use it as library.

Wdyt?

[max107]

fork is really required? maybe suggest danielqsj/kafka_exporter move codebase as a library?

[gaantunes]

In addition to moving the exporter to a lib, the fork we use also adds lag consumption time estimation, which is an important metric for us.

The mantainer said he is open to these changes, and I started working on it, but had to drop due to conflicting priorities. Won't be able to return to it in the foresseable future, but can help with context and reviews if someone is able to pick up the work.

[rfratto]

Hi there 👋

On April 9, 2024, Grafana Labs announced Grafana Alloy, the spirital successor to Grafana Agent and the final form of Grafana Agent flow mode. As a result, Grafana Agent has been deprecated and will only be receiving bug and security fixes until its end-of-life around November 1, 2025.

To make things easier for maintainers, we're in the process of migrating all issues tagged variant/flow to the Grafana Alloy repository to have a single home for tracking issues. This issue is likely something we'll want to address in both Grafana Alloy and Grafana Agent, so just because it's being moved doesn't mean we won't address the issue in Grafana Agent :)

[rfratto]

Reopening, not fixed in Alloy