摘要：可行工具圖為上監(jiān)控到的應(yīng)用程序響應(yīng)時(shí)間和吞吐量平均負(fù)載第二個(gè)廣泛使用的衡量指標(biāo)就是服務(wù)器的平均負(fù)載。率和中止時(shí)間垃圾回收器行為異常，是導(dǎo)致應(yīng)用吞吐量和響應(yīng)時(shí)間突然下降的主要原因之一。

在某個(gè)重大發(fā)布之后，都需要記錄相應(yīng)的指標(biāo)，本文介紹了最重要的幾個(gè) Java 性能指標(biāo)，包括響應(yīng)時(shí)間和平均負(fù)載等。為理解應(yīng)用程序在生產(chǎn)環(huán)境中如何運(yùn)行，就需要遵循一些 Java 性能指標(biāo)。

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

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

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

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

家下來我們來仔細(xì)解讀指標(biāo)的選擇，看看它們各自代表什么，并學(xué)習(xí)如何來理解這些指標(biāo)。

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

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

也可以內(nèi)部監(jiān)測響應(yīng)時(shí)間，但是需要硬代碼，例如通過 Dropwizard 指標(biāo)發(fā)送數(shù)據(jù)并在 Graphite 上發(fā)布。盡管看來將這些數(shù)據(jù)和其他標(biāo)準(zhǔn)關(guān)聯(lián)時(shí)會出現(xiàn)最有用的見解，但更多的見解仍涵蓋在接下來的方法中。

要點(diǎn)1: 確保所使用的采集方法可以實(shí)現(xiàn)從不同角度觀測數(shù)據(jù)，并開始進(jìn)入百分位層面。

可行工具：

AppDynamics

New Relic

Ruxit

OneAPM

圖為 OneAPM 上監(jiān)控到的 Java 應(yīng)用程序響應(yīng)時(shí)間和吞吐量

第二個(gè)廣泛使用的衡量指標(biāo)就是服務(wù)器的平均負(fù)載。平均負(fù)載習(xí)慣上分成3部分，在最后的1、5和15分鐘（從左到右）顯示其結(jié)果。只要分?jǐn)?shù)低于機(jī)器內(nèi)核的數(shù)量，就是無壓力狀態(tài)，一旦超過內(nèi)核數(shù)，就意味著機(jī)器處于壓力狀態(tài)。

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

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

要點(diǎn)2： 要確定負(fù)載，僅靠資源利用率是不夠的，還需要格外注意以便充分了解隊(duì)列中的進(jìn)程。

可行工具:

htop

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

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

圖為 OneAPM 對事務(wù)中的錯誤率監(jiān)控，隨時(shí)間監(jiān)控應(yīng)用錯誤率情況。

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

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

垃圾回收器行為異常，是導(dǎo)致應(yīng)用吞吐量和響應(yīng)時(shí)間突然下降的主要原因之一。讀者想要了解關(guān)于垃圾回收過程的更多知識和相關(guān)的標(biāo)準(zhǔn)，可閱讀 深入理解Java虛擬機(jī)（第2版）。

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

要點(diǎn)4： 請記住，分析不同指標(biāo)的相關(guān)數(shù)據(jù)，要保持開闊的思維，這樣容易發(fā)現(xiàn)它們之間的互相影響。

可行工具:

jClarity Censum

GCViewer

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

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

假如你要利用 Graphite 將匯報(bào)的業(yè)務(wù)指標(biāo)集中化，這就要求你所使用的工具對發(fā)送數(shù)據(jù)開放。例如，我們的工程組就將匯報(bào)指標(biāo)通過 StatsD 發(fā)布出來，因此相應(yīng)數(shù)據(jù)就可以指向任一用戶選擇使用的儀表板上。

要點(diǎn)5： 先入先出式數(shù)據(jù)已是過去式，在使用指標(biāo)時(shí)，也需要讓它們和其他來源的數(shù)據(jù)相關(guān)聯(lián)。

可行工具:

Grafana

The ELK stack

Datadog

Librato

該指標(biāo)為整體的工作定下基調(diào)。除用作警示媒介外，它還可用于在一段時(shí)間內(nèi)自定義 SLA，以便觀察當(dāng)為用戶提供功能完備的服務(wù)時(shí)所用時(shí)間的百分比。

我們通過運(yùn)行使用 servlet 的 Pingdom 來解決這個(gè)問題，它會對所有應(yīng)用程序事務(wù)中參與的服務(wù)進(jìn)行檢查，包括數(shù)據(jù)庫和 S3 等。

要點(diǎn)6： 正常運(yùn)行時(shí)可能是二進(jìn)制指標(biāo)，但是通過聚合多個(gè)值的方式在堆棧中定位薄弱點(diǎn)。

可行工具:

Pingdom

圖為用 Pingdom 監(jiān)測正常運(yùn)行時(shí)和應(yīng)用運(yùn)行狀況。

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

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

要點(diǎn)7： 日志會給人帶來很大的困擾，尤其是當(dāng)你用某些外部服務(wù)來處理日志時(shí)，你會被 GB 指控。這時(shí)就要重新考慮一下這個(gè)問題，還應(yīng)該開始降低日志大小。

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

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