OSS儲存服務提供了全面的監控指標和詳細的日誌記錄功能，協助您深入洞察程式運行行為，快速發現潛在問題，並精準定位故障根源，從而大幅提升問題解決效率。
本文主要描述如何使用OSS監控服務、日誌記錄功能以及其他第三方工具來監控、診斷和排查應用業務使用OSS儲存服務時遇到的相關問題，協助您達到如下目標：
即時監控OSS儲存服務的健全狀態和效能，並及時警示通知。
擷取有效方法和工具來定位問題。
根據相關問題的處理和操作指南，快速解決與OSS相關的問題。
本文包括如下內容：
服務監控
監控總體健全狀態
可用性和有效請求率
可用性和有效請求率是系統穩定性和使用者使用方式的重要指標，低於100%表示存在失敗的請求。
可能因為一些系統最佳化因素出現暫時性的低於100%，例如為了負載平衡而出現分區遷移，此時OSS的SDK能夠提供相關的重試機制無縫處理這類間歇性的失敗情況，使得業務端無感知。
對於有效請求率低於100%的情況，您需要根據自己的使用方式進行分析，可以通過請求分布統計或者請求狀態詳情確定錯誤請求的具體類型、原因，並排除故障。
對於某些業務情境，出現有效請求率低於100%是符合預期的。例如，使用者檢查Object存在性時，若Object不存在，會收到404錯誤，導致指標低於100%。
對於系統可用性要求高的業務，可以設定警示規則，低於閾值時警示。
總請求數和有效請求數
該指標從總訪問量角度來反應系統運行狀態，當有效請求數不等於總請求數時表明某些請求失敗。
您可以關注總請求數或者有效請求數的波動狀況，特別是突然上升或者下降的情況，需要進行跟進調查，可以通過設定警示規則進行及時通知。具體操作，請參見警示服務使用指南。
請求狀態分布統計
當可用性或者有效請求率低於100%（或者有效請求數不等於總請求數時），可以通過查看請求狀態分布統計快速確定請求的錯誤類型。有關該統計監控指標的更多資訊，請參見OSS監控指標參考手冊。
監控請求狀態詳情
請求狀態詳情是在請求狀態分布統計的基礎上進一步細化請求監控狀態，可以更加深入、具體地監控某類請求。
監控效能
監控服務提供了以下監控項來監控效能相關的指標：
平均延時，包括E2E平均延時和伺服器平均延時
延時指標顯示API操作類型處理請求所需的平均和最大時間。其中E2E延時是端到端延遲指標，除了包括處理請求所需的時間外，還包括讀取請求和發送響應所需的時間以及請求在網路上傳輸的延時；而伺服器延時只是請求在伺服器端被處理的時間，不包括與用戶端通訊的網路延時。所以當出現E2E延時突然升高的情況下，如果伺服器延時並沒有很大的變化，那麼可以判定是網路的不穩定因素造成的效能問題，排除OSS系統內部故障。
最大延時，包括E2E最大延時和伺服器最大延時
成功請求操作分類
流量
流量指標從使用者或者具體的Bucket層級的總體情況進行監控，關注公網、內網、CDN回源以及跨域複製等情境中的網路資源佔用狀況。
以上各個監控項（除流量）都分別從API操作類型進行分類監控，包括：
GetObject
HeadObject
PutObject
PostObject
AppendObject
UploadPart
UploadPartCopy
成功請求操作分類除了以上提到的API之外，還提供以下兩個API操作類型請求數量的監控：
DeleteObject
DeleteObjects
對於效能類指標項，您需要重點關注其突發的異常變化。例如，平均延時突然出現尖峰，或者長時間處於高出正常請求延時的基準上方等。您可以通過對效能指標設定對應的警示規則，當指標低於或者超過閾值時及時通知到相關人員。
監控計量
目前，OSS監控服務只支援監控儲存區空間大小、公網流出流量、Put類請求數和Get類請求數（不包括跨地區複製流出流量和CDN流出流量），不支援對計量資料的警示設定和OpenAPI的讀取。
OSS監控服務對Bucket層級的計量監控資料進行小時層級的粒度採集，可以在具體的Bucket監控視圖中查看其持續的監控趨勢圖。您可以根據監控視圖分析其業務的儲存服務資源使用趨勢並且進行成本的預估等。
OSS監控服務還提供了使用者層級和Bucket層級兩個不同維度當月消費的資源數統計。即統計阿里雲賬戶或者某個Bucket當月消耗的OSS資源總量，每小時更新一次，協助您瞭解本月資源的使用方式並計算消費。
有關OSS的計費項目和計費方式的更多資訊，請參見計量項目和計費項目。
說明監控服務中提供的計量資料是盡最大可能推送的，可能會與實際消費賬單不一致，請以費用中心的資料為準。
跟蹤診斷
問題診斷
診斷效能
對於應用程式的效能判斷，您需要根據具體業務情境確定基準線。效能問題可能由OSS儲存服務負載、用戶端TCP配置或網路流量瓶頸引起。首先設定合理的基準線，通過監控服務的效能指標確定問題根源，然後根據日誌進一步診斷和排除故障。
因此診斷效能問題首先需要設定合理的基準線，然後通過監控服務提供的效能指標確定效能問題可能的根源位置，接著根據日誌尋找詳細的資訊以便進一步診斷並且排除故障。
診斷錯誤
用戶端應用程式在請求錯誤時會接收到服務端返回的錯誤資訊，監控服務也會記錄各種錯誤類型。您可以通過檢查伺服器端、用戶端和部落格擷取詳細資料。HTTP狀態碼和OSS錯誤碼指示請求失敗原因。
有關錯誤響應的更多資訊，請參見 OSS錯誤響應。
使用日誌功能
OSS儲存服務提供服務端日誌記錄功能，協助使用者記錄詳細請求日誌。
使用部落格記錄工具
在某些情況下，可能需要使用部落格記錄工具捕獲用戶端和伺服器之間的流量，擷取詳細資料和網路狀況資訊。例如，使用者請求報告錯誤但伺服器端日誌中沒有記錄時，可以使用OSSLog Service或網路監控工具調查問題。常用工具之一是Wireshark，用於查看各種網路通訊協定的詳細資料包資訊。更多資訊，請參見安裝Wireshark和使用WireShark。
E2E跟蹤診斷
請求從用戶端發起，通過網路進入OSS服務端處理，然後響應返回用戶端。關聯用戶端、網路和服務端日誌有助於排查問題根源。OSS提供RequestID作為日誌關聯標識符，通過時間戳記可以迅速尋找和定位日誌範圍，瞭解請求發生時的其他事件，有利於問題分析和調查。
RequestID
OSS為每個請求分配唯一的RequestID。在不同日誌中，RequestID位於不同欄位：
在OSS服務端日誌中，RequestID出現在“Request ID”列中。
在網路跟蹤（如WireShark捕獲的資料流）中，RequestID作為x-oss-request-id標題值出現在響應訊息中。
在用戶端應用中，最新版本的Java SDK支援列印正常請求的RequestID，通過API介面返回的Result結果的getRequestId方法擷取。異常請求的RequestID通過調用OSSException的getRequestId方法擷取。
時間戳記
使用時間戳尋找相關日誌項時，注意用戶端和伺服器之間可能存在的時間偏差。在用戶端上基於時間戳記搜尋伺服器端日誌條目時，應加上或減去15分鐘。
故障排除
效能相關常見問題
平均E2E延時高，而平均服務端延時低
可能原因如下：
用戶端應用程式響應慢
可用串連數或可用線程數有限
使用相關命令檢查系統串連狀態，調整核心參數。
查看用戶端資源瓶頸，適當調大並發線程數，最佳化用戶端代碼。
CPU、記憶體或網路頻寬等資源不足
使用資源監控工具查看資源瓶頸，最佳化代碼或擴容資源。
網路原因
使用Wireshark調查網路問題。
平均E2E延時低，平均服務端延時低，但用戶端請求延時高
用戶端出現請求延時高的情況，最可能的原因是請求還未達到服務端就出現了延時。因此，應該調查來自用戶端的請求為什麼未到達伺服器。
對於用戶端延遲發送請求，可能的用戶端的原因有兩個：
可用串連數或可用線程數有限
檢查系統串連狀態，調整核心參數。
查看用戶端資源瓶頸，適當調大並發線程數，最佳化用戶端代碼。
用戶端請求出現多次重試
檢查用戶端日誌，調查重試原因，使用Wireshark調查網路問題。
檢查用戶端日誌，詳細日誌記錄會指示重試已發生過。以OSS的Java SDK為例，可以搜尋如下日誌提示，warn或者info的層級。如果存在該日誌，說明可能出現了重試。
[Server]Unable to execute HTTP request: 或者 [Client]Unable to execute HTTP request:如果用戶端的記錄層級為debug，以OSS的Java SDK為例，可以搜尋如下日誌，如果存在，那麼肯定出現過重試。
Retrying on
平均服務端延時高
對於下載或者上傳出現服務端高延時的情況，可能的原因有2個：
大量用戶端頻繁訪問同一個小Object
查看服務端日誌，考慮開通CDN服務或調整存取權限。
系統內部因素
提供用戶端日誌，聯絡售後技術人員協助解決。
服務端錯誤問題
暫時性的增加
調整用戶端重試策略，採用合理的退讓機制。
永久性的增加
提供用戶端日誌，聯絡售後技術人員協助調查。
網路錯誤問題
網路錯誤是指服務端正在處理請求時，串連在非伺服器端斷開而來不及返回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到期
授權第三方下載，即使用者使用簽名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錯誤響應。
儲存容量異常增加
儲存容量異常增加，如果不是上傳類請求量增多，常見的原因應該是清理操作出現了問題，可以根據下面兩個方面進行調查：
用戶端應用使用特定的進程定期清理來釋放空間。針對這種請求的調查步驟是：
查看有效請求率指標是否下降，因為失敗的刪除請求會導致清理操作沒能按預期完成。
定位請求有效率降低的具體原因，查看具體是什麼錯誤類型的請求導致。然後還可以結合具體的用戶端日誌定位更詳細的錯誤資訊（例如，用於釋放空間的STS臨時Token已到期）。
用戶端通過設定LifeCycle來清理空間：針對這種請求，需要通過控制台或者API介面查看目前Bucket的LifeCycle是否為之前設定的預期值。如果不是，可以直接更正目前配置；進一步的調查可以通過Logging功能記錄的服務端日誌查詢以前修改的具體資訊。如果LifeCycle是正常的，但是卻沒有生效，請聯絡OSS系統管理員協助調查。
其他儲存服務問題
如果前面的故障排除章節未包括您遇到的儲存服務問題，則可以採用以下方法來診斷和排查您的問題：
查看OSS監控服務，瞭解與預期的基準行為相比是否存在任何更改。監控視圖可能能夠確定此問題是暫時的還是永久性的，並可確定此問題影響哪些儲存操作。
使用監控資訊來協助您搜尋日誌功能記錄的服務端日誌資料，擷取相關時間點發生的任何錯誤資訊。此資訊可能會協助您排查和解決該問題。
如果伺服器端日誌中的資訊不足以成功排查此問題，則可以使用用戶端日誌來調查用戶端應用程式，或者使用網路工具（Wireshark等）調查您的網路問題。