目錄
名額監控
日志監控
小結
上一節，我帶你學習了，如何使用 USE 法來監控系統的性能，先簡單回顧一下。
系統監控的核心是資源的使用情況，這既包括 CPU、記憶體、磁盤、檔案系統、網絡等硬體資源，也包括檔案描述符數、連接配接數、連接配接跟蹤數等軟體資源。而要描述這些資源瓶頸，最簡單有效的方法就是 USE 法。
USE 法把系統資源的性能名額，簡化為了三個類别：使用率、飽和度以及錯誤數。 當這三者之中任一類别的名額過高時，都代表相對應的系統資源可能存在性能瓶頸。
基于 USE 法建立性能名額後，我們還需要通過一套完整的監控系統，把這些名額從采集、存儲、查詢、處理，再到告警和可視化展示等貫穿起來。這樣，不僅可以将系統資源的瓶頸快速暴露出來，還可以借助監控的曆史資料，來追蹤定位性能問題的根源。
除了上一節講到的系統資源需要監控之外，應用程式的性能監控，當然也是必不可少的。今天，我就帶你一起來看看，如何監控應用程式的性能。
跟系統監控一樣，在建構應用程式的監控系統之前，首先也需要确定，到底需要監控哪些名額。特别是要清楚，有哪些名額可以用來快速确認應用程式的性能問題。
對系統資源的監控，USE 法簡單有效，卻不代表其适合應用程式的監控。舉個例子，即使在 CPU 使用率很低的時候，也不能說明應用程式就沒有性能瓶頸。因為應用程式可能會因為鎖或者 RPC 調用等，導緻響應緩慢。
是以，應用程式的核心名額，不再是資源的使用情況，而是請求數、錯誤率和響應時間。這些名額不僅直接關系到使用者的使用體驗，還反映應用整體的可用性和可靠性。
有了請求數、錯誤率和響應時間這三個黃金名額之後，我們就可以快速知道，應用是否發生了性能問題。但是，隻有這些名額顯然還是不夠的，因為發生性能問題後，我們還希望能夠快速定位“性能瓶頸區”。是以，在我看來，下面幾種名額，也是監控應用程式時必不可少的。
第一個，是應用程序的資源使用情況，比如程序占用的 CPU、記憶體、磁盤 I/O、網絡等。使用過多的系統資源，導緻應用程式響應緩慢或者錯誤數升高，是一個最常見的性能問題。
第二個，是應用程式之間調用情況，比如調用頻率、錯誤數、延時等。由于應用程式并不是孤立的，如果其依賴的其他應用出現了性能問題，應用自身性能也會受到影響。
第三個，是應用程式内部核心邏輯的運作情況，比如關鍵環節的耗時以及執行過程中的錯誤等。由于這是應用程式内部的狀态，從外部通常無法直接擷取到詳細的性能資料。是以，應用程式在設計和開發時，就應該把這些名額提供出來，以便監控系統可以了解其内部運作狀态。
有了應用程序的資源使用名額，你就可以把系統資源的瓶頸跟應用程式關聯起來，進而迅速定位因系統資源不足而導緻的性能問題；
- 有了應用程式之間的調用名額，你可以迅速分析出一個請求處理的調用鍊中，到底哪個元件才是導緻性能問題的罪魁禍首；
- 而有了應用程式内部核心邏輯的運作性能，你就可以更進一步，直接進入應用程式的内部，定位到底是哪個處理環節的函數導緻了性能問題。
基于這些思路，我相信你就可以建構出，描述應用程式運作狀态的性能名額。再将這些名額納入我們上一期提到的監控系統（比如 Prometheus + Grafana）中，就可以跟系統監控一樣，一方面通過告警系統，把問題及時彙報給相關團隊處理；另一方面，通過直覺的圖形界面，動态展示應用程式的整體性能。
除此之外，由于業務系統通常會涉及到一連串的多個服務，形成一個複雜的分布式調用鍊。為了迅速定位這類跨應用的性能瓶頸，你還可以使用 Zipkin、Jaeger、Pinpoint 等各類開源工具，來建構全鍊路跟蹤系統。
比如，下圖就是一個 Jaeger 調用鍊跟蹤的示例。
（圖檔來自 Jaeger 文檔）
全鍊路跟蹤可以幫你迅速定位出，在一個請求處理過程中，哪個環節才是問題根源。比如，從上圖中，你就可以很容易看到，這是 Redis 逾時導緻的問題。
全鍊路跟蹤除了可以幫你快速定位跨應用的性能問題外，還可以幫你生成線上系統的調用拓撲圖。這些直覺的拓撲圖，在分析複雜系統（比如微服務）時尤其有效。
性能名額的監控，可以讓你迅速定位發生瓶頸的位置，不過隻有名額的話往往還不夠。比如，同樣的一個接口，當請求傳入的參數不同時，就可能會導緻完全不同的性能問題。是以，除了名額外，我們還需要對這些名額的上下文資訊進行監控，而日志正是這些上下文的最佳來源。
對比來看，
- 名額是特定時間段的數值型測量資料，通常以時間序列的方式處理，适合于實時監控。
- 而日志則完全不同，日志都是某個時間點的字元串消息，通常需要對搜尋引擎進行索引後，才能進行查詢和彙總分析。
對日志監控來說，最經典的方法，就是使用 ELK 技術棧，即使用 Elasticsearch、Logstash 和 Kibana 這三個元件的組合。
如下圖所示，就是一個經典的 ELK 架構圖：
（圖檔來自elastic.co）
這其中，
- Logstash 負責對從各個日志源采集日志，然後進行預處理，最後再把初步處理過的日志，發送給 Elasticsearch 進行索引。
- Elasticsearch 負責對日志進行索引，并提供了一個完整的全文搜尋引擎，這樣就可以友善你從日志中檢索需要的資料。
- Kibana 則負責對日志進行可視化分析，包括日志搜尋、處理以及絢麗的儀表闆展示等。
下面這張圖，就是一個 Kibana 儀表闆的示例，它直覺展示了 Apache 的通路概況。
值得注意的是，ELK 技術棧中的 Logstash 資源消耗比較大。是以，在資源緊張的環境中，我們往往使用資源消耗更低的 Fluentd，來替代 Logstash（也就是所謂的 EFK 技術棧）。
今天，我為你梳理了應用程式監控的基本思路。應用程式的監控，可以分為名額監控和日志監控兩大部分：
- 名額監控主要是對一定時間段内性能名額進行測量，然後再通過時間序列的方式，進行處理、存儲和告警。
- 日志監控則可以提供更詳細的上下文資訊，通常通過 ELK 技術棧來進行收集、索引和圖形化展示。
在跨多個不同應用的複雜業務場景中，你還可以建構全鍊路跟蹤系統。這樣可以動态跟蹤調用鍊中各個元件的性能，生成整個流程的調用拓撲圖，進而加快定位複雜應用的性能問題