【51CTO.com快譯】要為日志記錄機(jī)制找到合適的“度”殊非易事——日志太多則無關(guān)內(nèi)容泛濫，日志太少則可能錯過重要信息。這一問題在微服務(wù)架構(gòu)下則變得更為棘手。

日志難題

根據(jù)用戶們的反饋，其面對的兩大常見難題為：哪些組件需要進(jìn)行日志記錄，如何對需要收集的數(shù)據(jù)進(jìn)行優(yōu)先級排序。

大家可能或多或少接觸過某些復(fù)雜的系統(tǒng)，其中包含大量組件與分布式服務(wù)。對于每項組件，我們都需要考慮以下三個問題：

• 其是否進(jìn)行日志記錄?
• 如果沒有，是否應(yīng)當(dāng)進(jìn)行記錄?
• 是否應(yīng)該利用Loggly等日志管理服務(wù)對其日志進(jìn)行集中管理?

當(dāng)然，日志作為解決問題的重要參考，一般來說自然是越多越好。不過收集及存儲日志數(shù)據(jù)都會帶來成本，因此今天我們將探討如何找到正確的日志記錄平衡點(diǎn)。

宏觀視角：DevOps眼中的日志記錄思維

DevOps中的一大重要原則就是讓開發(fā)與運(yùn)維人員站在同一陣營。為了實(shí)現(xiàn)這一目標(biāo)，雙方需要以統(tǒng)一的角度了解堆棧中各組件的運(yùn)行情況。

就目前而言，客戶通常只保留那些關(guān)鍵性應(yīng)用的日志信息，也只有這部分信息會由Loggly等日志管理解決方案進(jìn)行操作。應(yīng)用是支撐業(yè)務(wù)的基礎(chǔ)，其負(fù)責(zé)為客戶提供所需，而技術(shù)人員則需要通過統(tǒng)計結(jié)果了解應(yīng)用代碼中所存在的主要問題。

不過真正的難題在于，我們的應(yīng)用始于何處又終于何處?

Web服務(wù)器?沒錯。應(yīng)用所使用的數(shù)據(jù)庫?差不多。不少用戶并沒有將數(shù)據(jù)庫日志納入集中管理范疇。那么操作系統(tǒng)、虛擬機(jī)管理程序、云基礎(chǔ)設(shè)施組件又 是否應(yīng)該得到重視?存儲后端呢?說到這里，問題變得愈發(fā)復(fù)雜。負(fù)載均衡、路由器與交換機(jī)?很多朋友認(rèn)為，越是接近底層的元素，越不需要進(jìn)行日志數(shù)據(jù)的集中 化收集與管理。

這些日志來源被排除在外的理由主要有兩點(diǎn)：

• 這些組件通常比較可靠。
• 其通常擁有自己的日志監(jiān)控解決方案。

有鑒于此，大家往往不會將此類日志數(shù)據(jù)納入集中日志管理方案。某些用戶甚至將其視為“信噪”。他們更傾向于監(jiān)控應(yīng)用日志，并通過路由器Web前端或者AWS CloudWatch來了解路由器或AWS Linux實(shí)例的運(yùn)行狀態(tài)。

這類做法的問題在于其本質(zhì)上在強(qiáng)調(diào)并且使用“日志孤島”，這意味著我們無法以集中化的方式，確保包括開發(fā)與運(yùn)維在內(nèi)的每一位技術(shù)人員獲取到綜合性應(yīng) 用運(yùn)行狀態(tài)。另外，假如這些底層組件對于業(yè)務(wù)極為重要，那么一旦遭遇極為罕見的組件缺陷或者是精心偽裝的惡意軟件入侵，后果會如何?雖說這種機(jī)率確實(shí)很 低，但其造成的后果難以承受。因此大家應(yīng)當(dāng)將其視為一種火災(zāi)保險式的預(yù)備手段——即使家中從未失火，我們也不妨買上一份。

日志數(shù)據(jù)在DevOps流程中的定位

由于日志數(shù)據(jù)屬于涵蓋每種組件及每個層的普遍性元素，因此以集中方式進(jìn)行日志數(shù)據(jù)管理能夠：

• 加快故障排查速度并及時通知相關(guān)度最高的人員。
• 立足于堆棧內(nèi)各層監(jiān)控問題。監(jiān)控工具多種多樣，但相當(dāng)一部分會迫使用戶以互不關(guān)聯(lián)的方式審視獨(dú)立組件。
• 實(shí)現(xiàn)代碼持續(xù)部署。日志管理應(yīng)當(dāng)作為持續(xù)集成測試周期的組成部分。測試環(huán)境越全面，需要進(jìn)行日志記錄的組件就越多。

將這些分析結(jié)論有效傳遞給每位相關(guān)成員，能夠切實(shí)推動DevOps思維的接納度與普及。

干擾數(shù)據(jù)該如何處理?

日志來源的增加無疑會令日志數(shù)據(jù)中出現(xiàn)更多干擾信息，即使沒那么嚴(yán)重，我們的日常工作強(qiáng)度也會因此增加。而且必須承認(rèn)，某些日志數(shù)據(jù)在通常情況下幾乎用不到。

在使用現(xiàn)代日志管理解決方案時，干擾數(shù)據(jù)的存在確實(shí)令人非常頭痛。我們可以利用多種方式進(jìn)行日志過濾，通過儀表板監(jiān)控相關(guān)指標(biāo)，保存所關(guān)注信息子集的搜索與過濾機(jī)制等等。

如果繼續(xù)沿用之前提到的火災(zāi)比喻，那么“干擾數(shù)據(jù)太多”就有點(diǎn)像買來一套實(shí)際容量只有20%的滅火器。之所以這樣選擇，是因?yàn)樗p便也更便宜，對應(yīng)小規(guī)模起火也綽綽有余。

集中化日志記錄是否矯枉過正?

答案是否定的。簡而言之，我們不需要記錄一切，但我們所記錄的一切都應(yīng)當(dāng)以集中方式得到收集與管理。

性能問題?其實(shí)是潤滑問題

一家企業(yè)客戶曾經(jīng)遭遇到性能問題——作為網(wǎng)絡(luò)游戲運(yùn)營商，其面對著高強(qiáng)度后端數(shù)據(jù)庫與存儲I/O資源需求。當(dāng)問題出現(xiàn)后，玩家們在社交媒體上大加抱 怨并紛紛離去。而通過日志檢查，技術(shù)人員們初步斷定數(shù)據(jù)庫正是造成問題的罪魁禍?zhǔn)?。在進(jìn)一步檢查數(shù)據(jù)庫相關(guān)存儲機(jī)制時，大家發(fā)現(xiàn)這些RAID系統(tǒng)的日志并 未進(jìn)行集中化管理，而且出現(xiàn)問題時其監(jiān)控工具仍然顯示一切正常。

但就在調(diào)查進(jìn)行時，RAID監(jiān)控系統(tǒng)又突然發(fā)出警報：大量磁盤出現(xiàn)故障，RAID已經(jīng)無法對其加以恢復(fù)。面對這樣的狀況，技術(shù)人員根本弄不清楚這是隨機(jī)事件還是蓄意攻擊的結(jié)果。整個恢復(fù)周期持續(xù)了100多個小時，無疑也給企業(yè)造成了嚴(yán)重?fù)p失。

最終取證工程師對Linux操作系統(tǒng)的內(nèi)核日志進(jìn)行了查閱，并發(fā)現(xiàn)此類故障自數(shù)個月之前就開始發(fā)生，并一直在緩慢地不斷增長。遺憾的是，存儲系統(tǒng)本身的監(jiān)控工具并沒能正確發(fā)現(xiàn)并報告這些問題，因?yàn)槠湔J(rèn)為實(shí)際情況尚未達(dá)到斷定磁盤或陣列遭受威脅的預(yù)設(shè)閾值。

內(nèi)核日志也顯示只有特定品牌及型號的磁盤受到了影響。制造商在檢查后發(fā)現(xiàn)某些批次的特定型號磁盤存在質(zhì)量問題，其磁盤主軸軸承潤滑劑存在蒸發(fā)現(xiàn)象，而該客戶正是少數(shù)受到影響的受害者。

諷刺的是，這一切都早已被記錄在日志當(dāng)中，但卻由于缺少集中化日志管理機(jī)制而被人們忽略。

雖然沒有明確的統(tǒng)計數(shù)據(jù)作為支持，但相信行業(yè)中因?yàn)槿鄙倏煽咳罩緮?shù)據(jù)分析系統(tǒng)而導(dǎo)致的負(fù)面影響絕對不在少數(shù)。因此，以看待保險產(chǎn)品的方式積極采用集中化日志管理方案應(yīng)當(dāng)成為企業(yè)運(yùn)營中的常態(tài)與共識。

原文：Which Components of Your System Should You Log?

【51CTO.com獨(dú)家譯稿，合作站點(diǎn)轉(zhuǎn)載請注明來源】