上一篇《100行代碼，搞定http監控架構》介紹了通用+可擴充的http監控平台的架構：
- 監控平台層：排程監控項，通過背景管理監控項
- 資訊管理層：通過服務和背景維護叢集，告警接收人，告警政策等資訊
- 告警發送層：通過接口發送郵件，短信，微信等消息
創業型公司，如果沒有上述完善的基礎設施，可以簡化為一個通用+可擴充的http監控架構：
- 排程器：100行的僞代碼，簡述了排程器的原理
- 可擴充配置：通過配置檔案來維護監控項、叢集、告警人資訊，同時保持擴充性
不少同學留言問，這個架構日志監控覆寫不了，RPC接口監控覆寫不了，xxoo監控覆寫不了。額，都說了是http監控了，其他類型的監控，聽樓主娓娓道來。
今天，要聊的是日志監控。
一、什麼是日志監控
關于日志，不同公司，情況不同：
- A類公司：沒有日志
- B類公司：有日志，隻有使用者說系統挂了，或者有bug的時候，才會登入到系統看看日志，大部分日志列印得對心所欲，缺乏組織性和系統性
畫外音：額，很多時候，追查bug發現日志資訊不全，要先上線一個有日志的版本，以幫助定位bug，你遇到過麼？
C類公司：有日志，有日志規範，系統性的組織和收集了日志
對日志進行監控，先于使用者發現系統的故障，實時告警，就是今天要讨論的日志監控問題。
二、日志監控需求分析
對于日志的監控，一般有這麼幾類需求：
- 某種級别的日志（例如FATAL級别，或者ERROR級别的日志）一旦出現，或者超過一定頻率，就告警
b包含某些特殊含義關鍵字（例如OutOfMemory，或者Exception）的異常日志，一旦出現，或者超過一定頻率，就告警
- 包含某些特殊含義關鍵字（例如Login，或者Click）的正常日志，一旦一定時間周期沒有出現，就告警
其中，前兩類需求，屬于異常日志監控範疇，出現異常，實施告警。
第三類需求，屬于正常日志監控範疇，一定的時間沒有出現“正常”，就預設異常，實施告警。
為什麼不是一出現異常日志就告警呢？
避免抖動引起的誤報，一般到達一定頻率才會告警，這屬于告警政策的一部分。
畫外音：關于人性化的告警政策，詳見《分級告警政策，人性化系統監控？》。
三、目錄與日志的規範化
這是一個線上子產品的目錄示例：
- 有源代碼：hello.c
- 有可執行檔案：a.out
- 有配置檔案：hello.conf
- 有備份日志：hello.log.2018012812
- 有日志：hello.log
- 有臨時檔案：tmp
體會一下，運維同學看到這樣的線上檔案部署，是什麼感受？
畫外音：沒見過源代碼直接部署到線上的？
三點一、目錄規範
目錄規範化不但對日志監控，對自動化運維都極為重要，要是線上目錄都瞎搞，幾乎沒有辦法實作自動化運維。
常見的目錄規範有兩類：子產品優先類目錄規範，功能優先類目錄規範。
什麼是子產品優先的目錄規範？
如上圖，以子產品名為優先組織目錄：
- 根目錄下，有das，entry，logic三個子產品目錄
- 在子產品目錄下，又分别有存放可執行檔案，配置檔案，日志檔案的bin目錄，conf目錄，以及log目錄
什麼是功能優先的目錄規範？
如上圖，以功能為優先組織目錄：
根目錄下，二進制目錄bin，配置檔案目錄conf，日志目錄log
功能目錄下，有das，entry，logic等不同子產品的目錄
樓主旗幟鮮明的推薦第二種，功能優先的目錄規範，對二進制備份，配置備份，日志清理都非常友善。
三點二、日志規範
日志規範化不但對日志監控，對大資料體系建設都極為重要，需要考慮規範：
日志分級規範：不同級别的日志理應打到不同的檔案中，例如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，自己怎麼沒有這三類規範呢？
四、通用可擴充日志監控平台/架構思路
制訂了目錄規範，日志規範之後，要建立日志監控平台/架構，實施異常與正常的日志監控，就簡單多了，主要有集中式監控，分散式監控兩類思路。
四點一、集中式
集中式的日志監控，最流行的莫過于ELK：
各個機器節點上部署logstash，收集日志
收集的日志彙總到ES
通過Kibana做統一分析和展現
運維的同學對這一套集中式日志監控系統非常熟悉。
四點二、分散式
ELK有點重，三套系統搭建與運維起來比較麻煩，如果隻是為了實作ERROR日志的監控，異常關鍵字監控，正常關鍵字監控，有點殺雞用牛刀了。
與集中式的日志監控相比，分散式的日志監控，就顯得輕量級許多，非常适用與早期的創業型公司，其思路為：
通過日志監控背景，對不同叢集，進行ERROR日志門檻值設定，進行異常關鍵字設定，正常關鍵字設定
日志監控中心，進行統一排程，将配置分發到不同機器的agent節點上
agent節點，并不統一收集日志，而是接收到監控中心分發的log監控配置，在各個機器上實施日志監控，如果觸發日志監控政策，立刻發起告警
與ELK相比，這個日志平台會簡單的多，而且擴充性非常好。
額，創業型公司沒有時間和人員研發agent，沒有資源研發日志監控中心服務，沒有人力研發日志監控背景，還有沒有更簡潔但可擴充的方案呢？
和《100行代碼，搞定http監控架構》的思路一樣，沒有服務，沒有背景，沒有agent，初期完全可以用配置檔案來替代。
五、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 : [email protected]
phone :15912345678
[zhangsan]
email : [email protected]
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){
// 略…
}
}
} 就是一個簡單的排程架構，看明白了嗎？
六、調研
調研一、對于日志，你的感觸是
- ca，啥是日志，什麼是grep
- 日志不全，查問題的時候需要加日志再釋出系統
- 日志全，但查問題的時候才上去grep一把
- 日志成體系，日志有監控，有背景不需要grep
調研二、對于日志切分，你的感觸是
- ca，啥是日志切分，就一個access.log呀
- 額，研發自己切分，沒有規範
- 不同團隊切分規範不同
運維提供工具統一規範切分
調研三、對于日志監控，你的感觸是
- ca，啥是日志監控，沒有哇
- ELK，集中式
- 日志監控平台，分散式
- 日志監控架構，分散式
調研四：你見過120G的日志檔案麼？