Apache NiFi系统管理员指南 [ 三 ]
- 基本群集设置
- 故障排除
- State管理
- 配置状态提供程序
- 嵌入式ZooKeeper服务器
- ZooKeeper访问控制
- ZooKeeper安全
- ZooKeeper Migrator
- Bootstrap属性
- 通知服务
- 电子邮件通知服务
- HTTP通知服务
- 代理配置
- Kerberos服务
- 笔记
基本群集设置
本节介绍由三个NiFi实例组成的简单三节点非安全集群的设置。
对于每个实例，都需要更新nifi.properties文件中的某些属性。特别是，应根据您的情况评估Web和群集属性并进行相应调整。所有属性都在本指南的“ 系统属性”部分中描述; 但是，在本节中，我们将重点关注必须为简单集群设置的最小属性。
对于所有三个实例，可以使用默认设置保留群集公共属性。但请注意，如果更改这些设置，则必须在群集中的每个实例上设置相同的设置。
对于每个节点，要配置的最小属性如下：
-
在“ 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"）：
State管理
NiFi为处理器，报告任务，控制器服务和框架本身提供了一种机制来保持状态。例如，这允许处理器在重新启动NiFi后从其停止的位置恢复。此外，它允许处理器存储某些信息，以便处理器可以从群集中的所有不同节点访问该信息。这允许一个节点拾取另一个节点停止的位置，或者在集群中的所有节点之间进行协调。
配置状态提供程序
当组件决定存储或检索状态时，它通过提供“范围” - 节点本地或群集范围来实现。然后，基于此Scope以及配置的状态提供程序确定用于存储和检索此状态的机制。该nifi.properties文件包含有关配置这些国家供应商三种不同的特性。
|
属性 |
描述 |
|
|
第一个是指定外部XML文件的属性，该文件用于配置本地和/或群集范围的状态提供程序。此XML文件可能包含多个提供程序的配置 |
|
|
提供此XML文件中配置的本地State Provider标识符的属性 |
|
|
同样，该属性提供在此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实例是否应运行嵌入式ZooKeeper服务器 |
|
|
如果 |
这可以通过设置来实现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命令。默认情况下，它只是简单 |
|
|
运行NiFi的用户名为。例如，如果NiFi应作为 |
|
|
用于NiFi 的lib目录。默认情况下，此设置为 |
|
|
用于NiFi 的conf目录。默认情况下，此设置为 |
|
|
当NiFi被指示关闭时，Bootstrap将等待这个秒数，以使该过程干净地关闭。在这段时间内，如果服务仍在运行，则Bootstrap将执行 |
|
|
启动进程时，可以将任意数量的JVM参数传递给NiFi JVM。这些参数是通过向以bootstrap.conf开头的属性添加来定义的 |
|
|
当NiFi启动或停止时，或当Bootstrap检测到NiFi已经死亡时，Bootstrap能够向相关方发送这些事件的通知。这是通过指定定义可以使用哪些通知服务的XML文件来配置的。有关此文件的更多信息，请参阅“ 通知服务”部分。 |
|
|
如果配置了通知服务但无法执行其功能，它将再次尝试最多尝试次数。此属性配置最大尝试次数。默认值为 |
|
|
此属性是以逗号分隔的通知服务标识符列表，这些标识符对应于 |
|
|
此属性是以逗号分隔的通知服务标识符列表，这些标识符对应于 |
|
|
此属性是以逗号分隔的通知服务标识符列表，这些标识符对应于 |
通知服务
当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。它具有以下属性：
|
属性 |
需要 |
描述 |
|
|
true |
用于发送电子邮件通知的SMTP服务器的主机名 |
|
|
true |
用于SMTP通信的端口 |
|
|
true |
SMTP帐户的用户名 |
|
|
SMTP帐户的密码 |
|
|
|
指示是否应使用身份验证的标志 |
|
|
|
指示是否应启用TLS的标志 |
|
|
|
|
|
|
|
X-Mailer用于传出电子邮件的标题中 |
|
|
|
Mime类型用于解释电子邮件的内容，例如 |
|
|
|
true |
指定用作发件人的电子邮件地址。否则，“友好名称”可用作“发件人”地址，但该值必须用双引号括起来。 |
|
|
收件人要包含在电子邮件的“收件人”行中 |
|
|
|
收件人包含在电子邮件的CC-Line中 |
|
|
|
收件人包含在电子邮件的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。它具有以下属性：
|
属性 |
需要 |
描述 |
|
|
true |
发送通知的URL。支持表达式语言。 |
|
|
连接远程服务的最长等待时间。支持表达式语言。默认为 |
|
|
|
远程服务读取发送请求的最长等待时间。支持表达式语言。默认为 |
|
|
|
Truststore的完全限定文件名 |
|
|
|
信任库的类型。无论是 |
|
|
|
Truststore的密码 |
|
|
|
Keystore的完全限定文件名 |
|
|
|
密钥库的密码 |
|
|
|
密钥的密码。如果未指定，但指定了密钥库文件名，密码和类型，则将假定密钥库密码与密钥密码相同。 |
|
|
|
用于此SSL上下文的算法。这可以是 |
除上述属性外，还可以添加动态属性。它们将作为标头添加到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服务身份验证。
|
属性 |
需要 |
描述 |
|
|
true |
NiFi用于与KDC通信的服务主体 |
|
|
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:~#
