如何在12個小時，搞定日誌監控？

日誌監控，是每一個公司必須解決的一個問題。創業型公司，如何用半天的時間，搞定一個 可擴展，通用 的 日誌監控框架 ，是今天要聊的話題。

 

什麼是日誌監控？

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

（1）A類公司：沒有日誌；

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

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

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

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

 

日誌監控有什麼需求？

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

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

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

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

 

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

 

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

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

 

爲何說，目錄與日誌的規範化，是通用日誌監控的前提？

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

（1）有源代碼：hello.c

（2）有可執行文件：a.out

（3）有配置文件：hello.conf

（4）有備份日誌：hello.log.2018012812

（5）有日誌：hello.log

（6）有臨時文件：tmp

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

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

 

有什麼常見的目錄規範呢？

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

常見的目錄規範有兩類：

（1）模塊優先類目錄規範；

（2）功能優先類目錄規範；

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

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

（1）根目錄下，有das，entry，logic三個模塊目錄；

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

 

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

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

（1）根目錄下，二進制目錄bin，配置文件目錄conf，日誌目錄log；

（2）功能目錄下，有das，entry，logic等不一樣模塊的目錄；

 

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

 

有什麼常見的日誌規範呢？

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

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

fatal.log

error.log

info.log

debug.log

…

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

daojia.log.2018012800

daojia.log.2018012801

…

daojia.log.2018012823

（3）日誌格式規範：日誌格式規範是一個可展開的話題，此處不展開；

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

 

通用可擴展日誌監控框架，有什麼思路？

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

 

什麼是集中式日誌監控？

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

（1）各個機器節點上部署logstash，收集日誌；

（2）收集的日誌彙總到ES；

（3）經過Kibana作統一分析和展示；

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

 

什麼是分散式日誌監控？

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

 

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

（1）經過日誌監控模塊，對不一樣集羣，進行ERROR日誌閾值設置，進行異常關鍵字設置，正常關鍵字設置；

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

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

 

與ELK相比，這個日誌監控框架會簡單的多，並且擴展性很是好。

 

如何半天搞定日誌監控框架？

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

（1）被監控集羣；

（2）基礎信息與服務；

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

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

         mail.service/SM.service：告警基礎服務

（3）日誌監控框架；

 

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

集羣配置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

 

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

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(each ip 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){

                           // 略…

                  }

         }

}

 

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

架構師之路-分享技術思路

思路比結論更重要，但願你們有收穫。

調研

貴司的 日誌 ，你的感 觸是：

（1）ca，啥是日誌，什麼是grep，沒有日誌；

（2）日誌不全，查問題的時候再加日誌；

（3）日誌全，但查問題的時候纔上去grep一把；

（4）日誌成體系，日誌有監控，不須要grep；

本文分享自微信公衆號 - 架構師之路（road5858）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。