nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Logan <>
Subject Re: Status of MetricsReportingTask?
Date Fri, 02 Nov 2018 19:24:17 GMT
We were planning on having a reporter to pipe the metrics off to AWS
CloudWatch. The one issue being ran into -- and we've ran into it for other
components -- is the classloading. What is the recommended way of adding
alternate implementations of services (in this case MetricReporterService)?
We run into issues that I think stem from classloading isolation between
NARs, such that our custom implementations of services are not being
detected from the other NAR's context. We end up having to duplicate the
service into our custom NAR, but that hardly seems like a good idea.


On Thu, Nov 1, 2018 at 10:27 PM Koji Kawamura <>

> Hi Jon,
> About reporting counter values, there is an existing JIRA for the
> improvement idea to expose counters to Reporting task context. That
> requires NiFi framework level improvements. I'd suggest taking a look
> on it, and resuming discussion there if needed.
> Although MetricsReportingTask currently only supports Graphite, the
> component is well designed for generic reporting use-cases. I don't
> think it is a legacy component. The underlying dropwizard metrics
> project seems active, too.
> I'm interested in what service implementation you're going to write.
> Is it going to use one of already available reporters?
> Thanks,
> Koji
> On Thu, Nov 1, 2018 at 3:17 AM Jon Logan <> wrote:
> >
> > Hi All,
> >
> > I was looking at utilizing the MetricsReportingTask service, but I was
> > wondering what the status of it is -- it seems to be lacking some
> features
> > that I thought it'd have (ex. reporting counters), and I'm not sure
> there's
> > an ability to extend the metrics being produced. Is this something that
> is
> > still being worked on, or is a legacy component? We are going to have to
> > write our own Service implementation, as the only supported one seems to
> be
> > Graphite, and wanted to make sure we're not going down a legacy path.
> >
> > Thanks!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message