IT運維日誌分析中有哪些常見但沒啥用的功能
在這些龐大的，或者說『泥沙俱下』的功能需求中，有那麽壹些然並卵的，或許因為聽起來很炫酷，或許因為想延續過去的使用習慣，今天因為出差到外地，難得有空放松下，決定吐槽幾個這種然並卵的功能。
作者：小碼哥來源：運維派|2016-11-22 14:12 收藏 分享
日誌分析是IT運維領域非常重要的壹部分工作。甚至可以說，在平臺化、模塊化、服務化盛行的今天，這部分工作的重要性已經逼近傳統的設備監控。不過日誌由於來源、使用者、管理者都比設備指標要復雜，導致日誌分析的功能需求，也龐大很多。在這些龐大的，或者說『泥沙俱下』的功能需求中，有那麽壹些然並卵的，或許因為聽起來很炫酷，或許因為想延續過去的使用習慣，今天因為出差到外地，難得有空放松下，決定吐槽幾個這種然並卵的功能。
realtimealert
排在第壹位的就是所謂的『實時告警』。做壹個告警系統，其實可以分成兩類不同的目的：
出現了問題要修復，
快要出問題得避免。
那麽分開說：
如果是要喊人來修復的，假設妳的告警內容已經細化到完全不用再排查問題，從告警發出來，到妳登錄到服務器解決問題，至少也需要數分鐘級別——根據墨菲定律，這時候妳很可能在睡覺在吃飯在坐車在團建，那麽十分鐘已經是妳行動迅速了。那麽告警是第0.1秒發出來的，跟是第10秒發出來的，有什麽區別?而把告警從間隔10秒壓縮到1秒內的實時，需要花費的架構調整和成本上升，可不是壹點半點……(妳說壹個關鍵字實時過濾沒啥成本?那妳需要先加強壹下告警系統的追蹤、擴展、抑制等功能呢，告警沒那麽簡單)
如果是要提前避免的，壹般妳的基礎架構已經進化的不錯了，才會想要通過告警的觸發動作來自動化修改妳的流量、資源和任務調度編排。這種需求其實更多歸入容量規劃範疇，很難想象這種事情要實時性幹嘛，誰家平臺不打余量的?
當然，不管上面哪種，我吐槽的都是追求1秒甚至毫秒的實時。如果妳的監控間隔還停留在5分鐘以上，可別拿我這段話做擋箭牌——如果妳從收到告警到解決問題需要小時級別，5分鐘可能是也不算多，但是妳的故障定位方式，或者說告警系統的內容細化水平，更加需要提高。
翻頁翻頁翻頁
排在第二位的就是showmemoremoney，錯了，logline。日誌分析系統壹般都會在界面上列出來日誌原文供查看。而壹幫『手賤』的人，就會很happy地點下壹頁下壹頁下壹頁下~壹~頁~下~然後系統出問題了。
這個功能需求其實就是過去catlogfile|grepKEYWORD|less習慣的遺毒。上來就恨不得自己能vim進去壹行行開始看日誌。Ctrl+F嗷嗷翻頁固然很爽，不知不覺中時間全都浪費掉了——想想上壹條妳還想要的『實時』——運維排查問題最適合的思路是快速試錯!壹個想法驗證下不行趕緊驗證下壹個。如果壹頁20條日誌妳看不出來，兩頁40條日誌妳看不出來，妳就趕緊改個時間段、改個關鍵詞吧。
當然，話說回來，老想著往後翻頁，也有可能是真想不出來改用啥關鍵詞。日誌分析系統有必要提供幫助用戶更快找到合適關鍵詞的能力。這東西就是儀表盤可視化。利用正確的能力做正確的事，而不應該在有正確的方法的情況下繼續使用麻煩辦法。