[[176851]]

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

realtimealert

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

出現了問題要修復，

快要出問題得避免。

那么分開說：

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

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

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

翻頁翻頁翻頁

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

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

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

經緯度地圖

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

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

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

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

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

說到實際情況，IT日志分析需要地圖的大多數時候是基于行政區劃的統計。全局負載均衡絕大多數都是以行政區劃和運營商為基準做的劃分，如果通過地圖真的定位到什么訪問問題，很大可能下一步你能做的是通過商務手段去聯系當地電信服務運營商!你要經緯度有什么用?——別忘了免費的GeoIP國內精準度本來就低。花點時間搞一個準確到地市運營商的IP地址庫，才是最應該做的事情。

全量下載(etltoBI)

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

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

非要把原日志(即使是歸一化之后的結構數據)導入到BI里做統計，是一個耗時耗力的下下之選。

SQL

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

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

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

從編程語言學來一個經驗，對特定領域，采用特定領域語言，即DSL的設計方式，永遠是更加高效、靈活、優秀的選擇。

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

熟悉日志分析領域的人可能看出來我是在給SPL寫軟文了……自Splunk發明SPL這種日志分析領域的DSL以來，已經有大批日志分析產品跟進了這個形式，SumoLogic、Rizhiyi、XpoLog、MicroSoftAzure、OracleCloudManagement等等。不過公平的說，上面一段要點，確實也可以提煉出來跟SPL不一樣的DSL設計，比如說：更接近面向對象編程語言的鏈式調用函數，同樣也符合這個習慣——這也是ELK從5.0開始分發的timelion插件的選擇。

livetail

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

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

直接從agent建聯，意味著后續的歸一化結構是無法用來做復雜過濾的，同樣還意味著跨平臺能力削弱;

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

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

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

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

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

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

就寫到這里吧，我猶豫很久要不要把人工智能機器學習寫進來。考慮到異常探測和預測也算是機器學習的一部分，還是不一竿子打倒全部吧~~這里只說一句：我花時間翻了一打IT運維日志相關的機器學習論文，用神經網絡的效果普遍比回歸差。嗯~總之，大家老實干活就好了。

文章出處：三斗室

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