nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Payne <marka...@hotmail.com>
Subject Re: LogAttribute - Sending that output to a custom logger?
Date Sun, 01 Nov 2015 16:23:43 GMT
Mark,

To make sure that I understand what you're proposing, you want to add a property to
LogAttribute that allows users to provide a custom logger name?

If that is indeed what you are suggesting then I think it's a great idea.

That being said, in practice I rarely ever use LogAttribute and we even considered removing
it from the codebase before we open sourced, because the Data Provenance provides a
much better view of what's going on to debug your flows. 

I know you're pretty new to NiFi, so if you've not yet had a chance to play with the Provenance,
you can see the section in the User Guide at http://nifi.apache.org/docs/nifi-docs/html/user-guide.html#data-provenance
<http://nifi.apache.org/docs/nifi-docs/html/user-guide.html#data-provenance>

If you're interested in updating the LogAttribute processor, though, we'd be happy to have
that contribution added, as it does make the Processor more usable.

Thanks
-Mark

> On Oct 31, 2015, at 12:35 PM, Mark Petronic <markpetronic@gmail.com> wrote:
> 
> From the code, it appears it cannot be done as the attribute logging
> goes the same getLogger() instance as the normal nifi-app traces. Has
> anyone considered making that configurable, maybe allowing you do
> define a different logger name for LogAttribute then creating that
> logger definition in log back conf allowing flexibility? I'm using
> attribute logging heavily as I try to better learn/debug Nifi (it give
> you a nice 'under the hood' view of the flow) and build up some flows
> and feel it would be beneficial to be able to capture the LogAttribte
> message by themselves for more clarity on what is happening. I would
> not mind maybe trying to implement this feature as my first crack at
> contributing to the project. Seems like a fairly easy one that would
> allow me to "go through the motions" of a full pull request process
> and iron out the process. Anyone have any thoughts on this?


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