運(yùn)維人員如何應(yīng)對(duì)訪問(wèn)出錯(cuò)故障？
在做運(yùn)維工作時(shí)，或多或少都會(huì)遇到訪問(wèn)出錯(cuò)或緩慢問(wèn)題，這里以兩個(gè)小的例子來(lái)簡(jiǎn)單說(shuō)明下這類問(wèn)題的troubleshooting的思路。
一、用戶查詢平臺(tái)故障一例
查詢平臺(tái)結(jié)構(gòu)
- nginx:80----------ip1/ip2 java------jdbc---(haproxy)--ip3(3000)+ip4(3000)hiveserver2---hdfs
從后端應(yīng)用開(kāi)始查：
1、通過(guò)hive cli運(yùn)行sql，檢測(cè)hadoop運(yùn)行job的狀態(tài)，正常。
2、由于應(yīng)用使用jdbc的方式連接hiveserver2，使用beeline測(cè)試hiveserver2的狀態(tài),正常。
連接方法：
- !connect jdbc:hive2:/xxxx:30000/cdnlog
3、查看應(yīng)用狀態(tài)，由于是java應(yīng)用，因此***時(shí)間使用jstat查看下gc信息。發(fā)現(xiàn)因?yàn)閟0和old區(qū)100%導(dǎo)致應(yīng)用在做頻繁的full gc,定位到是存在內(nèi)存泄露的問(wèn)題，通過(guò)jmap打印相關(guān)堆棧信息來(lái)進(jìn)一步分析。
- 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、再來(lái)看nginx的訪問(wèn)日志，可以明顯看到nginx首先proxy到ip1，當(dāng)響應(yīng)超時(shí)后再proxy到ip2，因此從日志中可以看到兩個(gè)status和upstream response time.
截取的一段日志："8.999, 0.008" "ip1:8081, ip2:8081" "502, 200" "9.007"
存在的問(wèn)題：
沒(méi)有有效的java監(jiān)控（包括性能監(jiān)控和日志監(jiān)控）
二、推薦域名訪問(wèn)故障問(wèn)題
故障現(xiàn)象：
用戶訪問(wèn)緩慢，一個(gè)url有時(shí)響應(yīng)超過(guò)3s，并且會(huì)有一定的幾率abort.
域名整個(gè)的訪問(wèn)流程：
client-----cdn-----內(nèi)部cdn節(jié)點(diǎn)-----源站（F5--nginx---java----redis---db）
從用戶端開(kāi)始入手：
1）通過(guò)curl xxxx --trace-time --verbose來(lái)查看訪問(wèn)時(shí)間的變化情況，單一請(qǐng)求時(shí)間3s，漸變點(diǎn)在用戶等待服務(wù)器響應(yīng)上
2）用戶與cdn服務(wù)器連通性沒(méi)有問(wèn)題（延遲5ms以內(nèi)，無(wú)丟包），這點(diǎn)從client—cdn建立連接耗時(shí)也可以看出來(lái)（5ms）
3）源站nginx響應(yīng)時(shí)間2ms，說(shuō)明后端應(yīng)用正常，源站到cdn節(jié)點(diǎn)延遲是50ms，無(wú)丟包,同時(shí)看到在cdn內(nèi)部經(jīng)過(guò)3多層代理，這就導(dǎo)致cdn內(nèi)部任何一層有問(wèn)題都會(huì)產(chǎn)生慢速響應(yīng)
4）調(diào)整cdn策略為一層代理，問(wèn)題得到緩解不過(guò)還是有一定比例的慢速響應(yīng)
5）跳過(guò)cdn節(jié)點(diǎn)，直接指向源站來(lái)進(jìn)行訪問(wèn)測(cè)試，發(fā)現(xiàn)有一定的幾率abort
6）在client端通過(guò)tcpdump抓包，發(fā)現(xiàn)client---server連接建立正常，但是server端有一定的概率會(huì)返回RST給client，造成abort的產(chǎn)生
即用戶到F5正常，由F5到后端nginx出現(xiàn)問(wèn)題，最終定位到是由于F5配置出錯(cuò)導(dǎo)致proxy到了錯(cuò)誤的server上。
【存在問(wèn)題】
1、RST不會(huì)在服務(wù)器上產(chǎn)生日志，是tcp層面的問(wèn)題，還沒(méi)到應(yīng)用層，因此通過(guò)監(jiān)控nginx的訪問(wèn)日志無(wú)法發(fā)現(xiàn)這種問(wèn)題，需要對(duì)client端的性能做監(jiān)控
2、F5的配置有些問(wèn)題，對(duì)于后面機(jī)器的檢測(cè)，只是使用了ping的方法，沒(méi)有檢測(cè)端口導(dǎo)致有一部分的請(qǐng)求會(huì)分發(fā)到有問(wèn)題的機(jī)器（比較理想的請(qǐng)求使用url的應(yīng)用層檢測(cè)）
【小結(jié)】
對(duì)于這類問(wèn)題，可以通過(guò)兩種方式來(lái)troubleshooting，從應(yīng)用出發(fā)和從client端出發(fā)。
兩種方法的思路都是一樣的，首先要清楚的了解整個(gè)的訪問(wèn)鏈，然后對(duì)訪問(wèn)進(jìn)行分解，對(duì)每一步都進(jìn)行檢測(cè)分析。
同時(shí)要注意服務(wù)器qos和用戶端qos的結(jié)合。
