Apache NiFi系統管理員指南 [ 三 ]

基本羣集設置

本節介紹由三個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"）：

    <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/[email protected]"

在這裏，我們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/[email protected]

這將在當前目錄中創建一個名爲的文件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/[email protected]";
};

請務必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/[email protected]"

同樣，請務必使用適當的值替換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 "[email protected]"

Kerberos Principal由三部分組成：主要部分，實例和領域。在這裏，我們正在創建一個具有主要nifi，無實例和領域的Principal EXAMPLE.COM。主要（nifi在本例中）是在通過Kerberos進行身份驗證時用於標識用戶的標識符。

在我們創建了Principal後，我們需要爲Principal創建一個KeyTab：

kadmin: xst -k nifi.keytab [email protected]

可以將此密鑰表文件複製到具有嵌入式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="[email protected]";
};

然後我們需要告訴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 [email protected]

現在，當我們啓動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">[email protected]</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">[email protected]</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/[email protected] with password.
kadmin.local:  listprincs
K/[email protected]
admin/[email protected]
...
kadmin.local:  addprinc -randkey HTTP/nifi.nifi.apache.org
WARNING: no policy specified for HTTP/[email protected]; defaulting to no policy
Principal "HTTP/[email protected]" 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/[email protected]
K/[email protected]
admin/[email protected]
...
kadmin.local: q
root@kdc:~# ll /http*
-rw------- 1 root root 162 Mar 14 21:43 /http-nifi.keytab
root@kdc:~#

Apache NiFi系統管理員指南 [ 三 ]

基本羣集設置

故障排除

State管理

配置狀態提供程序

嵌入式ZooKeeper服務器

ZooKeeper訪問控制

ZooKeeper安全

ZooKeeper Migrator

Bootstrap屬性

通知服務

電子郵件通知服務

HTTP通知服務

代理配置

Kerberos服務

筆記

24-5-18 X

dolphinscheduler-1.3.1 Task任務類型結構梳理

阿里Java開發手冊[泰山版] 關鍵速記 ?

Homebrew/Linuxbrew 更換數據源爲: 清華鏡像

MacOS 編譯OpenJDK13

配置yanagishima 既能連接Presto 又能連接Hive

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結