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

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

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

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

推薦工具：

•  AppDynamics
•  New Relic
•  Ruxit

New Relic報告：Web傳輸百分比和吞吐量

2.平均負載

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

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

推薦工具：

•  htop

3.錯誤率

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

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

推薦工具：

•  Takipi

4.GC率和暫停時間

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

推薦工具：

•  jClarity Censum
•  GCViewer

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

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

推薦工具：

•  Grafana
•  The ELK stack
•  Datadog
•  Librato

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

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

推薦工具：

•  Pingdom

7.日志大小

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

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

推薦工具：

•  Splunk
•  Sumo Logic
•  Loggly