在數(shù)據(jù)中心里，幾乎所有的系統(tǒng)和應用程序都會產(chǎn)生日志文件。日志是帶時間標記的足跡、記錄行為、條件和事件，通過對日志進行分析，往往能夠提前預知到數(shù)據(jù)中心運行的潛在風險，也能夠在發(fā)生故障之后，通過日志信息找到故障發(fā)生的原因，就像是飛機的黑匣子一樣，發(fā)生事故后追查原因的一個重要手段。然而，數(shù)據(jù)中心里的設備成千上萬，安裝的軟件和應用程序復雜多樣，每臺設備，每個應用都有自己的日志打印，這樣每天數(shù)據(jù)中心都會產(chǎn)生海量的日志信息，即使是最辛勤的管理員也無法在有生之年完成對逐個日志的甄別，大型數(shù)據(jù)中心運行中不斷生成日志數(shù)據(jù)的速度已遠遠超過人類分析的速度，傳統(tǒng)的數(shù)據(jù)分析方法是每周或每天依照列表審查日志文件，這種方法早已無法滿足現(xiàn)在數(shù)據(jù)中心的要求，于是出現(xiàn)了很多日志分析工具、網(wǎng)絡管理軟件，利用這些分析軟件來檢查日志信息，以便代替人工查閱的方式，提升分析日志的速度，這也是目前數(shù)據(jù)中心里對日志分析的普遍做法，但實際上能夠提前通過日志，預知隱患的很少，那應該如何利用日志信息來提升數(shù)據(jù)中心的可維護性呢，或者說通過分析日志，減少數(shù)據(jù)中心故障發(fā)生的概率呢，本文就來詳細談一談。
首先，日志分析作用的大小，取決于日志信息的準確性。如果日志信息本身就是不可信的，那分析出來的結果自然不可信，所以要對日志信息進行甄別。數(shù)據(jù)中心里的絕大部分設備都具有日志打印，有的設備還可以按照要求將日志發(fā)向網(wǎng)絡中特定的日志主機設備商。這些設備都有很多的日志打印開關，可以對日志信息進行過濾，那么哪些模塊是特定的數(shù)據(jù)中心所關心的，就打開，否則進行關閉，避免產(chǎn)生一些無關緊要、無用的日志。另外日志信息本身的準確性也非常重要，比如設備上報了一條The board is Fault，那么是單板壞了，還是軟件重啟了，是哪個槽位的板卡壞了？一條日志的信息要將整個事件的全貌反饋出來，而不是讓使用者去猜，這就要求數(shù)據(jù)中心的設備商要提供標準的日志輸出設計體系，日志簡單明了，能夠說明問題，而不是不知所云。這樣能夠在有問題或者在出問題之前有日志打印還好，就怕是故障已經(jīng)發(fā)生了，而卻沒有報出任何的日志，這讓人無從進行分析，而在數(shù)據(jù)中心運行正常的時候，反到噼哩叭啦地往外報無用的日志。若遇到這樣的設備或者系統(tǒng)，就應該將它們?nèi)舆M垃圾桶，這不是給數(shù)據(jù)中心添亂嗎。所以，一定要保證日志信息的準確性，打印的每一條日志，都是需要數(shù)據(jù)中心管理員去關注的，并且要采取一定的預防措施。
其次，很多時候我們不好界定一些日志有沒有用，所以經(jīng)過裁剪、判斷，還是會有很多的日志輸出出來。比如我拔插個光模塊，一定會有日志打印，端口的UP/DOWN，也一定會有日志打印，如果這些日志不打印出來，一旦有的時候是非人為的端口UP/DOWN，那就要查互聯(lián)端口有沒有問題，光模塊有沒有，光纖架或者跳線架有沒有問題等等，所以很多時候一些日志并不是上報問題，但又不能不打印，這時就需要甄別。因為大型的數(shù)據(jù)中心的設備實在太多，這樣日志信息收集起來也還是有很多，要靠人工每年去檢查，不太現(xiàn)實。網(wǎng)絡上有不少這類的日志分析工具，比如SiteFlow、IIS日志查看工具、光年日志分析工具等等，這些工具可以采集多臺設備的日志信息，并且根據(jù)設定的過濾條件，對關鍵字進行過濾，對日志進行分類：提示、一般、告警、致命等多個等級，支持告警。可以將日志實時通告給數(shù)據(jù)中心管理員，數(shù)據(jù)中心管理員對收到的日志進行檢查，根據(jù)日志的具體內(nèi)容，啟動相應的解決預案，如果不好處理，則可以立即召集相關技術人員一起討論商議對策。
再次，日志信息是準確的了，也會讓管理員及時知道什么設備報出了哪些日志，需要及時處理的，但這還遠遠不夠。未來擁有數(shù)千臺的數(shù)據(jù)中心往往就只要幾個人來管理與維護，這些日志分析工作也只是這些人平時工作其中的小部分，這些人還有很多其它的事情要做，所以很多時候對日志的輸出沒有時間來理會，更多的時候是已經(jīng)發(fā)生故障了，然后再回查故障當時和之前有沒有什么打印日志，但故障已經(jīng)發(fā)生了，影響已經(jīng)造成了，再去看日志無非是想找到故障的原因，有時是希望通過故障原因來對數(shù)據(jù)中心進行改進和優(yōu)化，避免再出這樣類似的故障，這不是一個很好的做法。最好的做法時，在故障發(fā)生之前或者故障剛發(fā)生，就通過日志得到故障事件，并通過自動化軟件自動啟動提前設置好的恢復預案，避免故障發(fā)生或者將故障帶來的影響降低到最小，將日志和自動化恢復的動作結合起來，通過軟件自動化判斷當前收到日志的嚴重性，根據(jù)故障的等級來執(zhí)行相應的動作，讓數(shù)據(jù)中心自動恢復運行。
最后，更多的設備僅僅靠日志分析，起不到什么效果，還需要通過流量分析工具，命令腳本工具來單獨收集一些數(shù)據(jù)中心運行信息，這些信息往往可以包含比日志還要豐富的信息，將這些信息與日志結合起來一起分析，才能達到更好的分析效果。日志僅是獲取數(shù)據(jù)中心運行情況的一個手段，但不是唯一的，需要通過多方面的信息，綜合分析，診斷數(shù)據(jù)中心的運行狀態(tài)。
日志的分析過程就是：收集—>甄別-->自動執(zhí)行動作，這樣的三個步驟，其實很多的數(shù)據(jù)中心都達不到這樣的要求，尤其是最后一部分，關鍵時候還是要靠人來執(zhí)行動作，而不是自動化軟件，數(shù)據(jù)中心軟件的發(fā)展遠沒有達到這樣高度自動化的水平，尤其是在數(shù)據(jù)中心這樣信息技術高度發(fā)達的地方，正是因為有這些不完善的地方，才促使數(shù)據(jù)中心技術在不斷地向前發(fā)展與進步。
京公網(wǎng)安備 11010502049343號