網(wǎng)站故障排查怎么做？我們首先判斷，從故障現(xiàn)象來(lái)看，應(yīng)該和后端無(wú)關(guān)，而是與前端有關(guān)，所以我們迅速查看了前端的日志，從日志來(lái)看，主要是用于判斷客戶端的地理位置接口持續(xù)出現(xiàn)錯(cuò)誤，出現(xiàn)大量的HTTP Status Code 406(24小時(shí)之內(nèi)出現(xiàn)了1w多條)。
網(wǎng)站故障排查怎么做?我們首先判斷，從故障現(xiàn)象來(lái)看，應(yīng)該和后端無(wú)關(guān)，而是與前端有關(guān)，所以我們迅速查看了前端的日志，從日志來(lái)看，主要是用于判斷客戶端的地理位置接口持續(xù)出現(xiàn)錯(cuò)誤，出現(xiàn)大量的HTTP Status Code 406(24小時(shí)之內(nèi)出現(xiàn)了1w多條)。
按照HTTP Status Code的規(guī)范，4開(kāi)頭的錯(cuò)誤碼和客戶端有關(guān)，考慮到這個(gè)故障只出現(xiàn)在一位老師那里，初步判斷406就是問(wèn)題的根源。
隨著掌握信息的增加，分析的加深，我們迅速解決了那位外教的故障，不幸的是，確認(rèn)它和406沒(méi)有關(guān)系。
但是，我們并不能就此打住。畢竟正常情況下響應(yīng)的HTTP Status Code應(yīng)該是200，那么大量的406到底是什么呢?為什么我們都無(wú)法復(fù)現(xiàn)?它們是如何引發(fā)的?如此大量的爆發(fā)應(yīng)當(dāng)引起用戶的反饋了?為什么線上的反饋這么平靜呢?
排查過(guò)程
為了保障性能，我們的 Node 端并沒(méi)有詳細(xì)記錄每個(gè)請(qǐng)求，所以單純看406的日志并不能知道具體的原因。為了排查這個(gè)問(wèn)題，我們緊急發(fā)布了在線補(bǔ)丁，具體記錄每個(gè)請(qǐng)求的詳細(xì)信息，然后在日志平臺(tái)中看到了下面的請(qǐng)求。
于是，我們?cè)?Postman 中模擬了錯(cuò)誤的請(qǐng)求，果然，我們復(fù)現(xiàn)了406錯(cuò)誤，所以可以確認(rèn)問(wèn)題是 Accept 字段導(dǎo)致。
406 Not Acceptable 狀態(tài)碼表示客戶端錯(cuò)誤，表示請(qǐng)求的資源的內(nèi)容特性無(wú)法滿足請(qǐng)求頭中的條件，因而無(wú)法生成響應(yīng)實(shí)體。 譯自HTTP協(xié)議規(guī)范RFC文檔
我們上網(wǎng)查閱資料并也跟后端同事討論了406的錯(cuò)誤碼，得知，如果請(qǐng)求頭的 Accept 不符合事先約定的契約，就會(huì)返回406錯(cuò)誤。報(bào)錯(cuò)的是 API 服務(wù)，返回的是
application/json 格式的數(shù)據(jù)， 然而請(qǐng)求中的 Accept 說(shuō)明它并不支持這種格式，所以會(huì)報(bào)出406錯(cuò)誤。
我們仔細(xì)檢查了常見(jiàn)瀏覽器發(fā)送的請(qǐng)求，發(fā)現(xiàn)全部都包含 Accept: */* ;。看來(lái)，這些引發(fā)406的請(qǐng)求并不是普通用戶發(fā)出來(lái)的。那么，究竟是誰(shuí)發(fā)出了這些請(qǐng)求呢?
難道是CDN?
CDN 的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。 其目的是使用戶可就近取得所需內(nèi)容，解決Internet網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問(wèn)網(wǎng)站的響應(yīng)速度。 CDN 網(wǎng)絡(luò)可以將
服務(wù)器的內(nèi)容緩存到分布全球的CDN節(jié)點(diǎn)，根據(jù)用戶的訪問(wèn) IP，就近連接 CDN，
提高網(wǎng)站響應(yīng)速度。(引用自google
.com)
以上就是小編對(duì)于網(wǎng)站故障排查的解析。
商品已成功加入購(gòu)物車