利用應用的日志文件診斷問(wèn)題并防止問(wèn)題出現。落實(shí)監控日志文件的流程，強制人們對發(fā)現的問(wèn)題采取措施。利用各種監控工具，如定制的腳本或者Splunk，觀(guān)察應用的日志，找出錯誤。導出這些錯誤，指派人員識別并解決相關(guān)的問(wèn)題。

日志文件是很好的信息源，可以了解應用是如何執行的。不要對它置之不理。好好利用日志文件，可以減少系統的生產(chǎn)問(wèn)題。



本著(zhù)要用正確的工具完成工作的精神，讓我們來(lái)看看可能每個(gè)人都有但卻常常被忽略的工具一日志文件。除非你故意關(guān)閉了Web或應用服務(wù)器的記錄日志功能，否則幾乎各種應用都有錯誤和訪(fǎng)問(wèn)日志。 Apache有錯誤和訪(fǎng)問(wèn)日志，Tomcat有java.util.logging或Log4j，Webshpere有Systremerr和Systemout日志。這些日志是非常有用的工具，可以讓我們了解應用的性能和可能會(huì )妨礙擴展的問(wèn)題。要最合理利用這種工具，需要遵守下面幾個(gè)簡(jiǎn)單但重要的步驟。

使用日志文件的第一步是把它們集合起來(lái)。因為你可能有幾十甚至幾百臺服務(wù)器，那么需要把數據集合起來(lái)才能使用。如果數據量太大，無(wú)法集合起來(lái)，那么可以采樣，如每N個(gè)服務(wù)器采集一次。另一種策略是把幾臺服務(wù)器的日志集合到一臺日志服務(wù)器上，然后由這臺服務(wù)器把這些半集合的日志傳遞到最終集合地點(diǎn)。專(zhuān)用的日志服務(wù)器可以把日志數據集合起來(lái)，然后發(fā)送到數據存儲設備上。這種集合操作通常是經(jīng)過(guò)帶外網(wǎng)絡(luò )執行的，與生產(chǎn)環(huán)境使用的不是同一個(gè)網(wǎng)絡(luò )。要避免日志數據、監控數據或集合數據影響生產(chǎn)環(huán)境的流量。
 
下一步是監控這些日志。令人吃驚的是，許多客戶(hù)花費了時(shí)間和計算資源記錄和集合日志，但是卻忽略了其中的數據。雖然你會(huì )使用發(fā)生事故時(shí)的日志文件幫助恢復服務(wù)，但這沒(méi)有最大化利用日志。首先可以采用的方式是利用自動(dòng)化工具監控這些日志文件?？梢允褂枚ㄖ频哪_本進(jìn)行監控，如一個(gè)shel腳本，可以按給定模式搜索文件內容，累計錯誤數量，當超過(guò)閾值時(shí)進(jìn)行修改。更復雜的工具，像Cricket或 Cacti，具有繪制圖形的能力。同時(shí)具有集合和監控日志文件功能的工具是Splunk在集合了日志并監控錯誤后，最后一步是修正問(wèn)題。這需要分配程序員和QA人員，識別與個(gè)別問(wèn)題相關(guān)的一般錯誤。通常，應用程序流中的一個(gè)bug會(huì )造成形式各異的錯誤。發(fā)現這個(gè)bug的程序員很可能會(huì )被指派為修正它的人，也可能會(huì )把這個(gè)任務(wù)分配給其他程序員。

雖然我們希望日志文件中完全沒(méi)有錯誤，但是不可能一直這樣。日志文件中的錯誤很常見(jiàn)，需要建立一個(gè)流程，確保它們不會(huì )失控或被忽略了。有些小組會(huì )定期(每發(fā)布三個(gè)版本或四個(gè)版本)清理那些不需要立即處理的錯誤。這些錯誤很簡(jiǎn)單，可能是應用中沒(méi)有重定向配置，或者沒(méi)有處理已知錯誤的條件等。

必須記住，記錄日志也是有成本的。不僅有保存額外數據的成本，還有事務(wù)響應時(shí)間的成本。通過(guò)不時(shí)地總結日志、歸檔、在日志價(jià)值下降時(shí)清除它，有助于減少保存數據的成本?？梢酝ㄟ^(guò)異步模式記錄日志，從而最小化存儲日志的成本。最終，我們要注意記錄日志的成本，關(guān)于記錄多少數據以及保留多少數據，需要作出高性?xún)r(jià)比的決策。

希望我們說(shuō)服了你，讓你相信在網(wǎng)站建設調試和監控應用時(shí)日志文件是個(gè)重要的工具。利用這么一個(gè)你很可能已經(jīng)有的工具，能夠幫助你極大地增強客戶(hù)體驗和應用的可擴展性。