Linux 效能優化筆記應用監控

跟系統監控一樣，在構建應用程式的監控系統之前，首先也需要確定，到底需要監控哪些指標。特別是要清楚，有哪些指標可以用來快速確認應用程式的效能問題。

對系統資源的監控，use 法簡單有效，卻不代表其適合應用程式的監控。舉個例子，即使在 cpu 使用率很低的時候，也不能說明應用程式就沒有效能瓶頸。因為應用程式可能會因為鎖或者 rpc 呼叫等，導致響應緩慢。

所以，應用程式的核心指標，不再是資源的使用情況，而是請求數、錯誤率和響應時間。這些指標不僅直接關係到使用者的使用體驗，還反映應用整體的可用性和可靠性。

有了請求數、錯誤率和響應時間這三個**指標之後，我們就可以快速知道，應用是否發生了效能問題。但是，只有這些指標顯然還是不夠的，因為發生效能問題後，我們還希望能夠快速定位「效能瓶頸區」。所以，在我看來，下面幾種指標，也是監控應用程式時必不可少的。

第乙個，是應用程序的資源使用情況，比如程序占用的 cpu、記憶體、磁碟 i/o、網路等。使用過多的系統資源，導致應用程式響應緩慢或者錯誤數公升高，是乙個最常見的效能問題。

第二個，是應用程式之間呼叫情況，比如呼叫頻率、錯誤數、延時等。由於應用程式並不是孤立的，如果其依賴的其他應用出現了效能問題，應用自身效能也會受到影響。

第三個，是應用程式內部核心邏輯的運**況，比如關鍵環節的耗時以及執行過程中的錯誤等。由於這是應用程式內部的狀態，從外部通常無法直接獲取到詳細的效能資料。所以，應用程式在設計和開發時，就應該把這些指標提供出來，以便監控系統可以了解其內部執行狀態。

有了應用程序的資源使用指標，你就可以把系統資源的瓶頸跟應用程式關聯起來，從而迅速定位因系統資源不足而導致的效能問題；

基於這些思路，我相信你就可以構建出，描述應用程式執行狀態的效能指標。再將這些指標納入我們上一期提到的監控系統（比如 prometheus + grafana）中，就可以跟系統監控一樣，一方面通過告警系統，把問題及時匯報給相關團隊處理；另一方面，通過直觀的圖形介面，動態展示應用程式的整體效能。

除此之外，由於業務系統通常會涉及到一連串的多個服務，形成乙個複雜的分布式呼叫鏈。為了迅速定位這類跨應用的效能瓶頸，你還可以使用 zipkin、jaeger、pinpoint 等各類開源工具，來構建全鏈路跟蹤系統。

比如，下圖就是乙個 jaeger 呼叫鏈跟蹤的示例。

全鏈路跟蹤可以幫你迅速定位出，在乙個請求處理過程中，哪個環節才是問題根源。比如，從上圖中，你就可以很容易看到，這是 redis 超時導致的問題。

全鏈路跟蹤除了可以幫你快速定位跨應用的效能問題外，還可以幫你生成線上系統的呼叫拓撲圖。這些直觀的拓撲圖，在分析複雜系統（比如微服務）時尤其有效。

效能指標的監控，可以讓你迅速定位發生瓶頸的位置，不過只有指標的話往往還不夠。比如，同樣的乙個介面，當請求傳入的引數不同時，就可能會導致完全不同的效能問題。所以，除了指標外，我們還需要對這些指標的上下文資訊進行監控，而日誌正是這些上下文的最佳**。

對比來看，

對日誌監控來說，最經典的方法，就是使用 elk 技術棧，即使用 elasticsearch、logstash 和 kibana 這三個元件的組合。

如下圖所示，就是乙個經典的 elk 架構圖：

這其中，

下面這張圖，就是乙個 kibana 儀表板的示例，它直觀展示了 apache 的訪問概況。

值得注意的是，elk 技術棧中的 logstash 資源消耗比較大。所以，在資源緊張的環境中，我們往往使用資源消耗更低的 fluentd，來替代 logstash（也就是所謂的 efk 技術棧）。

今天，我為你梳理了應用程式監控的基本思路。應用程式的監控，可以分為指標監控和日誌監控兩大部分：

在跨多個不同應用的複雜業務場景中，你還可以構建全鏈路跟蹤系統。這樣可以動態跟蹤呼叫鏈中各個元件的效能，生成整個流程的呼叫拓撲圖，從而加快定位複雜應用的效能問題。

Linux 效能優化筆記 應用監控