數據中心的日志主要來自三個方面：一是設備層，對數據中心內的各種設備進行監控，如：交換機、路由器、安全設備、服務器、UPS、精密空調等，實現物理層實時監控和數據采集;二是系統層，對數據中心主機(Linux主機和x86服務器)、操作系統 (Linux/Winwdos)、數據庫(Oracle、Mysql等主流)、中間件、存儲系統、應用軟件API、HTTP端口、備份系統、容災系統、數據同步系統、虛擬化系統，云平臺等進行實時監控、預警分析和故障定位;三是業務層，采集一定的業務數據，如用戶數、連接數、業務并發量、日志量等等，通過多維關聯和分析，對未來的業務運行進行分析和預測。這些日志有些是設備運行中主動輸出的，有些則是運維的人員通過特定命令到設備上采集到的，通過對這些日志進行分析，從而對設備、系統以及業務的運行情況進行評估，一旦發現異常，立即采取處理。
顯然，海量的日志如不經過處理，直接輸出到監控平臺，那將是非常多的。
首先，做標準化處理。數據中心要有各種日志的采集系統，將所有日志匯集起來，這些日志來自不同設備、不同系統、不同業務，格式和含義都不一樣，數據中心要做標準化處理，轉換成統一識別的格式，這個格式完全由數據中心定義，由技術人員進行轉義，形成標準化的日志語言;
第二，做日志過濾。日志經過標準化處理，整齊劃一，格式統一，但數量仍沒有減少，所以需要做過濾。過濾的原則是將級別低的、操作類的、提示類的日志過濾掉，將級別高的、異常類的日志留下來。具體到各種設備的日志，要由設備商提供全系列的日志信息，并標注優先級和表達的含義，由數據中心將這些信息輸入到知識庫中，作為過濾判斷的條件，知識庫是一個逐漸積累的過程，不僅是日志的過濾，還包括各種故障的處理方法、經典案例、解決方案等等，經過知識庫的過濾，將大部分的無用日志排除掉;
第三，做壓縮歸并，將過濾后的日志同類的要歸一化，尤其是在知識庫中已經存在過的，這類日志如何處理，在知識庫中可以找到答案，這時可以直接按照知識庫的指導來做。如果沒有遇到過的日志，則要交給下一級繼續處理，通過壓縮歸并也可以將日志的數量再次減少;
第四，做關聯分析，很多日志的來由都是有根源的，比如在一臺運行中的網絡設備上突然有一條OSPF鏈路震蕩了，那么可以檢查一下在同一時間，是否也有其它OSPF鄰居也震蕩了，如經過日志檢查，在另外多臺設備上也有OSPF震蕩，并且都集中連接到一臺設備，而這臺設備再查日志原來有人正在做reset ospf主動運維的操作，當通過這系列的關聯分析，就可以找到原因，及時將這種人為操作的原因告訴監控中心，并不會作為一種異常的故障告警出現;
第五，做定位分析。將預期內產生的日志消除后，來到第五步，這時的日志往往需要深入分析，如果在現有的知識庫里找不到解決方案，并且日志本身的告警級別還很高，這時就要輸出告警了，經過這五步處理，能夠輸出告警的日志已經很少了。
日志經過以上五個步驟處理，能夠精簡多少，這取決于現有的知識庫，知識庫內容越豐富，信息越準確，精簡下來的日志就越少。試想哪個數據中心會天天發生故障，一個月發生一次都了不得，否則早就關門大吉了，所以數據中心里每天產生的日志很多很多，而絕大部分的日志都影響不大，甚至無影響。當然，這種日志過濾也不排除將一些關鍵日志過濾掉了，導致出了問題，卻沒有告警，這是一個逐步完善的過程。現在AI技術這么火，也火到了數據中心運維領域，其實就是利用AI技術，對數據中心的知識庫進行學習，以便可以對新增的日志進行準確判斷，這個過程靠人工完成效率太低了，而利用機器學習，則可以瞬間完成，這也是智能運維研究的一個重要方向，通過AI處理數據中心的海量日志。
數據中心如何面對日志海洋?歸納起來就三個字：“簡、智、深”，精簡日志數量，過濾無用或無害日志;利用現有知識庫學習，智能分析日志產生的影響和后果;深度學習日志，輸出學習結果，根據日志做出判斷和自決，數據中心系統自動執行解決方案：切流量或者隔離故障設備，也可能是調整配置等等，自動進行處理，這種情況只要將處理結果反饋到監控平臺即可，甚至都可以不用給出日志告警，作為普通事件處理。只有AI不知如何處理時，再將告警日志交給監控平臺，由人工干預，處理完畢后再將本次的日志處理交給AI學習，同類日志再次出現時，系統就可以自行處理，不再需要人工干預，構建這樣一個學習日志系統，就是智能運維的開始。
