建站
咨詢
售后
建站咨詢
新聞中心
要為日志記錄機(jī)制找到合適的“度”殊非易事——日志太多則無(wú)關(guān)內(nèi)容泛濫，日志太少則可能錯(cuò)過(guò)重要信息。這一問(wèn)題在微服務(wù)架構(gòu)下則變得更為棘手。
創(chuàng)新互聯(lián)公司2013年開創(chuàng)至今，先為桑珠孜等服務(wù)建站，桑珠孜等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為桑珠孜企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
日志難題
根據(jù)用戶們的反饋，其面對(duì)的兩大常見(jiàn)難題為：哪些組件需要進(jìn)行日志記錄，如何對(duì)需要收集的數(shù)據(jù)進(jìn)行優(yōu)先級(jí)排序。
大家可能或多或少接觸過(guò)某些復(fù)雜的系統(tǒng)，其中包含大量組件與分布式服務(wù)。對(duì)于每項(xiàng)組件，我們都需要考慮以下三個(gè)問(wèn)題：
- 其是否進(jìn)行日志記錄?
- 如果沒(méi)有，是否應(yīng)當(dāng)進(jìn)行記錄?
- 是否應(yīng)該利用Loggly等日志管理服務(wù)對(duì)其日志進(jìn)行集中管理?
當(dāng)然，日志作為解決問(wèn)題的重要參考，一般來(lái)說(shuō)自然是越多越好。不過(guò)收集及存儲(chǔ)日志數(shù)據(jù)都會(huì)帶來(lái)成本，因此今天我們將探討如何找到正確的日志記錄平衡點(diǎn)。
宏觀視角：DevOps眼中的日志記錄思維
DevOps中的一大重要原則就是讓開發(fā)與運(yùn)維人員站在同一陣營(yíng)。為了實(shí)現(xiàn)這一目標(biāo)，雙方需要以統(tǒng)一的角度了解堆棧中各組件的運(yùn)行情況。
就目前而言，客戶通常只保留那些關(guān)鍵性應(yīng)用的日志信息，也只有這部分信息會(huì)由Loggly等日志管理解決方案進(jìn)行操作。應(yīng)用是支撐業(yè)務(wù)的基礎(chǔ)，其負(fù)責(zé)為客戶提供所需，而技術(shù)人員則需要通過(guò)統(tǒng)計(jì)結(jié)果了解應(yīng)用代碼中所存在的主要問(wèn)題。
不過(guò)真正的難題在于，我們的應(yīng)用始于何處又終于何處?
Web服務(wù)器?沒(méi)錯(cuò)。應(yīng)用所使用的數(shù)據(jù)庫(kù)?差不多。不少用戶并沒(méi)有將數(shù)據(jù)庫(kù)日志納入集中管理范疇。那么操作系統(tǒng)、虛擬機(jī)管理程序、云基礎(chǔ)設(shè)施組件又 是否應(yīng)該得到重視?存儲(chǔ)后端呢?說(shuō)到這里，問(wèn)題變得愈發(fā)復(fù)雜。負(fù)載均衡、路由器與交換機(jī)?很多朋友認(rèn)為，越是接近底層的元素，越不需要進(jìn)行日志數(shù)據(jù)的集中 化收集與管理。
這些日志來(lái)源被排除在外的理由主要有兩點(diǎn)：
- 這些組件通常比較可靠。
- 其通常擁有自己的日志監(jiān)控解決方案。
有鑒于此，大家往往不會(huì)將此類日志數(shù)據(jù)納入集中日志管理方案。某些用戶甚至將其視為“信噪”。他們更傾向于監(jiān)控應(yīng)用日志，并通過(guò)路由器Web前端或者AWS CloudWatch來(lái)了解路由器或AWS Linux實(shí)例的運(yùn)行狀態(tài)。
這類做法的問(wèn)題在于其本質(zhì)上在強(qiáng)調(diào)并且使用“日志孤島”，這意味著我們無(wú)法以集中化的方式，確保包括開發(fā)與運(yùn)維在內(nèi)的每一位技術(shù)人員獲取到綜合性應(yīng) 用運(yùn)行狀態(tài)。另外，假如這些底層組件對(duì)于業(yè)務(wù)極為重要，那么一旦遭遇極為罕見(jiàn)的組件缺陷或者是精心偽裝的惡意軟件入侵，后果會(huì)如何?雖說(shuō)這種機(jī)率確實(shí)很 低，但其造成的后果難以承受。因此大家應(yīng)當(dāng)將其視為一種火災(zāi)保險(xiǎn)式的預(yù)備手段——即使家中從未失火，我們也不妨買上一份。
日志數(shù)據(jù)在DevOps流程中的定位
由于日志數(shù)據(jù)屬于涵蓋每種組件及每個(gè)層的普遍性元素，因此以集中方式進(jìn)行日志數(shù)據(jù)管理能夠：
- 加快故障排查速度并及時(shí)通知相關(guān)度最高的人員。
- 立足于堆棧內(nèi)各層監(jiān)控問(wèn)題。監(jiān)控工具多種多樣，但相當(dāng)一部分會(huì)迫使用戶以互不關(guān)聯(lián)的方式審視獨(dú)立組件。
- 實(shí)現(xiàn)代碼持續(xù)部署。日志管理應(yīng)當(dāng)作為持續(xù)集成測(cè)試周期的組成部分。測(cè)試環(huán)境越全面，需要進(jìn)行日志記錄的組件就越多。
將這些分析結(jié)論有效傳遞給每位相關(guān)成員，能夠切實(shí)推動(dòng)DevOps思維的接納度與普及。
干擾數(shù)據(jù)該如何處理?
日志來(lái)源的增加無(wú)疑會(huì)令日志數(shù)據(jù)中出現(xiàn)更多干擾信息，即使沒(méi)那么嚴(yán)重，我們的日常工作強(qiáng)度也會(huì)因此增加。而且必須承認(rèn)，某些日志數(shù)據(jù)在通常情況下幾乎用不到。
在使用現(xiàn)代日志管理解決方案時(shí)，干擾數(shù)據(jù)的存在確實(shí)令人非常頭痛。我們可以利用多種方式進(jìn)行日志過(guò)濾，通過(guò)儀表板監(jiān)控相關(guān)指標(biāo)，保存所關(guān)注信息子集的搜索與過(guò)濾機(jī)制等等。
如果繼續(xù)沿用之前提到的火災(zāi)比喻，那么“干擾數(shù)據(jù)太多”就有點(diǎn)像買來(lái)一套實(shí)際容量只有20%的滅火器。之所以這樣選擇，是因?yàn)樗p便也更便宜，對(duì)應(yīng)小規(guī)模起火也綽綽有余。
集中化日志記錄是否矯枉過(guò)正?
答案是否定的。簡(jiǎn)而言之，我們不需要記錄一切，但我們所記錄的一切都應(yīng)當(dāng)以集中方式得到收集與管理。
性能問(wèn)題?其實(shí)是潤(rùn)滑問(wèn)題
一家企業(yè)客戶曾經(jīng)遭遇到性能問(wèn)題——作為網(wǎng)絡(luò)游戲運(yùn)營(yíng)商，其面對(duì)著高強(qiáng)度后端數(shù)據(jù)庫(kù)與存儲(chǔ)I/O資源需求。當(dāng)問(wèn)題出現(xiàn)后，玩家們?cè)谏缃幻襟w上大加抱 怨并紛紛離去。而通過(guò)日志檢查，技術(shù)人員們初步斷定數(shù)據(jù)庫(kù)正是造成問(wèn)題的罪魁禍?zhǔn)?。在進(jìn)一步檢查數(shù)據(jù)庫(kù)相關(guān)存儲(chǔ)機(jī)制時(shí)，大家發(fā)現(xiàn)這些RAID系統(tǒng)的日志并 未進(jìn)行集中化管理，而且出現(xiàn)問(wèn)題時(shí)其監(jiān)控工具仍然顯示一切正常。
但就在調(diào)查進(jìn)行時(shí)，RAID監(jiān)控系統(tǒng)又突然發(fā)出警報(bào)：大量磁盤出現(xiàn)故障，RAID已經(jīng)無(wú)法對(duì)其加以恢復(fù)。面對(duì)這樣的狀況，技術(shù)人員根本弄不清楚這是隨機(jī)事件還是蓄意攻擊的結(jié)果。整個(gè)恢復(fù)周期持續(xù)了100多個(gè)小時(shí)，無(wú)疑也給企業(yè)造成了嚴(yán)重?fù)p失。
最終取證工程師對(duì)Linux操作系統(tǒng)的內(nèi)核日志進(jìn)行了查閱，并發(fā)現(xiàn)此類故障自數(shù)個(gè)月之前就開始發(fā)生，并一直在緩慢地不斷增長(zhǎng)。遺憾的是，存儲(chǔ)系統(tǒng)本身的監(jiān)控工具并沒(méi)能正確發(fā)現(xiàn)并報(bào)告這些問(wèn)題，因?yàn)槠湔J(rèn)為實(shí)際情況尚未達(dá)到斷定磁盤或陣列遭受威脅的預(yù)設(shè)閾值。
內(nèi)核日志也顯示只有特定品牌及型號(hào)的磁盤受到了影響。制造商在檢查后發(fā)現(xiàn)某些批次的特定型號(hào)磁盤存在質(zhì)量問(wèn)題，其磁盤主軸軸承潤(rùn)滑劑存在蒸發(fā)現(xiàn)象，而該客戶正是少數(shù)受到影響的受害者。
諷刺的是，這一切都早已被記錄在日志當(dāng)中，但卻由于缺少集中化日志管理機(jī)制而被人們忽略。
雖然沒(méi)有明確的統(tǒng)計(jì)數(shù)據(jù)作為支持，但相信行業(yè)中因?yàn)槿鄙倏煽咳罩緮?shù)據(jù)分析系統(tǒng)而導(dǎo)致的負(fù)面影響絕對(duì)不在少數(shù)。因此，以看待保險(xiǎn)產(chǎn)品的方式積極采用集中化日志管理方案應(yīng)當(dāng)成為企業(yè)運(yùn)營(yíng)中的常態(tài)與共識(shí)。
原文：Which Components of Your System Should You Log?
【.com獨(dú)家譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明來(lái)源】
文章題目：到底哪些系統(tǒng)組件應(yīng)該進(jìn)行日志記錄?
網(wǎng)頁(yè)URL：http://m.5511xx.com/article/djdocoh.html
