《漫談線上問題排查》作者駱俊武，2013 年北航計算機系碩士畢業，網際網路行業工作 8 年，現在獨角獸公司做技術總監。作者對實際工作過程中經歷過的線上案例進行
提煉，一方面是自我的覆盤總結，另一方面也想公開出去，以便更多的人受益。
聯絡方式：
微訊號：luojunwu1988
郵箱：[email protected]

大佬分享的2句話，一起共勉：
1、獲得人生的成功，需要的專注和堅持不懈，多過天才和機會
2、世界上有兩種最耀眼的光芒：一種是太陽，一種是我們努力的模樣！

第一章 線上問題排查的方法論

1.1 線上問題的處理流程

1.2排查問題的技巧

針對處理流程中的 3 個關鍵環節：發現故障、恢復故障、故障分析，常用的技巧。

1)快速發現故障，取決於兩個方面：

(1) 對系統是否足夠了解？

　　(a)、對系統架構的瞭解：出現問題後，你需要知道關聯的上下游系統都有哪些？依賴

的儲存、中介軟體都有哪些？這樣你才會形成很清晰的鏈路，然後去定位問題出現在哪
個環節上？
　　(b)、對業務的瞭解：只有對業務足夠了解，你才能從業務邏輯上判斷它到底是不是故
障？這個故障具體是哪個業務環節出問題了？然後再回到系統、服務或者程式碼層面去
做進一步定位。

(2）系統的監控建設是否足夠完善？

　　(a)是否有配套的監控系統：首先要解決有無的問題，從機器、到作業系統（CPU、記憶體、磁碟、IO）、到各種中介軟體（DB、MQ、Redis）、再到應用層（JVM、介面效能、流量、業務指標）等，是否有配套的監控手段
　　(b)對監控系統的使用是否到位了：有工具了，然後再考慮業務上如何使用好這些工具？要建立哪些監控指標？告警閾值如何進行合理設定？技術同學對於監控系統的使用是否熟練？團隊是否有成熟的線上問題處理機制？

2) 快速恢復故障

　　出現故障後的原則一定是：第一時間恢復，以儘可能地減少對業務的影響。

　　快速恢復的常見手段有：回滾到上一個版本、緊急修復、服務擴容、服務降級、摘機、重啟等

　　在恢復故障的同時，還有一件很重要的事情不能遺漏，那就是：保留現場，方便後續進行根因分析

　　對於 Java 程式，常見的幾種保留現場方法是：

1、執行 jstack stack.log，每隔幾秒鐘儲存一次堆疊資訊
2、執行 jstat -gcutil ，檢視堆記憶體各區域的使用率以及GC情況
3、執行 jmap -histo | head -n20，檢視堆記憶體中的存活物件，並按空間排序
4、執行 jmap -dump:format=b,file=heap ，dump堆記憶體檔案，dump之前可以從做摘機處理，因為dump過程中會發生FGC，引發STW
 
5、執行 top 命令，shift + p 可以按 CPU 使用率倒排，記錄最消耗資源的程序資訊
6、執行 free -m 命令，shift + m 可以按照記憶體使用量倒排，記錄最好資源的程序\資訊

3)快速定位故障

非常依賴個人經驗、甚至是對底層原理的掌握深度。

　　　　　　　　　　　　　　　　　　　　　　　　Linux 定位工具

此外，還有這些非常高頻的命令列和工具:

磁碟：df -h
網路：netstat -nat | awk '{print $6}' | sort | uniq -c | sort -rn
IO：iostat
記憶體：free -m
CPU：top -Hp
JVM：jstack（執行緒）、jmap（記憶體）、jstat（GC）
其他工具：JVisual、MAT、arthas

1.3 監控體系建設

1.監控系統的7大作用

• 實時採集監控資料：包括 硬體、作業系統、中介軟體、應用程式等各個維度的資料。
• 實時反饋監控狀態：通過對採集的資料進行多維度統計和視覺化展示，能實時體現監控物件的狀態是正常還是異常。
• 預知故障和告警：能夠提前預知故障風險，並及時發出告警資訊。
• 輔助定位故障：提供故障發生時的各項指標資料，輔助故障分析和定位。
• 輔助效能調優：為效能調優提供資料支援，比如慢SQL，介面響應時間等。
• 輔助容量規劃：為伺服器、中介軟體以及應用叢集的容量規劃提供資料支撐。
• 輔助自動化運維：為自動擴容或者根據配置的SLA進行服務降級等智慧運維提供資料支撐。

2. 正確姿勢的使用監控系統

一個成熟的研發團隊通常會定一個監控規範，用來統一監控系統的使用方法。

• 瞭解監控物件的工作原理：要做到對監控物件有基本的瞭解，清楚它的工作原理。比如想對JVM進行監控，你必須清楚JVM的堆記憶體結構和垃圾回收機制。
• 確定監控物件的指標 ：清楚使用哪些指標來刻畫監控物件的狀態？比如想對某個介面進行監控，可以採用請求量、耗時、超時量、異常量等指標來衡量。
• 定義合理的報警閾值和等級：達到什麼閾值需要告警？對應的故障等級是多少？不需要處理的告警不是好告警，可見定義合理的閾值有多重要，否則只會降低運維效率或者讓監控系統失去它的作用。
• 建立完善的故障處理流程：收到故障告警後，一定要有相應的處理流程和oncall機制，讓故障及時被跟進處理。

3. 監控的物件和指標都有哪些？

常用的監控物件以及監控指標分類整理:

a. 硬體監控
　　包括：電源狀態、CPU狀態、機器溫度、風扇狀態、物理磁碟、raid狀態、記憶體狀態、網絡卡狀態
b. 伺服器基礎監控
　　CPU：單個CPU以及整體的使用情況
　　記憶體：已用記憶體、可用記憶體
　　磁碟：磁碟使用率、磁碟讀寫的吞吐量
　　網路：出口流量、入口流量、TCP連線狀態
c. 資料庫監控
　　包括：資料庫連線數、QPS、TPS、並行處理的會話數、快取命中率、主從延時、鎖狀\態、慢查詢
d. 中介軟體監控
　　Nginx：活躍連線數、等待連線數、丟棄連線數、請求量、耗時、5XX錯誤率
　　Tomcat：最大執行緒數、當前執行緒數、請求量、耗時、錯誤量、堆記憶體使用情況、GC次數和耗時
　　快取 ：成功連線數、阻塞連線數、已使用記憶體、記憶體碎片率、請求量、耗時、快取命中率
　　訊息佇列：連線數、佇列數、生產速率、消費速率、訊息堆積量
e. 應用監控
　　HTTP介面：URL存活、請求量、耗時、異常量RPC介面：請求量、耗時、超時量、拒絕量
　　JVM ：GC次數、GC耗時、各個記憶體區域的大小、當前執行緒數、死鎖執行緒數
　　執行緒池：活躍執行緒數、任務佇列大小、任務執行耗時、拒絕任務數
　　連線池：總連線數、活躍連線數
　　日誌監控：訪問日誌、錯誤日誌
　　業務指標：視業務來定，比如PV、訂單量等

4. 監控系統的基本流程

• 資料採集：採集的方式有很多種，包括 日誌埋點進行採集（通過Logstash、Filebeat等進行上報和解析）， JMX標準介面輸出監控指標，被監控物件提供RESTAPI進行資料採集（如Hadoop、ES），系統命令列，統一的SDK進行侵入式的埋點和上報等。
• 資料傳輸：將採集的資料以TCP、UDP或者HTTP協議的形式上報給監控系統，有主動Push模式，也有被動Pull模式。
• 資料儲存：有使用MySQL、Oracle等RDBMS儲存的，也有使用時序資料庫RRDTool、OpentTSDB、InfluxDB儲存的，還有使用HBase儲存的。
• 資料展示：資料指標的圖形化展示。
• 監控告警：靈活的告警設定，以及支援郵件、簡訊、IM等多種通知通道。

主流監控系統:

第二章典型案例的排查分析過程
2.1案例一：多執行緒死鎖問題排查