Object Storage Service：監控、診斷和故障排除

監視總體健全狀態

• 可用性和有效請求率

  可用性和有效請求率是有關係統穩定性和使用者是否正確使用系統的最重要指標，指標小於100%說明某些請求失敗。

  

  可能因為一些系統最佳化因素出現暫時性的低於100%，例如為了負載平衡而出現分區遷移，此時OSS的SDK能夠提供相關的重試機制無縫處理這類間歇性的失敗情況，使得業務端無感知。

  對於有效請求率低於100%的情況，您需要根據自己的使用方式進行分析，可以通過請求分布統計或者請求狀態詳情確定錯誤請求的具體類型、原因，並排除故障。

  對於某些業務情境，出現有效請求率低於100%是符合預期的。例如，使用者需要先檢查訪問的Object是否存在，然後根據Object的存在性採取一定的操作，如果Object不存在，檢測Object存在性的讀取請求會收到404錯誤（資源不存在錯誤），導致該指標項低於100%。

  對於系統可用性指標要求較高的業務，可以對其設定警示規則，當低於預期閾值時，進行警示。

• 總請求數和有效請求數

  該指標從總訪問量角度來反應系統運行狀態，當有效請求數不等於總請求數時表明某些請求失敗。

  

  您可以關注總請求數或者有效請求數的波動狀況，特別是突然上升或者下降的情況，需要進行跟進調查，可以通過設定警示規則進行及時通知。具體操作，請參見警示服務使用指南。

• 請求狀態分布統計

  當可用性或者有效請求率低於100%（或者有效請求數不等於總請求數時），可以通過查看請求狀態分布統計快速確定請求的錯誤類型。有關該統計監控指標的更多資訊，請參見OSS監控指標參考手冊。

  

監視請求狀態詳情

監視效能

對於效能類指標項，您需要重點關注其突發的異常變化。例如，平均延時突然出現尖峰，或者長時間處於高出正常請求延時的基準上方等。您可以通過對效能指標設定對應的警示規則，當指標低於或者超過閾值時及時通知到相關人員。

監視計量

目前，OSS監控服務只支援監控儲存區空間大小、公網流出流量、Put類請求數和Get類請求數（不包括跨地區複製流出流量和CDN流出流量），不支援對計量資料的警示設定和OpenAPI的讀取。

OSS監控服務還提供了使用者層級和Bucket層級兩個不同維度當月消費的資源數統計。即統計阿里雲賬戶或者某個Bucket當月消耗的OSS資源總量，每小時更新一次，協助您瞭解本月資源的使用方式並計算消費。

問題診斷

• 診斷效能

  對於應用程式的效能判斷多帶有主觀因素，您需要根據具體的業務情境確定滿足業務需求的基準線，來判定效能問題。另外，從用戶端發起的請求，能引起效能問題的因素貫穿整個請求鏈路。例如OSS儲存服務負載過大、用戶端TCP配置問題或網路基礎結構中存在的流量瓶頸等。

  因此診斷效能問題首先需要設定合理的基準線，然後通過監控服務提供的效能指標確定效能問題可能的根源位置，然後根據日誌查到詳細的資訊以便進一步診斷並且排除故障。

• 診斷錯誤

  用戶端應用程式會在請求發生錯誤時接收到服務端返回的相關錯誤資訊，監控服務也會記錄並顯示各種錯誤類型請求的計數和佔比。您也可以通過檢查伺服器端日誌、用戶端日誌和部落格來擷取相關單個請求的詳細資料。通常，響應中返回的HTTP狀態碼和OSS錯誤碼以及OSS錯誤資訊都指示請求失敗的原因。

  有關錯誤響應的更多資訊，請參見 OSS錯誤響應。

• 使用日誌功能

  OSS儲存服務為使用者的請求提供服務端日誌記錄功能，能協助使用者記錄端到端的詳細請求日誌跟蹤。

  有關如何開啟並使用日誌功能，請參見設定日誌。

  有關Log Service的命名規則以及記錄格式的更多資訊，請參見設定訪問日誌記錄。

• 使用部落格記錄工具

  在大多數情況下，通過Log Service記錄的儲存日誌和用戶端應用程式的日誌資料已足以診斷問題，但在某些情況下，可能需要更詳細的資訊，這時需要使用部落格記錄工具捕獲用戶端和伺服器之間的流量，可以更詳細地擷取用戶端和伺服器之間交換的資料以及底層網路狀況的詳細資料，協助問題的調查。例如，在某些情況下，使用者請求可能會報告一個錯誤，而伺服器端日誌中卻看不到任何該請求的訪問情況，這時就可以使用OSS的Log Service功能記錄的日誌來調查該問題的原因是否出在用戶端上，或者使用網路監視工具來調查網路問題。

  最常用的部落格分析工具之一是Wireshark。該免費的協議分析器運行在資料包層級，能夠查看各種網路通訊協定的詳細資料包資訊，從而可以排查丟失的資料包和串連問題。

  有關如何使用WireShark的詳情，請參見WireShark使用者指南。

E2E跟蹤診斷

請求從用戶端應用進程發起，通過網路環境，進入OSS服務端被處理，然後響應從服務端回到網路環境，被用戶端接收。整個過程，是一個端到端的跟蹤過程。關聯用戶端應用程式日誌、網路追蹤記錄檔和服務端日誌，有助於排查問題的詳細資料根源，發現潛在的問題。

效能相關常見問題

• 平均E2E延時高，而平均服務端延時低

  前面介紹了平均E2E延時與平均伺服器延時的區別。所以產生高E2E延時、低伺服器延時可能的原因有兩個：

  • 用戶端應用程式響應慢

    • 可用串連數或可用線程數有限

      • 對於可用串連數問題，可以使用相關命令確定系統是否存在大量TIME_WAIT狀態的串連。如果是，可以通過調整核心參數解決。

      • 對於可用線程數有限，可以先查看用戶端CPU、記憶體、網路等資源是否已經存在瓶頸，如果沒有，適當調大並發線程數。

      • 如果還不能解決問題，那麼就需要通過最佳化用戶端代碼。例如，使用非同步訪問方式等。也可以使用效能分析功能分析用戶端應用程式熱點，然後具體最佳化。

    • CPU、記憶體或網路頻寬等資源不足

      對於這類問題，需要先使用相關係統的資源監控查看用戶端具體的資源瓶頸在哪裡，然後通過最佳化代碼使其對資源的使用更為合理，或者擴容用戶端資源（使用更多的核心或者記憶體）。

  • 網路原因導致

    通常，因網路導致的端到端高延遲是由暫時狀況導致的。可以使用Wireshark調查臨時和持久網路問題，例如資料包丟失問題。

• 平均E2E延時低，平均服務端延時低，但用戶端請求延時高

  用戶端出現請求延時高的情況，最可能的原因是請求還未達到服務端就出現了延時。所以應該調查來自用戶端的請求為什麼未到達伺服器。

  對於用戶端延遲發送請求，可能的用戶端的原因有兩個：

  • 可用串連數或可用線程數有限

    • 對於可用串連數問題，可以使用相關命令確定系統是否存在大量TIME_WAIT狀態的串連。如果是，可以通過調整核心參數解決。

    • 對於可用線程數有限，可以先查看用戶端CPU、記憶體、網路等資源是否已經存在瓶頸，如果沒有，適當調大並發線程數。

    • 如果還不能解決問題，那麼就需要通過最佳化用戶端代碼。例如，使用非同步訪問方式等。也可以使用效能分析功能分析用戶端應用程式熱點，然後具體最佳化。

  • 用戶端請求出現多次重試，如果遇到這種情況，需要根據重試資訊具體調查重試的原因再解決。可以通過下面方式確定用戶端是否出現重試：

    • 檢查用戶端日誌，詳細日誌記錄會指示重試已發生過。以OSS的Java SDK為例，可以搜尋如下日誌提示，warn或者info的層級。如果存在該日誌，說明可能出現了重試。

      [Server]Unable to execute HTTP request:
        或者
        [Client]Unable to execute HTTP request:

    • 如果用戶端的記錄層級為debug，以OSS的Java SDK為例，可以搜尋如下日誌，如果存在，那麼肯定出現過重試。

      Retrying on

  如果用戶端沒有問題，則應調查潛在的網路問題，例如資料包丟失。可以使用工具（如Wireshark ）調查網路問題。

• 平均服務端延時高

  對於下載或者上傳出現服務端高延時的情況，可能的原因有2個：

  • 大量用戶端頻繁訪問同一個小Object

    這種情況，可以通過查看日誌功能記錄的服務端日誌資訊來確定是否在一段時間內，某個或某組Object被頻繁訪問。

    對於下載情境，建議使用者為該Bucket開通CDN服務，利用CDN來提升效能，並且可以節約流量費用；對於上傳情境，使用者可以考慮在不影響業務需求的情況下，收回Object或Bucket的寫存取權限。

  • 系統內部因素

    對於系統內部問題或者不能通過最佳化方式解決的問題，請提供用戶端日誌或者日誌功能記錄的日誌資訊中的RequestID，聯絡售後技術人員協助解決。

服務端錯誤問題

網路錯誤問題

在請求過程中，用戶端主動關閉請求或者用戶端網路斷掉都會產生網路錯誤。對於用戶端主動關閉請求的情況，需要調查用戶端中的代碼，瞭解用戶端斷開與儲存服務串連的原因和時間。對於用戶端網路斷掉的情況，使用者可以使用工具（如Wireshark）調查網路連接問題。

用戶端錯誤問題

• 用戶端授權錯誤請求增加

  當監控中的用戶端授權錯誤請求數增加，或者用戶端程式接收到大量的403請求錯誤，那麼最常見的可能原因有以下幾個：

  • 使用者訪問的Bucket網域名稱不正確

    • 如果使用者直接用第三層網域名或者次層網域訪問，那麼可能的原因就是使用者的Bucket並不屬於該網域名稱所指示的region內，例如，使用者建立的Bucket的地區為杭州，但是訪問的網域名稱卻為Bucket.oss-cn-shanghai.aliyuncs.com。這時需要確認Bucket的所屬地區，然後更正網域名稱資訊。

    • 如果使用者開啟了CDN加速服務，那麼可能的原因是CDN綁定的回源網域名稱錯了，請檢查CDN回源網域名稱是否為使用者Bucket的第三層網域名。

    • 如果使用者使用JavaScript用戶端遇到403錯誤，可能的原因就是CORS（跨域資源共用）的設定問題，因為Web瀏覽器實施了“同源策略”的安全限制。使用者需要先檢查所屬Bucket的CORS設定是否正確，並進行相應的更正。有關設定CORS的具體步驟，請參見跨域資源共用。

  • 存取控制問題

    • 使用者使用主AK訪問，那麼使用者需要檢查是否AK設定出錯，使用了無效AK。

    • 使用者使用RAM子帳號訪問，那麼使用者需要確定RAM子帳號是否使用了正確的子AK，或者對應子帳號的相關操作是否已經授權。

    • 使用者使用STS臨時Token訪問，那麼使用者需要確認一下這個臨時Token是否已經到期。如果到期，需要重新申請。

    • 如果Bucket或者Object設定了存取控制，這個時候需要查看使用者所訪問的Bucket或者Object是否支援相關的操作。

  • URL到期

    授權第三方下載，即使用者使用簽名URL進行OSS資源訪問，如果之前訪問正常而突然遇到403錯誤，最大可能的原因是URL已經到期。

  • RAM子帳號使用OSS周邊工具的情況也會出現403錯誤。這類周邊工具如ossftp、ossbrowser、OSS控制台用戶端等，在填寫相關的AK資訊登入時就拋出錯誤，此時如果您的AK是正確填寫的，那麼您需要查看使用的AK是否為子帳號AK，該子帳號是否有GetService等操作的授權等。

• 用戶端資源不存在錯誤請求增加

  用戶端收到404錯誤說明使用者試圖訪問不存在的資源資訊。當看到監控服務上資源不存在錯誤請求增加，那麼最大可能是以下問題導致的：

  • 使用者的業務使用方式。例如使用者需要先檢查Object是否存在來進行下一步動作，可以調用doesObjectExist（以JAVA SDK為例）方法，如果Object不存在，在用戶端則收到false值，但是這時在伺服器端實際上會產生一個404的請求資訊。所以，這種業務情境下，出現404是正常的業務行為。

  • 用戶端或其他進程以前刪除了該對象。這種情況可以通過搜尋logging功能記錄的服務端日誌資訊中的相關對象操作即可確認。

  • 網路故障引起丟包重試。例如用戶端發起一個刪除操作刪除某個Object，此時請求達到服務端，執行刪除成功，但是響應在網路環境中丟包，然後用戶端發起重試，第二次的刪除操作可能就會遇到404錯誤。這種由於網路問題引起的404錯誤可以通過用戶端日誌和服務端日誌確定：

    • 查看用戶端應用日誌是否出現重試請求。

    • 查看服務端日誌是否對該Object有兩次刪除操作，前一次的刪除操作HTTP Status為2xx。

• 有效請求率低且用戶端其他錯誤請求數高

  有效請求率為請求返回的HTTP狀態代碼為2xx/3xx的請求數佔總請求的比例。狀態代碼為4XX和5XX範圍內的請求將計為失敗並降低該比例。用戶端其他錯誤請求是指除服務端錯誤請求（5xx）、網路錯誤請求（499）、用戶端授權錯誤請求（403）、用戶端資源不存在錯誤請求（404）和用戶端逾時錯誤請求（408或者OSS錯誤碼為RequestTimeout的400請求）這些錯誤請求之外的請求。

  您可以通過查看日誌功能記錄的服務端日誌確定這些錯誤的具體類型，之後根據OSS錯誤響應碼在用戶端代碼中尋找具體原因進行解決。詳情請參見OSS錯誤響應。

儲存容量異常增加

其他儲存服務問題