【OSS 排查方案-11 監控】

摘要： 場景：雲監控 OSS 出現 "資料不足" 先看下 OSS 控制檯的監控的 http code 、以及 QPS 分析，如果 OSS 請求量比較小，而 OSS 對應的時間點有沒有請求就會出現資料不足的情況，這種問題最好設定合理的監控資料上報時間。 場景：雲監控發現...

場景：雲監控 OSS 出現 "資料不足"

先看下 OSS 控制檯的監控的 http code 、以及 QPS 分析，如果 OSS 請求量比較小，而 OSS 對應的時間點有沒有請求就會出現資料不足的情況，這種問題最好設定合理的監控資料上報時間。

場景：雲監控發現上傳下載延遲

• 這種情況是雲監控產品節點發起的探測請求，不能完全代表真實的 OSS 使用者，最好能夠以真實的業務請求為準，或者真實的客戶端在訪問發生延遲時，客戶端部署抓包看下為什麼有延遲。
• 使用 OSS的日誌功能，開始日誌後，OSS 的所有者可以自行通過日誌進行分析。看下處理時間是否真的有延遲。

場景：使用者自己監控系統發現請求有延遲

有的公司技術支援比較全面自己做了一套監控系統可以監控 OSS公網全鏈路，但是監控的只是網路傳輸的時間，可以輔助的去看問題，但是不可全信，當發現有延遲時。

• 公網的鏈路無法保證，做好能切到阿里雲主機上，使用同 region 的 OSS 域名進行訪問比較靠譜，如果有原因不能切到內網，需要進一步再確認。
• 提供上傳延遲的 OSS requestID ，通過這個可以讓阿里雲查下出現問題的處理時間是否真延遲。
• 客戶端肯定要抓包了，所有網路問題都逃不了抓包，傳授一個抓包技巧
• tcpdump -i <出口網絡卡> -s0 ( 本機出口IP and OSS域名 ) -w result.pcap

場景：有效請求率降低

物件儲存 OSS (<)Bucket=p2xxx，userId=1351655700114002(>)，有效請求率（30.51<90% ），持續時間0分鐘>

請求率規則是 2xx+3xx/總體數量計算出來的，先看下 OSS 控制檯的統計 2XX 3XX 以及其他遺產狀態碼的佔比確認是否因為異常狀態碼增加導致的有效請求率下降。

另外最靠譜的就是自己開通 OSS 的日誌隨時可以分析請求行為。