Apache NiFi系统管理员指南 [ 四 ]
- 系统属性
- 核心属性
- State管理
- H2设置
- FlowFile存储库
- 交换管理(Swap Management)
- 内容存储库 (Content Repository)
- 文件系统内容存储库属性 (File System Content Repository Properties)
- 易失性内容存储库属性 (Volatile Content Repository Properties)
- 原产地库(Provenance Repository)
- 提前编写源代码存储库属性(Write Ahead Provenance Repository Properties)
- 加密的提前写入存储库属性(Encrypted Write Ahead Provenance Repository Properties)
- 持久性源代码库属性(Persistent Provenance Repository Properties)
- 易失性来源存储库属性(Volatile Provenance Repository Properties)
- 组件状态存储库(Component Status Repository)
- 站点到站点属性(Site to Site Properties)
- 反向代理的站点到站点路由属性(Site to Site Routing Properties for Reverse Proxies)
- 网络属性 (Web Properties)
- 安全属性(Security Properties)
- 身份映射属性 ( Identity Mapping Properties )
- 群集公共属性
- 群集节点属性
- 索赔管理
- ZooKeeper属性
- Kerberos属性
- 自定义属性
系统属性
目录中的nifi.properties文件conf是用于控制NiFi运行方式的主要配置文件。本节概述了此文件中的属性，并包含有关如何以便于升级的方式对其进行配置的一些注意事项。更改此文件后，重新启动NiFi以使更改生效。
| 此文件的内容相对稳定，但会不时更改。升级时查看此文件始终是个好主意，并注意任何更改。考虑使用星号（*）配置下面的项目，以便更容易升级。有关详细信息，请参阅本节末尾有关升级的完整讨论。请注意，时间段和数据大小的值必须包括度量单位，例如“10秒”或“10 MB”，而不仅仅是“10”。 |
核心属性
nifi.properties文件的第一部分用于核心属性。这些属性作为一个整体适用于核心框架。
|
属性 |
描述 |
|
|
流配置文件的位置（即包含当前在NiFi图上显示的内容的文件）。 默认值为 |
|
|
指定NiFi是否在更新流时自动创建流的备份副本。 默认值为 |
|
|
存档目录的位置，其中保存了flow.xml的备份副本。默认值为 |
|
|
归档的flow.xml文件的生命周期。如果指定了此属性，NiFi将在更新flow.xml时删除过期的归档文件。到期时间取决于当前系统时间和已归档flow.xml的上次修改时间戳。如果在nifi.properties中未指定存档限制，则NiFi将删除早于以下版本的存档 |
|
|
存档的flow.xml文件允许的总数据大小。如果指定了此属性，NiFi将删除最早的归档文件，直到总归档文件大小小于此配置值。 如果在nifi.properties中未指定存档限制，则NiFi会使用 |
|
|
允许的归档文件数。如果指定了此属性，NiFi将删除最旧的存档文件，以便只保留N个最新存档。 |
|
|
指示是否重新启动 - NiFi图上的组件应返回其上一个状态。 默认值为 |
|
|
表示关机时间。 默认值为 |
|
|
当对flow.xml进行许多更改时，此属性指定在写出更改之前等待的时间，以便将更改批处理为单个写入。 默认值为 |
|
|
如果某个组件允许意外异常转义，则会将其视为错误。因此，框架将在这段时间内暂停（或在行政上产生）组件。这样做是为了使组件不会消耗大量的系统资源，因为已知在现有状态下存在问题。默认值为 |
|
|
当一个组件没有工作要做（即，“无聊”）时，这是它在检查是否有新数据要工作之前等待的时间。这样，它不会过多地检查新工作而耗尽CPU资源。设置此属性时，请注意它可能会为不经常工作的组件添加额外的延迟，因为一旦进入这种“无聊”状态，他们将等待这段时间后再检查更多工作。 默认值为 |
|
|
在两个组件之间绘制新连接时，这是该连接的背压对象阈值的默认值。 默认值为 |
|
|
在两个组件之间绘制新连接时，这是该连接的背压数据大小阈值的默认值。 默认值为 |
|
|
这是文件的位置，指定如何定义授权程序。 默认值为 |
|
|
这是文件的位置，指定如何执行用户名/密码身份验证。仅在 默认值为 |
|
|
这是保存流模板的目录的位置（仅用于向后兼容）。模板存储在flow.xml.gz中，从NiFi 1.0开始。模板目录可用于在NiFi启动时自动（批量）将模板导入到flow.xml.gz中。 默认值为 |
|
|
这是横幅文本，可配置为显示在用户界面的顶部。 默认为空白。 |
|
|
用户界面自动刷新的时间间隔。 默认值为 |
|
|
nar库的位置。默认值是 |
|
|
nar工作目录的位置。 默认值是 |
|
|
文档工作目录。 默认值是 |
|
|
等待处理器的生命周期操作（ |
State管理
“属性”文件的“状态管理”部分提供了一种机制，用于配置组件的本地和群集范围机制以保持状态。有关如何使用它的更多信息，请参见“ 状态管理”部分。
|
属性 |
描述 |
|
|
包含本地和群集范围的状态提供程序的配置的XML文件。 默认值为 |
|
|
要使用的本地状态提供程序的ID。此值必须与state-management.xml文件 |
|
|
要使用的群集状态提供程序的ID。此值必须与state-management.xml文件 |
|
|
指定此NiFi实例是否应启动嵌入式ZooKeeper服务器。它与ZooKeeperStateProvider一起使用。 |
|
|
指定一个属性文件，其中包含已启动的嵌入式ZooKeeper服务器的配置（如果该 |
H2设置
H2设置部分定义H2数据库的设置，该数据库跟踪用户访问和流控制器历史记录。
|
属性 |
描述 |
|
|
H2数据库目录的位置。 默认值为 |
|
|
此属性指定要添加到H2数据库的连接字符串的其他参数。 应使用默认值，不应更改。 它是： |
FlowFile存储库
FlowFile存储库跟踪系统中每个FlowFile的属性和当前状态。默认情况下，此存储库安装在与所有其他存储库相同的根安装目录中; 但是，如果可用，建议在单独的驱动器上进行配置。
|
属性 |
描述 |
|
|
FlowFile Repository实现。默认值为 |
|
|
如果存储库实现配置为使用 |
|
|
FlowFile存储库的位置。默认值为 |
|
|
分区数量。默认值为 |
|
|
FlowFile存储库检查点间隔。默认值为 |
|
|
如果设置为 |
交换管理(Swap Management)
NiFi将FlowFile信息保存在内存（JVM）中，但在传入数据激增期间，FlowFile信息可能开始占用系统性能受损的大量JVM。为了抵消这种影响，NiFi会暂时将FlowFile信息“交换”到磁盘，直到更多JVM空间再次可用。这些属性控制着该过程的发生方式。
|
属性 |
描述 |
|
|
Swap Manager实现。 默认值是
且不应更改。 |
|
|
NiFi开始将FlowFile信息交换到磁盘的队列阈值。 默认值为 |
|
|
交换期间。 默认值为 |
|
|
用于交换的线程数。 默认值为 |
|
|
换出期间。 默认值为 |
|
|
用于交换的线程数。 默认值为 |
内容存储库 (Content Repository)
内容存储库保存系统中所有FlowFiles的内容。默认情况下，它与所有其他存储库安装在同一根安装目录中; 但是，管理员可能希望在单独的驱动器上配置它（如果可用）。如果没有别的，最好是内容存储库与FlowFile存储库不在同一个驱动器上。在处理大量数据的数据流中，内容存储库可能会填满磁盘，而FlowFile存储库（如果也在该磁盘上）可能会损坏。要避免这种情况，请在不同的驱动器上配置这些存储库。
|
属性 |
描述 |
|
|
内容存储库实现。默认值为 |
文件系统内容存储库属性 (File System Content Repository Properties)
|
属性 |
描述 |
|
|
内容存储库实现。默认值为 |
|
|
内容声明的最大大小。默认值为 |
|
|
要分配给一个内容声明的最大FlowFiles数。默认值为 |
|
|
内容存储库的位置。默认值为 |
|
|
如果启用了归档（请参见 |
|
|
如果启用了归档（请参阅 |
|
|
要启用内容存档，请将其设置为 |
|
|
如果设置为 |
|
|
基于Web的内容查看器的URL（如果有）。默认为空白。 |
易失性内容存储库属性 (Volatile Content Repository Properties)
|
属性 |
描述 |
|
|
内容存储库中的内容存储库最大大小。默认值为 |
|
|
内容存储库块大小。默认值为 |
原产地库(Provenance Repository)
Provenance Repository包含与Data Provenance相关的信息。接下来的四个部分是针对Provenance Repository属性的。
|
属性 |
描述 |
|
|
Provenance Repository实现。默认值为 第三和第四种选择是可用的： 在 注：在 |
提前编写源代码存储库属性(Write Ahead Provenance Repository Properties)
|
属性 |
描述 |
|
|
Provenance存储库的位置。默认值为 |
|
|
保留数据出处信息的最长时间。默认值为 |
|
|
一次存储的最大数据源信息量。默认值为 |
|
|
滚动存储库正在写入的“事件文件”之前等待的时间。 |
|
|
要写入单个“事件文件”的数据量。默认值为 |
|
|
用于Provenance Repository查询的线程数。默认值为 |
|
|
用于索引Provenance事件的线程数，以便可以搜索它们。默认值为 |
|
|
指示在滚动“事件文件”时是否压缩起源信息。默认值为 |
|
|
如果设置为 |
|
|
这是一个以逗号分隔的字段列表，应该将其编入索引并进行搜索。未编制索引的字段将无法搜索。有效的字段有： |
|
|
这是一个以逗号分隔的FlowFile属性列表，应该对其进行索引并使其可搜索。默认为空白。但一些很好的例子要考虑的是 |
|
|
存储库使用Apache Lucene执行索引和搜索功能。此值指示在Repository开始写入新索引之前Lucene索引应该有多大。在搜索Provenance存储库时，分片大小的较大值将导致更多Java堆使用，但应提供更好的性能。默认值为 |
|
|
指示从存储库检索Provenance事件时FlowFile属性的最大长度。如果任何属性的长度超过此值，则在检索事件时将截断该值。默认值为 |
|
|
Apache Lucene在索引中创建了几个“段”。这些段定期合并在一起，以提供更快的查询。此属性指定允许用于每个存储目录的最大线程数。默认值为 |
|
|
每次运行Provenance查询时，查询必须首先搜索Apache Lucene索引（至少在大多数情况下 - 有一些查询经常运行并且结果被缓存以避免搜索Lucene索引）。当Lucene索引首次打开时，它可能非常昂贵并且需要几秒钟。这有很多不同的索引，并且可能导致Provenance查询花费更长时间。打开索引后，操作系统的磁盘缓存通常会保留足够的数据，以便更快地重新打开索引 - 至少在一段时间内，直到磁盘缓存逐出该数据。如果设置了此值，NiFi将定期打开每个Lucene索引，然后关闭它，以“加热”缓存。当Provenance Repository很大时，这将导致更快的查询。然而，与所有伟大的事物一样，它带来了成本。加热缓存确实需要一些CPU资源，但更重要的是，它会从操作系统磁盘缓存中驱逐其他数据，并导致从磁盘读取（可能是大量的）数据。这可能导致较低的NiFi性能。但是，如果NiFi在CPU和磁盘未充分利用的环境中运行，则此功能可以使Provenance查询速度快得多。此属性的默认值为空（即禁用）。但更重要的是，它将从操作系统磁盘缓存中驱逐其他数据，并将导致从磁盘读取（可能是大量）数据。这可能导致较低的NiFi性能。但是，如果NiFi在CPU和磁盘未充分利用的环境中运行，则此功能可以使Provenance查询速度快得多。此属性的默认值为空（即禁用）。但更重要的是，它将从操作系统磁盘缓存中驱逐其他数据，并将导致从磁盘读取（可能是大量）数据。这可能导致较低的NiFi性能。但是，如果NiFi在CPU和磁盘未充分利用的环境中运行，则此功能可以使Provenance查询速度快得多。此属性的默认值为空（即禁用）。 |
加密的提前写入存储库属性(Encrypted Write Ahead Provenance Repository Properties)
上面定义的所有属性（请参阅“ 编写预先存储库属性”）仍然适用。此处仅列出特定于加密的属性。有关详细信息，请参阅“用户指南”中的“加密的源代码存储库”。
|
属性 |
描述 |
|
|
控制在记录存储库性能指标的DEBUG语句之间处理的事件数。仅当在日志配置中启用DEBUG级别语句时才使用此值。 |
|
|
这是密钥提供者的完全限定类名。密钥提供程序是用于访问加密密钥以保护起源事件的数据存储区接口。目前有两种实现方式- |
|
|
该键定义资源的路径（为空 |
|
|
用于加密的活动密钥ID（例如 |
|
|
使用的关键 |
|
|
允许为其指定其他键 |
最简单的配置如下：
nifi.provenance.repository.implementation = org.apache.nifi.provenance.EncryptedWriteAheadProvenanceRepository nifi.provenance.repository.debug.frequency = 100 nifi.provenance.repository.encryption.key.provider.implementation = org.apache.nifi.security.kms.StaticKeyProvider nifi.provenance.repository.encryption.key.provider.location = nifi.provenance.repository.encryption.key.id =key1 nifi.provenance.repository.encryption.key = 0123456789ABCDEFFEDCBA98765432100123456789ABCDEFFEDCBA9876543210
持久性源代码库属性(Persistent Provenance Repository Properties)
|
属性 |
描述 |
|
|
Provenance存储库的位置。默认值为 |
|
|
保留数据出处信息的最长时间。默认值为 |
|
|
一次存储的最大数据源信息量。默认值为 |
|
|
在滚动最新数据出处信息之前等待的时间量，以便在用户界面中可用。默认值为 |
|
|
一次滚动的信息量。默认值为 |
|
|
用于Provenance Repository查询的线程数。默认值为 |
|
|
用于索引Provenance事件的线程数，以便可以搜索它们。默认值为 |
|
|
指示在翻转时是否压缩出处信息。默认值为 |
|
|
如果设置为 |
|
|
应该用于序列化Provenance事件数据的日志文件数。增加此值将允许更多任务同时更新存储库，但稍后将导致更昂贵的日志文件合并。理想情况下，此值应等于预期同时更新存储库的线程数，但16必须在必需环境中正常工作。默认值为 |
|
|
这是一个以逗号分隔的字段列表，应该将其编入索引并进行搜索。未编制索引的字段将无法搜索。有效的字段有： |
|
|
这是一个以逗号分隔的FlowFile属性列表，应该对其进行索引并使其可搜索。默认为空白。但一些很好的例子要考虑的是 |
|
|
在搜索Provenance存储库时，分片大小的较大值将导致更多Java堆使用，但应提供更好的性能。默认值为 |
|
|
指示从存储库检索Provenance事件时FlowFile属性的最大长度。如果任何属性的长度超过此值，则在检索事件时将截断该值。默认值为 |
易失性来源存储库属性(Volatile Provenance Repository Properties)
|
属性 |
描述 |
|
|
Provenance Repository缓冲区大小。 |
组件状态存储库(Component Status Repository)
组件状态存储库包含用户界面中“组件状态历史记录”工具的信息。这些属性控制着该工具的工作方式。
在buffer.size和snapshot.frequency一起工作以确定历史数据保留量。例如，配置两天的历史数据，每5分钟发生一次数据点快照，您将配置 snapshot.frequency为“5分钟”，缓冲区大小为“576”。为了进一步解释此示例每60分钟，该时间段有12（60/5）个快照窗口。为了保持48小时（12 * 48）的数据，最终缓冲区大小为576。
|
属性 |
描述 |
|
|
组件状态存储库实现。默认值是 |
|
|
指定组件状态存储库的缓冲区大小。默认值为 |
|
|
此值指示显示组件状态历史记录快照的频率。默认值为 |
站点到站点属性(Site to Site Properties)
这些属性控制在数据流中配置远程进程组时，此NiFi实例如何与远程NiFi实例通信。远程进程组可以从RAW和HTTP中选择传输协议。命名的属性nifi.remote.input.socket.*是特定于RAW传输协议的。同样，nifi.remote.input.http.*HTTP传输协议特定属性。
|
属性 |
描述 |
|
|
将发送给客户端以连接到此NiFi实例以进行站点到站点通信的主机名。默认情况下，它是来自的值 |
|
|
这表明此NiFi实例与远程NiFi实例之间的通信是否应该是安全的。默认情况下，它设置为 |
|
|
用于站点到站点通信的远程输入套接字端口。默认情况下，它是空白的，但它必须具有一个值才能使用RAW套接字作为站点到站点的传输协议。 |
|
|
指定是否应在此主机上启用HTTP站点到站点。默认情况下，它设置为 |
|
|
指定事务在服务器上保持活动状态的时间。默认情况下，它设置为 |
|
|
指定NiFi在通过站点到站点进行通信时应缓存有关远程NiFi实例的信息的时间。默认情况下，NiFi将缓存 |
反向代理的站点到站点路由属性(Site to Site Routing Properties for Reverse Proxies)
站点到站点需要客户端和远程NiFi节点之间的对等通信。例如，如果远程NiFi群集具有3个节点（nifi0，nifi1和nifi2），则必须能够到达每个远程节点的客户端请求。
如果计划通过互联网或公司防火墙从/向站点到站点客户端接收/传输数据，则可以在NiFi群集节点前部署反向代理服务器，作为将客户端请求路由到的网关上游NiFi节点，以减少必须暴露的服务器和端口的数量。
在这样的环境中，同一网络中的站点到站点客户端也可以访问相同的NiFi群集。将流文件发送给自身以在NiFi群集节点之间进行负载分配可以是典型示例。在这种情况下，客户端请求应该直接路由到节点而不通过反向代理。
为了支持此类部署，远程NiFi群集需要根据客户端请求上下文动态公开其站点到站点端点。以下属性配置对等方应如何向客户端公开。路由定义包括4个属性，when，hostname，port，和secure，通过分组protocol和name。可以配置多个路由定义。protocol表示站点到站点传输协议，即RAW或HTTP。
|
属性 |
描述 |
|
|
布尔值， |
|
|
指定将引入站点到站点客户端以进行进一步通信的主机名。 |
|
|
指定将引入站点到站点客户端以进行进一步通信的端口号。 |
|
|
布尔值， |
以上所有路由属性都可以使用NiFi表达式语言从请求上下文计算目标对等项描述。可用变量是：
|
变量名 |
描述 |
|
|
请求来源的源的主机名和原始目标。 |
|
|
与上面相同，对于端口。源端口可能没有用，因为它只是一个客户端TCP端口。 |
|
|
与上述相同，为安全与否。 |
|
|
正在使用的站点到站点协议的名称， |
|
|
当前请求类型的名称， |
|
|
HTTP请求标头值可以通过其名称引用。 |
站点到站点协议序列(Site to Site protocol sequence)
正确配置这些属性需要对站点到站点协议序列有一些了解。
-
客户端通过向指定的远程URL发送HTTP（S）请求来获取站点到站点协议，以获取远程群集站点到站点信息。具体来说，到' /nifi-api/site-to-site '。调用此请求
SiteToSiteDetail。 -
远程NiFi节点响应其输入和输出端口，以及RAW和TCP传输协议的TCP端口号。
-
客户端使用＃2返回的TCP端口号发送另一个请求以获取远程对等方。根据此请求，原始套接字通信用于RAW传输协议，而HTTP继续使用HTTP（S）。调用此请求
Peers。 -
远程NiFi节点使用包含主机名，端口，安全性和工作负载（例如排队的FlowFiles数）的可用远程对等体列表进行响应。从这一点开始，在客户端和远程NiFi节点之间进行进一步的通信。
-
客户端根据工作负载信息决定从哪个对等方传输数据。
-
客户端向远程NiFi节点发送创建事务的请求。
-
远程NiFi节点接受该事务。
-
数据被发送到目标对等方。可以批量发送多个数据包。
-
当没有更多数据要发送或达到批量限制时，通过计算发送数据的CRC32哈希来确认两端的事务。
-
交易在两端都有。
反向代理配置
大多数反向代理软件都实现HTTP和TCP代理模式。对于NiFi RAW站点到站点协议，需要HTTP和TCP代理配置，并且至少需要打开2个端口。NiFi HTTP站点到站点协议可以将反向代理所需的开放端口数量最小化为1。
在反向代理中设置正确的HTTP头对于NiFi正常工作至关重要，不仅可以路由请求，还可以授权客户端请求。另请参阅代理配置以获取详细信
可以在反向代理服务器上应用两种类型的请求到NiFi节点映射技术。一个是“服务器名称到节点”，另一个是“端口号到节点”。
使用“服务器名称到节点”，可以使用相同的端口根据请求的服务器名称（例如nifi0.example.com，nifi1.example.com）将请求路由到不同的上游NiFi节点。应将主机名解析配置为将不同的主机名映射到相同的反向代理地址，这可以通过添加/ etc / hosts文件或DNS服务器条目来完成。此外，如果反向代理的客户端使用HTTPS，则反向代理服务器证书应具有通配符公用名或SAN，以便由不同的主机名访问。
某些反向代理技术不支持服务器名称路由规则，在这种情况下，请使用“端口号到节点”技术。“端口号到节点”映射要求NiFi群集的反向代理处的N开放端口由N个节点组成。
有关实际配置，请参阅以下示例。
站点到站点和反向代理示例
下面是一些示例反向代理和NiFi设置，以说明配置文件的外观。
下图中的Client1表示无法直接访问NiFi节点的客户端，它通过反向代理进行访问，而Client2具有直接访问权限。
在此示例中，Nginx用作反向代理。
示例1：RAW - 服务器名称到节点映射
-
Client1启动站点到站点协议，请求被路由到上游NiFi节点之一。NiFi节点计算RAW的站点到站点端口。通过下面显示的nifi.properties中的路由规则example1，返回端口10443。
-
Client1要求对等方
nifi.example.com:10443，请求被路由到nifi0:8081。NiFi节点计算可用的对等体，通过example1路由规则，nifi0:8081转换为nifi0.example.com:10443，nifi1以及和nifi2。其结果是，nifi0.example.com:10443，nifi1.example.com:10443和nifi2.example.com:10443返回。 -
Client1决定
nifi2.example.com:10443用于进一步的通信。 -
另一方面，Client2有两个用于站点到站点引导URI的URI，并使用其中一个启动协议。在例1路由不匹配，这对于该请求，并返回端口8081。
-
Client2向同行询问
nifi1:8081。该例1不匹配，所以原来的nifi0:8081，nifi1:8081并且nifi2:8081因为它们返回。 -
Client2决定使用
nifi2:8081进一步的通信。
在nifi.properties中定义的路由规则example1（所有节点具有相同的路由配置）：
#S2S路由为RAW，使用服务器名称到节点
nifi.remote.route.raw.example1.when = \
$ {X-ProxyHost的：等于（ 'nifi.example.com'）或（\
$ {s2s.source.hostname：等于（ 'nifi.example.com'）或（\
$ {s2s.source.hostname：等于（ '192.168.99.100'）}）}）}
nifi.remote.route.raw.example1.hostname = $ {} s2s.target.hostname .example.com的
nifi.remote.route.raw.example1.port = 10443
nifi.remote.route.raw.example1.secure =真
nginx.conf：
http {
upstream nifi {
server nifi0:8443;
server nifi1:8443;
server nifi2:8443;
}
# Use dnsmasq so that hostnames such as 'nifi0' can be resolved by /etc/hosts
resolver 127.0.0.1;
server {
listen 443 ssl;
server_name nifi.example.com;
ssl_certificate /etc/nginx/nginx.crt;
ssl_certificate_key /etc/nginx/nginx.key;
proxy_ssl_certificate /etc/nginx/nginx.crt;
proxy_ssl_certificate_key /etc/nginx/nginx.key;
proxy_ssl_trusted_certificate /etc/nginx/nifi-cert.pem;
location / {
proxy_pass https://nifi;
proxy_set_header X-ProxyScheme https;
proxy_set_header X-ProxyHost nginx.example.com;
proxy_set_header X-ProxyPort 17590;
proxy_set_header X-ProxyContextPath /;
proxy_set_header X-ProxiedEntitiesChain $ssl_client_s_dn;
}
}
}
stream {
map $ssl_preread_server_name $nifi {
nifi0.example.com nifi0;
nifi1.example.com nifi1;
nifi2.example.com nifi2;
default nifi0;
}
resolver 127.0.0.1;
server {
listen 10443;
proxy_pass $nifi:8081;
}
}
示例2：RAW - 节点映射的端口号
该例题路由映射原始主机名（nifi0，nifi1和nifi2），以不同的代理端口（10443，10444以及10445使用）equals和ifElse表达式。
在nifi.properties中定义的路由规则example2（所有节点具有相同的路由配置）：
#S2S路由为RAW，使用端口号到节点
-
# S2S Routing for RAW, using port number to node nifi.remote.route.raw.example2.when=\ ${X-ProxyHost:equals('nifi.example.com'):or(\ ${s2s.source.hostname:equals('nifi.example.com'):or(\ ${s2s.source.hostname:equals('192.168.99.100')})})} nifi.remote.route.raw.example2.hostname=nifi.example.com nifi.remote.route.raw.example2.port=\ ${s2s.target.hostname:equals('nifi0'):ifElse('10443',\ ${s2s.target.hostname:equals('nifi1'):ifElse('10444',\ ${s2s.target.hostname:equals('nifi2'):ifElse('10445',\ 'undefined')})})} nifi.remote.route.raw.example2.secure=true
nginx.conf：
-
http { # Same as example 1. } stream { map $ssl_preread_server_name $nifi { nifi0.example.com nifi0; nifi1.example.com nifi1; nifi2.example.com nifi2; default nifi0; } resolver 127.0.0.1; server { listen 10443; proxy_pass nifi0:8081; } server { listen 10444; proxy_pass nifi1:8081; } server { listen 10445; proxy_pass nifi2:8081; } }
示例3：HTTP - 服务器名称到节点映射
nifi.properties中定义的路由规则example3（所有节点具有相同的路由配置）：
-
# S2S Routing for HTTP nifi.remote.route.http.example3.when=${X-ProxyHost:contains('.example.com')} nifi.remote.route.http.example3.hostname=${s2s.target.hostname}.example.com nifi.remote.route.http.example3.port=443 nifi.remote.route.http.example3.secure=true
nginx.conf：
-
http { upstream nifi_cluster { server nifi0:8443; server nifi1:8443; server nifi2:8443; } # If target node is not specified, use one from cluster. map $http_host $nifi { nifi0.example.com:443 "nifi0:8443"; nifi1.example.com:443 "nifi1:8443"; nifi2.example.com:443 "nifi2:8443"; default "nifi_cluster"; } resolver 127.0.0.1; server { listen 443 ssl; server_name ~^(.+\.example\.com)$; ssl_certificate /etc/nginx/nginx.crt; ssl_certificate_key /etc/nginx/nginx.key; proxy_ssl_certificate /etc/nginx/nginx.crt; proxy_ssl_certificate_key /etc/nginx/nginx.key; proxy_ssl_trusted_certificate /etc/nginx/nifi-cert.pem; location / { proxy_pass https://$nifi; proxy_set_header X-ProxyScheme https; proxy_set_header X-ProxyHost $1; proxy_set_header X-ProxyPort 443; proxy_set_header X-ProxyContextPath /; proxy_set_header X-ProxiedEntitiesChain $ssl_client_s_dn; } } }
网络属性 (Web Properties)
这些属性与基于Web的用户界面有关。
|
属性 |
描述 |
|
|
这是web war目录的位置。默认值为 |
|
|
HTTP主机。默认为空白。 |
|
|
HTTP端口。默认值为 |
|
|
将传入的HTTP请求转发到的端口 |
|
|
NiFi应为HTTP请求绑定的网络接口的名称。默认为空白。 |
|
|
HTTPS主机。默认为空白。 |
|
|
HTTPS端口。默认为空白。配置NiFi以安全运行时，应配置此端口。 |
|
|
|
|
|
NiFi应为HTTPS请求绑定的网络接口的名称。默认为空白。 |
|
|
Jetty工作目录的位置。默认值为 |
|
|
Jetty线程的数量。默认值为 |
|
|
请求和响应标头允许的最大大小。默认值为 |
|
|
以逗号分隔的允许的HTTP主机标头值列表，当NiFi安全运行时将考虑这些值，并且将接收到与其绑定的不同主机[：port]的请求。例如，在Docker容器中运行或在代理后面运行时（例如localhost：18443，proxyhost：443）。默认情况下，此值为空，表示NiFi应仅允许发送到NiFi绑定的主机[：port]的请求。 |
|
|
要考虑的允许HTTP X-ProxyContextPath，X-Forwarded-Context或X-Forwarded-Prefix标头值的逗号分隔列表。默认情况下，此值为空，表示拒绝包含代理上下文路径的所有请求。配置此属性将允许此列表中包含代理路径的请求。 |
安全属性(Security Properties)
这些属性与NiFi中的各种安全功能有关。本“管理员指南”的“ 安全配置”部分详细介绍了其中许多属性 。
|
属性 |
描述 |
|
|
这是用于加密处理器中配置的任何敏感属性值的密码。默认情况下，它是空白的，但系统管理员应为其提供值。它可以是任意长度的字符串，但建议的最小长度为10个字符。请注意，一旦设置了此密码并且配置了一个或多个敏感处理器属性，就不应更改此密码。 |
|
|
用于加密敏感属性的算法。默认值为 |
|
|
敏感的财产提供者。默认值为 |
|
|
除了默认敏感属性之外，nifi.properties中的逗号分隔属性列表还要加密（请参阅配置文件中的加密密码）。 |
|
|
密钥库的完整路径和名称。默认为空白。 |
|
|
密钥库类型。默认为空白。 |
|
|
密钥库密码。默认为空白。 |
|
|
密钥密码。默认为空白。 |
|
|
信任库的完整路径和名称。默认为空白。 |
|
|
信任库类型。默认为空白。 |
|
|
信任库密码。默认为空白。 |
|
|
指定authorizers.xml文件中要使用的已配置Authorizer 。默认情况下，它设置为 |
|
|
这表示要使用的登录标识提供程序类型。默认值为空，可以从指定文件中的提供程序设置为标识符 |
|
|
这是在线证书状态协议（OCSP）响应程序的URL（如果正在使用）。默认为空白。 |
|
|
这是OCSP响应者证书的位置（如果正在使用）。默认为空白。 |
身份映射属性 ( Identity Mapping Properties )
这些属性可用于规范用户身份。实施后，由不同身份提供商（证书，LDAP，Kerberos）进行身份验证的身份在NiFi内部处理相同。因此，避免了重复的用户，并且仅需要为每个用户设置一次特定于用户的配置（例如授权）。
以下示例演示了如何从证书和Kerberos主体中规范化DN：
-
nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), L=(.*?), ST=(.*?), C=(.*?)$ nifi.security.identity.mapping.value.dn=$1@$2 nifi.security.identity.mapping.transform.dn=NONE nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$ nifi.security.identity.mapping.value.kerb=$1@$2 nifi.security.identity.mapping.transform.kerb=NONE
-
每个属性的最后一段是用于将模式与替换值相关联的标识符。当用户向NiFi发出请求时，将检查其身份以查看它是否与字典顺序中的每个模式匹配。对于匹配的第一个，nifi.security.identity.mapping.value.xxxx使用属性中指定的替换。因此，登录与CN=localhost, OU=Apache NiFi, O=Apache, L=Santa Monica, ST=CA, C=US上面的DN映射模式匹配，并$1@$2应用DN映射值。用户标准化为localhost@Apache NiFi。
除了映射之外，还可以应用变换。支持的版本是NONE（未应用转换），LOWER（标识小写）和UPPER（标识大写）。如果未指定，则默认值为NONE。
| 这些映射还应用于“初始管理员标识”，“群集节点标识”以及authorizers.xml文件中的所有旧用户以及从LDAP导入的用户（请参阅Authorizers.xml安装程序）。 |
组名也可以映射。以下示例将接受现有的组名称，但会将其小写。与外部授权人一起使用时，这可能会有所帮助。
-
nifi.security.group.mapping.pattern.anygroup=^(.*)$ nifi.security.group.mapping.value.anygroup=$1 nifi.security.group.mapping.transform.anygroup=LOWER
-
| 这些映射适用于authorizers.xml中引用的任何遗留组以及从LDAP导入的组。 |
群集公共属性
设置NiFi群集时，应在所有节点上以相同方式配置这些属性。
|
属性 |
描述 |
|
|
节点应向群集协调器发出心跳的时间间隔。默认值为 |
|
|
这表明群集通信是否安全。默认值为 |
群集节点属性
为群集节点配置这些属性。
|
属性 |
描述 |
|
|
|
|
|
节点的完全限定地址。默认为空白。 |
|
|
节点的协议端口。默认为空白。 |
|
|
应该用于与群集中的其他节点通信的线程数。此属性默认为 |
|
|
应该用于与群集中其他节点通信的最大线程数。此属性默认为 |
|
|
更改群集中节点的状态时，将生成一个事件，并可在“群集”页面中查看该事件。此值指示每个节点在内存中保留的事件数。默认值为 |
|
|
连接到群集中的另一个节点时，指定在考虑连接失败之前此节点应等待的时间。默认值为 |
|
|
与群集中的另一个节点通信时，指定此节点在考虑与节点通信失败之前应等待多长时间从远程节点接收信息。默认值为 |
|
|
可以复制到群集中节点的未完成Web请求的最大数量。如果超过此数量的请求，嵌入式Jetty服务器将返回“409：Conflict”响应。此属性默认为 |
|
|
节点防火墙文件的位置。这是一个文件，可用于列出允许连接到群集的所有节点。它提供了额外的安全层。默认情况下，此值为空，表示不使用防火墙文件。 |
|
|
指定在选择Flow作为“正确”流之前等待的时间量。如果已投票的节点数等于 |
|
|
指定群集中所需的节点数，以便提前选择流。这允许群集中的节点避免在开始处理之前等待很长时间，如果我们至少达到群集中的此数量的节点。 |
|
|
指定在选择Flow作为“正确”流之前等待的时间量。如果已投票的节点数等于 |
|
|
指定群集中所需的节点数，以便提前选择流。这允许群集中的节点避免在开始处理之前等待很长时间，如果我们至少达到群集中的此数量的节点。 |
|
|
指定要侦听传入连接的端口，以便跨群集负载平衡数据。默认值为 |
|
|
指定要侦听传入连接的主机名，以便跨群集负载平衡数据。如果未指定，将默认为 |
|
|
此节点与群集中每个其他节点之间要创建的最大连接数。例如，如果群集中有5个节点且此值设置为4，则最多将建立20个套接字连接以实现负载平衡（5 x 4 = 20）。默认值为 |
|
|
用于将数据从此节点传输到群集中其他节点的最大线程数。例如，如果此值设置为8，则最多有8个线程负责将数据传输到其他节点，而不管群集中有多少个节点。虽然给定线程一次只能写入一个套接字，但是单个线程能够同时为多个连接提供服务，因为给定的连接可能无法在任何给定时间进行读/写。默认值为 |
|
|
与另一个节点通信时，如果在读取或写入套接字时经过了这段时间而没有取得任何进展，则会抛出TimeoutException。这将导致数据被重试或发送到集群中的另一个节点，具体取决于配置的负载平衡策略。默认值为 |
索赔管理
每当请求更改数据流时，重要的是NiFi群集中的所有节点都保持同步。为了实现这一点，NiFi采用了两阶段提交。首先将请求复制到群集中的所有节点，只询问是否允许该请求。然后，每个节点确定它是否允许该请求，如果是，则在被修改的组件上发出“声明”。可以将此声明视为请求者拥有的互斥锁。一旦所有节点都对是否允许该请求进行了投票，则发起请求的节点必须决定是否完成该请求。如果任何节点投票为“否”，则取消请求并取消声明，并将错误消息发送回用户。但是，如果节点全部投票' 是'然后请求完成。在这种分布式环境中，在发生投票之后和请求完成之前，发出原始请求的节点可能会失败。这将使组件无限期地锁定，以便不再对组件进行更改。为了避免这种情况，索赔将在一段时间后超时。
ZooKeeper属性
NiFi依赖于Apache ZooKeeper来确定集群中哪个节点应该扮演主节点的角色以及哪个节点应该扮演集群协调器的角色。必须配置这些属性才能使NiFi加入群集。
|
属性 |
描述 |
|
|
连接到Apache ZooKeeper所需的Connect String。这是一个以逗号分隔的hostname：port对列表。例如， |
|
|
在考虑连接失败之前连接到ZooKeeper时需要等待多长时间。默认值为 |
|
|
在会话过期之前丢失与ZooKeeper的连接后等待多长时间。默认值为 |
|
|
应该在ZooKeeper中使用的根ZNode。ZooKeeper提供了一个类似目录的结构来存储数据。此结构中的每个“目录”称为ZNode。这表示应该用于存储数据的根ZNode或“目录”。默认值为 |
Kerberos属性
|
属性 |
描述 |
|
|
krb5文件的位置（如果使用）。默认为空白。此时，每个NiFi实例只允许指定一个krb5文件，因此此属性在此处配置为支持SPNEGO和服务主体，而不是单个处理器。如有必要，krb5文件可以支持多个领域。例： |
|
|
NiFi Kerberos服务主体的名称（如果使用）。默认为空白。请注意，此属性适用于NiFi作为客户端其他系统进行身份验证。示例： |
|
|
NiFi Kerberos密钥表的文件路径（如果使用）。默认为空白。请注意，此属性适用于NiFi作为客户端其他系统进行身份验证。例： |
|
|
NiFi Kerberos服务主体的名称（如果使用）。默认为空白。请注意，此属性用于验证NiFi用户。示例： |
|
|
NiFi Kerberos密钥表的文件路径（如果使用）。默认为空白。请注意，此属性用于验证NiFi用户。例： |
|
|
成功使用Kerberos用户身份验证的到期持续时间（如果使用）。默认值为 |
自定义属性
配置用于NiFi表达式语言的自定义属性：
-
创建自定义属性。确保这件事：
-
每个自定义属性都包含一个不同的属性值，因此它不会被现有的环境属性，系统属性或FlowFile属性覆盖。
-
群集环境中的每个节点都配置有相同的自定义属性。
-
-
nifi.variable.registry.properties使用自定义属性文件的位置进行更新：
|
属性 |
描述 |
|
|
这是一个逗号分隔的一个或多个自定义属性文件的文件位置路径列表。 |
-
重新启动NiFi实例以获取要更新的更新。
也可以在NiFi UI中配置自定义属性。有关详细信息，请参阅“ 用户指南”中的“ 变量窗口”部分。
|
升级 配置上面标有星号（*）的属性时要小心。要使升级过程更容易，建议将默认配置更改为主根安装目录之外的位置。通过这种方式，这些项目可以通过升级保留在其配置的位置，NiFi可以找到所有存储库和配置文件，并在旧版本停止并启动新版本后立即从中断处继续。此外，管理员可以重复使用此nifi.properties文件和任何其他配置文件，而无需在每次升级时重新配置它们。如前所述，检查nifi.properties中的任何更改非常重要升级时新版本的文件，并确保它们反映在您使用的nifi.properties文件中。 |
