記一次線上問題排查

這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。

day1：

2023年06月21號上午10點，收到運營同事通知，http://**.com/api/訪問量劇增，日誌量達到80g/天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量：

收到通知後立即展開摸排：

1：第一時間登入伺服器，檢視服務狀態。

top命令兩台伺服器的狀態良好。df -h磁碟空間，發現data盤利用率為80%，明顯有點高。

2：postman模擬呼叫線上服務，果不其然503，408錯誤，伺服器基本上接收不了請求，在崩潰的邊緣。

3：備份日誌，重啟服務（在重啟服務之前把日誌備份是乙個良好的習慣）

4：再次請求服務，錯誤依舊。

5：聯絡運營同事，了解實時的請求量。大概80w/分鐘

到這個時候，就知道想短時間恢復服務功能，是不太可能。事情緊急，隨後立即匯報領導（這點很關鍵，這種事情影響比較大，需要立即知會上級，等待上級的處理指示）。

一天10億+的量，實行第6部根本就是無用功，因為這個服務我們只部署了2臺機器，配置是4核8g500m，別說擴一台了，擴幾台都對付不了。

我從日誌裡面費了九牛二虎之力統計出下面結果（awk 命令確實很強大高效）：第一列是請求量，第二列是請求狀態，最後一列是呼叫端。可以很清楚的知道始作俑者是誰了。很快，客戶端定位出是新發的版本存在重複呼叫的bug。

事情到這算是告一段落了。這個時候是2023年06月21號下午3點鐘，中午飯還沒吃（不得不佩服敬業程度啊），不過總算查到原因了，跟服務端沒有直接關係，提著的心總算放下來了。

伺服器已經癱掉，重啟也沒作用。我老大的意思把介面邏輯遮蔽掉，只是記錄日誌。修改**很快打包上線部署，靜觀日誌。

day2：

2023年06月22號上午，接到通知，呼叫端bug已解決，並於昨晚輸出版本（又一聲驚嘆，佩服網際網路之高效率）。聯絡運營檢視介面的訪問情況，分鐘/1w左右。這幾乎算降到乙個正常水平，隨即重新打包，把注釋放開，部署。蛋疼的事發生了，部署幾分鐘後又出現503等錯誤。兩腿一緊。。。

這個量雖然有點偏高，但憑伺服器的效能，對付應該問題不大。趕緊處理吧，又投入到解生產問題的緊張狀態中去了。

登入兩台api伺服器，檢視狀態都是良好，找到lockback日誌，發現error日誌量巨大，不得了，快把磁碟沾滿了。備份出部分，趕緊清理調。可能那會緊張，命令搞錯了（本來應該是echo "" > ***.log），rm -rf ***.log,直接乾掉了日誌檔案。我去，發現事態不對，可為時已晚。賣個關子：知道在高速記日誌的情況下，直接乾掉日誌檔案的後果是什麼嗎？

對的，不多久，發現服務重啟不了，報/tmp/****tomcat**valid錯誤，大概意思是tomcat子模組重啟不成功（專案是springboot構建的，自帶的tomcat容器）。對的，導致這一問題的元凶就是我手動乾掉了日誌檔案，日誌還會繼續寫，但寫的是linux伺服器當前登入的使用者目錄下，對，也就是系統盤，系統盤滿了，所以重啟不了應用了。

花了不少時間，找運營幫忙刪檔案，因為自己沒有root許可權。

檢視錯誤日誌，發現都是mongo連線錯誤，大概的意思是超出了最大500的連線數。想都沒想，直接把最大執行緒連線數改到2000，?waitqueuemultiple=2000。重新發布監控，還是大量丟擲錯誤，錯誤資訊為連線超時。

目前的訪問量為10w/min。看來mongo伺服器還是承載不了。登陸上mongo伺服器，發現cpu使用率一直是399%，看來四核資源都被它占用了。其實這個量對於mongo來說，根本不是問題，為什麼會出現超時呢。登陸進去mongo後台，檢視主要的介面文件資料，每個文件的量大概40w左右。進一步排查介面**，發現**裡面有一段檢索的邏輯。靈光乍現，是不是文件裡面沒有建立索引？檢視，果然如此。立即建立文件幾個唯一業務資料的索引，乙個30個文件，著實花了一段時間。索引建立後，觀察mongo伺服器的狀態，cpu還是沒有下來。

奇怪，難道不是索引的問題？再一次檢視**，發現檢索的都是傳入單個業務字段，而我建立的是復合索引。印個是這個問題。再建吧，30個文件，每個文件建立5個索引。完成後監控伺服器，cpu使用率降至4%左右，完美解決!

後記，通過這次生產事件，讓我反思有很多地方是我們需要改進的：

1：後端介面沒有乙個實時的監控體系，還是運營發現問題通知到，這個是需要我們改進的。

2：對於訪問攻擊，介面應該有基本的防護體系，比如對ip限流等

3：在設計mongo文件的時候，一定記得要規範好索引，別等出現問題的時候再去亡羊補牢。

記一次React線上問題排查

昨天運營報了乙個問題，之前一直正常執行的react專案突然頁面訪問不了了，通過排查發現頁面報錯了，錯誤如下 uncaught typeerror failed to set an indexed property on cssstyledeclaration index property sette...

druid深入學習（記一次線上問題排查）

由於公司線上執行專案突然出現訪問不到介面但是程式執行正常的問題，於是想起了druid連線池，乙個為監控而生的資料庫連線池！問題排查1 加監控 druid 問題排查2 netstat t 檢視tcp埠連線情況，乙個完整的tcp連線有三次握手，四次揮手，期間每個階段對應不同狀態 檢視文章的第二點有詳細描...

記一次問題排查心得

平時程式執行的好好的，昨天收到一則使用者上報，在xp系統下面，程式啟動後彈出 應用程式正常初始化 0xc0150002 失敗，請單擊確定，終止應用程式 遇到這個問題後，在自己的xp虛擬機器裡面呼叫一把，果然也出現這個問題，接下來記錄解決這個問題的全過程。然後就是各種安裝 解除安裝 檢測組合情況，最後...