摘要：可行工具圖為上監控到的應用程序響應時間和吞吐量平均負載第二個廣泛使用的衡量指標就是服務器的平均負載。率和中止時間垃圾回收器行為異常，是導致應用吞吐量和響應時間突然下降的主要原因之一。

在某個重大發布之后，都需要記錄相應的指標，本文介紹了最重要的幾個 Java 性能指標，包括響應時間和平均負載等。為理解應用程序在生產環境中如何運行，就需要遵循一些 Java 性能指標。

在以前，當軟件被發布后，開發者是沒有方法去了解它在生產環境中的運行情況；而現在，幾乎任一個你可以想到的指標都可以被監測和報告。時下，開發者面臨的問題并不是缺乏信息，而是信息過載、過大。因此在數百臺服務器同時工作的情景下，跟蹤記錄信息就變得越來越困難，雖然多數開發者為了深刻理解產品系統仍舊需要利用日志文件，但依然阻擋不了它們逐步被取代的命運。

本文整理了一些重要的指標，使開發者在不借助任何日志文件的情況下，便于理解應用程序在生產環境中運行的具體過程。談到對 Java 性能的影響，除了像用戶負載（或者 AWS 云服務器停機）這樣的外部因素，新功能發布可能是最常見的誘因。所以在那些新功能發布之后的敏感時段，遵循相應準則變得更為關鍵。

在逐個討論指標之前，先來強調一個重要問題。有這樣一個觀點：如果某個觀點可以得到數字支持，那么它一定是毋庸置疑的。但是這里存在的問題是，當給你呈現時，很多因素會歪曲你對數據的理解。這么說可能有點抽象，這里可以對比這兩個測量用例：首先，在一個簡單的時間序列中，觀察某一個特定基本指標如何隨著時間推移而變化；其次，從不同的角度觀察數據，并保存關注的性能百分比，底線就是一定要關心留意的那個指標所產生的影響，并給以完整性檢查以便對其評估。

例如，假設我們正在觀察中值/50百分點處的事務響應時間，因為該點的響應時間已被廣泛用作指示符，很多公司將其作為主要KPI之一。在實際中，若單個頁面瀏覽人數達到幾十及以上（一般遠遠超過40），就意味著該用戶有99.999...%的可能會經受比中值更差的結果（數學公式可簡單的表示為：1 –（0.5 ^ 40） 。因此什么百分點更有意義呢？即使觀察點設在第95的百分點，然后你的單頁面瀏覽人數遠大于40，那么大部分的用戶仍會經受比之前更糟糕的響應時間。若符合多個頁面瀏覽量，事情會更加復雜。想閱讀更多關于百分點的知識，了解其對數據的誤導，可點擊此處進入Gil Tene 的博客。

家下來我們來仔細解讀指標的選擇，看看它們各自代表什么，并學習如何來理解這些指標。

響應時間用來衡量應用程序中的事務處理速度，它也可以從 HTTP 請求層和數據庫層來觀察。有些最慢的查詢需要最優化解決，而響應時間可以縮小該查詢的范圍。吞吐量從另一個角度觀察處理過程，并顯示應用程序在給定時間域中處理多少請求，通常單位為每分鐘（cpm）。

測量響應時間的方法之一就是使用像 New Relic 或者 AppDynamics（就是曾在以前的博客討論的）那種 APM（應用性能監控工具），通過這些工具，可以追蹤平均響應時間，并可以直接在主報告儀表板上與昨日或者上周的平均響應時間作比較，這些比較有助于查看新的部署如何對應用程序造成了影響。另一種方法是通過測量網頁處理的百分位數，來測量 HTTP 請求完成響應所需的時間。

也可以內部監測響應時間，但是需要硬代碼，例如通過 Dropwizard 指標發送數據并在 Graphite 上發布。盡管看來將這些數據和其他標準關聯時會出現最有用的見解，但更多的見解仍涵蓋在接下來的方法中。

要點1: 確保所使用的采集方法可以實現從不同角度觀測數據，并開始進入百分位層面。

可行工具：

AppDynamics

New Relic

Ruxit

OneAPM

圖為 OneAPM 上監控到的 Java 應用程序響應時間和吞吐量

第二個廣泛使用的衡量指標就是服務器的平均負載。平均負載習慣上分成3部分，在最后的1、5和15分鐘（從左到右）顯示其結果。只要分數低于機器內核的數量，就是無壓力狀態，一旦超過內核數，就意味著機器處于壓力狀態。

平均負載除了可以簡單測量 CPU 利用率，更著重于考量每個內核目前在隊列中有多少進程。某內核利用率達100%，但是卻即將結束任務，而另一內核在隊列中還有6個進程要處理，這兩種情況是截然不同的。CPU 這一概念并沒有涵蓋其區別，但是平均負載卻可以從大局中考慮此問題。

若在 linux 系統上跟蹤平均負載情況，一個極好的方式就是通過 Hisham Muhammad 利用 htop 完成。豐富的色彩加上生動的視覺化效果，瞬間使得命令行有了 NASA 儀表板的即視感。

要點2： 要確定負載，僅靠資源利用率是不夠的，還需要格外注意以便充分了解隊列中的進程。

可行工具:

htop

圖為在一臺服務器上運行 htop 以檢測負載，平均負載顯示在界面的右上角。

錯誤率觀測有多種方法，而多數開發人員都利用高層次標準——在整個應用層考察錯誤率，比如在所有 HTTP 請求中考察失敗的 HTTP 處理總數。但是還有一個經常被忽視的具體點：特定事務的錯誤，這與應用程序的運行狀況有直接的影響。代碼中某一特定方法失敗、生成日志錯誤及發生異常的次數占總調用次數的比重，也要予以顯示。

圖為 OneAPM 對事務中的錯誤率監控，隨時間監控應用錯誤率情況。

但是這些數據對其本身并沒有太大的意義。第一步，從正在處理的事件中優選出最緊急的一件，找到日志錯誤或異常；第二步，從實際根源處著手，并予以修復。而且基于此問題，已有相應的解決辦法。有了 OneAPM ，就沒有必要根據日志文件去找錯誤提示，因為關于服務器狀態的所有信息都會在同一界面顯示，包括堆棧蹤跡、實源代碼、變量值及每個錯誤調用的應用實例。

要點3： 要解決錯誤率增長的根本原因，僅靠日志文件是不夠的，為了得到大量關于我們所需指標的數據，還需要利用一些錯誤率監控工具。

垃圾回收器行為異常，是導致應用吞吐量和響應時間突然下降的主要原因之一。讀者想要了解關于垃圾回收過程的更多知識和相關的標準，可閱讀 深入理解Java虛擬機（第2版）。

分析 GC 日志文件是理解 GC 中止時間和頻率的關鍵。如果不自行分析，或者使用類似于 jClarity 的工具，這種指標是沒有辦法直接使用的。所以要確保使用合適的 JVM 參數打開 GC 日志采集，以便分析。

要點4： 請記住，分析不同指標的相關數據，要保持開闊的思維，這樣容易發現它們之間的互相影響。

可行工具:

jClarity Censum

GCViewer

應用的性能不是僅僅依賴于快速響應，也非錯誤率，另一個方面就是業務指標。其業務責任也不是只由產品/銷售人員全權負責。收入、用戶數、與應用中特定區域的互動等，這些都對理解軟件的運行極為關鍵。若要從業務角度觀察，你所配置的修復方法和新功能是如何影響底線的，以上因素與新部署的時間標記一起作用這一點至關重要。我們固然希望情況向好的方向發展，但假如事態惡化，一旦你把所有數據都存在同一位置，要想知道哪里出了問題需要修復，這就相當容易了。

此外，將業務指標與錯誤率、延時等數據實時連接起來，這種能力是極有力度的。然后會讓人不由自主地深入研討到底是什么錯誤或異常造成了這次最主要的問題，接著就可以按照對業務目的影響優先考慮它們。想要搞清楚遍布各處的所有異常及日志錯誤，就得使用集成開放的監測工具。所以，保持數據開放，使其可以輸出到選擇服務中，這是極其重要的。

假如你要利用 Graphite 將匯報的業務指標集中化，這就要求你所使用的工具對發送數據開放。例如，我們的工程組就將匯報指標通過 StatsD 發布出來，因此相應數據就可以指向任一用戶選擇使用的儀表板上。

要點5： 先入先出式數據已是過去式，在使用指標時，也需要讓它們和其他來源的數據相關聯。

可行工具:

Grafana

The ELK stack

Datadog

Librato

該指標為整體的工作定下基調。除用作警示媒介外，它還可用于在一段時間內自定義 SLA，以便觀察當為用戶提供功能完備的服務時所用時間的百分比。

我們通過運行使用 servlet 的 Pingdom 來解決這個問題，它會對所有應用程序事務中參與的服務進行檢查，包括數據庫和 S3 等。

要點6： 正常運行時可能是二進制指標，但是通過聚合多個值的方式在堆棧中定位薄弱點。

可行工具:

Pingdom

圖為用 Pingdom 監測正常運行時和應用運行狀況。

以上討論到的指標除了 GC 都沒有提到日志，但這個仍然不可忽略。日志文件的副作用就是它們一直在增長，如果不留意其大小以及抑制，那么后果不堪設想。當日志不受控制，磁盤驅動器很可能被撐爆，服務器中會充斥著垃圾文件，運行緩慢，因此，一定要密切關注日志規模，否則隨時會崩潰。

一個廣泛使用的解決辦法就是，使用 logstash 等將服務器上的日志分塊，再將其送入Splunk、ELK 等其他日志管理工具中存儲，或者直接簡單地存入 S3。另一種方法就是在某一時間將日志文件翻轉再截斷，但此法要冒信息丟失的風險。和大部分開發人員一樣，目前我們還必須依賴于日志。

要點7： 日志會給人帶來很大的困擾，尤其是當你用某些外部服務來處理日志時，你會被 GB 指控。這時就要重新考慮一下這個問題，還應該開始降低日志大小。

我們可以看到這一趨勢：目前在產品中，應用里的數據采集器正逐漸脫離對日志文件的依賴。軟件分析的新世界越來越開放，數據更加智能化，已不再是以前枯燥的數字，而是帶有豐富的情境。我們很興奮地看著世界的改變，并期待和你們一起共建嶄新的未來。

原文地址：https://dzone.com/articles/7-java-performance-metrics-to-watch-after-a-major-1