建站
咨詢
售后
建站咨詢
新聞中心
Hello 大家好，我是阿粉，工作這么多年雖然經(jīng)歷過風(fēng)風(fēng)雨雨，但是每次線上發(fā)布版本的時候都是一場硬戰(zhàn)，這不最近發(fā)布了一個版本，一不小心寫了個 bug，差點造成了生產(chǎn)事故，幸好運維老大發(fā)現(xiàn)及時。
背景
事情是這樣的，上周的一個早上阿粉高高興興的上班，剛到座位上早飯都還沒來得及吃，就收到一條企業(yè)微信，是運維老大發(fā)來的，說有個服務(wù) A 的 nginx 日志暴增。從平時的每天 133M 一下子暴增到 29G，看到這里突然想起來前一天剛好發(fā)過版本，一下子早餐也吃不下了，趕緊拿著電腦跑到運維那邊排查問題。
首先找到對應(yīng)服務(wù) A 的 nginx 日志，通過命令 tail -f xxx.log 查看日志數(shù)據(jù)，發(fā)現(xiàn)日志里面輸出最多的是對一個獲取配置信息的接口的調(diào)用。這個接口是一個很簡單的接口，就是加載數(shù)據(jù)庫的數(shù)據(jù)存入緩存，然后對外提供接口訪問，本身不存在業(yè)務(wù)邏輯。確定了接口以后，通過 nginx 日志看到請求都是來自一個核心的服務(wù) B。
到這里基本上可以斷定是服務(wù) B 的邏輯有問題了，問題的方向已經(jīng)確定下來了。定位了一下在服務(wù) B 中調(diào)用了該接口的地方，總共有兩處，一處是每五分鐘調(diào)用一次，進行內(nèi)存緩存，這塊的邏輯是一直都有的，不會有問題;另一處是一個自定義的普羅米修斯的指標采集，普羅米修斯每 15 秒會進行一次數(shù)據(jù)的采集，這么一想那問題肯定是出在這里了。
看了一下邏輯，這塊的代碼是做了一個自定義的指標采集，用于在 Grafana 上面采集相應(yīng)的數(shù)據(jù)，剛好生產(chǎn)上有 Prometheus 每 15 秒 Pull 一次數(shù)據(jù)，再加上生產(chǎn)環(huán)境的數(shù)據(jù)量較大，這段代碼里面調(diào)用接口的邏輯寫在了一個循環(huán)里面，從而導(dǎo)致了，每 15 秒會觸發(fā)一次循環(huán)，每次循環(huán)的數(shù)據(jù)量很大并且每次都調(diào)用接口，并且服務(wù) B 還是多實例部署，導(dǎo)致接口的調(diào)用次數(shù)暴增，從而引發(fā)了此次”血案“。
問題定位出來了，解決就比較簡單了，將接口的調(diào)用從循環(huán)體內(nèi)遷移到外面，方案做了一些變動，改完過后合并了一下代碼，打了一個 tag，升級了其中一臺服務(wù)器進行觀察，發(fā)布完過后，整個接口調(diào)用的次數(shù)就下降了，觀察了一會沒有異常就全網(wǎng)了。
復(fù)盤
事后對這個問題做了一下復(fù)盤，事故的本身沒有引起業(yè)務(wù)的異常，但是還好發(fā)現(xiàn)的早，不然每天產(chǎn)生如此大的日志量遲早會占滿磁盤空間出事情。再深度復(fù)查一下發(fā)現(xiàn)接入普羅米修斯的這塊自定義指標其實并沒有實際使用價值，這塊的邏輯前前后后改動過好多版本，但是沒有一個最終的版本，不知道在哪個版本將代碼提交上去了。這也體現(xiàn)出我們的版本規(guī)劃是有問題的，很多需求前前后后經(jīng)常變動和插入，沒有嚴格的按照版本執(zhí)行也是導(dǎo)致此次問題的一個重要原因。
這里也提醒一下大家一定要嚴格按照版本迭代進行開發(fā)和發(fā)布。不然哪天踩了這樣的坑就比較尷尬了。
工作中難免會出現(xiàn)失誤，但是有些失誤能犯有些不能犯，每個程序員都會寫出 bug，寫出 bug 問題不大，但是能不能及時解決就很關(guān)鍵了。真正影響到線上業(yè)務(wù)的 bug，時間就是金錢，多消耗一分鐘就損失一分鐘的錢，有的時候一分鐘的錢沒多少，有的時候一分鐘的錢足以倒閉一家公司。
所以我們每個程序員都應(yīng)該要敬畏線上。
網(wǎng)頁名稱：通過循環(huán)就可以搞垮服務(wù)器
網(wǎng)頁地址：http://www.dlmjj.cn/article/djepcpi.html
