運維人員如何應對訪問出錯故障？
在做運維工作時，或多或少都會遇到訪問出錯或緩慢問題，這里以兩個小的例子來簡單說明下這類問題的troubleshooting的思路。
一、用戶查詢平臺故障一例
查詢平臺結構
- nginx:80----------ip1/ip2 java------jdbc---(haproxy)--ip3(3000)+ip4(3000)hiveserver2---hdfs
從后端應用開始查：
1、通過hive cli運行sql，檢測hadoop運行job的狀態，正常。
2、由于應用使用jdbc的方式連接hiveserver2，使用beeline測試hiveserver2的狀態,正常。
連接方法：
- !connect jdbc:hive2:/xxxx:30000/cdnlog
3、查看應用狀態，由于是java應用，因此***時間使用jstat查看下gc信息。發現因為s0和old區100%導致應用在做頻繁的full gc,定位到是存在內存泄露的問題，通過jmap打印相關堆棧信息來進一步分析。
- 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監控（包括性能監控和日志監控）
二、推薦域名訪問故障問題
故障現象：
用戶訪問緩慢，一個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的結合。
