使用CFM進行日誌減少技術

語言: CN / TW / HK

Cloudera服務日誌提供了廣泛的資訊以協助叢集維護;從協助進行安全檢查、稽核任務以及對效能優化和測試任務進行驗證,僅舉幾例。 

但是,由這些服務生成的日誌記錄對於每個組織而言並價值並不相同。例如:網路團隊可能會在概述使用者行為訪問資料時的日誌中發現更多價值,而運營團隊可能更喜歡顯示一天中載入時間高峰的日誌。

由此產生一個問題:我們如何滿足為特定的團隊或使用者認為有用的日誌過濾的需求?

在這裡可以使用Cloudera Flow Management(CFM)。儘管有第三方產品可以過濾日誌,但要為現有的CDP叢集支付額外的費用,但是採用CFM可以減輕Cloudera CDP訂閱中已經擁有CFM的企業的財務負擔。

為了解決這個問題,可以採用兩種不同的方法。

  1. 使用SQL將流轉換為記錄並進行過濾

  2. 使用NiFi表達語言提取變數並進行過濾

這兩個過程的概述如下

方法

描述

記錄上的SQL過濾

日誌被提取並轉換為記錄,然後使用SQL搜尋這些記錄。

優點:

  • 高效能的首選方法

  • 適合大量攝入

缺點:

  • 使用架構定義更難實現

NiFi表示式對提取的屬性進行過濾

傳入日誌具有從中提取的屬性,然後使用NiFi表達語言過濾這些記錄

優點:

  • 易於實施

  • 適合少量攝入

缺點:

  • 與記錄方法相比效率較低

  • 更多處理器

我們將在以下各節中擴充套件這兩個工作流程。

假設條件

將要討論的工作流程假定是使用啟用了Kerberos和TLS的CDP 7.1.x叢集。此外,假定同時安裝了Ranger和Apache Solr,作為選擇用於利用NiFi畫布中的日誌提取的兩個主要服務。

但是,沒有這些配置的叢集也可以採用工作流的原理。

這個工作流程是什麼樣的?

基於記錄

將日誌提取流檔案轉換為記錄是一種通過CFM篩選日誌的快速有效的方法。但是,它並非總是最容易實現的,具體取決於所提取日誌的格式。

此工作流程的高階概述如下:

基於屬性

基於屬性的過濾的主要概念是使處理器能夠提取感興趣的屬性並在指定條件下進行路由。任何其他事情都取決於實施模板的人員,他們希望工作流程是多麼複雜或簡單。

此工作流程的高階概述如下:


為Cloudera叢集實施此工作流需要哪些處理器?


基於記錄

攝取

使用一個遠端處理組,我們將收集掛接到正在從中提取的服務(在本例中為Solr)所需的所有處理器,並僅提取我們想要的服務。請注意,從Solr抓取日誌不是唯一的解決方案,為了儘量減少叢集將容納的日誌量,MiNiFi代理或Apache NiFi可以直接從其來源抓取日誌。此示例解決方案將概述資料的重新路由/過濾,但是通過此工作流程可以實現整體減少。

選擇使用哪個處理器以及從中提取日誌的服務將作為過濾第一級; 我們不需要的服務將沒有專用的處理器。

這些處理器將專用於您要定位的特定服務,例如HDFS,YARN,Apache Kafka,Hive,Impala等。

在此工作流程示例中,使用GetSolr處理器,其中使用Solr Query欄位過濾服務

記錄轉換

此過程的第一步是將傳入的日誌記錄轉換為記錄。對於此示例,傳入的Solr記錄作為XML檔案被提取,並轉換為json記錄。

作為參考,此示例的傳入Solr日誌流檔案如下:

<?xml version="1.0" encoding="UTF-8"?>xml version="1.0" encoding="UTF-8"?><docs>   <doc><doc>   <field name="field_one">some_value</field> name="field_one">some_value</field>   <field name="field_two">some_value</field> name="field_two">some_value</field>                <field name="field_three">some_value</field><field name="field_three">some_value</field>   <docs><docs>   <doc><doc>   <doc><doc>   <field name="field_one">some_value</field> name="field_one">some_value</field>   <field name="field_two">some_value</field> name="field_two">some_value</field>                <field name="field_three">some_value</field><field name="field_three">some_value</field>   <docs><docs><docs> 

請注意,此步驟有兩種方法可以解決,第一種方法是在單獨的處理器中對其進行轉換。第二個是在下一個過濾記錄處理器中將其轉換,這從根本上簡化了此過程。但是,並非所有XML檔案都可以立即轉換。

對於Solr示例,不可能立即進行轉換,因此需要附加處理器。此轉換是使用JoltTransformRecord處理器完成的。

在此處理器中,有兩個主要功能。首先是將記錄從XML轉換為JSON。這是通過利用讀取器和寫入器控制器來完成的。對於此示例,已採用XML ReaderJSONRecordSetWriter控制器。

由於Solr生成日誌的方式,因此採用類似於以下內容的架構

{    "name": "docs","name": "docs",    "namespace": "doc","namespace": "doc",    "type": "record","type": "record",    "fields": [ {"fields": [ {     "name" : "field","name" : "field",     "type" : {"type" : {     "type" : "array","type" : "array",     "items" : {"items" : {     "type" : "record","type" : "record",     "name" : "record_tag","name" : "record_tag",     "namespace" : "name","namespace" : "name",     "fields" : ["fields" : [     {"name": "name", "type": "string"},{"name": "name", "type": "string"},     {"name": "value", "type": "string"}] } }  } ]{"name": "value", "type": "string"}] } }  } ]}

在欄位中,“內容的欄位名稱”設定為value。

轉換記錄後,我們將使用Jolt Specification欄位將json記錄調整為便於查詢所需的值。在此示例中,我們使用以下規範

[{"operation": "shift",: "shift","spec": {: {   "field": {: {     "*": {: {       "value": "@(1,name)"} }: "@(1,name)"} }}  }]}]

隨著該領域的發展,Jolt Transformation DSL已設定為chain。

JSON格式的Solr記錄的輸出現在將採用類似於以下格式:

[ { {"field_one":"some_value",:"some_value","field_two":"some_value",:"some_value","field_three":"some_value":"some_value"},{"field_one":"some_value",:"some_value","field_two":"some_value",:"some_value","field_three":"some_value":"some_value"] ]

現在可以在下一階段過濾輸出記錄。

篩選記錄

這可以使用QueryRecord處理器來完成。如果攝取的日誌檔案格式正確,則也可以在此處理器中進行轉換,由此在此步驟中首先呼叫將日誌轉換為記錄的控制器。

如果不是,則可以提取記錄並以相同格式寫出。此階段的過濾以對傳入記錄使用SQL的查詢形式出現。這種查詢的一般格式如下

SELECT *FROM FLOWFILEWHERE field = ‘something’= ‘something’

這些查詢將作為新欄位新增到處理器。該欄位的名稱將是聯結器的最終名稱,該聯結器將用於將新過濾的日誌路由到其下一階段。 

合併與儲存

這是一個可選步驟,一旦日誌被過濾掉,之後發生的事情取決於此工作流程部署的用例。這裡概述了一種簡單的方法,即使用MergeRecord處理器簡單地合併傳入的流檔案,然後儲存到磁碟

如果需要,可以使用“相關屬性名稱”欄位合併傳入的流檔案,這有助於將類似的記錄分組在一起。 

儲存到磁碟(在本例中為HDFS)時,使用相同的原理。用於將流檔案分組的屬性與用於指示應將一組記錄儲存在磁碟上的位置的屬性相同

基於屬性

攝取

與上述基於記錄的方法中發現的過程相同,此過程仍充當此方法的第一級過濾

記錄分割

我們要基於一個事件而不是一組事件進行評估,因此需要一個處理器來分割傳入的記錄。在此工作示例中,提取處理器以XML格式提供記錄,因此採用了SplitXml處理器,但是根據需要可以採用其他用於非XML日誌的處理器。

屬性提取

需要處理器來提取將在下一階段的過濾語句中使用的所有變數。對於此處理器,我們採用了EvaluateXPath處理器。

提取的這些變數將作為元資料附加到傳出的流檔案中,因此僅提取需要的變數。所需的變數取決於下一階段。

根據使用者條件過濾

採用上面提取的屬性,並在給定條件下進行過濾。這兩個處理器是工作流程中所需的主要元件,它們代表此工作流程提供的第二級過濾。如果第一級停止了不需要的服務,則此階段將停止不需要的事件。

最好只提取需要的內容。

所有條件均以NiFi表達語言列出,其示例如下:

 條件示例:

  • 來自查詢引擎的任何記錄(例如Hive,Impala等),僅當該記錄是使用者執行的命令時

  • 來自HDFS的任何記錄,僅當該記錄是由特定服務提供的,並且該事件表示寫操作時

  • 來自Kafka的任何記錄,僅當該記錄代表釋出到某些Kafka主題的使用者時

  • YARN的任何記錄,僅當用戶通過Hive提交應用程式時才記錄

這些條件(以及更多條件)可以用NiFi表達語言進行佈局。然後,可以將符合給定條件的所有傳入記錄路由到下一個階段。可以從流程中刪除任何不滿足任何列出條件要求的記錄,這些記錄被工作流程視為“噪音”。

合併與儲存

這是一個可選步驟,並遵循上面相應的基於記錄的方法中概述的相同原理。但是,在這種情況下,將改為使用MergeContent處理器。

從這往哪兒走

根據您自己的實現,無論是基於記錄的、基於屬性的還是兩者的組合,您都需要在需要的地方新增處理器,刪除不需要的處理器,並調整資料流以符合您的要求。這些基本步驟應使您開始構建自己的管道,以幫助豐富日誌資料的價值。

Cloudera的許多客戶已將該解決方案擴充套件到涵蓋一系列企業應用程式日誌,從而顯著減少了日誌量,並經常豐富剩餘的內容以確保剩餘的內容有意義且可操作。 

如果您或您的組織希望採用此解決方案,並且想進一步討論有關如何過濾日誌的更多選擇,則Cloudera Professional Services擁有經驗豐富的顧問,他們將很樂意幫助您當今優化業務。 

作者:Danielle Mathews& Pierre Villard

原文連結:https://blog.cloudera.com/log-reduction-techniques-with-cfm/




本文分享自微信公眾號 - 大資料雜貨鋪(bigdataGrocery)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。