本文中，小編搜集了7個(gè)最有影響的衡量標(biāo)注，讓你可以不依賴日志文件來(lái)了解應(yīng)用程序。現(xiàn)在，讓我們看看這些性能指標(biāo)，并了解如何查看并收集它們：

1.響應(yīng)時(shí)間和吞吐量

根據(jù)應(yīng)用程序的響應(yīng)時(shí)間可以知道程序完成傳輸數(shù)據(jù)所用的時(shí)間。也可以從HTTP請(qǐng)求級(jí)別，或者成為數(shù)據(jù)庫(kù)級(jí)別來(lái)看。對(duì)那些緩慢的查詢你需要做一些優(yōu)化來(lái)縮短時(shí)間。吞吐量是另一個(gè)角度衡量傳輸數(shù)據(jù)的指標(biāo)，是指單位時(shí)間內(nèi)系統(tǒng)處理的客戶請(qǐng)求的數(shù)量。

我們可以使用APMs（例如New Relic或AppDynamics）來(lái)衡量這些指標(biāo)。使用這些工具，你可以在主報(bào)告儀表板中將平均響應(yīng)時(shí)間與昨天的甚至上周的直接進(jìn)行對(duì)比。這有助于我們觀察新的部署是否會(huì)影響到我們的應(yīng)用程序。你可以看到網(wǎng)絡(luò)傳輸?shù)陌俜直龋瑴y(cè)量HTTP完成請(qǐng)求需要多長(zhǎng)時(shí)間。

推薦工具：

New Relic報(bào)告：Web傳輸百分比和吞吐量

2.平均負(fù)載

第二個(gè)應(yīng)用廣泛的指標(biāo)是平均負(fù)載。我們習(xí)慣上會(huì)把平均負(fù)載分為這三步測(cè)量，分別是第5分鐘、第15分鐘和最后1分鐘。要保證數(shù)量低于機(jī)器的內(nèi)核數(shù)。一旦超過(guò)內(nèi)核數(shù)，機(jī)器就會(huì)運(yùn)行在壓力狀態(tài)下。

除了簡(jiǎn)單測(cè)量CPU使用率，還需要關(guān)注每個(gè)內(nèi)核的隊(duì)列中有多少進(jìn)程。在內(nèi)核使用率都是100%的情況下，隊(duì)列中只有1個(gè)任務(wù)和有6個(gè)任務(wù)有很大不同。因此，平均負(fù)載不能只考慮CPU使用率。

推薦工具：

3.錯(cuò)誤率

大多數(shù)開(kāi)發(fā)人員判斷錯(cuò)誤率是根據(jù)HTTP傳輸總失敗百分比。但是他們忽略了一個(gè)更深層的東西：特定傳輸?shù)腻e(cuò)誤率。這直接影響到您應(yīng)用程序的運(yùn)行狀況。這可以顯示出代碼方法的錯(cuò)誤以及錯(cuò)誤或異常出現(xiàn)的次數(shù)。

但單純的錯(cuò)誤率數(shù)據(jù)對(duì)我們沒(méi)有多大幫助。最重要的是我們要找到它們的根源并解決問(wèn)題。隨著Takipi的運(yùn)行，我們要在日志文件中需找線索。你可以找到所有關(guān)于服務(wù)器狀態(tài)的信息，包括堆棧跟蹤、源代碼和變量值。

推薦工具：

4.GC率和暫停時(shí)間

異常行為垃圾收集器應(yīng)用程序的吞吐量和響應(yīng)時(shí)間采取深潛的主要原因之一。了解GC暫停頻率和持續(xù)時(shí)間的關(guān)鍵是分析GC日志文件。要分析它們，你需要收集GC日志和JVM參數(shù)。你要注意觀察不同指標(biāo)之間的數(shù)據(jù)是如何相互影響的。

推薦工具：

5.業(yè)務(wù)指標(biāo)

應(yīng)用程序的性能不完全取決于響應(yīng)時(shí)間和錯(cuò)誤率。業(yè)務(wù)指標(biāo)也是一方面，例如收益、用戶數(shù)。

推薦工具：

6.正常運(yùn)行時(shí)間和服務(wù)運(yùn)行狀態(tài)

這一指標(biāo)奠定了整個(gè)應(yīng)用程序性能的基礎(chǔ)。不僅可以當(dāng)做一個(gè)提醒指標(biāo)，也可以讓你定義一段時(shí)間內(nèi)的SKA。我們可以使用Pingdom的servlet功能進(jìn)行運(yùn)行狀態(tài)檢查。我們可以查到應(yīng)用程序的所有傳輸，包括數(shù)據(jù)庫(kù)和S3。

推薦工具：

7.日志大小

日志有一個(gè)缺點(diǎn)，它是一直在增加的。當(dāng)您的服務(wù)器啟動(dòng)塞滿了垃圾，一切都慢下來(lái)。因此，我們需要密切的關(guān)注日志大小。

目前通常的解決辦法是使用logstash劃分使用日志，并將它們發(fā)送并存儲(chǔ)在Splunk、ELK或其他的日志管理工具中。

推薦工具：