文件系統內容存儲庫屬性 (File System Content Repository Properties)
易失性內容存儲庫屬性 (Volatile Content Repository Properties)
提前編寫源代碼存儲庫屬性(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)
身份映射屬性 ( Identity Mapping Properties )
系統屬性
目錄中的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文件中。 |