相對於傳統應用程式，開發雲端應用雖然降低了用戶在基礎設施搭建、運維等方面的成本，但卻增大了監控、診斷和故障排查的難度。OSS儲存服務為您提供了豐富的監控和日誌資訊，幫助您深刻洞察程式行為，及時發現並快速定位問題。

概述

本文主要描述如何使用OSS監控服務、日誌記錄功能以及其他第三方工具來監控、診斷和排查應用業務使用OSS儲存服務時遇到的相關問題，幫助您達到如下目標：

  • 即時監控OSS儲存服務的健全狀態和性能，並及時報警通知。
  • 獲取有效方法和工具來定位問題。
  • 根據相關問題的處理和操作指南，快速解決與OSS相關的問題。

本文包括如下內容：

  • 服務監控，介紹如何使用OSS監控服務持續監控OSS儲存服務的健全狀態和性能。
  • 跟蹤診斷，介紹如何使用OSS監控服務和logging記錄功能診斷問題；另外，還介紹如何關聯各種記錄檔中的相關資訊進行跟蹤診斷。
  • 故障排除，提供常見的問題場景和故障排除方法。


服務監控

監視總體健全狀態
  • 可用性和有效請求率

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

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

    另外，對於有效請求率低於100%的情況，用戶需要根據自己的使用方式進行分析，可以通過請求分布統計或者請求狀態詳情確定錯誤請求的具體類型，跟蹤診斷確定原因，並故障排除。當然，對於一些業務場景，出現有效請求率低於100%是符合預期的，比如，用戶需要先check訪問的object是否存在，然後根據object的存在性採取一定的操作，如果object不存在，檢測object存在性的讀取請求必然會收到404錯誤（資源不存在錯誤），那麼必然會導致該指標項低於100%。

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

  • 總請求數和有效請求數

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



    用戶可以關注總請求數或者有效請求數的波動狀況，特別是突然上升或者下降的情況，需要進行跟進調查，可以通過設定報警規則進行及時通知，對於存在周期性狀況的業務，可以設定為環比報警規則（環比報警方式即將上線），詳見報警服務使用指南。

  • 請求狀態分布統計

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



監視請求狀態詳情

請求狀態詳情在請求狀態分布統計的基礎上進一步細化請求監控狀態，可以更加深入、具體地監視某類請求。



監視性能

監控服務提供了以下幾個監控項用來監控性能相關的指標。

  • 平均延時，包括E2E平均延時和伺服器平均延時

  • 最大延時，包括E2E最大延時和伺服器最大延時

  • 成功請求操作分類

  • 流量

    以上各個監控項（除流量）都分別從API操作類型進行分類監控：

    • GetObject
    • HeadObject
    • PutObject
    • PostObject
    • AppendObject
    • UploadPart
    • UploadPartCopy

    延時指標顯示API操作類型處理請求所需的平均和最大時間。其中E2E延時是端到端延遲指標，除了包括處理請求所需的時間外，還包括讀取請求和發送響應所需的時間以及請求在網路上傳輸的延時；而伺服器延時只是請求在伺服器端被處理的時間，不包括與客戶端通訊的網路延時。所以當出現E2E延時突然升高的情況下，如果伺服器延時並沒有很大的變化，那麼可以判定是網路的不穩定因素造成的性能問題，排除OSS系統內部故障。

    成功請求操作分類除了以上提到的API之外，還提供以下兩個API操作類型請求數量的監控：

    • DeleteObject
    • DeleteObjects

    流量指標從用戶或者具體的Bucket層級的總體情況進行監控，關注公網、內網、cdn回源以及跨域複製等場景中的網路資源佔用狀況。

    對於性能類指標項，需要重點關注其突發的異常變化，例如，平均延時突然出現尖峰，或者長時間處於高出正常請求延時的基準上方等等。用戶可以通過對性能指標設定對應的報警規則，對於低於或者超過閾值時及時通知到相關人員。對於有業務周期性的業務，可以設定環比報警規則(環比一周、環比一天或者環比一個小時，環比報警方式即將上線)。

監視計量

攥寫本文檔時，OSS監控服務只支援監控儲存區大小、公網流出流量、Put類請求數和Get類請求數（不包括跨區域複製流出流量和cdn流出流量），而且不支援對計量數據的報警設定和OpenAPI的讀取。

OSS監控服務對Bucket層級的計量監控數據進行小時等級的粒度採集，可以在具體的Bucket監控視圖中查看其持續的監控趨勢圖。用戶可以根據監控視圖分析其業務的儲存服務資源使用趨勢並且進行成本的預估等。如下所示：



OSS監控服務還提供了用戶層級和Bucket層級兩個不同維度當月消費的資源數統計。即從當月1號開始到目前的賬戶或者某個Bucket所消耗的OSS資源總量，每小時更新，幫助用戶即時了解本月使用資源的情況並計算消費。

OSS的消費計算請參考計量項和計費項。
说明
監控服務中提供的計量數據是盡最大可能推送的，可能會與實際消費賬單中產生差異，請以費用中心的數據為準。

跟蹤診斷

問題診斷
  • 診斷性能

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

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

    在下文故障排除中例舉了常見的性能問題和排查措施，可以參考。

  • 診斷錯誤

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

    相關錯誤響應資訊請參考 OSS錯誤響應。

  • 使用Logging功能

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

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

    有關Log Service的命名規則以及記錄格式等詳細資料，請參見設定訪問日誌記錄。

  • 使用部落格記錄工具

    在許多情況下，通過Logging功能記錄的儲存日誌和用戶端應用程式的日誌數據已足以診斷問題，但在某些情況下，可能需要更詳細的資訊，這時需要使用部落格記錄工具。

    捕獲客戶端和伺服器之間的流量，可以更詳細地獲取客戶端和伺服器之間交換的數據以及底層網路狀況的詳細資料，幫助問題的調查。例如，在某些情況下，用戶請求可能會報告一個錯誤，而伺服器端日誌中卻看不到任何該請求的訪問情況，這時就可以使用OSS的Log Service功能記錄的日誌來調查該問題的原因是否出在客戶端上，或者使用網路監視工具來調查網路問題。

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

    更詳細的WireShark操作請參見WireShark用戶指南。

E2E跟蹤診斷

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

在OSS儲存服務中，提供了RequestID作為關聯各處日誌資訊的標識符。另外，通過日誌的時間戳記，不僅可以迅速尋找和定位日誌範圍，還能夠了解在請求發生時間點範圍內，客戶端應用、網路或者服務系統發生的其他事件，有利於問題的分析和調查。

  • RequestID

    OSS服務始會為接收的每個請求分配唯一的伺服器請求ID，即RequestID。在不同的日誌中，RequestID位於不同的欄位中:

    • 在OSS logging功能記錄的服務端日誌記錄中，RequestID出現在“Request ID”列中。
    • 在網路跟蹤（如WireShark捕獲的資料流）中，RequestID作為x-oss-request-id標題值出現在響應消息中。
    • 在客戶端應用中，需要客戶端code實現的時候將請求的RequestID自行列印到客戶端日誌中。在攥寫本文的時候，最新版本的JAVA SDK已經支援列印正常請求的RequestID資訊，可以通過各個API介面返回的Result結果的getRequestId這個方法獲取。OSS的各個版本SDK都支援列印出異常請求的RequestID，可以通過調用OSSException的getRequestId方法獲取。
  • 時間戳記

    使用時間戳來尋找相關日誌項，需要注意客戶端和伺服器之間可能存在的時間偏差。在客戶端上基於時間戳記搜索logging功能記錄的伺服器端日誌條目時，應加/減15分鐘。

故障排除

性能相關常見問題
  • 平均E2E延時高，而平均服務端延時低

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

    • 用戶端應用程式響應慢。
    • 網路原因導致。
    用戶端應用程式響應速度慢的可能原因包括：

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

      • 對於可用串連數問題，可以使用相關命令確定系統是否存在大量TIME_WAIT狀態的串連。如果是，可以通過調整核心參數解決。
      • 對於可用線程數有限，可以先查看客戶端CPU、記憶體、網路等資源是否已經存在瓶頸，如果沒有，適當調大並發線程數。
      • 如果還不能解決問題，那麼就需要通過優化客戶端代碼，比如，使用非同步訪問方式等。也可以使用性能分析功能分析用戶端應用程式熱點，然後具體優化。

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

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

    網路延遲的可能原因是：

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

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

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

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

    • 可用串連數或可用線程數有限，在上面章節已經描述過解決方案。

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

      • 檢查客戶端日誌。詳細日誌記錄會指示重試已發生過。以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。

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

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

    • 系統內部因素。

      對於系統內部問題或者不能通過優化方式解決的問題，請提供客戶端日誌或者Loggging功能記錄的日誌資訊中的RequestID，聯繫系統工作人員協助解決。

服務端錯誤問題

對於服務端錯誤的增加，可以分為兩個場景考慮：

  • 暫時性的增加

    對於這一類問題，用戶需要調整用戶端程式中的重試策略，採用合理的退讓機制，例如指數退避。這樣不僅可以有效避免因為優化或者升級等系統操作（如為了系統負載平衡進行分區遷移等）暫時導致的服務不可用問題，還可以避開業務峰值的壓力。

  • 永久性的增加

    如果服務端錯誤持續在一個較高的水平，那麼請提供客戶端日誌或者Logging功能記錄的RequestID，聯繫後台工作人員協助調查。

網路錯誤問題

網路錯誤是指服務端正在處理請求時，串連在非伺服器端斷開而來不及返回HTTP要求標頭的情況。此時系統會記錄該請求的HTTP狀態碼為499。以下幾種情況會導致伺服器記錄請求的狀態碼變為499:

  • 伺服器在收到讀寫請求處理之前，會檢查串連是否可用，不可用則為499.
  • 伺服器正在處理請求時，客戶端提前關閉了串連，此時請求被記錄為499.

總之，在請求過程中，客戶端主動關閉請求或者客戶端網路斷掉都會產生網路錯誤。對於客戶端主動關閉請求的情況，需要調查客戶端中的代碼，了解客戶端斷開與儲存服務串連的原因和時間。對於客戶端網路斷掉的情況，用戶可以使用工具（如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進行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請求）這些錯誤請求之外的請求。

    可以通過查看Logging功能記錄的服務端日誌確定這些錯誤的具體類型，可以在OSS錯誤響應上找到儲存服務返回的常見錯誤碼的列表，然後檢查客戶端代碼中尋找具體原因進行解決。

儲存容量異常增加

儲存容量異常增加，如果不是上傳類請求量增多，一般常見的原因應該是清理操作出現了問題，可以根據下面兩個方面進行調查:

  • 客戶端應用使用特定的進程定期清理來釋放空間。針對這種請求的調查步驟是:

    1. 查看有效請求率指標是否下降，因為失敗的刪除請求會導致清理操作沒能按預期完成。
    2. 定位請求有效率降低的具體原因，查看具體是什麼錯誤類型的請求導致。然後還可以結合具體的客戶端日誌定位更詳細的錯誤資訊（例如，用於釋放空間的STS臨時Token已過期）。

  • 客戶端通過設定LifeCycle來清理空間：針對這種請求，需要通過控制台或者API介面查看目前Bucket的LifeCycle是否為之前設定的預期值。如果不是，可以直接更正目前配置；進一步的調查可以通過Logging功能記錄的服務端日誌記錄查詢以前修改的具體資訊。如果LifeCycle是正常的，但是卻沒有生效，請聯繫OSS系統管理員協助調查。

其他儲存服務問題

如果前面的故障排除章節未包括您遇到的儲存服務問題，則可以採用以下方法來診斷和排查您的問題：

  1. 查看OSS監控服務，了解與預期的基準行為相比是否存在任何更改。監控視圖可能能夠確定此問題是暫時的還是永久性的，並可確定此問題影響哪些儲存操作。
  2. 使用監控資訊來幫助您搜索Logging功能記錄的服務端日誌數據，獲取相關時間點發生的任何錯誤資訊。此資訊可能會幫助您排查和解決該問題。
  3. 如果伺服器端日誌中的資訊不足以成功排查此問題，則可以使用客戶端日誌來調查用戶端應用程式，或者配合使用網路工具（Wireshark等）調查您的網路問題。