[
https://issues.apache.org/jira/browse/NIFI-5429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-5429:
--------------------------------
Attachment: asf_hc_failure_reporting.003.jpeg
asf_hc_failure_reporting.002.jpeg
asf_hc_failure_reporting.001.jpeg
> Improve failure monitoring
> --------------------------
>
> Key: NIFI-5429
> URL: https://issues.apache.org/jira/browse/NIFI-5429
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Affects Versions: 1.7.0
> Reporter: Andy LoPresto
> Priority: Major
> Labels: failure, monitoring, provenance, reporting
> Attachments: asf_hc_failure_reporting.001.jpeg,
> asf_hc_failure_reporting.002.jpeg, asf_hc_failure_reporting.003.jpeg
>
>
> A user in the ASF HipChat room and I discussed the following scenario:
> {quote}
> With N processors in a flow, I want to send a notification on any failure
> event to a remote monitoring system. For this example, let the remote
> monitoring system be Elasticsearch. Currently, I need N unique
> PutElasticsearch processors to uniquely identify the processor which has the
> failure.
> {quote}
> I created some diagrams showing the existing setup and desired setup (one
> with direct to reporting; one with an {{ExecuteScript}} processor for
> metadata enrichment (i.e. if the component {{UUID}} is available, use {{ES}}
> to resolve the human-friendly {{name}} and processor group nesting to be
> persisted)).
> There are concerns about exposing component ID to flowfiles and how this can
> be misused, but there needs to be a better solution for how to monitor flow
> failures without 1:1 processors for monitoring.
> I have also attached the conversation.
> cc: [~markap14] [~joewitt]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
