@wffger2  NiFi Flow Definitions are meant to be reusable snippets of flow.  Meaning it can be imported to the canvas of the same NiFi Cluster or to the canvas of another NiFi cluster.  Since you can not have multiple components on the canvas using the same component UUID, you will not be able to compare Flow Definitions between two different environments without seeing differences in those UUIDs. If you want to track differences in dataflows between your UAT and DEV environments, NiFi-Registry is the method you want to use.  You can install a single NiFi-Registry and configure both your NiFi's to point at that same instance of NiFi-Registry.  Then on your DEV environment you start version control on a process group (testNiFiDefinition).  Then on your UAT environment you import that same version flow from the NiFi-registry.  Now you have both your NiFi environments tracking against the same version flow stored in that NiFi-registry.  While the component UUID will still be different, they both track to same versioned flow.  If you then make changes in DEV and commit those to NiFi-Registry as a new version of the already version controlled flow, you UAT environment will report a newer version as being available.  You can see the differences directly from the NiFi UI and easily upgrade your dataflow on the UAT environment to the newer version available if you choose. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@srilakshmi  The PublishKafka processor can be configured with a comma separated list of KaFla brokers.  If the processor at time of execution is able to communicate with one of these configured brokers, it will received a destination for publishing the content. If during the publish a failure occurs,  The FlowFile is routed to the failure relationship. You have configurable options to retry on failure x number of times.  You should avoid auto-terminating failure relationships in your datafow designs unless data loss is acceptable. Each attempt is a new execution of the processor which means connect to broker again. A failure is when PublishKafka was unable to send all the content bytes (for example: connection gets closed).    Best Effort and Guarantee single node delivery setting in the PublishKafka processor have nothing to do with the NiFi nodes in the NiFi cluster.  This has to do with the nodes in the destination Kafka setup. In a NiFi cluster each node executes its own copy of the dataflow(s) and each node has its own content and FlowFile repositories.  Nodes are unaware of FlowFiles that exist on the other nodes in the cluster.  So a FlowFile's content that fails to publish on say node2 will route to failure relationship on node 2 and if you use retry, will be executed on again on node 2.   When a node goes down the FlowFile queued in connection remain on that node until it is brought back on line.   When the node comes back up, it will continue processing FlowFiles from the last connection in which they were queued. So it is important the the Content and FlowFile repositories are protected to avoid dataloss (such as using RAID storage). A node that is disconnected from the cluster will still execute its dataflow(s) as long as NiFi is still running on that node. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@ManishR  NiFi offers many components (processors, controller services, reporting tasks, etc) that can be used to construct a flow based program on the NiFi canvas (Referred to as a NiFi dataflow).  While this list of default available components may be different depending on the release of NiFi being used, NiFi has embedded documentation found under help within the NiFi UI that shows all components available in that installed release. Apache NiFi also publishes the same info for the most current released version here: https://nifi.apache.org/docs/nifi-docs/ Selecting a component from the documentation with open a description of the component and all list configurable properties. Building a dataflow on the NiFi canvas consist of dragging and dropping new component processors to the canvas.  You can then drag connection between these components to construct your end-to-end dataflow.  There are 100s of component processors available out of the box and even more that you can download and add to your NiFi from the apache community. Once a dataflow is built and configured, starting those components would result in the creation of FlowFile (for testing, you can add a GenerateFlowFile processor that generates a FlowFile rather then ingesting content from an external source like the local file system, kafka, DB, etc. As each component executes against a FlowFile, that FlowFile is routed to one of the available relationships the particular processor offers.  These relationships would be assigned to one of the connection exiting the processor and connecting to another downstream processor. The following Apache NiFi docs explain how to build a dtaflow: https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#building-dataflow This covers how to search for a component in yoru dataflow(s): https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#search   Then when it comes to looking at the detailed lineage of an individual FlowFile, you can use NiFi's data Provenance for that.  Individual processor components generate provenance events as they execute on FlowFile (create, route, drop, etc...). You can look at the entire lineage from create to drop of a FlowFile (assuming you configure NiFi provenance with enough storage to store all the lineage).  BY default NiFI is configured to only use 10GB for Provenance and only store Provenance for 24 hours, but this can be configured in the nifi.properties file.  You can write click on NiFi processor component in your dataflow and Select data provenance from the pop-up context menu.  This will open a provenance search query result set that show FlowFile that traversed the component.  You can select one and even expand the lineage of that select component.  The lineage of a FlowFile will show all events associated to that FlowFile created by the processor components that FlowFile traversed.  This covers how to use NiFi's Data Provenance: https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#data_provenance If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@apmmahesh  Make sure that the nifi.properties file on all nodes is configured the same. Make sure that the "nifi.cluster.protocol.is.secure" property is set to true on all the nodes. Matt ... View more

@NafeesShaikh93  Interesting Use case you have.  I am not all that familiar with all the methods the Graylog offers for ingesting logs from other servers.  I'd assume Syslog is one of them?  If so, NiFi offers. putSyslog processor. Looking at the dataflow you build thus far, I am not sure what you are trying to accomplish.  The LogAttribute and logMessage processors allows you to write a log entry in a NiFi log defined by an appender and logger in the logback.xml NiFi configuration file.  By default these log lines would end up in the nifi-app.log.    You could however add an additional appender and the a custom logger to send log lines produced by these processors classes to the new appender thus isolating them from the other logging in the nifi-app.log.  There is no way to setup a specific logger by processor on canvas.  So every logAttribute and logMessage processor you use will write to the same destination NiFi appender log. The classes for the logAttribute and logMessage processors are: org.apache.nifi.processors.standard.LogAttribute org.apache.nifi.processors.standard.LogMessage NiFi also has a tailFile processor that can tail a log file and create FlowFiles with that log entries at content.  You could then use PutSyslog processor to send those log lines to yoru Graylog server possibly. The above design involves extra disk I/O that may not be necessary since you could possibly design your flow to create FlowFile attributes with all the file information you want to send to GrayLog an then use a replaceText at end of successful dataflow to replace the content of yoru FlowFile with a crafted syslog formatted content from those attributes and send directly to Graylog via the PutSyslog processor.  This removes the need to write to a new logger and consume from that new log before sending o syslog.  But again this is a matter of preference.  Perhaps in you case maybe you want a local copy of these logs as well. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@srilakshmi  Yes, Apache NiFi 1.9.0 was released over 4 years ago on February 19, 2019.  Many bugs, improvements and security fixes have made there may into the product since then.  The latest release as of this post is 1.20. While i can't verify 100% from what exists in this thread that you are experiencing NIFI-9688, the odds are pretty strong. You can fin the release notes for Apache NiFi here: https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.20.0   If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@apmmahesh  Your current issue is unrelated to your original issue.  What you have now is an issue with your mutual TLS exchange between your cluster nodes. NiFi does nothing unusual or out of spec with regards to TLS. Specifically this line snippet you shared:   javax.net.ssl.SSLHandshakeException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors   points to a trust issue within the exchange. So few things about your certificates: 1. Is "nifi1" the actual hostname for this server? (same for nifi2 and nifi3) 2. What is inside the truststore.jks you are using on each of your NiFi nodes?  The complete TLS trustchain for your NiFi certificates must be in this truststore.jks.  Your truststore.jks should contain one too many TrustedCertEntries.  Your keystore.jks must contain only 1 PrivateKeyEntry. Assuming that all your node's certificates were generated using the NiFi TLS toolkit, they should all be issued/signed by the same certifcate Authority (Issuer: CN=localhost, OU=NIFI).  Their then must be a a trustedCertEntry present in the trustsore.jks used by all your nodes for "CN=localhost, OU=NIFI". You can use the same keytool -v -list -keystore truststore.jks command to verify the contents of your truststore.jks. You can also use the following command to obtain the public cert(s) for your CA from any one of your NiFi servers: openssl s_client -connect <nifi hostname>:<nifi port> -showcerts each public cert will have this structure: -----BEGIN CERTIFICATE----- MIIFYjCCBEqgAw..............b9Sz/yilrbCgj8= -----END CERTIFICATE---- I cut out portion of string in above, but the certificate includes everything above in it.  You can copy each and save them to "<filename>.crt" files which you can import to your truststore.jks files (all nodes shoudl e using a common truststore.jks) if they are missing. keytool -import -alias <some unique ca name> -file <filename>.crt -keystore truststore.jks -storepass <truststore.jks password>   You'll need to restart your NiFi anytime you modify either the keystore or truststore.  NiFi only reads these files on startup. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@srilakshmi  Were you able to identify the three FlowFile that did not produce the expected log output from your logAttribute processors? Do you auto-terminate the "success" relationship out of your LogAttribute processors? If so, do you see DROP events in those FlowFIle's provenance lineage? If you look at the event timestamp does is correlate to a time that falls between when the shutdown was initiated and when you restarted the NiFi instance? What version of NiFi are you using?  Is it older than Apache NiFi 1.16? If so, you may be hitting this bug addressed as of the NiFi 1.16 release: https://issues.apache.org/jira/browse/NIFI-9688 If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more