在做運維工作時，或多或少都會遇到訪問出錯或緩慢問題，這里以兩個小的例子來簡單說明下這類問題的troubleshooting的思路。

1.用戶查詢平臺故障一例 查詢平臺結構

nginx:80----------ip1/ip2 java------jdbc---(haproxy)--ip3(3000)+ip4(3000)hiveserver2---hdfs

從后端應用開始查： 1）通過hive cli運行sql，檢測hadoop運行job的狀態，正常。 2）由于應用使用jdbc的方式連接hiveserver2，使用beeline測試hiveserver2的狀態,正常。 連接方法:

1	!connect jdbc:hive2:/xxxx:30000/cdnlog

3）查看應用狀態，由于是java應用，因此第一時間使用jstat查看下gc信息。發現因為s0和old區100%導致應用在做頻繁的full gc,定位到是存在內存泄露的問題，通過jmap打印相關堆棧信息來進一步分析。

1 2 3 4 5

jstat -gcutil? 14266 1000 1000 ??S0???? S1???? E????? O????? P???? YGC???? YGCT??? FGC??? FGCT???? GCT 100.00?? 0.00 100.00 100.00? 21.65??? 596?? 77.267?? 629 2817.783 2895.050 100.00?? 0.00 100.00 100.00? 21.65??? 596?? 77.267?? 629 2817.783 2895.050 100.00?? 0.00 100.00 100.00? 21.65??? 596?? 77.267?? 629 2817.783 2895.050

4）再來看nginx的訪問日志，可以明顯看到nginx首先proxy到ip1，當響應超時后再proxy到ip2，因此從日志中可以看到兩個status和upstream response time.

截取的一段日志："8.999, 0.008" "ip1:8081, ip2:8081" "502, 200" "9.007"

存在的問題： 沒有有效的java監控（包括性能監控和日志監控）
2.推薦域名訪問故障問題 故障現象： 用戶訪問緩慢，一個url有時響應超過3s，并且會有一定的幾率abort. 域名整個的訪問流程： client-----cdn-----內部cdn節點-----源站（F5--nginx---java----redis---db） 從用戶端開始入手： 1）通過curl xxxx --trace-time --verbose來查看訪問時間的變化情況，單一請求時間3s，漸變點在用戶等待服務器響應上 2）用戶與cdn服務器連通性沒有問題（延遲5ms以內，無丟包），這點從client—cdn建立連接耗時也可以看出來（5ms） 3）源站nginx響應時間2ms，說明后端應用正常，源站到cdn節點延遲是50ms，無丟包,同時看到在cdn內部經過3多層代理，這就導致cdn內部任何一層有問題都會產生慢速響應 4）調整cdn策略為一層代理，問題得到緩解不過還是有一定比例的慢速響應 5）跳過cdn節點，直接指向源站來進行訪問測試，發現有一定的幾率abort 6）在client端通過tcpdump抓包，發現client---server連接建立正常，但是server端有一定的概率會返回RST給client，造成abort的產生
即用戶到F5正常，由F5到后端nginx出現問題，最終定位到是由于F5配置出錯導致proxy到了錯誤的server上。
存在問題： 1)RST不會在服務器上產生日志，是tcp層面的問題，還沒到應用層，因此通過監控nginx的訪問日志無法發現這種問題，需要對client端的性能做監控 2）F5的配置有些問題，對于后面機器的檢測，只是使用了ping的方法，沒有檢測端口導致有一部分的請求會分發到有問題的機器（比較理想的請求使用url的應用層檢測）
小結： 對于這類問題，可以通過兩種方式來troubleshooting，從應用出發和從client端出發。 兩種方法的思路都是一樣的，首先要清楚的了解整個的訪問鏈，然后對訪問進行分解，對每一步都進行檢測分析。 同時要注意服務器qos和用戶端qos的結合。

本文轉自菜菜光 51CTO博客，原文鏈接：http://blog.51cto.com/caiguangguang/1393707，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的两例访问故障小结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。