幾周前，一位同事要求我花一個星期的時間做后援，因為他需要一個掩護，而他度過了一個賺錢的假期，而他找不到其他人。 當我剛完成一個特別復雜的編碼項目并感到有些疲倦時，我說“是”。 畢竟，改變對我有好處。

工作的一部分包括監視一組相當關鍵的支持流程，以查看它們的執行情況以及它們是否出錯。

我們的開發人員花費大量時間和精力在我們的應用程序中添加日志記錄，以證明它可以正常工作并找出發生異常時出了什么問題。 這些日志文件通常用于告訴我們我們的應用程序每天的運行狀況有多好。

我忽略了其他技術，例如通過選擇的任何方法（例如HTTP或JMX）向應用程序添加探針。 這些提供有關您的應用程序的即時信息，而不是此處討論的第二級監視。

至少有三種監視日志文件的方式：

• 決不
• 積極地
• 主動地

“從不”表示它的意思。 我敢打賭，有些應用程序會上線，似乎永遠不會失敗，也不會被檢查。

“反應式”策略非常普遍； Doncaster的Smith夫人打電話給她，抱怨說她試圖買一雙新鞋時網站崩潰了。 她被起訴了兩次，從未收到任何鞋子。 在這個傳統的公司中，DEV和OPS的角色完全分開，研究問題的開發人員要求OPS記錄事件發生的時間和日期。 當然，開發人員會獲取日志中完全不相關的部分，并且不得不重新請求正確的部分-幾次。 到那時，已經過去了幾個星期，史密斯太太很生氣。 日志最終到達，問題得以解決。

在這種“反應性”場景中，我假設當開發人員在沒有信任或允許接觸實時服務器的情況下，這就是那些公司之一。 這太普遍了，我們大多數人都會去過那里。 開發人員應該可以使用實時系統。 但是，作為開發人員，您應該記住在處理實時系統時有兩個黃金法則：

不要破壞任何東西。

如果您確實弄壞了東西，請確保您還有其他責任。

“主動”是指定期檢查日志文件：每天，每小時或任何時間。 即使您的應用程序包含大量的JMX，http或其他探針，也無法保證它們會發現問題。 探測只能探測您告訴他們要探測的內容，其他任何問題都無法解決。

回到我的支持上來……是出于某種（可能是歷史原因）的原因，此監視的大部分內容包括使用一組記錄的“ grep”命令通過一些剪切和粘貼手動檢查日志文件中的錯誤。 如果您將花費的時間加在重復的剪切和粘貼工作上，那么我可以確認，它每周大約消耗?人日。

這讓我開始思考……我真的不喜歡做這種任務。 我不太擅長，它是手動的，容易出錯，重復并且很無聊。 每周要花費?個工作日來完成這項任務，顯然會節省成本，只要不花時間在使他的解決方案完美無缺上。 那么，有哪些選擇呢？

如果您從專業的角度來看，那么Splunk就是可以監視來自多種來源（例如syslog守護程序）的消息的工具。

這意味著向Splunk發送錯誤的一種簡單方法是簡單地設置Log4j syslog附加程序，但這超出了本博客的范圍……

在快速而骯臟的范圍內，您可以非常Swift地編寫一個shell腳本來執行一些“ grep”命令，將結果寫入文件并將其郵寄到您的Unix郵箱。

然后我想到了中間立場。 編寫一個包含盡可能多的通用可重用類的Spring應用程序有多困難，它會定期運行以檢查大量錯誤日志并通過電子郵件將結果發送給您。 對于這種事情，電子郵件是件好事，因為您通常出于習慣閱讀它們。

入門

在任何這樣的項目中，都有一些無形的第一步可以推動整個過程。 它們構成了對您需要編寫哪些類才能發布此“東西”的問題的答案？ 有很多方法可以確定需要編寫哪些類，例如，使用UML，快速原型設計或測試驅動設計之類的正式設計技術，憑空挑選它們（膽怯）。 在每種情況下，您真正??要做的就是提出一些要求，從中彈出某些類的名稱。 例如，在這種情況下，我需要：

搜索給定目錄及其子目錄（可能）以查找特定類型的文件。

如果找到文件，請檢查其日期：是否需要搜索文件以查找錯誤？

如果文件足夠年輕以至于無法檢查，則對其進行驗證，以查找異常。

如果它包含例外，是我們正在尋找的例外還是被排除在外？

如果它包含我們所需要的例外類型，則將詳細信息添加到報告中。

檢查完所有文件后，格式化報告以準備發布。

使用電子郵件或其他技術發布報告。

整個過程每天都會在給定的時間運行

這拋出了幾個類的名稱。 我需要一個FileLocator ， FileValidator ， RegexValidator ， FileAgeValidator和一個Report 。

鑒于以上列表中多次出現“ Validator”一詞，這表明我可以使用一個接口（大概稱為Validator并創建多個實現來執行上述驗證任務。 然后可以將這些實現組合在一起以創建一個一致的應用程序。

請注意，這只是想法的初步列表。 如果看一下代碼，將找不到名為Report的類，將其重命名為Results并進行重構以創建Formatter接口， TextFormatter和HtmlFormatter類以及Publisher接口和EmailPublisher類。

就定期運行此功能而言，有兩種選擇。 首先，您可以將Java代碼與一個簡單的腳本一起編寫以調用它，并將其提供給Unix機器crontab。 沒關系，但這意味著該應用程序無法在Windows上運行，并且只能作為獨立應用程序運行。 這可能是一件大事，所以可以選擇使用Spring和Quartz時間表。 使制定Cron時間表相當簡單。

至于報告的電子郵件發送； 再次，Spring提供了一個非常好的電子郵件模板，可以簡化Java電子郵件類的使用。

好的，這就是起點：一組模糊的類想法可以以某種松散耦合的方式鏈接在一起以創建我們的應用程序。 如果您走了一條正式路線，那么您可能想花時間記錄所有這些內容，甚至可能制作一個類圖，然后將其添加到Word文檔中，并進行多次審查，直到一切都定下來。 但是，我不必為此煩惱……

配置應用程序

與任何應用程序一樣，需要弄清楚我們將如何設置通常是整個屬性值的數組以及應用程序如何使用它們。 該應用程序通常由src/main/resources目錄中的app.properties文件驅動。

# The path to the log file directory to scan for errors scan.in=/Library/Tomcat/logs # A regex defining what to look for - or what not to include scan.for=^.*Exception.* exclude=^.*IllegalStateException.* # The number of following lines to add to the report following.lines=10 # Where to email the report email.to=info@captaindebug.com # The max age of a file in days max.days=1000

我們感興趣的第一個屬性是scan.in屬性。 這是我們Web服務器日志目錄的位置，用作下一節概述的FileLocator類的起點。

搜索文件

在編寫FileLocator我超出了要求，并有意進行了一些“鍍金” 。

鍍金確實是個壞主意。 您應該只編寫足以滿足功能要求的代碼，即可以完成工作。 在這種情況下，作為一個博客……我的博客，我可以說它符合記錄我以前使用過多次的技術的非功能性要求，以此來證明它是合理的。

以下代碼不僅在指定的日志文件目錄中搜索日志文件，還搜索所有/任何子目錄。

@Service public class FileLocator { private static final Logger logger = LoggerFactory.getLogger(FileLocator.class); @Value("${scan.in}") private String scanIn; @Autowired @Qualifier("fileValidator") private Validator validator; /** Search for the files requested */ public void findFile() { logger.info("Searching in... {}", scanIn); File file = createFile(scanIn); search(file); } @VisibleForTesting File createFile(String name) { return new File(name); } private void search(File file) { if (file.isDirectory()) { logger.debug("Searching directory: {}", file.getName()); File[] files = file.listFiles(); searchFiles(files); } else { logger.debug("Validating file: {}", file.getName()); validator.validate(file); } } private void searchFiles(File[] files) { for (File file : files) { search(file); } } }

上面的代碼使用了古老的遞歸技術來搜索日志文件。 主要入口是findFile() 。 它通過Spring @Value注釋的scanIn實例變量創建一個File對象，并將其傳遞給search()方法。 然后，它檢查此對象是否為目錄，如果是，它將獲取目錄中的所有文件，并循環調用列表中每個File對象的search() 。 如果目錄檢查顯示File對象是文件，則調用文件驗證。

到目前為止，到目前為止，使用應用程序的第一類，我們現在可以搜索日志文件目錄； 但是，如果您想知道找到文件后會發生什么，則必須等到下一個博客發布為止。

最后一個想法：您是否需要調查系統中的每個錯誤？ 有一句古老的哲學名言：如果一棵樹在森林中倒下而沒有人聽到，它還能發出聲音嗎？ 同樣，如果您的應用程序引發異常并且用戶不受影響，那么它仍然是錯誤嗎？ 您需要花費時間進行調查嗎？ 讓我知道你的想法？

• 該博客的代碼可在Github上找到： https : //github.com/roghughe/captaindebug/tree/master/error-track 。

參考： Captain Debug的Blog博客上的JCG合作伙伴 Roger Hughes 使用Spring跟蹤了應用程序異常 。

翻譯自: https://www.javacodegeeks.com/2014/03/tracking-application-exceptions-with-spring.html

總結

以上是生活随笔為你收集整理的使用Spring跟踪应用程序异常的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。