銷售: 1-800-867-1380

取得 Blob 服務統計資料

更新日期: 2014年11月

Get Blob Service Stats作業會擷取與 Blob 服務的複寫相關的統計資料。當儲存體帳戶啟用讀取權限的地理備援複寫時,它只能用於次要位置端點。

Get Blob Service Stats 要求的建構如下。建議使用 HTTPS。請以您的儲存體帳戶名稱取代 myaccount,並注意需要 -secondary 尾碼:

 

方法 要求 URI HTTP 版本

GET

https://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats

HTTP/1.1

請注意,URI 一律需包含正斜線 (/),將主機名稱與 URI 的路徑和查詢部分隔開。若為這項作業,URI 的路徑部分為空白。

您可以在要求的 URI 中指定下列其他參數。

 

參數 描述

Timeout

選擇性。timeout 參數以秒為單位。

下表描述必要的和選用的要求標頭。

 

要求標頭 描述

Authorization

必要項。指定驗證配置、帳戶名稱及簽章。如需���細資訊,請參閱 Azure 儲存體服務的驗證

Date or x-ms-date

必要項。指定要求的國際標準時間 (UTC)。如需���細資訊,請參閱 Azure 儲存體服務的驗證

x-ms-version

所有已驗證要求的必要項。指定用於這個要求的作業版本。如需詳細資訊,請參閱為 Azure 中的 Blob、佇列和表格服務進行版本設定

x-ms-client-request-id

選擇性。當啟用儲存體分析記錄時,用戶端會產生不透明的值,而且在分析記錄中有 1KB 的字元限制。要將用戶端活動與伺服器收到的要求產生關聯時,極力建議您使用這個標頭。如需詳細資訊,請參閱 Azure 記錄:使用記錄檔追蹤儲存體需求

無。

回應包括 HTTP 狀態碼、一組回應標頭和回應主體

成功的作業會傳回狀態碼 200 (確定)。在未啟用次要讀取的次要位置端點上呼叫時,它會傳回 Http 狀態碼 403 與 InsufficientAccountPermissions 錯誤。

如需有關狀態碼的詳細資訊,請參閱服務管理狀態和錯誤碼

這項作業的回應包括下列標頭。此回應也包含其他標準 HTTP 標頭。所有標準標頭都符合 HTTP/1.1 通訊協定規格

 

回應標頭

描述

x-ms-request-id

此標頭可唯一識別提出的要求,而且可用來進行要求的疑難排解。如需詳細資訊,請參閱對應用程式開發介面作業進行疑難排解

x-ms-version

指定用於回應的作業版本。如需詳細資訊,請參閱為 Azure 中的 Blob、佇列和表格服務進行版本設定

Date

服務產生的 UTC 日期/時間值,可指出啟動回應的時間。

回應主體的格式如下:

<?xml version="1.0" encoding="utf-8"?> <StorageServiceStats>   <GeoReplication>             <Status>live|bootstrap|unavailable</Status>       <LastSyncTime>sync-time|<empty></LastSyncTime>   </GeoReplication> </StorageServiceStats>

下表描述回應主體的元素:

 

回應標頭

描述

Status

次要位置的狀態。可能的值為:

  • live:指出次要位置為作用中而且可以運作。

  • bootstrap:表示從主要位置初始同步處理到次要位置的作業在進行中。這通常發生在最初啟用複寫時。

  • 無法使用:表示次要位置暫時無法使用。

LastSyncTime

GMT 日期/時間值 (到秒值)。這個值前面的所有主要寫入保證都可在次要位置供讀取作業使用。這個點後面的主要寫入不一定可供讀取作業使用。

如果無法使用 LastSyncTime,這個值可能是空的。如果複寫狀態為 bootstrapunavailable,就可能會發生這個情況。

雖然持續啟用地理複寫,但是 LastSyncTime 結果可能會反映服務中每隔幾分鐘重新整理一次的快取值。

只有帳戶擁有者可呼叫這項作業。

有了地理備援複寫,Azure 儲存體會以持久的方式在兩個位置維護您的資料。在這兩個位置中,Azure 儲存體會持續維護狀況良好的多個資料複本。

您讀取、建立、更新或刪除資料的位置是「主要」儲存體帳戶的位置。主要位置存在於您透過 Azure 管理入口網站建立帳戶時所選擇的地區,例如 [美國中北部]。資料複寫的目標位置是「次要」位置。次要位置是根據主要的位置自動判斷而來,它是與主要位置位於相同地區的第二個資料中心。當儲存體帳戶啟用「讀取權限的地理備援複寫」時,可從次要位置使用唯讀權限。如需有關「讀取權限的地理備援複寫」的詳細資訊,請參閱 Azure 儲存體團隊部落格

若要針對次要端點建構讀取作業的要求,請將 -secondary 當做尾碼附加到帳戶名稱,此名稱位於您用來從 Blob 儲存體讀取的 URI 內。例如,取得 Blob (REST 應用程式開發介面) 作業的次要 URI 將類似於 https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob

以下顯示Get Blob Service Stats作業的範例要求:

GET http://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats HTTP/1.1

所傳送的要求包含下列標頭:

x-ms-version: 2013-08-15 x-ms-date: Wed, 23 Oct 2013 22:08:44 GMT Authorization: SharedKey myaccount:CY1OP3O3jGFpYFbTCBimLn0Xov0vt0khH/E5Gy0fXvg=

傳回的狀態碼和回應標頭如下:

HTTP/1.1 200 OK Content-Type: application/xml Date: Wed, 23 Oct 2013 22:08:54 GMT x-ms-version: 2013-08-15 x-ms-request-id: cb939a31-0cc6-49bb-9fe5-3327691f2a30 Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

回應包含下列 XML 主體:

<?xml version="1.0" encoding="utf-8"?> <StorageServiceStats>   <GeoReplication>       <Status>live</Status>       <LastSyncTime> Wed, 23 Oct 2013 22:05:54 GMT</LastSyncTime>         </GeoReplication> </StorageServiceStats>

另請參閱

本文對您有任何幫助嗎?
(剩餘 1500 個字元)
感謝您提供意見
顯示:
© 2015 Microsoft