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

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

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

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

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

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

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

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

要點(diǎn)1: 確保所使用的采集方法可以實(shí)現(xiàn)從不同角度觀(guān)測(cè)數(shù)據(jù)，并開(kāi)始進(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ù)量，就是無(wú)壓力狀態(tài)，一旦超過(guò)內(nèi)核數(shù)，就意味著機(jī)器處于壓力狀態(tài)。

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

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

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

可行工具:

htop

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

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

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

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

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

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

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

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

可行工具:

jClarity Censum

GCViewer

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

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

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

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

可行工具:

Grafana

The ELK stack

Datadog

Librato

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

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

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

可行工具:

Pingdom

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

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

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

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

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

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