文章作者：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本身還是很有意義的，相信后面也會有不錯的發展。