Hi, Mickael, Sophie, Doğuşcan. Thanks for your replys.
I like the idea of adding the version and commitId as tags for existed metric
named "startTimeMs". I will update the KIP doc and start the vote process for
this KIP.
It seems that there is not an existing metric named "uptime", Doğuşcan.
bes
Hello, do we have a metric showing the uptime? We could tag that metric
with version information as well.
I like the idea of adding the version as a tag as well. However, I am not
inclined to tag each metric with a KafkaVersion information. We could
discuss which metrics could be tagged but let's
Just to chime in here since I recently went through a similar thing, I
support adding the version
as a tag instead of introducing an entirely new metric for this. In fact I
just implemented exactly this
in a project that uses Kafka, for these reasons:
1. Adding the version as a tag means that all
Hi Hudeqi,
Rather than creating a gauge with a dummy value, could we add the
version (and commitId) as tags to an existing metric.
For example, the alongside the existing Version and CommitId metrics
we have StartTimeMs. Maybe we can have a StartTimeMs metrics with the
version and commitId) as tag
Thank you for your answer, Mickael.
If set the value of gauge to a constant value of 1, adding that tag key is
"version" and value is the version value of the obtained string type, does this
solve the problem? We can get the version by tag in prometheus.
best,
hudeqi
"Mickael Maison"
Hi,
Prometheus only support numeric values for metrics. This means it's
not able to handle the kafka.server:type=app-info metric since Kafka
versions are not valid numbers (3.5.0).
As a workaround we could create a metric with the version without the
dots, for example with value 350 for Kafka 3.5.
Hi, Kamal, thanks your reminding, but I have a question: It seems that I can't
get this metric through "jmx_prometheus"? Although I observed this metric
through other tools.
best,
hudeqi
"Kamal Chandraprakash" 写道:
> Hi Hudeqi,
>
> Kafka already emits the version