open-falcon的falcon-log-agent日誌監控

falcon-log-agent

簡介

falcon-log-agent是一個開源版的日誌採集工具，旨在從流式的日誌中抓取、統計日誌中的特徵信息。

獲取的特徵信息，與開源版Open-Falcon監控系統打通。可用於業務指標的衡量、也可用於穩定性的建設。

Feature

• 準確可依賴：歷經滴滴線上業務近一年考驗，統計準確性高。
• 性能高、資源消耗可控：性能優化程度高，單核單策略可支撐日誌分析:20W條/秒
• 接入成本低：外掛式採集，只須要標準化日誌便可；輸出數據直接對接open-falcon。

附：我司agent升級先後資源佔用對比圖 

什麼是日誌採集

日誌採集，是一種外掛式的採集。經過讀取進程打印的日誌，來進行監控數據的採集與匯聚計算。

falcon-log-agent如何工做

本agent即日誌採集場景下的實時計算。實時讀取文件內容，實時計算，將計算結果直接推送至falcon。

限定條件

• 要求日誌必須包含時間：不包含時間的日誌，只能根據當前時間統計日誌條數，結果很是不許確。
• 不支持文件軟鏈
• 日誌時間必須有序：爲了應對日誌延遲落盤等，agent會根據日誌的時間來判斷某一週期的數據是否採集完成，若是日誌時間順序錯亂，可能致使採集不許。

開始使用log-agent

構建

git clone https://github.com/didi/falcon-log-agent.git && cd falcon-log-agent && sh build.sh

修改配置文件

# base config
cp cfg/dev.cfg cfg/cfg.json
vim cfg/cfg.json

# strategy config
cp cfg/strategy.dev.json cfg/strategy.json
vim cfg/strategy.json

啓動/中止服務

# start
./control start

# stop
./control stop

# status
./control status

基礎配置項

基礎配置項，即程序自己的配置項。默認是cfg/cfg.json，能夠經過-c參數來指定。

日誌相關

log_path：程序輸出的日誌目錄
log_level：日誌等級
log_rotate_size：日誌切割大小
log_rotate_num：按配置切割以後，保留多少個文件，其餘的清理掉

worker相關

worker_num：每一個日誌文件，進行計算的併發數
queue_size：讀文件和進行計算之間，有一個緩衝隊列，若是隊列滿了，意味着計算能力跟不上，就要丟日誌了。這個配置就是這個緩衝隊列的大小。
push_interval：循環判斷將計算完成的數據推送至發送隊列的時間
push_url：推送的odin-agent的url

資源限制

max_cpu_rate:最大使用的cpu百分比。（可用核數=ceil(總核數*max_cpu_rate))
max_mem_rate:最打使用內存百分比。(最大內存=(內存總大小*max_mem_rate)，最小爲500M)

策略相關

update_duration:策略的更新週期
default_degree:默認的採集精度

其餘

http_port:自身狀態對外暴露的接口

採集策略

文件路徑

文件路徑，即file_path配置項。必需要求啓動agent的用戶，對這個文件有可讀權限。

文件路徑支持固定路徑和動態路徑兩種：

• 固定路徑：直接填寫便可，如/var/log/falcon-log-agent.log
• 動態路徑：可支持按照規則配置的根據時間變化的路徑。例如：

好比：線上有些模塊本身按照小時寫入文件，路徑爲：
/xiaoju/application/log/20150723/application.log.2015072312
 
對應的咱們的配置方式能夠填寫爲：
/xiaoju/application/log/${%Y%m%d}/application.log.${%Y%m%d%H}    //  ${}中不能包含/

時間格式

時間格式，即time_format配置項。

若是日誌中沒有時間格式，一旦遇到日誌延遲落盤、或者日誌量太大計算延遲的狀況。會直接致使咱們的監控採集不許。

所以，咱們規定日誌中必須有合法的時間格式。且在配置中time_format項指定。

若是想要添加本身的時間格式，能夠直接在common/utils/util.go裏添加。

目前已經支持的時間格式以下：

dd/mmm/yyyy:HH:MM:SS
dd/mmm/yyyy HH:MM:SS
yyyy-mm-ddTHH:MM:SS
dd-mmm-yyyy HH:MM:SS
yyyy-mm-dd HH:MM:SS
yyyy/mm/dd HH:MM:SS
yyyymmdd HH:MM:SS
mmm dd HH:MM:SS

PS：爲了防止日誌積壓或性能不足致使的計算誤差，日誌採集的計算，依賴於日誌的時間戳。
所以若是配置了錯誤的時間格式，將沒法獲得正確的結果。

採集規則

採集正則，包含兩個配置項：pattern和exclude。

兩個採集項都是正則表達式，正則表達式的支持狀況見：google/re2

pattern表明須要徹底匹配出來的表達式。

exclude表明須要排除掉的表達式。

eg. 例如，我但願統計code=500或400的日誌數量，可是想排除掉關鍵字SpeciallyErrorNo。 配置以下：

pattern: code=[45]00
exclude: SpeciallyErrorNo

採集週期

採集週期(step)，對應着監控系統的上報週期。意味着多久合併上報一次。

假設每秒產生1條符合採集規則的日誌，配置的採集方式爲計數。
若是step爲10 : 則每10s上報一次，值爲10
若是step爲60 : 則每60s上報一次，值爲60

採集方式

採集方式(func)的意思是，當咱們從日誌中篩選出一堆符合規則的日誌以後，應該以哪一種規則來計算拿到最後的值來上報。

目前支持的採集方式有：

• cnt
• avg
• sum
• max
• min

舉例：

假設：
正則表達式配置爲 Return Success : (\d+)s Used
 
某一個週期內日誌滾動：
2017/12/01 12:12:01 Return Success : 1s Used
2017/12/01 12:12:02 Return Success : 2s Used
2017/12/01 12:12:03 Return Success : 4s Used
2017/12/01 12:12:04 Return Success : 2s Used
2017/12/01 12:12:05 Return Success : 1s Used
 
首先，根據正則獲取到括號內的值：一、二、四、二、1
接下來，根據不一樣的計算方式，會獲得不一樣的結果：
avg   : (1 + 2 + 4 + 2 + 1) / 5 = 2
count : 5
sum   : (1 + 2 + 4 + 2 + 1) = 10
max   : Max(1, 2, 4, 2, 1) = 4
min   : Min(1, 2, 4, 2, 1) = 1

採集名稱

採集名稱(name)對應open-falcon中的metric，即監控項。

標籤

標籤(tags)與open-falcon中的tags相對應。能夠理解爲肯定監控項的補充。

說明：機器A的第一個核的cpu空閒率。

採集名稱(metric): cpu空閒率(cpu.idle)
標籤(tags)：兩個標籤: host=機器A;核數=第一個核

在主正則匹配完成後，而後匹配出tag的值，一塊兒進行上報。

若沒法匹配出tag的值，則視爲該條數據未匹配到，該條日誌將再也不計入統計。

其餘

• degree: 精度
• comment: 備註

自身狀態暴露

falcon-log-agent自己對外提供了一個http服務用來暴露自身狀態。

主要提供的url以下：

• /health ： 自身存活狀態
• /strategy ：當前生效的策略列表
• /cached ： 最近1min內上報的點

自監控

在common/proc/metric/metric.go定義了一個自監控結構體。

在程序運行過程當中會不斷收集信息，主要包括以下：

MemUsedMB       進程內存佔用
ReadLineCnt     讀日誌行數
DropLineCnt     隊列打滿後，扔掉的日誌行數
AnalysisCnt     分析完成的日誌行數
AnalysisSuccCnt 分析成功匹配的日誌行數
PushCnt         推送的監控數據點數
PushErrorCnt    推送錯誤的監控數據點數
PushLatency     推送監控數據延遲

這些數據，目前自監控的處理方式是：定時輸出日誌。

若是須要對接本身公司的監控系統，在common/proc/metric/metric.go修改HandleMetrics方法便可。

 

 

文檔出自：https://github.com/didi/falcon-log-agent/blob/master/readme.md