Member since
07-30-2019
3472
Posts
1642
Kudos Received
1021
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 205 | 06-15-2026 08:08 AM | |
| 388 | 06-03-2026 06:06 PM | |
| 617 | 05-06-2026 09:16 AM | |
| 1379 | 05-04-2026 05:20 AM | |
| 710 | 05-01-2026 10:15 AM |
02-18-2025
05:59 AM
1 Kudo
@MarinaM Welcome to the Cloudera Community. Your Questions: Does NiFi allow segregation of data sources? - Would need a bit more information from you on this requirement/question. You can certainly create non connected dataflows on the NiFi canvas for handling of NiFi FlowFiles from various sources to keep them separate. However on the NiFi backend their is no segregation of content. NiFi stores the content of 1 too many FlowFiles in content claims. Anytime new content is created, it is written to the currently still open content claim no matter where in any of the dataflows that content is created. Content written to a content claim is immutable (can't be modified once written), so anywhere in yoru dataflow where you may make modification to a FlowFile's content would result in the new modified version of the content being written to a new content claim. Handling LEEF logs: logs reach NiFi with the original source IP but leave NiFi with NiFi’s source IP. - Would need details on how you have these logs arriving at NiFi and being ingested. Since QRadar first looks for the hostname in the payload (and if absent, uses the source IP), this could cause misidentification. - I am not familiar with QRadar, but perhaps you can modify the content when the hostname is missing in the payload via your NiFi dataflow(s)? Can NiFi be configured to retain the original source IP while forwarding logs, without modifying the original log (to comply with legal requirements)? - NiFi is a data agnostic tool and does not differentiate logs form any other content it is processing. Content in NiFi is just bytes of data and it becomes the requirement of any individual processor that may need to interact with the content of the FlowFiles to understand the content format. Would need to understand how you are ingesting these logs into NiFi. Some processor may be creating FlowFile attributes containing the source IP information which perhaps you can use later in your dataflow? Perhaps another option is to build yoru dataflow to do lookups on the source IP and modify the syslog header when the hostname is missing? Log Integrity & Authenticity: Does NiFi ensure log integrity and authenticity for legal and compliance purposes? - As mentioned for NiFi is data agnostic and content claims are immutable. Once a log is ingested the dataflow(s) you build can modify content if designed to do so and that modified log content is written to a new content claim. Some Processors that modify content may create an entirely new FlowFile with that content referenced in it, but other may just modify the existing FlowFile to point and new modified content in the new content claim while keeping the original FlowFile identifier. Typically this is the case with processor that have an "Original" relationship where the unmodified original FlowFile routes to this relationship while the modified content is assigned to an entirely new FlowFile which becomes a child FlowFile or that original. LEEF Parsing: Is there a NiFi processor available to parse LEEF logs before storing them in HDFS? - Based on this IBM doc on LEEF (https://www.ibm.com/docs/en/SS42VS_DSM/pdf/b_Leef_format_guide.pdf), the LEEF logs consists of a RFC 5424 or RFC3164 formatted syslog headers which can be parsed by NiFi Syslog processors. ListenSyslog ParseSyslog ParseSyslog5424 PutSyslog- Perhaps using PutSyslog instead of PutTCP can solve your Source IP issue you encounter by using PutTCP. There are also controller services that support these syslog formats: SyslogReader Syslog5424Reader Please help our community grow and thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
02-14-2025
01:22 PM
Thank you very much for your answer 🙂 I tried it and found it worked.
... View more
02-13-2025
01:22 PM
@OfekRo1 I looked at the StandardProvenaceEventRecord source in Github plus I know many of the open source contributors. 😀 https://github.com/rdblue/incubator-nifi/blob/master/commons/data-provenance-utils/src/main/java/org/apache/nifi/provenance/StandardProvenanceEventRecord.java Your welcome and thank you for being part of the community!
... View more
02-13-2025
09:56 AM
@mks27 What you are trying accomplish is not possible in NiFi. In my 15 years of working with NiFi, I believe this is first time I have seen such a request. So what you are expecting to happen is NiFi presents the login window and a user supplies a username and password. You then expect NiFi to attempt authentication via one ldap provider and if that results in unknown username or bad password response, move on to next ldap provider an attempt again? The users that will need access to your NiFi don't all exist in just one of your ldaps? I suppose if you have a multi node NiFi cluster setup, you could configure the ldap-provider on one node to use one of the ldap servers and the ldap-provider on another node to use the other ldap server. Since the NiFi cluster can be accessed from any node, you would just need make sure your users access the NIFi cluster from the appropriate node that is configured with their ldap server. NOTE: Authorization (happens after successful authentication) need to be identical on all nodes in a cluster, but that is not an issue here. You'll just configure the authorizers.xml so that all user and group identities from both ldaps are authorized appropriately. This bootleg way of facilitating authentication via multiple LDAPs, is not something I have ever tested/tried, but believe would work. You could also raise an improvement jira in Apache Jira NiFi project to see if the community might be interested in implementing this change, but I don't anticipate there is much demand for it. https://issues.apache.org/jira/browse/NIFI Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
02-12-2025
10:34 AM
@fy-test The NiFi node that disconnects due to a flow mismatch should inherit the cluster flow when it attempts to rejoin the cluster. The only time this is not possible is if the cluster flow includes change that would result in dataloss. Example: Cluster flow has a connection removed that on the connecting node still has queued FlowFiles. NiFi has not feature to force removal/archive of a flow.json.gz on a disconnected node. You could file an Apache NiFi improvement jira here: https://issues.apache.org/jira/projects/NIFI But first step is to identify why your node is not able to inherit cluster flow and rejoin the cluster. What is the exception logged when it attempts to rejoin the cluster? Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
02-11-2025
07:19 AM
@jfs912 Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.
... View more
02-07-2025
02:09 PM
@doora Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.
... View more
02-07-2025
12:09 PM
@Darryl You will certainly have issues using localhost even outside docker with a multi-node NiFi cluster since only the NiFi node installed in the same server as Keycloak would have any chance of connecting with Keycloak. Understand that a NiFi cluster can bae accessed form any node in the NiFi cluster. So first thing i would have suggested is using the hostname of the actual server that is hosting Keycloak rather then localhost. I am not familiar with Keycloak myself and the article you reference (while i know the author) is very old. A lot has likely evolved/changes with regards to security since it was written. Glad to hear you had some success even if it was outside of Docker and thank you with sharing what you learned with the community. Matt
... View more
02-07-2025
05:48 AM
@Darryl Please start a new community question around your new keycloak integration issues with NiFi. Thank you, Matt
... View more
02-06-2025
07:00 AM
@BK84 The exception is caused by: Caused by: java.lang.IllegalStateException: The specified class 'org.apache.nifi.controller.state.providers.raft.RaftStateProvider' is not known to this nifi. Your NiFi knows nothing about this class meanung the nifi lib directory does not contain any nar that includes this class: org.apache.nifi.controller.state.providers.raft.RaftStateProvider I also see nothing in Apache NiFi Jira nor in the NiFi 2 documentation mentioning this class or any type of raft state provider. Looking at the properties configured with this provider class, they match the zookeeper properties. So I suspect you should be using this class instead in your stet provider: org.apache.nifi.controller.state.providers.zookeeper.ZooKeeperStateProvider Please help our community grow and thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more