90行代碼，搞定日誌監控框架

創業型公司，若是沒有上述完善的基礎設施，能夠簡化爲一個通用+可擴展的http監控框架：

• 調度器：100行的僞代碼，簡述了調度器的原理

• 可擴展配置：經過配置文件來維護監控項、集羣、告警人信息，同時保持擴展性

 

很多同窗留言問，這個框架日誌監控覆蓋不了，RPC接口監控覆蓋不了，xxoo監控覆蓋不了。額，都說了是http監控了，其餘類型的監控，聽樓主娓娓道來。

 

今天，要聊的是日誌監控。

 

1、什麼是日誌監控

關於日誌，不一樣公司，狀況不一樣：

• A類公司：沒有日誌

• B類公司：有日誌，只有用戶說系統掛了，或者有bug的時候，纔會登陸到系統看看日誌，大部分日誌打印得對心所欲，缺少組織性和系統性

畫外音：額，不少時候，追查bug發現日誌信息不全，要先上線一個有日誌的版本，以幫助定位bug，你遇到過麼？

• C類公司：有日誌，有日誌規範，系統性的組織和收集了日誌

 

對日誌進行監控，先於用戶發現系統的故障，實時告警，就是今天要討論的日誌監控問題。

 

2、日誌監控需求分析

對於日誌的監控，通常有這麼幾類需求：

• 某種級別的日誌（例如FATAL級別，或者ERROR級別的日誌）一旦出現，或者超過必定頻率，就告警

• 包含某些特殊含義關鍵字（例如OutOfMemory，或者Exception）的異常日誌，一旦出現，或者超過必定頻率，就告警

• 包含某些特殊含義關鍵字（例如Login，或者Click）的正常日誌，一旦必定時間週期沒有出現，就告警

 

其中，前兩類需求，屬於異常日誌監控範疇，出現異常，實施告警。

第三類需求，屬於正常日誌監控範疇，必定的時間沒有出現「正常」，就默認異常，實施告警。

 

爲何不是一出現異常日誌就告警呢？

避免抖動引發的誤報，通常到達必定頻率纔會告警，這屬於告警策略的一部分。

畫外音：關於人性化的告警策略，詳見《分級告警策略，人性化系統監控？》。

 

3、目錄與日誌的規範化

這是一個線上模塊的目錄示例：

• 有源代碼：hello.c

• 有可執行文件：a.out

• 有配置文件：hello.conf

• 有備份日誌：hello.log.2018012812

• 有日誌：hello.log

• 有臨時文件：tmp

體會一下，運維同窗看到這樣的線上文件部署，是什麼感覺？

畫外音：沒見過源代碼直接部署到線上的？

 

三點1、目錄規範

目錄規範化不但對日誌監控，對自動化運維都極爲重要，要是線上目錄都瞎搞，幾乎沒有辦法實現自動化運維。

 

常見的目錄規範有兩類：模塊優先類目錄規範，功能優先類目錄規範。

 

什麼是模塊優先的目錄規範？

如上圖，以模塊名爲優先組織目錄：

• 根目錄下，有das，entry，logic三個模塊目錄

• 在模塊目錄下，又分別有存放可執行文件，配置文件，日誌文件的bin目錄，conf目錄，以及log目錄

 

什麼是功能優先的目錄規範？

如上圖，以功能爲優先組織目錄：

• 根目錄下，二進制目錄bin，配置文件目錄conf，日誌目錄log

• 功能目錄下，有das，entry，logic等不一樣模塊的目錄

 

樓主旗幟鮮明的推薦第二種，功能優先的目錄規範，對二進制備份，配置備份，日誌清理都很是方便。

 

三點2、日誌規範

日誌規範化不但對日誌監控，對大數據體系建設都極爲重要，須要考慮規範：

• 日誌分級規範：不一樣級別的日誌理應打到不一樣的文件中，例如FATAL級，ERROR級，WARM級，LOG級，INFO級，DEBUG級

fatal.log

error.log

info.log

debug.log

…

• 日誌切分規範：運維應該提供自動化的日誌切分工具，支持小時級別，或者天級別的日誌切分，曾經看過一個120G的access日誌，從日誌中grep出某個uid的日誌，是極其低效的

daojia.log.2018012800

daojia.log.2018012801

…

daojia.log.2018012823

• 日誌格式規範：日誌格式規範是一個可展開的話題，必要性很強，挖個坑下回細說

畫外音：是否是有小夥伴在思考，ca，本身怎麼沒有這三類規範呢？

 

4、通用可擴展日誌監控平臺/框架思路

制訂了目錄規範，日誌規範以後，要創建日誌監控平臺/框架，實施異常與正常的日誌監控，就簡單多了，主要有集中式監控，分散式監控兩類思路。

 

四點1、集中式

集中式的日誌監控，最流行的莫過於ELK：

• 各個機器節點上部署logstash，收集日誌

• 收集的日誌彙總到ES

• 經過Kibana作統一分析和展示

運維的同窗對這一套集中式日誌監控系統很是熟悉。

 

四點2、分散式

ELK有點重，三套系統搭建與運維起來比較麻煩，若是隻是爲了實現ERROR日誌的監控，異常關鍵字監控，正常關鍵字監控，有點殺雞用牛刀了。

 

與集中式的日誌監控相比，分散式的日誌監控，就顯得輕量級許多，很是適用與早期的創業型公司，其思路爲：

• 經過日誌監控後臺，對不一樣集羣，進行ERROR日誌閾值設置，進行異常關鍵字設置，正常關鍵字設置

• 日誌監控中心，進行統一調度，將配置分發到不一樣機器的agent節點上

• agent節點，並不統一收集日誌，而是接收到監控中心分發的log監控配置，在各個機器上實施日誌監控，若是觸發日誌監控策略，馬上發起告警

 

與ELK相比，這個日誌平臺會簡單的多，並且擴展性很是好。

 

額，創業型公司沒有時間和人員研發agent，沒有資源研發日誌監控中心服務，沒有人力研發日誌監控後臺，還有沒有更簡潔但可擴展的方案呢？

和《100行代碼，搞定http監控框架》的思路同樣，沒有服務，沒有後臺，沒有agent，初期徹底能夠用配置文件來替代。

 

5、100行搞定日誌監控平臺

整個框架設計如上，大體分爲三個部分：

• 被監控集羣

• 基礎信息與服務

         cluster.info.xml：存儲集羣信息

         owner.info.xml：存儲集羣責任人信息

         mail.service/SM.service：發郵件，發短信的基礎服務

• 日誌監控框架

 

集羣信息與負責人信息，與前文描述的同樣。

集羣配置cluster.info.conf

[daojia_main]

ip.list : ip1, ip2, ip3

log.path : /home/work/log/daojia_main/

owner.list : shenjian, zhangsan

 

[daojia_user]

ip.list : ip4, ip5, ip6

log.path : /home/work/log/daojia_user/

owner.list : shenjian

 

責任人配置owner.info.conf

[shenjian]

email : XX@XX.com

phone :15912345678

 

[zhangsan]

email : YY@YY.com

phone :18611220099

 

日誌監控框架又分爲兩個模塊：

• 可擴展監控配置文件log.monitor.conf

[log.monitor.item]

cluster.name : daojia_main

# error日誌監控，每分鐘超過此閾值就告警

error.log. threshold : 10

# 異常關鍵字監控，日誌出現這些關鍵字就告警

bad.key : exeption | timeout | coredump

# 正常關鍵字監控，日誌每分鐘不出現這些關鍵字就告警

good.key : login | user | click

 

[log.monitor.item]

cluster.name : daojia_user

error.log.threshold : 10

 

日誌監控調度框架，這裏須要編碼啦，100行的僞代碼以下：

Array[log-monitor] A1= Parse(log.monitor.config);

Array[cluster-info] A2= Parse(cluster.info.config);

Array[owner-info] A3= Parse(owner.info.config);

 

// 遍歷全部監控項

for(each item in A1){

         //取出監控項的集羣名，閾值，異常/正常關鍵詞

         clusterName= item.clusterName;

         threshold= item.threshold;

         badKey= item.badkey;

         goodKey= item.goodkey;

 

         //由集羣名，獲取集羣信息

         clusterInfo= A2[clusterName];

         //獲取日誌目錄，集羣ip列表，集羣負責人列表

         logPath= clusterInfo.path;

         List<String>ips = clusterInfo.ip;

         List<String>owners = clusterinfo.owner;

        

         //集羣內的每個ip實例，都須要日誌監控

         for(eachip in ips){

                   //登陸到這一臺機器

                   ssh $ip

                   //跳到相關的目錄下

                   cd $logPath

                   //查看近一分鐘error日誌數量

                   $count= `grep $time error.log | wc -l`

                   //查看badkey與goodkey

                   $boolBad= `grep $badkey *`

                   $boolGood= `grep $goodkey *`

 

                   if($count< threshold && 

                        $boolBad==NO &&

                         $boolGood==YES){

                            //正常，繼續監控

                            continue;

                  }

 

                  // 不然，對全部集羣負責人發送告警

                  for(each owner in owners){

                           // 略…

                  }

         }

}

 

就是一個簡單的調度框架，看明白了嗎？

 

6、調研

調研一、對於日誌，你的感觸是

• ca，啥是日誌，什麼是grep

• 日誌不全，查問題的時候須要加日誌再發布系統

• 日誌全，但查問題的時候纔上去grep一把

• 日誌成體系，日誌有監控，有後臺不須要grep

 

調研二、對於日誌切分，你的感觸是

• ca，啥是日誌切分，就一個access.log呀

• 額，研發本身切分，沒有規範

• 不一樣團隊切分規範不一樣

• 運維提供工具統一規範切分

 

調研三、對於日誌監控，你的感觸是

• ca，啥是日誌監控，沒有哇

• ELK，集中式

• 日誌監控平臺，分散式

• 日誌監控框架，分散式

 

 

調研四：你見過120G的日誌文件麼？