在做運(yùn)維工作時(shí)，或多或少都會(huì)遇到訪(fǎng)問(wèn)出錯(cuò)或緩慢問(wèn)題，這里以?xún)蓚€(gè)小的例子來(lái)簡(jiǎn)單說(shuō)明下這類(lèi)問(wèn)題的troubleshooting的思路。

1.用戶(hù)查詢(xún)平臺(tái)故障一例 查詢(xún)平臺(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),正常。 連接方法:

1	!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)一步分析。

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）再來(lái)看nginx的訪(fǎng)問(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)控）
2.推薦域名訪(fǎng)問(wèn)故障問(wèn)題 故障現(xiàn)象： 用戶(hù)訪(fǎng)問(wèn)緩慢，一個(gè)url有時(shí)響應(yīng)超過(guò)3s，并且會(huì)有一定的幾率abort. 域名整個(gè)的訪(fǎng)問(wèn)流程： client-----cdn-----內(nèi)部cdn節(jié)點(diǎn)-----源站（F5--nginx---java----redis---db） 從用戶(hù)端開(kāi)始入手： 1）通過(guò)curl xxxx --trace-time --verbose來(lái)查看訪(fǎng)問(wèn)時(shí)間的變化情況，單一請(qǐng)求時(shí)間3s，漸變點(diǎn)在用戶(hù)等待服務(wù)器響應(yīng)上 2）用戶(hù)與cdn服務(wù)器連通性沒(méi)有問(wèn)題（延遲5ms以?xún)?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)行訪(fǎng)問(wèn)測(cè)試，發(fā)現(xiàn)有一定的幾率abort 6）在client端通過(guò)tcpdump抓包，發(fā)現(xiàn)client---server連接建立正常，但是server端有一定的概率會(huì)返回RST給client，造成abort的產(chǎn)生
即用戶(hù)到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的訪(fǎng)問(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ì)于這類(lèi)問(wèn)題，可以通過(guò)兩種方式來(lái)troubleshooting，從應(yīng)用出發(fā)和從client端出發(fā)。 兩種方法的思路都是一樣的，首先要清楚的了解整個(gè)的訪(fǎng)問(wèn)鏈，然后對(duì)訪(fǎng)問(wèn)進(jìn)行分解，對(duì)每一步都進(jìn)行檢測(cè)分析。 同時(shí)要注意服務(wù)器qos和用戶(hù)端qos的結(jié)合。

本文轉(zhuǎn)自菜菜光 51CTO博客，原文鏈接：http://blog.51cto.com/caiguangguang/1393707，如需轉(zhuǎn)載請(qǐng)自行聯(lián)系原作者

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。