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

文章出處：三斗室

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

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運維日誌相關的機器學習論文，用神經網路的效果普遍比迴歸差。嗯~總之，大家老實幹活就好了。