java實現(xiàn)資源監(jiān)視器

Java監(jiān)視的當前狀態(tài)最大的問題是什么？

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

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

來吧。

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

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

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

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

步驟2：關閉監(jiān)控信息過載

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

其中很大一部分是將異常和已記錄的錯誤濫用為應用程序控制流的一部分，從而以“正常”異常的悖論堵塞了日志。 您可以在最近的電子書，我們發(fā)布了關于此這里 。

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

底線：盡管逐漸變得更容易記錄和報告所有內容，但錯誤根本原因的發(fā)現(xiàn)仍然主要是手動的，大海撈針變得更大，更難找到針頭。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在生產中。

搞亂真實用戶。

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

底線：成功的監(jiān)視策略的最終目標是防止此周期的發(fā)生。

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

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

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

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

步驟＃8：為分布式錯誤監(jiān)控做準備

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

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

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

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

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

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

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

步驟＃10：確認開發(fā)人員與運營商的困境

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

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

底線：協(xié)作工作流程加快了問題解決的速度。

步驟＃11：有希望

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

底線：密切注意工具生態(tài)系統(tǒng)的發(fā)展以及其他公司的最佳實踐。

步驟＃12：宣傳

監(jiān)視是軟件開發(fā)中不可分割的一部分，讓我們繼續(xù)進行討論吧！

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

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

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

java實現(xiàn)資源監(jiān)視器

總結

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

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