在“ Web属性”部分下，设置要在其上运行节点的HTTP或HTTPS端口。另外，请考虑是否需要设置HTTP或HTTPS主机属性。群集中的所有节点都应使用相同的协议设置。
在“ 状态管理”部分下，将该nifi.state.management.provider.cluster属性设置为“群集状态提供程序”的标识符。确保已在state-management.xml文件中配置了群集状态提供程序。有关更多信息，请参阅配置状态提供程序
在“ 群集节点属性”下，设置以下内容：
- nifi.cluster.is.node- 将此设置为true。
- nifi.cluster.node.address - 将其设置为节点的标准主机名。如果留空，则默认为localhost。
- nifi.cluster.node.protocol.port - 将其设置为高于1024的开放端口（任何低端都需要root）。
- nifi.cluster.node.protocol.threads - 应该用于与群集中的其他节点通信的线程数。此属性默认为10。线程池用于将请求复制到所有节点，并且线程池的线程数永远不会少于此数量。它将根据需要增长到nifi.cluster.node.protocol.max.threads 属性设置的最大值。
- nifi.cluster.node.protocol.max.threads - 应该用于与群集中其他节点通信的最大线程数。此属性默认为50。线程池用于对所有节点的复制请求，并且线程池将具有由nifi.cluster.node.protocol.threads属性配置的“核心”大小。但是，如有必要，线程池会将活动线程数增加到此属性设置的限制。
- nifi.zookeeper.connect.string - 连接到Apache ZooKeeper所需的连接字符串。这是一个以逗号分隔的hostname：port对列表。例如，localhost:2181,localhost:2182,localhost:2183。这应该包含ZooKeeper仲裁中所有ZooKeeper实例的列表。
- nifi.zookeeper.root.node - 应在ZooKeeper中使用的根ZNode。ZooKeeper提供了一个类似目录的结构来存储数据。此结构中的每个“目录”称为ZNode。这表示应该用于存储数据的根ZNode或“目录”。默认值为/root。这对于正确设置很重要，因为NiFi实例尝试加入的群集取决于它连接到哪个ZooKeeper实例以及指定的ZooKeeper根节点。
- nifi.cluster.flow.election.max.wait.time - 指定在选择Flow作为“正确”流之前等待的时间量。如果已投票的节点数等于nifi.cluster.flow.election.max.candidates 属性指定的数量，则群集将不会等待这么长时间。默认值为5 mins。请注意，一旦投票第一次投票，时间就会开始。
- nifi.cluster.flow.election.max.candidates - 指定群集中所需的节点数，以便提前选择流。这允许群集中的节点避免在开始处理之前等待很长时间，如果我们至少达到群集中的此数量的节点。

现在，可以启动集群。实例启动的顺序无关紧要。导航到其中一个节点的URL，用户界面应类似于以下内容：

故障排除

如果遇到问题并且您的群集无法按照描述运行，请调查节点上的nifi-app.log和nifi-user.log文件。如果需要，可以通过编辑conf/logback.xml文件将日志记录级别更改为DEBUG 。具体来说，设置level="DEBUG"以下行（而不是"INFO"）：

<logger name="org.apache.nifi.web.api.config" level="INFO" additivity="false">

<appender-ref ref="USER_FILE"/>

</logger>

State管理

NiFi为处理器，报告任务，控制器服务和框架本身提供了一种机制来保持状态。例如，这允许处理器在重新启动NiFi后从其停止的位置恢复。此外，它允许处理器存储某些信息，以便处理器可以从群集中的所有不同节点访问该信息。这允许一个节点拾取另一个节点停止的位置，或者在集群中的所有节点之间进行协调。

配置状态提供程序

当组件决定存储或检索状态时，它通过提供“范围” - 节点本地或群集范围来实现。然后，基于此Scope以及配置的状态提供程序确定用于存储和检索此状态的机制。该nifi.properties文件包含有关配置这些国家供应商三种不同的特性。

属性	描述
`nifi.state.management.configuration.file`	第一个是指定外部XML文件的属性，该文件用于配置本地和/或群集范围的状态提供程序。此XML文件可能包含多个提供程序的配置
`nifi.state.management.provider.local`	提供此XML文件中配置的本地State Provider标识符的属性
`nifi.state.management.provider.cluster`	同样，该属性提供在此XML文件中配置的群集范围的State Provider的标识符。

此XML文件由*state-management元素组成，该元素具有一个或多个local-provider零个或多个cluster-provider 元素。然后，这些元素中的每一个都包含一个id元素，用于指定可在nifi.properties文件中引用的标识符，以及一个class元素，该元素指定要用于实例化State Provider的完全限定类名。最后，这些元素中的每一个可以具有零个或多个property元素。每个property元素都有一个属性，name即propertyState Provider支持的名称。property元素的文本内容是属性的值。

在state-management.xml文件（或配置的任何文件）中配置了这些状态提供程序后，这些提供程序可能会被其标识符引用。

默认情况下，本地状态提供程序配置为将WriteAheadLocalStateProvider数据持久保存到 $NIFI_HOME/state/local目录。默认的群集状态提供程序配置为a ZooKeeperStateProvider。默认的基于ZooKeeper的提供程序必须先Connect String填充其属性，然后才能使用它。如果多个NiFi实例将使用相同的ZooKeeper实例，则建议Root Node更改属性的值。例如，可以将值设置为 /nifi/<team name>/production。A Connect String采用逗号分隔的<host>：<port>元组的形式，例如 my-zk-server1:2181,my-zk-server2:2181,my-zk-server3:2181。如果没有为任何主机指定端口，2181则假定为ZooKeeper默认值。

向ZooKeeper添加数据时，Access Control有两个选项：Open和CreatorOnly。如果该Access Control属性设置为Open，则允许任何人登录ZooKeeper并拥有查看，更改，删除或管理数据的完全权限。如果CreatorOnly已指定，则仅允许创建数据的用户读取，更改，删除或管理数据。为了使用该CreatorOnly选项，NiFi必须提供某种形式的身份验证。有关如何配置身份验证的详细信息，请参阅下面的ZooKeeper访问控制部分。

如果NiFi配置为在独立模式下运行，则cluster-provider无需在state-management.xml 文件中填充该元素，如果填充它们，实际上将忽略该元素。但是，local-provider元素必须始终存在并填充。此外，如果NiFi在群集中运行，则每个节点还必须具有该cluster-provider元素并且已正确配置。否则，NiFi将无法启动。

虽然没有很多属性需要为这些提供程序配置，但它们被外部化为单独的state-management.xml 文件，而不是通过nifi.properties文件进行配置，因为不同的实现可能需要不同的属性，并且它更容易维护和理解基于XML的文件中的配置，而不是将Provider的属性与所有其他NiFi框架特定的属性混合在一起。

应注意，如果处理器和其他组件使用“集群”作用域保存状态，则如果实例是独立实例（不在集群中）或与集群断开连接，则将使用本地状态提供程序。这也意味着如果将独立实例迁移为群集，则该状态将不再可用，因为该组件将开始使用群集状态提供程序而不是本地状态提供程序。

嵌入式ZooKeeper服务器

如上所述，群集范围状态的默认状态提供程序是ZooKeeperStateProvider。在撰写本文时，这是唯一存在用于处理群集范围状态的状态提供程序。这意味着NiFi依赖于ZooKeeper以表现为集群。但是，在许多环境中，部署了NiFi，而没有维护现有的ZooKeeper集合。为了避免强迫管理员维护单独的ZooKeeper实例的负担，NiFi提供了启动嵌入式ZooKeeper服务器的选项。

属性	描述
`nifi.state.management.embedded.zookeeper.start`	指定此NiFi实例是否应运行嵌入式ZooKeeper服务器
`nifi.state.management.embedded.zookeeper.properties`	如果`nifi.state.management.embedded.zookeeper.start`设置为，则提供要使用的ZooKeeper属性的属性文件`true`

这可以通过设置来实现nifi.state.management.embedded.zookeeper.start财产nifi.properties到true应该运行嵌入式的ZooKeeper服务器的节点上。通常，建议在3或5个节点上运行ZooKeeper。在少于3个节点上运行可在遇到故障时提供较低的耐用性。在超过5个节点上运行通常会产生比必要更多的网络流量。此外，在4个节点上运行ZooKeeper提供的优势不比在3个节点上运行，ZooKeeper要求大多数节点处于活动状态才能运行。但是，由管理员决定最适合NiFi特定部署的节点数。

如果nifi.state.management.embedded.zookeeper.start属性设置为true，则nifi.properties中的nifi.state.management.embedded.zookeeper.properties属性也变得相关。这指定要使用的ZooKeeper属性文件。此属性文件至少需要填充ZooKeeper服务器列表。服务器被指定为的形式属性，以。每个服务器都配置为<hostname>：<quorum port> [：<leader election port>]。例如，。此节点列表应该是NiFi群集中具有属性设置的相同节点server.1server.2server.nmyhost:2888:3888nifi.state.management.embedded.zookeeper.starttrue。另请注意，由于ZooKeeper将侦听这些端口，因此可能需要将防火墙配置为打开这些端口以用于传入流量，至少在群集中的节点之间。此外，必须在防火墙中打开侦听客户端连接的端口。默认值为，2181但可以通过zookeeper.properties文件中的clientPort属性进行配置。

使用嵌入式ZooKeeper时，。/ conf / zookeeper.properties文件具有名为的属性dataDir。默认情况下，此值设置为./state/zookeeper。如果多个NiFi节点正在运行嵌入式ZooKeeper，则告诉服务器它是哪一个非常重要。这是通过创建名为myid的文件并将其放在ZooKeeper的数据目录中来完成的。此文件的内容应该是特定于服务器的索引server.<number>。因此，对于其中一个ZooKeeper服务器，我们将通过执行以下命令来完成此任务：

cd $NIFI_HOME
 
mkdir state
 
mkdir state/zookeeper
 
echo 1 > state/zookeeper/myid

对于将运行ZooKeeper的下一个NiFi节点，我们可以通过执行以下命令来实现此目的：

cd $NIFI_HOME
 
mkdir state
 
mkdir state/zookeeper
 
echo 2 > state/zookeeper/myid

等等。

有关用于管理ZooKeeper的属性的更多信息，请参阅 ZooKeeper管理员指南。

有关保护嵌入式ZooKeeper服务器的信息，请参阅下面的“ 保护ZooKeeper”部分。

ZooKeeper访问控制

ZooKeeper通过访问控制列表（ACL）机制为其数据提供访问控制。当数据写入ZooKeeper时，NiFi将提供一个ACL，指示允许任何用户拥有对数据的完全权限，或者提供一个ACL，指示只允许创建数据的用户访问数据。使用哪个ACL取决于该Access Control属性的值ZooKeeperStateProvider（有关详细信息，请参阅“ 配置状态提供程序”部分）。

为了使用指示只允许Creator访问数据的ACL，我们需要告诉ZooKeeper创建者是谁。有两种机制可以实现这一目标。第一种机制是使用Kerberos提供身份验证。有关更多信息，请参阅Kerberizing NiFi的ZooKeeper客户端。

第二个选项是使用用户名和密码。这是通过为其指定值Username和Password属性值来配置的ZooKeeperStateProvider（有关详细信息，请参阅“ 配置状态提供程序”部分）。不过，要记住的重要一点是ZooKeeper会以纯文本传递密码。这意味着不应使用用户名和密码，除非ZooKeeper在localhost上作为单实例集群运行，或者与ZooKeeper的通信仅在加密通信（例如VPN或SSL连接）上发生。ZooKeeper将在3.5.0版本中为SSL连接提供支持。

ZooKeeper安全

当NiFi与ZooKeeper通信时，默认情况下，所有通信都是不安全的，登录ZooKeeper的任何人都可以查看和操作存储在ZooKeeper中的所有NiFi状态。为了防止这种情况，我们可以使用Kerberos来管理身份验证。目前，ZooKeeper不支持通过SSL加密。正在积极开发对ZooKeeper中的SSL的支持，预计将在3.5.x发行版中提供。

为了保护通信安全，我们需要确保客户端和服务器都支持相同的配置。下面提供了配置NiFi ZooKeeper客户端和嵌入式ZooKeeper服务器以使用Kerberos的说明。

如果您的环境中尚未设置Kerberos，则可以在Red Hat客户门户上找到有关安装和设置Kerberos服务器的信息：配置Kerberos 5服务器。本指南假定Kerberos已经安装在运行NiFi的环境中。

请注意，以下用于在NiFi节点中对嵌入式ZooKeeper服务器进行kerberizing并对ZooKeeper NiFi客户端进行kerberizing的过程将要求安装Kerberos客户端库。这是通过以下方式在基于Fedora的Linux发行版中完成的：

yum install krb5-workstation

完成后，需要为组织的Kerberos环境正确配置/etc/krb5.conf。

Kerberizing嵌入式ZooKeeper服务器

所述的krb5.conf上具有嵌入的动物园管理员服务器系统文件应该是相同的，其中krb5kdc服务运行在系统上的一个。使用嵌入式ZooKeeper服务器时，我们可能会选择使用Kerberos来保护服务器。配置为启动嵌入式ZooKeeper并使用Kerberos的所有节点都应遵循以下步骤。使用嵌入式ZooKeeper服务器时，我们可能会选择使用Kerberos来保护服务器。配置为启动嵌入式ZooKeeper并使用Kerberos的所有节点都应遵循以下步骤。

为了使用Kerberos，我们首先需要为ZooKeeper服务器生成Kerberos Principal。在运行krb5kdc服务的服务器上运行以下命令。这是通过kadmin工具完成的：

kadmin: addprinc "zookeeper/myHost.example.com@EXAMPLE.COM"

在这里，我们zookeeper/myHost.example.com使用领域创建一个主要的Principal EXAMPLE.COM。我们需要使用名称为的Principal <service name>/<instance name>。在这种情况下，服务是zookeeper，实例名称是myHost.example.com（我们的主机的完全限定名称）。

接下来，我们需要为此Principal创建一个KeyTab，此命令在具有嵌入式zookeeper服务器的NiFi实例的服务器上运行：

kadmin: xst -k zookeeper-server.keytab zookeeper/myHost.example.com@EXAMPLE.COM

这将在当前目录中创建一个名为的文件zookeeper-server.keytab。我们现在可以将该文件复制到$NIFI_HOME/conf/目录中。我们应该确保只允许运行NiFi的用户读取该文件。

我们需要重复每个NiFi的情况下，上述步骤将运行嵌入式的ZooKeeper服务器，请务必更换myHost.example.com同myHost2.example.com，或任何完全合格的主机名的ZooKeeper服务器将运行。

现在我们已经为每个将运行NiFi的服务器提供了KeyTab，我们需要配置NiFi的嵌入式ZooKeeper服务器才能使用此配置。ZooKeeper使用Java身份验证和授权服务（JAAS），因此我们需要创建一个与JAAS兼容的文件在$NIFI_HOME/conf/目录中，创建一个名为zookeeper-jaas.conf的文件（如果客户端已配置为进行身份验证，则此文件已存在通过Kerberos。没关系，只需添加到文件中）。我们将添加到此文件，以下代码段：

Server {
 
com.sun.security.auth.module.Krb5LoginModule required
 
useKeyTab=true
 
keyTab="./conf/zookeeper-server.keytab"
 
storeKey=true
 
useTicketCache=false
 
principal="zookeeper/myHost.example.com@EXAMPLE.COM";
 
};

请务必principal使用适当的Principal 替换上面的值，包括服务器的完全限定域名。

接下来，我们需要告诉NiFi使用它作为我们的JAAS配置。这是通过设置JVM系统属性来完成的，因此我们将编辑conf / bootstrap.conf文件。如果客户端已配置为使用Kerberos，则不需要这样做，如上所述。否则，我们将以下行添加到bootstrap.conf文件中：

java.arg.15=-Djava.security.auth.login.config=./conf/zookeeper-jaas.conf

文件中的这一附加行不必是15号，只需将其添加到bootstrap.conf文件中即可。使用适合您的配置的任何数字。

我们希望通过运行以下命令来初始化我们的Kerberos票证：

kinit –kt zookeeper-server.keytab "zookeeper/myHost.example.com@EXAMPLE.COM"

同样，请务必使用适当的值替换Principal，包括您的领域和完全限定的主机名。

最后，我们需要告诉Kerberos服务器使用SASL身份验证提供程序。为此，我们编辑$ NIFI_HOME / conf / zookeeper.properties文件并添加以下行：

authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
 
kerberos.removeHostFromPrincipal=true
 
kerberos.removeRealmFromPrincipal=true
 
jaasLoginRenew=3600000
 
requireClientAuthScheme=sasl

的kerberos.removeHostFromPrincipal和kerberos.removeRealmFromPrincipal特性被用来标识进行比较来施加在Z序节点的ACL之前归一化所述用户主要名称。默认情况下，全部本金用来然而设置kerberos.removeHostFromPrincipal和kerberos.removeRealmFromPrincipal属性为true，将指示动物园管理员删除的主机和登录用户的身份进行比较的境界。在NiFi节点（在同一群集内）使用具有不同主机/域值的主体的情况下，可以配置这些kerberos属性以确保节点的标识将被标准化并且节点将具有适当的访问Zookeeper中的共享Znodes。

最后一行是可选的，但指定客户端必须使用Kerberos与我们的ZooKeeper实例进行通信。

现在，我们可以启动NiFi，嵌入式ZooKeeper服务器将使用Kerberos作为身份验证机制。

Kerberizing NiFi的ZooKeeper客户端

运行嵌入式zookeeper服务器的NiFi节点也需要遵循以下过程，因为它们也将同时充当客户端。

使用ZooKeeper验证用户的首选机制是使用Kerberos。为了使用Kerberos进行身份验证，我们必须配置一些系统属性，以便ZooKeeper客户端知道用户是谁以及KeyTab文件所在的位置。配置为使用ZooKeeperStateProvider和使用Kerberos 存储群集范围状态的所有节点都应遵循以下步骤。

首先，我们必须创建在与ZooKeeper通信时使用的Principal。这通常通过kadmin工具完成：

kadmin: addprinc "nifi@EXAMPLE.COM"

Kerberos Principal由三部分组成：主要部分，实例和领域。在这里，我们正在创建一个具有主要nifi，无实例和领域的Principal EXAMPLE.COM。主要（nifi在本例中）是在通过Kerberos进行身份验证时用于标识用户的标识符。

在我们创建了Principal后，我们需要为Principal创建一个KeyTab：

kadmin: xst -k nifi.keytab nifi@EXAMPLE.COM

可以将此密钥表文件复制到具有嵌入式zookeeper服务器的其他NiFi节点。

这将在名为nifi.keytab的当前目录中创建一个文件。我们现在可以将该文件复制到$NIFI_HOME/conf/目录中。我们应该确保只允许运行NiFi的用户读取该文件。

接下来，我们需要配置NiFi以使用此KeyTab进行身份验证。由于ZooKeeper使用Java身份验证和授权服务（JAAS），因此我们需要创建一个与JAAS兼容的文件。在$NIFI_HOME/conf/目录中，创建一个名为zookeeper-jaas.conf的文件，并在其中添加以下代码段：

Client {
 
com.sun.security.auth.module.Krb5LoginModule required
 
useKeyTab=true
 
keyTab="./conf/nifi.keytab"
 
storeKey=true
 
useTicketCache=false
 
principal="nifi@EXAMPLE.COM";
 
};

然后我们需要告诉NiFi使用它作为我们的JAAS配置。这是通过设置JVM系统属性来完成的，因此我们将编辑conf / bootstrap.conf文件。我们在此文件中的任何位置添加以下行，以告知NiFi JVM使用此配置：

java.arg.15=-Djava.security.auth.login.config=./conf/zookeeper-jaas.conf

最后，我们需要更新nifi.properties，以确保NiFi知道为它将在Zookeeper中创建的用于集群管理的Znodes应用SASL特定的ACL。要启用此功能，请在$ NIFI_HOME / conf / nifi.properties文件中编辑以下属性，如下所示：

nifi.zookeeper.auth.type=sasl
 
nifi.zookeeper.kerberos.removeHostFromPrincipal=true
 
nifi.zookeeper.kerberos.removeRealmFromPrincipal=true

该kerberos.removeHostFromPrincipal和kerberos.removeRealmFromPrincipal应与什么是在动物园管理员的配置设置是一致的。

我们可以通过运行以下命令来初始化我们的Kerberos票证：

kinit -kt nifi.keytab nifi@EXAMPLE.COM

现在，当我们启动NiFi时，它将使用Kerberos nifi在与ZooKeeper通信时作为用户进行身份验证。

Kerberos配置疑难解答

使用Kerberos时，导入使用完全限定的域名而不使用localhost。请确保在以下位置使用每个服务器的完全限定主机名：

的conf / zookeeper.properties文件应该使用的FQDN server.1，server.2...，server.N值。
Connect StringZooKeeperStateProvider 的属性
在/ etc / hosts中的文件也应FQDN解析为是一个IP地址不是 127.0.0.1。

如果不这样做，可能会导致类似以下错误：

2016-01-08 16:08:57,888 ERROR [pool-26-thread-1-SendThread(localhost:2181)] o.a.zookeeper.client.ZooKeeperSaslClient An error: (java.security.PrivilegedActionException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - LOOKING_UP_SERVER)]) occurred when evaluating Zookeeper Quorum Member's  received SASL token. Zookeeper Client will go to AUTH_FAILED state.

如果在使用Kerberos进行通信或身份验证时出现问题，则本故障排除指南可能很有用。

上述故障排除指南中最重要的注意事项之一是为Kerberos启用调试输出的机制。这是通过设置sun.security.krb5.debug环境变量来完成的。在NiFi中，这可以通过在$ NIFI_HOME / conf / bootstrap.conf文件中添加以下行来实现：

java.arg.16=-Dsun.security.krb5.debug=true

这将导致调试输出写入NiFi Bootstrap日志文件。默认情况下，它位于$ NIFI_HOME / logs / nifi-bootstrap.log中。此输出可能相当冗长，但为解决Kerberos故障提供了极有价值的信息。

ZooKeeper Migrator

您可以使用该zk-migrator工具执行以下任务：

将ZooKeeper信息从一个ZooKeeper集群移动到另一个集群
迁移ZooKeeper节点所有权

例如，您可能希望在以下情况下使用ZooKeeper Migrator：

从NiFi 0.x升级到使用嵌入式ZooKeeper的NiFi 1.x.
从NiFi 0.x或1.x中的嵌入式ZooKeeper迁移到外部ZooKeeper
使用外部ZooKeeper从NiFi 0.x升级到NiFi 1.x，使用相同的外部ZooKeeper
从外部ZooKeeper迁移到NiFi 1.x中的嵌入式ZooKeeper

有关更多信息，请参阅NiFi工具包指南中的Zookeeper Migrator部分。

Bootstrap属性

目录中的bootstrap.conf文件conf允许用户配置NiFi应如何启动的设置。这包括参数，例如Java堆的大小，要运行的Java命令以及Java系统属性。

在这里，我们将解决文件中可用的不同属性。只有在NiFi停止并重新启动后，对此文件的任何更改才会生效。

属性	描述
`java`	指定要运行的完全限定的java命令。默认情况下，它只是简单`java`但可以更改为绝对路径或引用环境变量，例如`$JAVA_HOME/bin/java`
`run.as`	运行NiFi的用户名为。例如，如果NiFi应作为`nifi`用户运行，则将此值设置为`nifi`将导致NiFi Process作为`nifi`用户运行。在Windows上忽略此属性。对于Linux，指定的用户可能需要sudo权限。
`lib.dir`	用于NiFi 的lib目录。默认情况下，此设置为`./lib`
`conf.dir`	用于NiFi 的conf目录。默认情况下，此设置为`./conf`
`graceful.shutdown.seconds`	当NiFi被指示关闭时，Bootstrap将等待这个秒数，以使该过程干净地关闭。在这段时间内，如果服务仍在运行，则Bootstrap将执行`kill`该过程，或者突然终止该过程。
`java.arg.N`	启动进程时，可以将任意数量的JVM参数传递给NiFi JVM。这些参数是通过向以bootstrap.conf开头的属性添加来定义的`java.arg.`。除了区分属性名称之外，属性名称的其余部分不相关，将被忽略。默认值包括最小和最大Java堆大小的属性，要使用的垃圾收集器等。
`notification.services.file`	当NiFi启动或停止时，或当Bootstrap检测到NiFi已经死亡时，Bootstrap能够向相关方发送这些事件的通知。这是通过指定定义可以使用哪些通知服务的XML文件来配置的。有关此文件的更多信息，请参阅“ 通知服务”部分。
`notification.max.attempts`	如果配置了通知服务但无法执行其功能，它将再次尝试最多尝试次数。此属性配置最大尝试次数。默认值为`5`。
`nifi.start.notification.services`	此属性是以逗号分隔的通知服务标识符列表，这些标识符对应于`notification.services.file`属性中定义的Notification Services 。具有指定标识符的服务将用于在启动NiFi时通知其配置的收件人。
`nifi.stop.notification.services`	此属性是以逗号分隔的通知服务标识符列表，这些标识符对应于`notification.services.file`属性中定义的Notification Services 。每当NiFi停止时，具有指定标识符的服务将用于通知其配置的收件人。
`nifi.died.notification.services`	此属性是以逗号分隔的通知服务标识符列表，这些标识符对应于`notification.services.file`属性中定义的Notification Services 。如果引导程序确定NiFi意外死亡，则具有指定标识符的服务将用于通知其配置的收件人。

通知服务

当NiFi引导程序启动或停止NiFi，或检测到它已意外死亡时，它能够通知已配置的收件人。目前，提供的唯一机制是发送电子邮件或HTTP POST通知。通知服务配置文件是一个XML文件，其中配置了通知功能。

XML文件的默认位置是conf/bootstrap-notification-services.xml，但可以在conf/bootstrap.conf文件中更改此值。

XML文件的语法如下：

<services>
 
<!-- any number of service elements can be defined. -->
 
<service>
 
<id>some-identifier</id>
 
<!-- The fully-qualified class name of the Notification Service. -->
 
<class>org.apache.nifi.bootstrap.notification.email.EmailNotificationService</class>
 
 
 
<!-- Any number of properties can be set using this syntax.
 
The properties available depend on the Notification Service. -->
 
<property name="Property Name 1">Property Value</property>
 
<property name="Another Property Name">Property Value 2</property>
 
</service>
 
</services>

一旦配置了所需的服务，就可以在bootstrap.conf文件中引用它们。

电子邮件通知服务

第一个通知程序是发送电子邮件，实现是org.apache.nifi.bootstrap.notification.email.EmailNotificationService。它具有以下属性：

属性	需要	描述
`SMTP Hostname`	true	用于发送电子邮件通知的SMTP服务器的主机名
`SMTP Port`	true	用于SMTP通信的端口
`SMTP Username`	true	SMTP帐户的用户名
`SMTP Password`		SMTP帐户的密码
`SMTP Auth`		指示是否应使用身份验证的标志
`SMTP TLS`		指示是否应启用TLS的标志
`SMTP Socket Factory`		`javax.net.ssl.SSLSocketFactory`
`SMTP X-Mailer Header`		X-Mailer用于传出电子邮件的标题中
`Content Type`		Mime类型用于解释电子邮件的内容，例如`text/plain`或`text/html`
`From`	true	指定用作发件人的电子邮件地址。否则，“友好名称”可用作“发件人”地址，但该值必须用双引号括起来。
`To`		收件人要包含在电子邮件的“收件人”行中
`CC`		收件人包含在电子邮件的CC-Line中
`BCC`		收件人包含在电子邮件的BCC-Line中

除了上面所述的属性标记为需要，的至少一种To，CC或BCC属性必须被设置。

配置电子邮件服务的完整示例如下所示：

<service>
 
<id>email-notification</id>
 
<class>org.apache.nifi.bootstrap.notification.email.EmailNotificationService</class>
 
<property name="SMTP Hostname">smtp.gmail.com</property>
 
<property name="SMTP Port">587</property>
 
<property name="SMTP Username">username@gmail.com</property>
 
<property name="SMTP Password">super-secret-password</property>
 
<property name="SMTP TLS">true</property>
 
<property name="From">"NiFi Service Notifier"</property>
 
<property name="To">username@gmail.com</property>
 
</service>

HTTP通知服务

第二个通告程序是发送HTTP POST请求，实现是org.apache.nifi.bootstrap.notification.http.HttpNotificationService。它具有以下属性：

属性	需要	描述
`URL`	true	发送通知的URL。支持表达式语言。
`Connection timeout`		连接远程服务的最长等待时间。支持表达式语言。默认为`10s`。
`Write timeout`		远程服务读取发送请求的最长等待时间。支持表达式语言。默认为`10s`。
`Truststore Filename`		Truststore的完全限定文件名
`Truststore Type`		信任库的类型。无论是`JKS`或`PKCS12`
`Truststore Password`		Truststore的密码
`Keystore Filename`		Keystore的完全限定文件名
`Keystore Type`		密钥库的密码
`Keystore Password`		密钥的密码。如果未指定，但指定了密钥库文件名，密码和类型，则将假定密钥库密码与密钥密码相同。
`SSL Protocol`		用于此SSL上下文的算法。这可以是`SSL`或`TLS`。

除上述属性外，还可以添加动态属性。它们将作为标头添加到HTTP请求中。支持表达式语言。

通知消息位于POST请求的正文中。通知的类型位于标题“notification.type”中，主题使用标题“notification.subject”。

配置HTTP服务的完整示例如下所示：

<service>
 
<id>http-notification</id>
 
<class>org.apache.nifi.bootstrap.notification.http.HttpNotificationService</class>
 
<property name="URL">https://testServer.com:8080/</property>
 
<property name="Truststore Filename">localhost-ts.jks</property>
 
<property name="Truststore Type">JKS</property>
 
<property name="Truststore Password">localtest<property>
 
<property name="Keystore Filename">localhost-ts.jks</property>
 
<property name="Keystore Type">JKS</property>
 
<property name="Keystore Password">localtest</property>
 
<property name="notification.timestamp">${now()}</property>
 
</service>

代理配置

在代理后面运行Apache NiFi时，在部署期间需要注意几个关键项。

NiFi由许多Web应用程序（Web UI，Web API，文档，自定义UI，数据查看器等）组成，因此需要为根路径配置映射。这样，所有上下文路径都相应地传递。例如，如果仅/nifi映射了上下文路径，则UpdateAttribute的自定义UI将不起作用，因为它可用于/update-attribute-ui-<version>。
NiFi的REST API将为图表上的每个组件生成URI。由于请求是通过代理发出的，因此需要覆盖生成的URI的某些元素。如果不覆盖，用户将能够在画布上查看数据流，但无法修改现有组件。请求将尝试直接回拨给NiFi，而不是通过代理。当代理生成对NiFi实例的HTTP请求时，可以通过添加以下HTTP标头来覆盖URI的元素：

X-ProxyScheme - the scheme to use to connect to the proxy
 
X-ProxyHost - the host of the proxy
 
X-ProxyPort - the port the proxy is listening on
 
X-ProxyContextPath - the path configured to map to the NiFi instance

如果NiFi安全运行，则需要授权任何代理来代理用户请求。这些可以通过全局菜单在NiFi UI中配置。一旦这些权限到位，代理就可以开始代理用户请求。必须在HTTP标头中中继最终用户标识。例如，如果最终用户向代理发送了请求，则代理必须对用户进行身份验证。在此之后，代理可以将请求发送到NiFi。在此请求中，应添加HTTP标头，如下所示。

X-ProxiedEntitiesChain：<end-user-identity>

如果代理配置为发送到另一个代理，则来自第二个代理的对NiFi的请求应包含如下标头。

X-ProxiedEntitiesChain：<end-user-identity> <proxy-1-identity>

设置所需属性的示例Apache代理配置可能如下所示。完整的代理配置超出了本文档的范围。有关部署环境和用例的指导，请参阅代理文档。

...
<Location "/my-nifi">
    ...
	SSLEngine On
	SSLCertificateFile /path/to/proxy/certificate.crt
	SSLCertificateKeyFile /path/to/proxy/key.key
	SSLCACertificateFile /path/to/ca/certificate.crt
	SSLVerifyClient require
	RequestHeader add X-ProxyScheme "https"
	RequestHeader add X-ProxyHost "proxy-host"
	RequestHeader add X-ProxyPort "443"
	RequestHeader add X-ProxyContextPath "/my-nifi"
	RequestHeader add X-ProxiedEntitiesChain "<%{SSL_CLIENT_S_DN}>"
	ProxyPass https://nifi-host:8443
	ProxyPassReverse https://nifi-host:8443
	...
</Location>
...

必须更新其他NiFi代理配置，以允许预期的主机和上下文路径HTTP标头。
- 默认情况下，如果NiFi安全运行，它将仅接受具有与其绑定的主机[：port]匹配的主机头的HTTP请求。如果NiFi接受指向不同主机[：port]的请求，则需要配置预期值。在代理服务器后面运行或在容器化环境中运行时可能需要这样做。这是使用属性（例如）在nifi.properties中以逗号分隔的列表配置的。接受IPv6地址。有关其他详细信息，请参阅RFC 5952第4节和第6节。nifi.web.proxy.hostlocalhost:18443, proxyhost:443
- 如果该值nifi.web.proxy.context.path在nifi.properties中的属性中列入白名单，则NiFi将仅接受带有X-ProxyContextPath，X-Forwarded-Context或X-Forwarded-Prefix标头的HTTP请求。此属性接受以逗号分隔的预期值列表。如果传入请求具有白名单中不存在的X-ProxyContextPath，X-Forwarded-Context或X-Forwarded-Prefix标头值，则会显示“发生意外错误”页面，并且将显示错误写入nifi-app.log。
需要在代理服务器和NiFi群集上进行其他配置，以使NiFi站点到站点在反向代理后面工作。有关详细信息，请参阅反向代理的站点到站点路由属性。
- 为了通过反向代理通过站点到站点协议传输数据，代理和站点到站点客户端NiFi用户都需要具有以下策略，“检索站点到站点的详细信息”，“通过站点接收数据”到-site'用于输入端口，'通过站点到站点发送数据'用于输出端口。

Kerberos服务

可以将NiFi配置为使用Kerberos SPNEGO（或“Kerberos服务”）进行身份验证。在这种情况下，用户将点击REST端点/access/kerberos，服务器将使用401状态代码和质询响应标头进行响应WWW-Authenticate: Negotiate。这将与浏览器通信以使用GSS-API并加载用户的Kerberos票证，并在后续请求中将其作为Base64编码的标头值提供。它将是形式Authorization: Negotiate YII…。NiFi将尝试使用KDC验证此票证。如果成功，则为用户的主体将作为标识返回，并且流将遵循登录/凭证认证，因为将在响应中发出JWT以防止在每个后续请求上进行Kerberos身份验证的不必要开销。如果无法验证故障单，它将返回相应的错误响应代码。然后，如果KerberosLoginIdentityProvider已配置，则用户将能够将其Kerberos凭据提供给登录表单。有关详细信息，请参阅Kerberos登录标识提供程序。

NiFi只会通过HTTPS连接响应Kerberos SPNEGO协商，因为不安全的请求永远不会被验证。

必须在nifi.properties中设置以下属性才能启用Kerberos服务身份验证。

属性	需要	描述
`Service Principal`	true	NiFi用于与KDC通信的服务主体
`Keytab Location`	true	包含服务主体的keytab的文件路径

有关完整文档，请参阅Kerberos属性。

笔记

Kerberos在许多地方都是区分大小写的，并且错误消息（或缺少错误消息）可能没有充分解释。检查配置文件中服务主体的区分大小写。公约是HTTP/fully.qualified.domain@REALM。
在处理SPNEGO谈判时，浏览器有不同程度的限制。有些会向请求它的任何域提供本地Kerberos票证，而其他域会将受信任域列入白名单。请参阅Spring Security Kerberos - 参考文档：附录E.为常见浏览器配置SPNEGO协商的浏览器。
某些浏览器（传统IE）不支持最近的加密算法（如AES），并且仅限于传统算法（DES）。生成keytabs时应注意这一点。
必须配置KDC并为NiFi定义服务主体并导出密钥表。有关Kerberos服务器配置和管理的综合说明超出了本文档的范围（请参阅MIT Kerberos管理员指南），但示例如下：

在服务器上添加服务主体nifi.nifi.apache.org并从KDC导出keytab：

root@kdc:/etc/krb5kdc# kadmin.local
Authenticating as principal admin/admin@NIFI.APACHE.ORG with password.
kadmin.local:  listprincs
K/M@NIFI.APACHE.ORG
admin/admin@NIFI.APACHE.ORG
...
kadmin.local:  addprinc -randkey HTTP/nifi.nifi.apache.org
WARNING: no policy specified for HTTP/nifi.nifi.apache.org@NIFI.APACHE.ORG; defaulting to no policy
Principal "HTTP/nifi.nifi.apache.org@NIFI.APACHE.ORG" created.
kadmin.local:  ktadd -k /http-nifi.keytab HTTP/nifi.nifi.apache.org
Entry for principal HTTP/nifi.nifi.apache.org with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/http-nifi.keytab.
Entry for principal HTTP/nifi.nifi.apache.org with kvno 2, encryption type des-cbc-crc added to keytab WRFILE:/http-nifi.keytab.
kadmin.local:  listprincs
HTTP/nifi.nifi.apache.org@NIFI.APACHE.ORG
K/M@NIFI.APACHE.ORG
admin/admin@NIFI.APACHE.ORG
...
kadmin.local: q
root@kdc:~# ll /http*
-rw------- 1 root root 162 Mar 14 21:43 /http-nifi.keytab
root@kdc:~#

码农公寓

基本群集设置