IT運維日誌分析中有哪些常見但無用的功能？
在這些龐大的功能需求中，或者說“泥沙俱下”，有壹部分是天然蛋，或許是因為聽起來很酷，又或許是想延續過去的使用習慣。今天因為在外地出差，很少有時間放松，所以決定吐槽壹下這些天然雞蛋的幾大功效。
作者:葛來源:運維學校| 2016-11-22 14:12收藏與分享
日誌分析是IT運維中非常重要的壹部分。甚至可以說，這部分工作的重要性已經逼近了當今流行的平臺化、模塊化、服務化的傳統設備監控。但由於日誌的來源、使用者、管理者比設備指標更復雜，日誌分析的功能需求也是巨大的。在這些龐大的功能需求中，或者說“泥沙俱下”，有壹部分是天然蛋，或許是因為聽起來很酷，又或許是想延續過去的使用習慣。今天因為在外地出差，很少有時間放松，所以決定吐槽壹下這些天然雞蛋的幾大功效。
實時警報
第壹個地方就是所謂的“實時報警”。報警系統實際上可以分為兩種不同的用途:
有個問題需要解決，
有些事情將會出錯，我們必須避免它。
那就分開說:
如果要打電話找人修，從報警發出到登錄服務器解決問題，至少需要幾分鐘。根據墨菲定律，妳很可能正在團建裏睡覺、吃飯、坐車，所以十分鐘已經是妳的快速行動了。所以警報是在0.1秒發送的，這與10秒不同。而將報警從10秒的區間壓縮到1秒內的實時，將需要大量的結構調整和成本增加...(妳說壹個關鍵詞實時過濾沒有成本？那麽妳需要先加強報警系統的跟蹤、擴大、壓制等功能。
如果要提前避免，壹般妳的基礎設施已經進化的很好了，妳會想通過鬧鐘的觸發動作來自動修改妳的流量、資源和任務調度。其實這種需求更多的是屬於產能規劃的範疇。很難想象為什麽這種事情需要實時。誰的平臺不賺保證金？
當然，無論以上哪壹種，我吐槽的都是對實時1秒甚至毫秒的追求。如果妳的監測間隔還停留在5分鐘以上，不要拿我的話當擋箭牌——如果妳從接到報警到解決問題需要的是小時級別，5分鐘可能不算多，但是妳的故障定位方法，或者說報警系統的內容精細化水平還有待提高。
翻頁翻頁翻頁翻頁。
第二名是showmemoremoney，錯了，logline。日誌分析系統壹般會在界面上列出原始日誌以供查看。而壹堆“手賤”的人會開心的去下壹頁，下壹頁，下壹頁，下壹頁，然後系統就出問題了。
這個功能需求其實是過去catlogfile|grepKEYWORD|less習慣的遺留。我希望我可以進入並開始逐行閱讀日誌。Ctrl+F翻頁很爽，但是所有的時間都在不知不覺中浪費掉了——想想妳還想要的“實時”——運維故障排除最適合的思路就是快速試錯！測試壹個想法。不，只是測試下壹個。如果壹頁看不到20條日誌，兩頁看不到40條日誌，可以快速改變時間段，改變關鍵詞。
當然，另壹方面，總想把頁面翻回來，不然可能真的想不出用什麽關鍵詞。日誌分析系統有必要提供幫助用戶更快找到合適關鍵詞的能力。這個東西是儀表板可視化。用正確的能力去做正確的事情，而不是在有正確方法的情況下繼續用麻煩的方法。