上一節，我帶你學習了，如何使用 use 法來監控系統的效能，先簡單回顧一下。
系統監控的核心是資源的使用情況，這既包括 cpu、記憶體、磁碟、檔案系統、網路等硬體資源，也包括檔案描述符數、連線數、連線跟蹤數等軟體資源。而要描述這些資源瓶頸，最簡單有效的
方法就是 use 法。
use 法把系統資源的效能指標，簡化為了三個類別：使用率、飽和度以及錯誤數。 當這三者之中任一類別的指標過高時，都代表相對應的系統資源可能存在效能瓶頸。
基於 use 法建立效能指標後，我們還需要通過一套完整的監控系統，把這些指標從採集、儲存、查詢、處理，再到告警和視覺化展示等貫穿起來。這樣，不僅可以將系統資源的瓶頸快速暴露出
來，還可以借助監控的歷史資料，來追蹤定位效能問題的根源。
跟系統監控一樣，在構建應用程式的監控系統之前，首先也需要確定，到底需要監控哪些指標。特別是要清楚，有哪些指標可以用來快速確認應用程式的效能問題。
對系統資源的監控，use 法簡單有效，卻不代表其適合應用程式的監控。舉個例子，即使在 cpu使用率很低的時候，也不能說明應用程式就沒有效能瓶頸。因為應用程式可能會因為鎖或者 rpc
呼叫等，導致響應緩慢。
所以，應用程式的核心指標，不再是資源的使用情況，而是請求數、錯誤率和響應時間。這些指標不僅直接關係到使用者的使用體驗，還反映應用整體的可用性和可靠性。
有了請求數、錯誤率和響應時間這三個**指標之後，我們就可以快速知道，應用是否發生了效能問題。但是，只有這些指標顯然還是不夠的，因為發生效能問題後，我們還希望能夠快速定
位「效能瓶頸區」。所以，在我看來，下面幾種指標，也是監控應用程式時必不可少的。
第乙個，是應用程序的資源使用情況，比如程序占用的 cpu、記憶體、磁碟 i/o、網路等。使用過多的系統資源，導致應用程式響應緩慢或者錯誤數公升高，是乙個最常見的效能問題。
第二個，是應用程式之間呼叫情況，比如呼叫頻率、錯誤數、延時等。由於應用程式並不是孤立的，如果其依賴的其他應用出現了效能問題，應用自身效能也會受到影響。
第三個，是應用程式內部核心邏輯的運**況，比如關鍵環節的耗時以及執行過程中的錯誤等。由於這是應用程式內部的狀態，從外部通常無法直接獲取到詳細的效能資料。所以，應用程式在
設計和開發時，就應該把這些指標提供出來，以便監控系統可以了解其內部執行狀態。
有了應用程序的資源使用指標，你就可以把系統資源的瓶頸跟應用程式關聯起來，從而迅速定位因系統資源不足而導致的效能問題；
有了應用程式之間的呼叫指標，你可以迅速分析出乙個請求處理的呼叫鏈中，到底哪個元件才是導致效能問題的罪魁禍首；
而有了應用程式內部核心邏輯的執行效能，你就可以更進一步，直接進入應用程式的內部，定位到底是哪個處理環節的函式導致了效能問題。
基於這些思路，我相信你就可以構建出，描述應用程式執行狀態的效能指標。再將這些指標納入我們上一期提到的監控系統（比如 prometheus + grafana）中，就可以跟系統監控一樣，一方
面通過告警系統，把問題及時匯報給相關團隊處理；另一方面，通過直觀的圖形介面，動態展示應用程式的整體效能。
除此之外，由於業務系統通常會涉及到一連串的多個服務，形成乙個複雜的分布式呼叫鏈。為了迅速定位這類跨應用的效能瓶頸，你還可以使用 zipkin、jaeger、pinpoint 等各類開源工具，
來構建全鏈路跟蹤系統。
比如，下圖就是乙個 jaeger 呼叫鏈跟蹤的示例。
全鏈路跟蹤可以幫你迅速定位出，在乙個請求處理過程中，哪個環節才是問題根源。比如，從上圖中，你就可以很容易看到，這是 redis 超時導致的問題。
全鏈路跟蹤除了可以幫你快速定位跨應用的效能問題外，還可以幫你生成線上系統的呼叫拓撲圖。這些直觀的拓撲圖，在分析複雜系統（比如微服務）時尤其有效
效能指標的監控，可以讓你迅速定位發生瓶頸的位置，不過只有指標的話往往還不夠。比如，同樣的乙個介面，當請求傳入的引數不同時，就可能會導致完全不同的效能問題。所以，除了指標
外，我們還需要對這些指標的上下文資訊進行監控，而日誌正是這些上下文的最佳**。對比來看，
指標是特定時間段的數值型測量資料，通常以時間序列的方式處理，適合於實時監控。
而日誌則完全不同，日誌都是某個時間點的字串訊息，通常需要對搜尋引擎進行索引後，才能進行查詢和彙總分析。
對日誌監控來說，最經典的方法，就是使用 elk 技術棧，即使用 elasticsearch、logstash 和kibana 這三個元件的組合。
如下圖所示，就是乙個經典的 elk 架構圖：
這其中，
logstash 負責對從各個日誌源採集日誌，然後進行預處理，最後再把初步處理過的日誌，傳送給 elasticsearch 進行索引。
elasticsearch 負責對日誌進行索引，並提供了乙個完整的全文搜尋引擎，這樣就可以方便你從日誌中檢索需要的資料。
kibana 則負責對日誌進行視覺化分析，包括日誌搜尋、處理以及絢麗的儀表板展示等。
下面這張圖，就是乙個 kibana 儀表板的示例，它直觀展示了 apache 的訪問概況。
值得注意的是，elk 技術棧中的 logstash 資源消耗比較大。所以，在資源緊張的環境中，我們往往使用資源消耗更低的 fluentd，來替代 logstash（也就是所謂的 efk 技術棧）。
今天，我為你梳理了應用程式監控的基本思路。應用程式的監控，可以分為指標監控和日誌監控兩大部分：
指標監控主要是對一定時間段內效能指標進行測量，然後再通過時間序列的方式，進行處理、儲存和告警。
日誌監控則可以提供更詳細的上下文資訊，通常通過 elk 技術棧來進行收集、索引和圖形化展示。
在跨多個不同應用的複雜業務場景中，你還可以構建全鏈路跟蹤系統。這樣可以動態跟蹤呼叫鏈中各個元件的效能，生成整個流程的呼叫拓撲圖，從而加快定位複雜應用的效能問題。
LinuxIO效能優化實戰學習筆記
以下內容來自極客課程，如對您有幫助，詳細課程請見海報 1.檔案系統 為了方便管理，linux 檔案系統為每個檔案都分配兩個資料結構，索引節點 index node 和目錄項 directory entry 它們主要用來記錄檔案的元資訊和目錄結構。2.slab cache cached sreclai...
學習Linux效能優化實戰 1
程序排程 軟中斷測試工具 最近在極客時間上面發現了倪鵬飛老師的linux效能優化實戰，自己感覺講得很好，有興趣的朋友可以去極客時間上面訂閱。部落格是自己總結學習到的一些命令，記錄下來，以備後面使用。侵刪。uptime 用來看系統過去的 1 5 15 分鐘的平均負載。mpstat p all inte...
Linux效能優化實戰學習筆記 第三講
上下文切換是對任務當前執行狀態的暫存和恢復 當多個程序競爭cpu的時候，cpu為了保證每個程序能公平被排程執行，採取了處理任務時間分片的機制，輪流處理多個程序，由於cpu處理速度非常快，在人類的感官上認為是並行處理，實際是 偽 並行，同一時間只有乙個任務在執行處理。根據 tsuna 的測試報告，每次...