NiFi & Kylo Provenance


Kylo uses a custom ProvenanceRepository (KyloPersistentProvenanceEventRepository) to send data from NiFi to Kylo. A custom NiFi nar file is used for the ProvenanceRepository.


  1. Edit the file (/opt/nifi/current/conf/ and change the nifi.provenance.repository.implementation property as below:

    # Provenance Repository Properties
  2. Ensure the correct nars are available in the NiFi classpath. Depending upon the NiFi version there are 2 different nar files that are used. If you use the kylo wizard it will copy the nar files and setup the symlinks to point to the correct nar version for your NiFi installation.

    • For NiFi 1.0 or 1.1

      • kylo-nifi-provenance-repo-v1-nar-<version>.nar
    • For NiFi 1.2 or 1.3

      • kylo-nifi-provenance-repo-v1.2-nar-<version>.nar
  3. Configure the KyloPersistentProvenanceEventRepository properties: The Provenance Repository uses properties found in the /opt/nifi/ext-config/ file.

    Note: this location is configurable via the System Property kylo.nifi.configPath passed into NiFi when it launches. Below are the defaults which are automatically set if the file/properties are not found.

    Note: the marked with ## Supports dynamic update below can be updated without restarting NiFi. Every 30 seconds a check is made to see if the file has been updated.

    ## Back up location to write the Feed stats data if NiFi goes down
    ## *Supports dynamic update*
    ## The maximum number of starting flow files per feed during the given run interval to send to ops manager
    ## *Supports dynamic update*
    ## The number of starting flow files allowed to be sent through until the throttle mechanism in engaged.
    # if the feed starting processor gets more than this number of events during a rolling window based upon the kylo.provenance.event.throttle.threshold.time.millis timefame events will be throttled back to 1 per second until its slowed down
    ## Throttle timefame used to check the rolling window to determine if rapid fire is occurring
    ## run interval to gather stats and send to ops manager
    ## *Supports dynamic update*
    ## JSON string of the Event Type to Array of Processor classes
    ## These processors produce orphan child flow files that dont send DROP provenance events for the children.
    ## Child flow files produced by events  matching the EventType and processor class will not be processed
    ## *Supports dynamic update*

Event Processing

When NiFi runs the processors will send provenance events to JMS Queues. Kylo listens on these JMS queues and creates Jobs/Steps and Streaming statistics about each feed and job execution. These are displayed in the Operations Manager.