Ambari Log Search

   文章做者：luxianghao

   文章來源：http://www.cnblogs.com/luxianghao/p/8630195.html  轉載請註明，謝謝合做。

   免責聲明：文章內容僅表明我的觀點，若有不當，歡迎指正。

   --- 

 

一 簡介

Ambari Log Search是Ambari社區從2.4版本推出的一個新組件，主要功能包括日誌監控、收集、分析，併爲收集的日誌創建索引從而進行故障排查，日誌搜索、日誌審計等，官方介紹參考這裏

 

二 架構

Log Search擁有兩個組件：Log Search Portal（server + web UI）和Log Feeder。

Log Feeder分佈在所監控服務的多個主機上，負責監控特定的日誌文件並把解析過的日誌發送到Solr，用戶使用Log Search Portal的web UI來查詢日誌，web UI發送請求給Log Search Portal的後端server，後端server再發送query請求給Solr服務，最終實現日誌查詢。

Log Search Portal後端server集成了spring-data-solr，並利用spring-data-solr做爲Solr的client和Solr交互。

其中，Solr是Apache的一個開源搜索平臺， Log Search依賴Ambari Infra服務，Ambari Infra服務中含有Solr組件。

具體架構圖以下

 

 

三 功能預覽

1 歷史操做日誌存儲

Ambari所管理的組件在Ambari Server上的歷史操做日誌將被保存，這對故障排查，歷史回故，場景再現會比較有幫助。

 

2 主機相關組件日誌快速查看

Ambari Server所管理的主機的的日誌在的web端也將很容易查看，而且能夠經過超連接直接跳轉到Log Search UI。 

 

3 Log Search UI

1）故障排查

選擇Log Search UI的Troubleshoting標籤，若是HDFS有故障，正常狀況下ERROR，FATAL日誌的數量將會顯著增長，那麼你能夠選擇HDFS服務和相應的時間段，並點擊GO to Logs，Log Search會自動查詢全部HDFS相關的組件的日誌，而後你就能夠方便的查看日誌，並高效的debug了。

Tips：有故障排查經驗的同窗確定知道，通常狀況下服務出現問題時，你都要先搜尋目標主機，而後到對應的機器上的對應目錄打開對應的日誌文件，查找ERROR或者FATAL日誌，分析日誌進行故障排查，有了Log Search咱們會省去不少中間環節，爲咱們的故障排查贏得寶貴的時間，從而快人一步，保證咱們服務的穩定性。

 

2)查詢服務日誌

選擇Log Search UI的Service Logs標籤，用戶可以在一個頁面快速的查看和搜索相關服務日誌，用戶能夠經過時間、主機、日誌級別、組件類型、日誌存放路徑、關鍵詞等作快速查詢，同時頁面上也會統計不一樣時間、不一樣級別的日誌狀況 

 

3）查詢審計日誌

選擇Log Search UI的Access Logs標籤，用戶能方便的查看審計日誌，例如HDFS，你能夠方便的看到是哪一個用戶、哪一個目錄、哪段時間的訪問頻率比較高，而後能夠作相關的資源控制，冷熱數據分離，這些都是和成本等息息相關的，相信這個功能也是頗有必要的。

 

四 添加自定義組件

本節主要介紹下怎樣在Log Search中添加一個自定義組件，並監控新的日誌文件。

爲了定義應該監控哪個文件，怎樣解析這些文件，你須要定義一些相關的輸入日誌數據的配置，服務部署好後，這些配置能夠在/etc/ambari-logsearch-logfeeder/conf/logfeeder.properties中的logfeeder.config.files屬性中找到。

若是你添加了一個自定義的服務（添加自定義服務參考這裏），爲了在Log Search中也支持這個服務，你須要在定義這個服務的configuration目錄中添加*-logsearch-conf.xml的配置文件，*能夠是自定義的名字，Ambari會根據*在 /etc/ambari-logsearch-logfeeder/conf/產生一個input.config-*.json的文件，*-logsearch-conf.xml中應該包含以下3個屬性，

- service_name

- component_mappings

- content

第一個屬性是service_name，這是自定義服務在Log Search中的標籤，它也將在Log Search UI的troubleshooting的web頁面上顯示。
第二個是component_mapings, 這很重要，緣由以下：
1 ）你在Log Search portal上點擊自定義服務標籤的時候，它會選擇合適的組件去過濾；
2） 須要把Ambari組件和制定的logIds作個映射，你也會看到Ambari的組件名和Log Search的名字是不同的
例如ZOOKEEPER_SERVER <-> zookeeper_server

對一個Ambari組件來講，它可能有多個Logids，由於一個組件可能有多個日誌文件須要監控。

第三個屬性是content，他是一個在logfeeder啓動的時候會生成的一個配置文件模板，若是你在集羣中新添加了一個帶有*-logsearch-conf 配置的服務，你須要重啓下Log Feeder。其中，

input描述了被Log Feeder監控的日誌文件；

"rowtype"爲service；

"type"爲logid；

"path"爲日誌位置的表達式，支持正則，在例子中你能夠看到path對應的是python代碼，這個能夠用來從Ambari配置裏獲取zookeeper的日誌目錄，若是日誌目錄會被更改這個功能就比較重要了；

filter模塊裏你應該選擇"grok", 也支持"json"，不過這個只有在你的classpath裏有logsearch-log4j-appender才能正常工做，在Grok裏你能夠定義每行日誌應該怎麼去解析，每個field須要映射成爲solr的field；

multiline_pattern 若是這個模式匹配上，意味着在日誌中的行會被追加到上一行；

message_pattern定義了怎樣解析指定的field並映射成爲Solr field, 這裏邊"logtime"和"log_message"是必須的，"level"是可選的，可是推薦使用。

 

解析完成後，你能夠在"post_map_values"裏修改映射，例子裏你能夠看到，咱們用指定的形式對日期從新作了映射，以便在solr裏以指定的格式存儲

更多關於input配置的能夠參考這裏，

爲了找出針對你本身的日誌文件的更合適的表達式，你可使用這個，

在Log Search裏也有一些內建的grok表達式，你能夠在這裏找到。

配置例子

<configuration supports_final="false" supports_adding_forbidden="true">  
  <property>    
    <name>service_name</name>
    <display-name>Service name</display-name>    
    <description>Service name for Logsearch Portal (label)</description>
    <value>Zookeeper</value>
    <on-ambari-upgrade add="true"/>  
  </property>  
  <property>
    <name>component_mappings</name>
    <display-name>Component mapping</display-name>
    <description>Logsearch component logid mapping list (e.g.: COMPONENT1:logid1,logid2;COMPONENT2:logid3)</description>
   <value>ZOOKEEPER_SERVER:zookeeper</value>
   <on-ambari-upgrade add="true"/>
 </property>
 <property>
   <name>content</name>
   <display-name>Logfeeder Config</display-name>
   <description>Metadata jinja template for Logfeeder which contains grok patterns for reading service specific logs.</description>
  <value>{  "input":[    
           {     "type":"zookeeper",     
                 "rowtype":"service",
                 "path":"{{default('/configurations/zookeeper-env/zk_log_dir', '/var/log/zookeeper')}}/zookeeper*.log"}  ],
            "filter":[   {
               "filter":"grok",
               "conditions":{
                 "fields":{"type":["zookeeper"]}
               }, 
               "log4j_format":"%d{ISO8601} - %-5p [%t:%C{1}@%L] - %m%n",     "multiline_pattern":"^(%{TIMESTAMP_ISO8601:logtime})", 
               "message_pattern":"(?m)^%{TIMESTAMP_ISO8601:logtime}%{SPACE}-%{SPACE}%{LOGLEVEL:level}%{SPACE}\\[%{DATA:thread_name}\\@%{INT:line_number}\\]%{SPACE}-%{SPACE}%{GREEDYDATA:log_message}",
              "post_map_values": { 
                 "logtime": {
                    "map_date":{
                       "target_date_pattern":"yyyy-MM-dd HH:mm:ss,SSS"         
                    }       
                  }     
               }    
          }   
      ]}    
    </value>
    <value-attributes>
      <type>content</type>
      <show-property-name>false</show-property-name>
    </value-attributes>
    <on-ambari-upgrade add="true"/>
  </property>
</configuration>

 

五 程序調試

在ambari-logserarch-portal組件部署的主機上的/etc/ambari-logsearch-portal/conf/logsearch-env.sh文件中會有相關的配置文件

#export LOGSEARCH_DEBUG=false
export LOGSEARCH_DEBUG=true

export LOGSEARCH_DEBUG_PORT=5005

默認DEBUG模式是關閉的，打開後ambari-logserarch-portal就會監聽5005端口了，而後你就能夠用idea或者其餘工具愉快的進行遠程調試了。

 

六 相關問題

實際使用過程當中發現，查詢的時候會有正則匹配相關的問題，refer to AMBARI-23333

 

七 後記

因爲Ambari Log Search是爲大數據相關服務定製，大數據集羣通常集羣規模會比較大，組件也不少，對應的相關日誌也不少，可能考慮到負載、健壯性等問題，官方目前也只是在小規模（例如在只有100多個節點的非生產環境的小集羣上使用）的在使用。不過Ambari Log Search自己仍是頗有意義的，相信後面也會有不錯的發展。