淺談
- OSS 和雲監控是兩個獨立的産品，但是 OSS 控制台上看到的存儲容量監控以及貸款流量監控來自于雲監控産品的資料。
- OSS 的監控資料延遲 2-3 小時，同時雲監控在采集 OSS 資料時存在視窗期，比如 5 分鐘，如果超過視窗期後，雲監控不在接受過期的資料，同時也不支援補推。
- 是以建議廣大使用者不要用 OSS 控制台的監控和賬單進行對賬，那樣是不準确的。如果要進行對賬，請務必開通 OSS log 的方式去核對 log 日志計算，那樣才是相對準确的值。
案例分析
案例：
雲監控 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=135114002(>)，有效請求率（30.51<90% ），持續時間0分鐘>
請求率規則是 2xx+3xx/總體數量計算出來的，先看下 OSS 控制台的統計 2XX 3XX 以及其他遺産狀态碼的占比确認是否因為異常狀态碼增加導緻的有效請求率下降。
另外最靠譜的就是自己開通 OSS 的日志随時可以分析請求行為。
雲監控報警 404
對象存儲OSS執行個體：Bucket=xum-ali，userId=19733976745，資源不存在錯誤請求數于11:45恢複正常，值為30次，持續時間5分鐘。
規則詳情：報警規則oss_ResourceNotFoundErrorCount，資源不存在錯誤請求數的5分鐘統計值，連續1次滿足表達式目前值>30次
- 這種問題就是 bucket 資源不存在報警，如果上面的方法都是要自己開通 OSS 日志服務子產品來分析，不過這種 404 也是正常的響應，并非是異常狀态。
雲監控出現 NoSuchWebSiteConfigration
出現這種問題是用戶端在請求 OSS 時加載的功能配置不存是以報錯 404 ，是正常請求，不是異常。200 的轉狀态是使用者已經在 OSS 上配置的功能子產品，報警人可以忽略這部分的報錯資訊。
OSS 控制台 API 統計圖無資料
這種情況并不是異常，完成的監控資料都是隔天顯示，目前時間是 10.12 ，完整的資料還沒有出來，是以不能畫點，要等到 13 号才能看到完整的 12 号資料。
通過 OSS 監控計費賬單對比
先了解 OSS 監控
- 概覽看到的當月請求次數有 “GET” 讀去類型，和 “PUT” 寫類型，“GET” 類型包括了 HEAD GET，“PUT” 類型包含了 PUT、DELETE、POST ，這點高搞清楚。
- OSS 的監控是雲監控的資料有 2-3 小時的延遲，用它和賬單計費肯定是不準的。
結論：
準确合理的對賬方式通過兩種途徑：
- 提前開啟 OSS 日志，然後通過 OSS 日志的統計和賬單核對。
- 如果自己不願意核對日志，可以開啟 OSS 的日志分析功能，把 OSS 的日志導入到日志分析處理，直接看結果。
雲監控顯示某個時間段的有效請求率下降為 0，但是 OSS 的 log 以及控制台的監控資料都是正常。
分析
首先要知道源監控有效請求率的計算是 （2x x+3xx)/總請求數量
發現類似情況觀察下 OSS 控制台或者 OSS log 沒有異常即可，出現這種問題是因為 OSS 再收斂整個叢集日志推送到雲監控時超過了雲監控的接收視窗期，而雲監控不支援補推，是以這塊資料調為 0 。
目前 OSS 再 2019-1-1 後對監控資料進行優化可以規避掉這種問題，後續還會持續優化類似場景。