Java監視的當前狀態最大的問題是什么？

生產中的錯誤很像喝醉的短信。 您只有在事情已經發生之后才意識到出了點問題。 發短信日志通常比應用程序錯誤日志更有趣，但是……兩者都同樣難以修復。

在本文中，我們將執行一個12步的監視漏洞修復程序。 由Takipi用戶的經驗支持的思想實驗，解決了您可能會遇到的一些最常見問題–以及您可以如何處理。

來吧。

步驟＃1：承認我們有問題

實際上，這只是更高級別的應用程序可靠性問題。 為了能夠快速了解??應用程序何時出現問題，并能夠快速訪問所需的所有信息以進行修復。

當我們更進一步時，可靠性問題由監視和日志記錄的當前狀態下的許多其他癥狀組成。 這些是大多數人試圖掩埋或完全避免的棘手問題。 但是在這篇文章中，我們將它們放在了焦點。

底線：不可避免地要對生產中出現的新錯誤進行故障排除和處理。

步驟2：關閉監控信息過載

一個好的做法是收集有關應用程序的所有信息，但這僅在度量標準有意義時才有用。 如果日志記錄和度量標準遙測的可操作性只是事后的想法，則會產生更多的噪聲。 即使它們產生漂亮的儀表板。

其中很大一部分是將異常和記錄的錯誤濫用為應用程序控制流的一部分，從而以“正?！碑惓５你Ｕ摱氯巳罩?。 您可以在我們這里發布的最新電子書中了解有關此內容的更多信息。

隨著監視和數據保留成本的降低，問題開始轉移到收集可行的數據并使之有意義。

底線：盡管逐漸變得更容易記錄和報告所有內容，但錯誤根源發現仍然大部分是手動的，大海撈針越來越大，很難找到針頭。

步驟＃3：避免繁瑣的日志分析

假設我們有一些錯誤，一個特定的事務有時會失敗。 現在，我們必須在日志文件中找到有關它的所有相關信息。 是時候翻閱日志的方式了，或者使用諸如Splunk，ELK或其他日志 管理工具之類的可以使搜索更快的工具來處理不同的查詢。

為了使此過程更容易，使用Takipi的開發人員可以將每個記錄的錯誤，警告和異常的上下文擴展到導致它的源，狀態和變量狀態。 每條日志行都有一個鏈接附加到該鏈接，從而可以在Takipi中進行事件分析：

底線：手動篩選日志是一個繁瑣的過程，可以避免。

步驟4：認識到生產日志級別不夠詳細

原木水平是一把雙刃劍。 您登錄生產的級別越多，您擁有的上下文就越多。 但是，額外的日志記錄會產生開銷，最好在生產中避免。 有時，您需要的其他數據將出現在“ DEBUG”或“ INFO”消息中，但是生產應用程序通常僅寫入“ WARN”級消息或更高級別。

我們在Takipi中解決此問題的方法是使用最近發布的新功能，該功能使您能夠查看線程中導致錯誤的最后250條日志語句。 即使它們沒有在生產中寫入日志文件。

等一下 無日志記錄，無額外開銷。 由于日志語句是直接在內存中捕獲的，而不依賴于日志文件，因此我們能夠在生產中進行詳盡的描述，而不會影響日志大小或增加開銷。 您可以在這里閱讀有關它的更多信息，或者自己嘗試 。

底線：從今天開始，您不僅限于WARN或更高級別的生產日志記錄。

步驟＃5：下一個說“無法復制”的人買了一輪飲料

推遲錯誤修復的最常見借口是“無法復制”。 缺少導致它的狀態的錯誤。 不好的事情發生了，通常您首先會從實際用戶那里聽到它，并且無法重新創建它或在日志/收集的指標中找到證據。

從根本上講，“無法復制”的隱藏含義是正確的。 如果您習慣于第一次聽到用戶的錯誤消息，則內部跟蹤錯誤的方式可能有問題。 通過適當的監視，可以在實際用戶報告錯誤之前識別并解決錯誤。

底線：停止復制“無法復制”。

步驟＃6：打破日志語句重新部署周期

一種常見的臭名昭著且不幸的“無法復制”的解決方法是在生產中添加其他日志記錄語句，并希望該錯誤再次發生。

在生產中。

搞亂真實用戶。

那就是生產調試悖論。 發生錯誤時，您沒有足夠的數據來解決它（但您確實有很多雜音），添加了日志記錄語句，進行了構建，測試（首先錯過了該錯誤的同一測試），部署到生產環境，希望為使它再次發生，希望新數據足夠或…重復。

底線：成功的監視策略的最終目標是防止此周期的發生。

步驟＃7：APM +跟蹤器+指標+日志=可見性受限

讓我們提高一個等級。 我們已經介紹了日志和儀表板報告指標，現在是時候添加錯誤跟蹤工具 和 APM了。

事實是，即使監視堆棧包括所有4類的解決方案，您進入應用程序錯誤的可見性也受到限制。 您將看到事務的堆棧跟蹤，或者最多看到特定的預定義硬編碼變量。 傳統的監視堆棧在出現錯誤時無法查看應用程序的完整狀態。

底線：在當今的通用監視堆棧中，有一個關鍵的缺失組件。 生產調試具有可變級別的可見性。

步驟＃8：為分布式錯誤監控做準備

監視不會在單個服務器級別上停止，尤其是在微服務體系結構中，在一臺服務器上形成的錯誤可能在其他地方引起麻煩。

盡管微服務提倡“關注點分離”原則，但它們還在服務器級別上引入了許多新問題。 在上一篇文章中，我們討論了這些問題，并提供了可能的解決方案策略。

底線：任何監視解決方案都應考慮分布式錯誤，并能夠對來自多個源的數據進行故障排除。

步驟＃9：找到解決方法，以解決較長的故障排除周期

無論是警告問題還是僅是優先事項，對于大多數應用程序，在引入第一個錯誤之后，故障排除周期都需要數天，數周甚至數月的時間。 報告該錯誤的人可能無法訪問或更糟，由于數據保留策略，相關數據可能長期未保存/滾動。

在這種情況下，即使在錯誤時刻凍結應用程序狀態快照的能力（即使它來自多個服務/源）也至關重要，否則，重要數據可能會丟失。

底線：應避免較長的故障排除周期。

步驟＃10：確認開發人員與運營者的困境

跟上發布周期的問題，我們所有人都在同一條船上，但是，開發人員希望更快地發布功能，而運營則希望保持生產環境的穩定。

短的功能周期和長的故障排除周期根本不會在一起。 兩者之間應該保持平衡。 監視是一項團隊運動，并且工具必須知道如何相互交談。 例如，在Takipi，您可以獲得有關Slack，Pagerduty或Hipchat的警報，并直接打開JIRA憑單，其中包含所有可用的錯誤分析數據。

底線：協作工作流加快了問題解決的速度。

步驟＃11：有希望

現代開發人員工具正在采取重大措施來改善當前的監視狀態。 無論是在日志，應用程序性能管理領域還是在進行中的新類別。

底線：密切注意工具生態系統的發展以及其他公司的最佳實踐。

步驟＃12：宣傳

監視是軟件開發不可分割的一部分，讓我們繼續進行討論吧！

我們希望您對當前監視狀態的一些主要問題感到滿意/概述。 監控還有其他問題讓您徹夜難眠嗎？

請隨時在下面的評論部分中分享它們。

翻譯自: https://www.javacodegeeks.com/2016/08/12-step-program-realizing-java-monitoring-flawed.html

總結

以上是生活随笔為你收集整理的实现Java监视的12个步骤程序存在缺陷的全部內容，希望文章能夠幫你解決所遇到的問題。

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