最早接觸的日志管理應(yīng)用是ELK，當(dāng)時忽悠君坐在我對面成天喊要招個ES的大牛，一會林大師又在旁邊寫著各種正則式。還搞不清楚狀況的我就開始改KIBANA，給KIBANA換個皮。無奈KIBANA實在太不好改了，時間也不是特別充裕，好吧，從頭寫一個還快，雖然效果不太好。具體那玩意是做什么的，當(dāng)時也沒細(xì)想，反正能展示出來就好了，就是給個關(guān)鍵字，然后展示下對應(yīng)人日志。
過了沒多久，就跑去聽了一下Splunk的安利會議，聽半天，好像什么都沒收獲到，提問的人問的問題也很技術(shù)，沒有落到實用性上。不過現(xiàn)在回過頭來想想，要說收獲其實也算有的，就是我坐在會場，安裝了環(huán)境之后半天都沒搞明白怎么把日志塞進(jìn)去。。。一堆的選項，都不知道點哪個好。再后來，就入坑了（具體是怎么入的參見《自動化運維軟件設(shè)計實戰(zhàn)》。。血淚史 (≡ω≡．) ）
經(jīng)歷了一系列系統(tǒng)開發(fā)與運維后，其實作為開發(fā)者，我希望我接入的日志管理系統(tǒng)是這樣的。
能夠讓我輕易的就把日志放進(jìn)去
也算是當(dāng)初剛上手Splunk的不滿之一，太多的選項，都不知道點哪個，點下去會不會爆炸什么的。其實，作為開發(fā)者，我不就想把一些日志都收集起來，方便找嘛
不要一上來就要我寫正則式
寫了這么久程序，反正我是記不住幾個正則式(/"≡ _ ≡)/~┴┴ (這反人類的正則式。。。我就只記住了.*)最好是能通過簡單的幾個符號就解決搜索的問題了（假如在谷歌或者百度上面搜個東西還要用正則式的話，請自行腦補(bǔ)）
能夠搜索到上下文
有些時候日志打的很快，他們可能是不同線程打出來的，他們可能是不同服務(wù)器打出來的（不過帶有一定的先后性），他們可能是不同應(yīng)用打出來的，這個時候上下文就很重要了，沒有了上下文，無論是運維還是開發(fā)，在排除的時候都只能看到一個點，沒辦法根據(jù)實際的情況進(jìn)行排查。遇到復(fù)雜問題的時候也就這么2種處理方法。一種是：哦，這樣啊，我試了沒什么問題啊，要不，你下次再做操作的時候我這邊也一起看看？另外一種情況是：這樣啊，我們花時間查查究竟是什么原因（有很大幾率是查不出來的ㄟ( ▔, ▔ )ㄏ ）然后就不了了之了。所以上下文其實是挺重要的。這個地方出錯了，那前面發(fā)生了什么事情了呢？
能夠?qū)θ罩具M(jìn)行平行的分析
場景1：在應(yīng)用穩(wěn)定之前，我基本上都是采取單服務(wù)器的方式跑，有些小伙伴會說，你這樣單點了呢，不夠可靠。且不說應(yīng)用未完全穩(wěn)定之前會對程序頻繁的進(jìn)行改動導(dǎo)致發(fā)布的不便（好吧，這個時候那些搞CI的就會跳出來了，我只能說，事情總不是想象中那么順利的(′Д｀) ，而且。。我一個人的話，我也懶得去搞就是了，哈哈），特別是多臺服務(wù)器打日志的時候，我就會很煩惱，究竟這個請求落到哪臺服務(wù)器上了? 報的什么樣的錯誤？為什么其他服務(wù)器上又不會等等問題。碰到這種情況下，也就只能一臺一臺的登上去，tail -f xxxx.log，然后喊：”麻煩。。再點一次試試“。
場景2：小菜找到DBA，覺得數(shù)據(jù)庫的主從是不是沒同步到，DBA登上主庫打開binlog，再登上從庫打開binlog，看完日志之后，告訴小菜，從日志上來看，他們是同步的。
能夠提取一些有價值的數(shù)據(jù)，做點圖表
小菜在調(diào)用公司另外一個業(yè)務(wù)的接口的時候速度慢的不行，對方總說沒問題啊，我這邊看都挺好的。小菜心想，好吧，你不認(rèn)賬，我給你放個監(jiān)控，每分鐘都撥測你一下，等我手里有數(shù)據(jù)了，我還怕你不成？結(jié)果一周下來了，監(jiān)控到的指標(biāo)性能都挺不錯的，但是用戶還是反應(yīng)調(diào)用接口的時候性能很差。無奈的小菜翻了翻服務(wù)器上自己每次調(diào)用接口打出來的日志，的確是挺慢的。但是小菜也沒辦法，這。。舊的日志自己當(dāng)做垃圾數(shù)據(jù)給rm掉了，新的數(shù)據(jù)有是有那么些，但是一方面數(shù)據(jù)量不夠，另外一方面，自己再去這么一堆日志文件里面提取挺費勁的，╮(╯▽╰)╭趕進(jìn)度趕進(jìn)度，性能的事情以后再說吧。
能夠產(chǎn)生告警
監(jiān)控告警這種事情本應(yīng)該是監(jiān)控系統(tǒng)干的，但是從日志上出發(fā)，也會給我們帶來不一樣的想法：在一個陽光明媚的早上，小菜熟練的打開了MySQL的客戶端工具，在鍵盤下敲下來select * from .... 結(jié)果半天回不來結(jié)果？”奇怪？昨天都還很正常的啊？“于是趕緊向DBA求助，DBA登上服務(wù)器一看日志，發(fā)現(xiàn)服務(wù)器磁盤滿了。。。。當(dāng)然這種情況在生產(chǎn)環(huán)境下還是比較少見的，但是另外一種情況就比較多見了。B系統(tǒng)對A系統(tǒng)提供了對外的接口，A系統(tǒng)調(diào)用后出現(xiàn)調(diào)用失敗，或者B系統(tǒng)返回調(diào)用成功但實際上卻是調(diào)用失敗的情況。這種時候就應(yīng)該出現(xiàn)告警信息，提醒我們需要留意這個事件了，不然對于某些關(guān)鍵業(yè)務(wù)很容易就會出大問題的。（同時也保留一些罪證，哈哈哈o(*≧▽≦)ツ┏━┓）
小結(jié)
日志管理應(yīng)用能夠做的事情其實也挺多的，以上只是一些比較零散的點，晚上泡完腳突然有些想法，寫下來順便分享一下(話說晚上泡個腳還是挺舒服的(?????)? ?? )但是都是從實際應(yīng)用上出發(fā)提出的。看到過有些廠商貌似做了個服務(wù)器掛了之后就把日志傳回去，然后自動生成一個case，接著就會有人處理了（好吧，反正我就只看過這種推廣 (′?ω?｀)。。實際是不是這個效果我就不知道了）。
