Apache NiFi Team

MiNiFi Homepage

This documentation is for MiNiFi 0.5.0.

Automatic Warm-Redeploy

When many MiNiFi agents running on the edge, it may not be possible to manually stop, edit the config.yml and then restart every one every time their configuration needs to change. The Config Change Coordinator and its Ingestors were designed to automatically redeploy in response to a configuration update.

The Config Change Ingestors are the means by which the agent is notified of a potential new configuration. Currently there are three:

• FileChangeIngestor
• RestChangeIngestor
• PullHttpChangeIngestor

After a new configuration has been pulled/received the Ingestors use a Differentiator in order to determine if the currently running config is different than the new config. Which Differentiator is used, is configurable for each Ingestor. Currently there is only one Differentiator:

• WholeConfigDifferentiator: Compares the entire new config with the currently running one, byte for byte.

After a new config is determined to be new, the MiNiFi agent will attempt to restart. The bootstrap first saves the old config into a swap file. The bootstrap monitors the agent as it restarts and if it fails it will roll back to the old config. If it succeeds then the swap file will be deleted and the agent will start processing using the new config.

Note: Data left in connections when the agent attempts to restart will either be mapped to a connection with the same ID in the new config, or orphaned and deleted.

The configuration for Warm-Redeploy is done in the bootstrap.conf and primarily revolve around the Config Change Ingestors. The configuration in the bootstrap.conf is done using the nifi.minifi.notifier.ingestors key followed by the full path name of the desired Ingestor implementation to run. Use a comma separated list to define more than one Ingestor implementation. For example:

nifi.minifi.notifier.ingestors=org.apache.nifi.minifi.bootstrap.configuration.ingestors.PullHttpChangeIngestor

Ingestor specific configuration is also necessary and done in the bootstrap.conf as well. Specifics for each are detailed below.

FileChangeIngestor

class name: org.apache.nifi.minifi.bootstrap.configuration.ingestors.FileChangeIngestor

This Config Change Ingestor watches a file and when the file is updated, the file is ingested as a new config.

Note: The config file path configured here and in nifi.minifi.config cannot be the same. This is due to the swapping mechanism and other implementation limitations.

Below are the configuration options. The file config path is the only required property.

RestChangeIngestor

class name: org.apache.nifi.minifi.bootstrap.configuration.ingestors.RestChangeIngestor

This Config Change Ingestor sets up a light-weight Jetty HTTP(S) REST service in order to listen to HTTP(S) requests. A potential new configuration is sent via a POST request with the BODY being the potential new config.

Note: The encoding is expected to be Unicode and the exact version specified by the BOM mark (‘UTF-8’,‘UTF-16BE’ or ‘UTF-16LE’). If there is no BOM mark, then UTF-8 is used.

Here is an example post request using curl hitting the local machine on port 8338 and it is executed with the config file config.yml in the directory the command is run from:

curl --request POST --data-binary "@config.yml" http://localhost:8338/

Below are the configuration options. There are no required options. If no properties are set then the server will bind to hostname localhost on a random open port, will only connect via HTTP and will use the WholeConfigDifferentiator.

PullHttpChangeIngestor

class name: org.apache.nifi.minifi.bootstrap.configuration.ingestors.PullHttpChangeIngestor

This Config Change Ingestor periodically sends a GET request to a REST endpoint using HTTP(S) to order to pull the potential new config.

Below are the configuration options. The hostname and port are the only required properties.

Status Reporting and Querying

In NiFi there is a lot of information, such as stats and bulletins, that is only available to view through the UI. MiNiFi provides access to this information through a query mechanism. You can query FlowStatus either using the minifi.sh script or by configuring one of the Periodic Status Reporters. The API for the query is the same for the reporters and the “flowStatus” script option. The API is outlined in the “FlowStatus Query Options” section below.

FlowStatus Script Query

From the minifi.sh script, you can manually query to get the current status of your dataflow. The following is an example of a minifi.sh query you might run to view health, stats, and bulletins for the TailFile processor. This query returns information to your command-line.

minifi.sh flowStatus processor:TailFile:health,stats,bulletins

Currently the script only accepts one high level option at a time. Also any names of connections, remote process groups, or processors that contain " " (a space), “:”, “;” or “,” cause parsing errors when querying.

Note: The examples in this documentation are provided for *nix based environments. Windows support is also provided by by the flowstatus-minifi.bat file. To perform one of the listed interactions, minifi.sh flowStatus would simply be replaced by flowstatus-minifi.bat. For example, the sample query above in *nix environments,

minifi.sh flowStatus processor:TailFile:health,stats,bulletins

would translate to Windows environments as,

flowstatus-minifi.bat processor:TailFile:health,stats,bulletins

Periodic Status Reporters

You can set up Periodic Status Reporters to periodically report the status of your dataflow. The query executes at configurable intervals and the results are reported using the configured implementation. Configure the Reporters in the bootstrap.conf file, using the nifi.minifi.status.reporter.components key followed by the full path name of the desired Reporter implementation to run. Use a comma separated list to define more than one Reporter implementation. For example:

nifi.minifi.status.reporter.components=org.apache.nifi.minifi.bootstrap.status.reporters.StatusLogger

StatusLogger

class name: org.apache.nifi.minifi.bootstrap.status.reporters.StatusLogger

The Periodic Status Reporter logs the results of the query to the logs. By default it is logged to the minifi-bootstrap.log but you can modify logback.xml to log to an alternate file and location.

Example bootstrap.conf configuration:

# The FlowStatus query to submit to the MiNiFi instance
nifi.minifi.status.reporter.log.query=instance:health,bulletins
# The log level at which the status will be logged
nifi.minifi.status.reporter.log.level=INFO
# The period (in milliseconds) at which to log the status
nifi.minifi.status.reporter.log.period=60000

Example logback.xml configuration to output the status to its own rolling log file:

<appender name="STATUS_LOG_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>logs/minifi-status.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <!--
          For daily rollover, use 'user_%d.log'.
          For hourly rollover, use 'user_%d{yyyy-MM-dd_HH}.log'.
          To GZIP rolled files, replace '.log' with '.log.gz'.
          To ZIP rolled files, replace '.log' with '.log.zip'.
        -->
        <fileNamePattern>./logs/minifi-status_%d.log</fileNamePattern>
        <!-- keep 5 log files worth of history -->
        <maxHistory>5</maxHistory>
    </rollingPolicy>
    <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
        <pattern>%date %level [%thread] %logger{40} %msg%n</pattern>
    </encoder>
</appender>

<logger name="org.apache.nifi.minifi.bootstrap.status.reporters.StatusLogger" level="INFO" additivity="false">
    <appender-ref ref="STATUS_LOG_FILE" />
</logger>

FlowStatus Query Options

This section outlines each option to query the MiNiFi instance for the FlowStatus.

Note: In Windows environments, all minifi.sh flowStatus invocations should be replaced with flowstatus-minifi.bat. See FlowStatus Script Query for an illustration.

Processors

To query the processors, use the processor flag and specify the processor (by ID, name or “all”) followed by one of the processor options. The processor options are below.

An example query to get the health, bulletins and stats of the “TailFile” processor is below.

minifi.sh flowStatus processor:TailFile:health,stats,bulletins

Connections

To query the connections, use the connection flag and specify the connection (by ID, name or “all”) followed by one of the connection options. The connection options are below.

An example query to get the health and stats of the “TailToS2S” connection is below.

minifi.sh flowStatus connection:TailToS2S:health,stats

Remote Process Groups

To query the remote process groups (RPGs), use the remoteprocessgroup flag and specify the RPG (by ID, name or “all”) followed by one of the remote process group options. The remote process group options are below.

An example query to get the health, bulletins, input ports and stats of all the RPGs is below.

minifi.sh flowStatus remoteprocessgroup:all:health,bulletins,inputports,stats

Controller Services

To query the controller services, use the controllerservices flag followed by one of the controller service options. The controller service options are below.

An example query to get the health and bulletins of all the controller services is below.

minifi.sh flowStatus controllerservices:health,bulletins

Provenance Reporting

To query the status of the provenance reporting, use the provenancereporting flag followed by one of the provenance reporting options. The provenance reporting options are below.

An example query to get the health and bulletins of the provenance reporting is below.

minifi.sh flowStatus provenancereporting:health,bulletins

Instance

To query the status of the MiNiFi instance, use the instance flag followed by one of the instance options. The instance options are below.

An example query to get the health, stats and bulletins of the instance is below.

minifi.sh flowStatus instance:health,stats,bulletins

System Diagnostics

To query the system diagnostics, use the systemdiagnostics flag followed by one of the system diagnostics options. The system diagnostics options are below.

An example query to get the heap, processor stats, content repository usage, FlowFile repository usage and garbage collection from the system diagnostics is below.

minifi.sh flowStatus systemdiagnostics:heap,processorstats,contentrepositoryusage,flowfilerepositoryusage,garbagecollection

Example

This is an example of a simple query to get the health of all the processors and its results from a simple flow:

User:minifi-0.0.1-SNAPSHOT user ./bin/minifi.sh flowStatus processor:all:health

Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home
MiNiFi home: /Users/user/projects/nifi-minifi/minifi-assembly/target/minifi-0.0.1-SNAPSHOT-bin/minifi-0.0.1-SNAPSHOT

Bootstrap Config File: /Users/user/projects/nifi-minifi/minifi-assembly/target/minifi-0.0.1-SNAPSHOT-bin/minifi-0.0.1-SNAPSHOT/conf/bootstrap.conf

{"controllerServiceStatusList":null,"processorStatusList":[{"name":"Connection Diagnostics","processorHealth":{"runStatus":"Running","hasBulletins":false,"validationErrorList":[]},"processorStats":null,"bulletinList":null},{"name":"UpdateAttribute","processorHealth":{"runStatus":"Running","hasBulletins":false,"validationErrorList":[]},"processorStats":null,"bulletinList":null},{"name":"Processor Diagnostics","processorHealth":{"runStatus":"Running","hasBulletins":false,"validationErrorList":[]},"processorStats":null,"bulletinList":null},{"name":"System Diagnostics","processorHealth":{"runStatus":"Running","hasBulletins":false,"validationErrorList":[]},"processorStats":null,"bulletinList":null},{"name":"GenerateFlowFile","processorHealth":{"runStatus":"Running","hasBulletins":false,"validationErrorList":[]},"processorStats":null,"bulletinList":null}],"connectionStatusList":null,"remoteProcessGroupStatusList":null,"instanceStatus":null,"systemDiagnosticsStatus":null,"reportingTaskStatusList":null,"errorsGeneratingReport":[]}

Periodic Status Reporters

Config File

The config.yml in the conf directory is the main configuration file for controlling how MiNiFi runs. This section provides an overview of the properties in this file. The file is a YAML and follows the YAML format laid out here.

Alternatively, the MiNiFi Toolkit Converter can aid in creating a config.yml from a generated template exported from a NiFi instance. This tool can be downloaded from https://nifi.apache.org/minifi/download.html under the “MiNiFi Toolkit Binaries” section. Information on the toolkit’s usage is available at https://nifi.apache.org/minifi/minifi-toolkit.html.

Note: Values for periods of time and data sizes must include the unit of measure, for example “10 sec” or “10 MB”, not simply “10”.

Versioning

The “MiNiFi Config Version” property is used to indicate to the configuration parser which version of the config file it is looking at. If the property is empty or missing, version 1 is assumed.

The MiNiFi Toolkit Converter is capable of parsing previous versions (possibly subject to a future deprecation policy) and writing out the current version. It can also validate that a given config file parses and upconverts to the current version without issue.

Version 1 -> Version 2 changes

1. Use ids instead of names for processors, connections.
2. Allow multiple source relationships for connections.
3. Added support for process groups, and internal input ports an output ports.
4. Change Id Key for RPGs from “Remote Processing Groups” to the proper “Remote Process Groups” (not “ing”).

Version 2 -> Version 3 changes

1. Added support for Controller Services.
2. Added support for Site-To-Site over proxy.
3. Added support for overriding nifi.properties values
4. Added support for Output Ports to Remote Process Groups

Flow Controller

The first section of config.yml is for naming and commenting on the file.

Core Properties

The “Core Properties” section applies to the core framework as a whole.

FlowFile Repository

The FlowFile repository keeps track of the attributes and current state of each FlowFile in the system. By default, this repository is installed in the same root installation directory as all the other repositories; however, it is advisable to configure it on a separate drive if available.

Swap Subsection

A part of the “FlowFile Repository” section there is a “Swap” subsection.

NiFi keeps FlowFile information in memory (the JVM) but during surges of incoming data, the FlowFile information can start to take up so much of the JVM that system performance suffers. To counteract this effect, NiFi “swaps” the FlowFile information to disk temporarily until more JVM space becomes available again. The “Swap” subsection of properties govern how that process occurs.

Content Repository

The Content Repository holds the content for all the FlowFiles in the system. By default, it is installed in the same root installation directory as all the other repositories; however, administrators will likely want to configure it on a separate drive if available. If nothing else, it is best if the Content Repository is not on the same drive as the FlowFile Repository. In dataflows that handle a large amount of data, the Content Repository could fill up a disk and the FlowFile Repository, if also on that disk, could become corrupt. To avoid this situation, configure these repositories on different drives.

Provenance Repository

Component Status Repository

The Component Status Repository contains the information for the Component Status History tool in the User Interface. These properties govern how that tool works.

The buffer size and snapshot frequency work together to determine the amount of historical data to retain. As an example to configure two days worth of historical data with a data point snapshot occurring every 5 minutes you would configure snapshot frequency to be “5 mins” and the buffer size to be “576”. To further explain this example, for every 60 minutes there are 12 (60 / 5) snapshot windows for that time period. To keep that data for 48 hours (12 * 48) you end up with a buffer size of 576.

Security Properties

These properties pertain to various security features in NiFi. Many of these properties are covered in more detail in the “Security Configuration” section of this Administrator’s Guide.

Note: A StandardSSLContextService will be made automatically with the ID “SSL-Context-Service” if ssl protocol is configured.

Sensitive Properties Subsection

Some properties for processors are marked as sensitive and should be encrypted. These following properties will be used to encrypt the properties while in use by MiNiFi. This will currently not be used to encrypt properties in the config file.

Processors

The current implementation of MiNiFi supports multiple processors. The “Processors” subsection is a list of these processors. Each processor must specify these properties. They are the basic configuration general to all processor implementations. Make sure that all relationships for a processor are accounted for in the auto-terminated relationship list or are used in a connection.

Processor Properties

Within the “Processor Configuration” section, there is the “Properties” subsection. The keys and values in this section are the property names and values for the processor. For example the TailFile processor would have a section like this:

Properties:
    File to Tail: logs/nifi-app.log
    Rolling Filename Pattern: nifi-app*
    State File: ./conf/state/tail-file
    Initial Start Position: Beginning of File

Controller Services

The current implementation of MiNiFi supports Controller Services. The “Controller Services” subsection is a list of these services. Each Controller Service must specify the following properties. They are the basic configuration general to all Controller Service implementations.

Note: If the “Security Properties” is configured with an “ssl protocol” then a StandardSSLContextService will be made automatically with the ID “SSL-Context-Service”.

Controller Service Properties

Within the “Controller Service Configuration” section, there is the “Properties” subsection. The keys and values in this section are the property names and values for the service. For example, the StandardSSLContextService would have a section like this:

Properties:
  Keystore Filename: /tmp/localhost/keystore.jks
  Keystore Password: keystorePassword
  Keystore Type: JKS
  SSL Protocol: TLS
  Truststore Filename: /tmp/truststore.jks
  Truststore Password: truststorePassword
  Truststore Type: JKS
  key-password: keyPassword

Process Groups

Process groups can be nested from the top level. They can contain other process groups as well and can be used to logically group related operations.

Input Ports

These ports provide input to the Process Group they reside on. (Currently only for internal Input ports.)

Output Ports

These ports provide output from the Process Group they reside on. (Currently only for internal Output ports.)

Funnels

Funnels can be used to combine outputs from multiple processors into a single connection for ease of design.

Connections

There can be multiple connections in this version of MiNiFi. The “Connections” subsection is a list of connections. Each connection must specify these properties.

Remote Process Groups

MiNiFi can be used to send data using the Site to Site protocol (via a Remote Process Group) or a Processor. These properties configure the Remote Process Groups that use Site-To-Site to send data to a core instance. The proxy settings are for HTTP Site-To-Site.

Input/Output Ports Subsection

When connecting via Site to Site, MiNiFi needs to know which input or output port to communicate to of the core NiFi instance. These properties designate and configure communication with that port.

Provenance Reporting

MiNiFi is currently designed only to report provenance data using the Site to Site protocol. These properties configure the underlying reporting task that sends the provenance events.

Note: In order to send via HTTPS, the “Security Properties” must be fully configured. A StandardSSLContextService will be made automatically with the ID “SSL-Context-Service” and used by the Provenance Reporting.

NiFi Properties Overrides

This is a yaml map that contains values to be put into nifi.properties. This will supercede any hardcoded or other schema values that are substituted into nifi.properties file.

Example NiFi Properties Overrides

NiFi Properties Overrides:
  nifi.flowfile.repository.directory: ./flowfile_repository_override
  nifi.content.repository.directory.default: ./content_repository_override
  nifi.database.directory: ./database_repository_override

Running as a Windows Service

MiNiFi can run as a Windows service. To do so, you must modify the conf/bootstrap.conf to set absolute paths for some properties. The properties are:

• lib.dir (e.g. C:\\minifi-x.x.x\\lib)
• conf.dir (e.g. C:\\minifi-x.x.x\\conf)
• nifi.minifi.config (e.g. C:\\minifi-x.x.x\\conf\\config.yml)

You can now install the MiNiFi service by running the install-service.bat script. To remove the service run the delete-service.bat file.

The minifi.exe in MiNiFi bin directory is used to run MiNiFi Windows service. The bundled one is for 64 bit architecture and requires 64 bit JRE. If you have to use 32 bit JRE for some reason, you need to replace the minifi.exe file with the one for 32 bit to make MiNiFi service runs successfully. To do so, go to Commons Daemon project download page, download the binary (e.g. commons-daemon-1.1.0-bin.zip), extract it and replace bin/minifi.exe by copying commons-daemon-x.x.x-bin/prunsrv.exe into MiNiFi bin directory as minifi.exe to overwrite the 64 bit exe with the 32 bit one.

Example Config File

Below are two example config YAML files. The first tails the minifi-app.log and sends the tailed log and provenance data back to a secure instance of NiFi. The second uses a series of processors to tail the app log, routes off only lines that contain “WriteAheadFlowFileRepository” and puts it as a file in the “./” directory.

MiNiFi Config Version: 1
Flow Controller:
    name: MiNiFi Flow
    comment:

Core Properties:
    flow controller graceful shutdown period: 10 sec
    flow service write delay interval: 500 ms
    administrative yield duration: 30 sec
    bored yield duration: 10 millis

FlowFile Repository:
    partitions: 256
    checkpoint interval: 2 mins
    always sync: false
    Swap:
        threshold: 20000
        in period: 5 sec
        in threads: 1
        out period: 5 sec
        out threads: 4

Provenance Repository:
    provenance rollover time: 1 min

Content Repository:
    content claim max appendable size: 10 MB
    content claim max flow files: 100
    always sync: false

Component Status Repository:
    buffer size: 1440
    snapshot frequency: 1 min

Security Properties:
    keystore: /tmp/ssl/localhost-ks.jks
    keystore type: JKS
    keystore password: localtest
    key password: localtest
    truststore: /tmp/ssl/localhost-ts.jks
    truststore type: JKS
    truststore password: localtest
    ssl protocol: TLS
    Sensitive Props:
        key:
        algorithm: PBEWITHMD5AND256BITAES-CBC-OPENSSL
        provider: BC

Processors:
    - name: TailFile
      class: org.apache.nifi.processors.standard.TailFile
      max concurrent tasks: 1
      scheduling strategy: TIMER_DRIVEN
      scheduling period: 1 sec
      penalization period: 30 sec
      yield period: 1 sec
      run duration nanos: 0
      auto-terminated relationships list:
      Properties:
          File to Tail: logs/minifi-app.log
          Rolling Filename Pattern: minifi-app*
          Initial Start Position: Beginning of File

Connections:
    - name: TailToS2S
      source name: TailFile
      source relationship name: success
      destination name: 8644cbcc-a45c-40e0-964d-5e536e2ada61
      max work queue size: 0
      max work queue data size: 1 MB
      flowfile expiration: 60 sec
      queue prioritizer class: org.apache.nifi.prioritizer.NewestFlowFileFirstPrioritizer

Remote Processing Groups:
    - name: NiFi Flow
      comment:
      url: https://localhost:8090/nifi
      timeout: 30 secs
      yield period: 10 sec
      Input Ports:
          - id: 8644cbcc-a45c-40e0-964d-5e536e2ada61
            name: tailed log
            comments:
            max concurrent tasks: 1
            use compression: false

Provenance Reporting:
    comment:
    scheduling strategy: TIMER_DRIVEN
    scheduling period: 30 sec
    destination url: https://localhost:8090/
    port name: provenance
    originating url: http://${hostname(true)}:8081/nifi
    use compression: true
    timeout: 30 secs
    batch size: 1000

Flow Controller:
    name: MiNiFi Flow
    comment:

Core Properties:
    flow controller graceful shutdown period: 10 sec
    flow service write delay interval: 500 ms
    administrative yield duration: 30 sec
    bored yield duration: 10 millis
    max concurrent threads: 1

FlowFile Repository:
    partitions: 256
    checkpoint interval: 2 mins
    always sync: false
    Swap:
        threshold: 20000
        in period: 5 sec
        in threads: 1
        out period: 5 sec
        out threads: 4

Content Repository:
    content claim max appendable size: 10 MB
    content claim max flow files: 100
    always sync: false

Component Status Repository:
    buffer size: 1440
    snapshot frequency: 1 min

Security Properties:
    keystore: /tmp/ssl/localhost-ks.jks
    keystore type: JKS
    keystore password: localtest
    key password: localtest
    truststore: /tmp/ssl/localhost-ts.jks
    truststore type: JKS
    truststore password: localtest
    ssl protocol: TLS
    Sensitive Props:
        key:
        algorithm: PBEWITHMD5AND256BITAES-CBC-OPENSSL
        provider: BC

Processors:
    - name: TailAppLog
      class: org.apache.nifi.processors.standard.TailFile
      max concurrent tasks: 1
      scheduling strategy: TIMER_DRIVEN
      scheduling period: 10 sec
      penalization period: 30 sec
      yield period: 1 sec
      run duration nanos: 0
      auto-terminated relationships list:
      Properties:
          File to Tail: logs/minifi-app.log
          Rolling Filename Pattern: minifi-app*
          Initial Start Position: Beginning of File
    - name: SplitIntoSingleLines
      class: org.apache.nifi.processors.standard.SplitText
      max concurrent tasks: 1
      scheduling strategy: TIMER_DRIVEN
      scheduling period: 0 sec
      penalization period: 30 sec
      yield period: 1 sec
      run duration nanos: 0
      auto-terminated relationships list:
          - failure
          - original
      Properties:
          Line Split Count: 1
          Header Line Count: 0
          Remove Trailing Newlines: true
    - name: RouteErrors
      class: org.apache.nifi.processors.standard.RouteText
      max concurrent tasks: 1
      scheduling strategy: TIMER_DRIVEN
      scheduling period: 0 sec
      penalization period: 30 sec
      yield period: 1 sec
      run duration nanos: 0
      auto-terminated relationships list:
          - unmatched
          - original
      Properties:
          Routing Strategy: Route to 'matched' if line matches all conditions
          Matching Strategy: Contains
          Character Set: UTF-8
          Ignore Leading/Trailing Whitespace: true
          Ignore Case: true
          Grouping Regular Expression:
          WALFFR: WriteAheadFlowFileRepository
    - name: PutFile
      class: org.apache.nifi.processors.standard.PutFile
      max concurrent tasks: 1
      scheduling strategy: TIMER_DRIVEN
      scheduling period: 0 sec
      penalization period: 30 sec
      yield period: 1 sec
      run duration nanos: 0
      auto-terminated relationships list:
          - failure
          - success
      Properties:
          Directory: ./
          Conflict Resolution Strategy: replace
          Create Missing Directories: true
          Maximum File Count:
          Last Modified Time:
          Permissions:
          Owner:
          Group:

Connections:
    - name: TailToSplit
      source name: TailAppLog
      source relationship name: success
      destination name: SplitIntoSingleLines
      max work queue size: 0
      max work queue data size: 1 MB
      flowfile expiration: 60 sec
      queue prioritizer class: org.apache.nifi.prioritizer.NewestFlowFileFirstPrioritizer
    - name: SplitToRoute
      source name: SplitIntoSingleLines
      source relationship name: splits
      destination name: RouteErrors
      max work queue size: 0
      max work queue data size: 1 MB
      flowfile expiration: 60 sec
      queue prioritizer class: org.apache.nifi.prioritizer.NewestFlowFileFirstPrioritizer
    - name: RouteToS2S
      source name: RouteErrors
      source relationship name: matched
      destination name: PutFile
      max work queue size: 0
      max work queue data size: 1 MB
      flowfile expiration: 60 sec
      queue prioritizer class: org.apache.nifi.prioritizer.NewestFlowFileFirstPrioritizer

Provenance Reporting:
    comment:
    scheduling strategy: TIMER_DRIVEN
    scheduling period: 30 sec
    destination url: https://localhost:8080/
    port name: provenance
    originating url: http://${hostname(true)}:8081/nifi
    use compression: true
    timeout: 30 secs
    batch size: 1000