nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <>
Subject Re: Metric access for reporting tasks
Date Sun, 17 Sep 2017 21:57:12 GMT

Is the right list and it's awesome you want to contribute.

Yes for sure such contribs are welcome.  Just need to be sure all libraries
used including transitive deps are fair game as far as licensing goes and
are properly accounted for.

As far as refactoring to avoid code duplication it could be helpful.  You
might want to just do a jira and PR to do yours in a nice and clean and
reusable way and once that is done and in then do another jira and PR to
clean up the others.


On Sep 16, 2017 2:44 PM, "Omer Hadari" <> wrote:

> Hello,
> I hope I am writing to the correct mailing list.
> We use graphite in my organization, and recently started to use nifi.
> We went on to write a simple reporting task for graphite, and I figured
> it could be used by other people as well, so why not contribute it.
> I was looking at other reporting tasks though (DataDog and Ambari), and
> there seems to me that there is some code duplication in how they access
> metrics. They both use very similar classes in order to to that:
> org.apache.nifi.reporting.ambari.metrics.MetricsService
> org.apache.nifi.reporting.ambari.metrics.MetricNames
> org.apache.nifi.reporting.datadog.metrics.MetricsService
> org.apache.nifi.reporting.datadog.metrics.MetricNames
> They are not identical, but again - very similar. I think this
> functionality can be easily exported to some other module, in order for
> more reporting tasks that need to generally report the same metrics to be
> written more easily.
> My questions are:
> a. Are more metric reporting tasks (like graphite) welcome
> b. If the refactor I am suggesting is in order, will it belong in
> nifi-commons or is a new module for reporting tasks in order?
> I would be more than happy to implement any and all changes I have just
> suggested by myself, and am simply asking these questions in order to best
> fit into your conventions and workflow.
> Thank you in advance!

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