- 1. 響應時間和吞吐量
- 2. 平均負載
- 3.錯誤率
- 4.GC 率和暫停時間
- 5.業務指標
- 6.正常執行時間和服務執行狀態
- 7.日誌大小
本文中,蒐集了7個最有影響的衡量標註,讓你可以不依賴日誌檔案來瞭解應用程式。現在,讓我們看看這些效能指標,並瞭解如何檢視並收集它們:
1. 響應時間和吞吐量
根據應用程式的響應時間可以知道程式完成傳輸資料所用的時間。也可以從HTTP請求級別,或者成為資料庫級別來看。對那些緩慢的查詢你需要做一些最佳化來縮短時間。吞吐量是另一個角度衡量傳輸資料的指標,是指單位時間內系統處理的客戶請求的數量。
我們可以使用APMs(例如New Relic或AppDynamics)來衡量這些指標。使用這些工具,你可以在主報告儀錶板中將平均響應時間與昨天的甚至上週的直接進行對比。這有助於我們觀察新的部署是否會影響到我們的應用程式。你可以看到網路傳輸的百分比,測量HTTP完成請求需要多長時間。
推薦工具:
- AppDynamics
- New Relic
- Ruxit
New Relic報告:Web傳輸百分比和吞吐量
2. 平均負載
第二個應用廣泛的指標是平均負載。我們習慣上會把平均負載分為這三步測量,分別是第5分鐘、第15分鐘和最後1分鐘。要保證數量低於機器的核心數。一旦超過核心數,機器就會執行在壓力狀態下。
除了簡單測量CPU使用率,還需要關註每個內核的佇列中有多少行程。在核心使用率都是100%的情況下,佇列中只有1個任務和有6個任務有很大不同。因此,平均負載不能只考慮CPU使用率。
推薦工具:
- htop
3.錯誤率
大多數開發人員判斷錯誤率是根據HTTP傳輸總失敗百分比。但是他們忽略了一個更深層的東西:特定傳輸的錯誤率。這直接影響到您應用程式的執行狀況。這可以顯示出程式碼方法的錯誤以及錯誤或異常出現的次數。
但單純的錯誤率資料對我們沒有多大幫助。最重要的是我們要找到它們的根源並解決問題。隨著Takipi的執行,我們要在日誌檔案中需找線索。你可以找到所有關於伺服器狀態的資訊,包括堆疊跟蹤、原始碼和變數值。
推薦工具:
- Takipi
4.GC 率和暫停時間
異常行為垃圾收集器應用程式的吞吐量和響應時間採取深潛的主要原因之一。瞭解GC暫停頻率和持續時間的關鍵是分析GC日誌檔案。要分析它們,你需要收集GC日誌和JVM引數。你要註意觀察不同指標之間的資料是如何相互影響的。
推薦工具:
- jClarity Censum
- GCViewer
5.業務指標
應用程式的效能不完全取決於響應時間和錯誤率。業務指標也是一方面,例如收益、使用者數。
推薦工具:
- Grafana
- The ELK stack
- Datadog
- Librato
6.正常執行時間和服務執行狀態
這一指標奠定了整個應用程式效能的基礎。不僅可以當做一個提醒指標,也可以讓你定義一段時間內的SKA。我們可以使用Pingdom的servlet功能進行執行狀態檢查。我們可以查到應用程式的所有傳輸,包括資料庫和S3。
推薦工具:
- Pingdom
7.日誌大小
日誌有一個缺點,它是一直在增加的。當您的伺服器啟動塞滿了垃圾,一切都慢下來。因此,我們需要密切的關註日誌大小。
目前通常的解決辦法是使用logstash劃分使用日誌,並將它們傳送並儲存在Splunk、ELK或其他的日誌管理工具中。
推薦工具:
- Splunk
- Sumo Logic
- Loggly
朋友會在“發現-看一看”看到你“在看”的內容