[[176851]]

日志分析是IT運維領(lǐng)域非常重要的一部分工作。甚至可以說，在平臺化、模塊化、服務(wù)化盛行的今天，這部分工作的重要性已經(jīng)逼近傳統(tǒng)的設(shè)備監(jiān)控。不過日志由于來源、使用者、管理者都比設(shè)備指標(biāo)要復(fù)雜，導(dǎo)致日志分析的功能需求，也龐大很多。在這些龐大的，或者說『泥沙俱下』的功能需求中，有那么一些然并卵的，或許因為聽起來很炫酷，或許因為想延續(xù)過去的使用習(xí)慣，今天因為出差到外地，難得有空放松下，決定吐槽幾個這種然并卵的功能。

realtimealert

排在第一位的就是所謂的『實時告警』。做一個告警系統(tǒng)，其實可以分成兩類不同的目的：

出現(xiàn)了問題要修復(fù)，

快要出問題得避免。

那么分開說：

如果是要喊人來修復(fù)的，假設(shè)你的告警內(nèi)容已經(jīng)細(xì)化到完全不用再排查問題，從告警發(fā)出來，到你登錄到服務(wù)器解決問題，至少也需要數(shù)分鐘級別——根據(jù)墨菲定律，這時候你很可能在睡覺在吃飯在坐車在團建，那么十分鐘已經(jīng)是你行動迅速了。那么告警是第0.1秒發(fā)出來的，跟是第10秒發(fā)出來的，有什么區(qū)別?而把告警從間隔10秒壓縮到1秒內(nèi)的實時，需要花費的架構(gòu)調(diào)整和成本上升，可不是一點半點……(你說一個關(guān)鍵字實時過濾沒啥成本?那你需要先加強一下告警系統(tǒng)的追蹤、擴展、抑制等功能呢，告警沒那么簡單)

如果是要提前避免的，一般你的基礎(chǔ)架構(gòu)已經(jīng)進化的不錯了，才會想要通過告警的觸發(fā)動作來自動化修改你的流量、資源和任務(wù)調(diào)度編排。這種需求其實更多歸入容量規(guī)劃范疇，很難想象這種事情要實時性干嘛，誰家平臺不打余量的?

當(dāng)然，不管上面哪種，我吐槽的都是追求1秒甚至毫秒的實時。如果你的監(jiān)控間隔還停留在5分鐘以上，可別拿我這段話做擋箭牌——如果你從收到告警到解決問題需要小時級別，5分鐘可能是也不算多，但是你的故障定位方式，或者說告警系統(tǒng)的內(nèi)容細(xì)化水平，更加需要提高。

翻頁翻頁翻頁

排在第二位的就是showmemoremoney，錯了，logline。日志分析系統(tǒng)一般都會在界面上列出來日志原文供查看。而一幫『手賤』的人，就會很happy地點下一頁下一頁下一頁下~一~頁~下~然后系統(tǒng)出問題了。

這個功能需求其實就是過去catlogfile|grepKEYWORD|less習(xí)慣的遺毒。上來就恨不得自己能vim進去一行行開始看日志。Ctrl+F嗷嗷翻頁固然很爽，不知不覺中時間全都浪費掉了——想想上一條你還想要的『實時』——運維排查問題最適合的思路是快速試錯!一個想法驗證下不行趕緊驗證下一個。如果一頁20條日志你看不出來，兩頁40條日志你看不出來，你就趕緊改個時間段、改個關(guān)鍵詞吧。

當(dāng)然，話說回來，老想著往后翻頁，也有可能是真想不出來改用啥關(guān)鍵詞。日志分析系統(tǒng)有必要提供幫助用戶更快找到合適關(guān)鍵詞的能力。這東西就是儀表盤可視化。利用正確的能力做正確的事，而不應(yīng)該在有正確的方法的情況下繼續(xù)使用麻煩辦法。

經(jīng)緯度地圖

既然說到可視化，可視化方面是做日志分析乃至數(shù)據(jù)分析最容易誤入歧途的方向了。有興趣的可以看下面幾個鏈接，是我從KibanaPlugin社區(qū)討論組里復(fù)制過來的：

http://www.businessinsider.com/the-27-worst-charts-of-all-time-2013-6?op=1&IR=T

http://flowingdata.com/category/visualization/ugly-visualization/

這些很復(fù)雜的可視化就不提了。在日志分析方面，最常見的一個炫酷的效果就是地圖。地圖可真是一個被各種玩出花來的東西，諸如安全攻擊喜歡放個3D地球，在google圖片上隨便搜『DDoSatackearth』關(guān)鍵詞，大把大把;做個推廣活動，喜歡搞個實時連線的中國地圖看PV，全國各地，來一個訪問，飛一個點出來到北京。。。

真的是酷斃了。不過，然后呢?你看到這個點能干嘛?而且飛動中的點，唰唰就過去了，壓根捕捉不到。

說到實際情況，IT日志分析需要地圖的大多數(shù)時候是基于行政區(qū)劃的統(tǒng)計。全局負(fù)載均衡絕大多數(shù)都是以行政區(qū)劃和運營商為基準(zhǔn)做的劃分，如果通過地圖真的定位到什么訪問問題，很大可能下一步你能做的是通過商務(wù)手段去聯(lián)系當(dāng)?shù)仉娦欧?wù)運營商!你要經(jīng)緯度有什么用?——別忘了免費的GeoIP國內(nèi)精準(zhǔn)度本來就低?；c時間搞一個準(zhǔn)確到地市運營商的IP地址庫，才是最應(yīng)該做的事情。

全量下載(etltoBI)

另一個和翻頁有些類似的功能，就是要求全量日志下載。這種需求通常目的也是分兩類，一類其實跟翻頁是一個需求，不知道查啥內(nèi)容，干脆要求把日志都下載回來自己慢慢折騰;另一類則是環(huán)境中有一些標(biāo)準(zhǔn)的BI軟件，覺得日志分析軟件的可視化和統(tǒng)計方法不夠用，還是喜歡、習(xí)慣BI，所以要求日志分析系統(tǒng)負(fù)責(zé)搜索，BI系統(tǒng)負(fù)責(zé)分析。

這塊怎么說呢，列出來有些個人主觀化，我個人不太覺得在IT運維領(lǐng)域，有啥是BI能做，而開源日志分析項目做不來的事情。退一步說：真要兩個系統(tǒng)的結(jié)合，也應(yīng)該是分層的架構(gòu)。充分利用日志分析系統(tǒng)的分布式架構(gòu)并行處理能力，將大量map操作在日志系統(tǒng)完成，將中間統(tǒng)計結(jié)果導(dǎo)入到BI中完成最后的reduce工作即可。

非要把原日志(即使是歸一化之后的結(jié)構(gòu)數(shù)據(jù))導(dǎo)入到BI里做統(tǒng)計，是一個耗時耗力的下下之選。

SQL

第四個很常見的功能，就是SQL。這甚至不是日志分析領(lǐng)域的毛病，在所有和數(shù)據(jù)相關(guān)的、非關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)存儲系統(tǒng)上，都會有大把人問：有SQL支持么?

就我的淺薄見識，對所有存儲系統(tǒng)要FUSE掛載，對所有數(shù)據(jù)系統(tǒng)要SQL查詢，應(yīng)該是可以對等的兩個吃力不討好的工作了。在Hadoop上有無數(shù)個實現(xiàn)SQL的項目，哪怕Hive和SparkSQL這種級別的大項目在，我還是要說：研發(fā)同仁們想要SQL，不就是覺得自己已經(jīng)會SQL，所以要無縫對接，不用學(xué)習(xí)新知識么?你們點開Hive文檔，里面有多少是非標(biāo)準(zhǔn)SQL的函數(shù)功能?

只有極少數(shù)基礎(chǔ)的、簡單的過濾和統(tǒng)計函數(shù)，可以橫跨API、SQL、DSL等方式，在各平臺上都通用。而你選擇某個大數(shù)據(jù)平臺的實際理由，大多是它的xxxyyyzzz亮點功能，很好，你需要自己搞一個UDF了……這還搞SQL有什么意義。

從編程語言學(xué)來一個經(jīng)驗，對特定領(lǐng)域，采用特定領(lǐng)域語言，即DSL的設(shè)計方式，永遠是更加高效、靈活、優(yōu)秀的選擇。

在日志分析方面來說，抓住關(guān)鍵詞檢索、分組統(tǒng)計、上下文關(guān)聯(lián)、時間序列這幾個特性，你就可以抽象出來幾個能覆蓋足夠場景的函數(shù)了，而借鑒命令行操作的形式，從左到右的書寫習(xí)慣也比SQL的從右到左的形式更加符合數(shù)據(jù)流向的效果。

熟悉日志分析領(lǐng)域的人可能看出來我是在給SPL寫軟文了……自Splunk發(fā)明SPL這種日志分析領(lǐng)域的DSL以來，已經(jīng)有大批日志分析產(chǎn)品跟進了這個形式，SumoLogic、Rizhiyi、XpoLog、MicroSoftAzure、OracleCloudManagement等等。不過公平的說，上面一段要點，確實也可以提煉出來跟SPL不一樣的DSL設(shè)計，比如說：更接近面向?qū)ο缶幊陶Z言的鏈?zhǔn)秸{(diào)用函數(shù)，同樣也符合這個習(xí)慣——這也是ELK從5.0開始分發(fā)的timelion插件的選擇。

livetail

今天我能想到的最后一個惡習(xí)遺毒，同樣還符合酷炫概念的功能，是livetail，也有叫webtail或者logtail的。不知道從哪來的程序員情節(jié)，覺得終端的黑底白字最棒了，非要在瀏覽器頁面上，通過websocket連接上某臺服務(wù)器，實時查看某個日志文件的尾部滾動。或者簡單說，就是一個tail-Flogfile功能的網(wǎng)頁化。

由于網(wǎng)絡(luò)的限制、瀏覽器渲染的限制(畢竟要很多酷炫效果呢)，這類功能一般實現(xiàn)出來帶有諸多的限制：

直接從agent建聯(lián)，意味著后續(xù)的歸一化結(jié)構(gòu)是無法用來做復(fù)雜過濾的，同樣還意味著跨平臺能力削弱;

需要限制使用者的并發(fā)數(shù)，以及每個連接的流速。一般來說是每秒不許超過1000條——人肉眼其實每秒也看不過來這么多數(shù)據(jù);

為了限速，必須指定具體的hostname和filename，無法使用通配符，無法跨文件關(guān)聯(lián)查詢;

為了解決跨文件，在同一頁面上切分屏幕，考慮美觀和視覺，最多也就是切分一次，即一次可以看兩個文件的tail。

我在最前面已經(jīng)說到了，日志系統(tǒng)之所以現(xiàn)在重要性提高，就是因為日志前所未有的分散，兩個分屏的tail，有什么用?

當(dāng)然，回到這個偽需求的根本目的：我就是在調(diào)試而不是事后排錯呢，怎么讓我可以快速看到我橫跨好幾個模塊的調(diào)試日志是否正常?

這跟前面『無限翻頁』類似：你真正需要的知道新入的日志有沒有異常，而不是刷過去什么字樣。通過ANDORNOT等過濾條件，通過時間排序，通過關(guān)聯(lián)ID，你完全可以在秒級得到更精準(zhǔn)的、更有利于你閱讀的日志。

就寫到這里吧，我猶豫很久要不要把人工智能機器學(xué)習(xí)寫進來?？紤]到異常探測和預(yù)測也算是機器學(xué)習(xí)的一部分，還是不一竿子打倒全部吧~~這里只說一句：我花時間翻了一打IT運維日志相關(guān)的機器學(xué)習(xí)論文，用神經(jīng)網(wǎng)絡(luò)的效果普遍比回歸差。嗯~總之，大家老實干活就好了。

文章出處：三斗室

鏈接：http://chenlinux.com/2016/11/15/important-unuseful-feature-in-log-analysis/