Noble,
We have to expose those via the interface vs trying to cast to some
expected object. For things like NIFI-8239 [1] we'll expose new
properties from an object the rest of the code can't get to (and
rightfully so), and I suspect the same would go for the properties of
FlowController that
Hi Matt
Thanks for the clarification – I see your point. Both thread metrics
[1] are constant and at this stage we are trying to get them in the
right location.
We have updated the appropriate Registry classes and
PrometheusMetricsUtil and the additional JVM metrics are displaying in
both the
Thanks for clarifying, Matt!
Please ignore everything I said
> On Feb 9, 2021, at 14:41, Matt Burgess wrote:
>
> The PrometheusReportingTask and the NIFi API endpoint for Prometheus
> metrics are different beasts but they use quite a bit of the same code
> [1]. The intent is to report on
The PrometheusReportingTask and the NIFi API endpoint for Prometheus
metrics are different beasts but they use quite a bit of the same code
[1]. The intent is to report on the same metrics wherever possible,
and I think for the most part we've done that. They don't call each
other, instead they
Hello and thanks for your interest in contributing to NiFi.
If my understanding is correct, PrometheusReportingTask is an implementation of
the ReportingTask interface that exposes data available in the ReportingContext
and other internal interfaces on the Prometheus Meter Registry and
Hi everyone,
We have added metrics to the Prometheus metrics endpoint in the API
(/nifi-api/flow/metrics/prometheus) to improve programmatic access to
NiFi metrics for the purpose of monitoring. We’d like to contribute
these back to the project for the benefit of others. Please find the
list of
