次の方法で共有

Get Blob Service Stats

  • [アーティクル]

操作はGet Blob Service Stats、Azure Blob Storageのレプリケーションに関連する統計を取得します。 この操作は、ストレージ アカウントに対して読み取りアクセス geo 冗長レプリケーションが有効になっている場合に、セカンダリ ロケーション エンドポイントでのみ使用できます。

要求

要求は Get Blob Service Stats 次のように構築できます。 HTTPS を使用することをお勧めします。 myaccount をストレージ アカウントの名前で置き換えます。-secondary サフィックスが必要です。

Method 要求 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 Storage への要求を承認する」をご覧ください。
Date or x-ms-date 必須。 要求に対して協定世界時 (UTC) を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
x-ms-version すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 詳細については、「Azure Storage サービスのバージョン管理」を参照してください。
x-ms-client-request-id 省略可能。 ログ記録の構成時にログに記録される 1 kibibyte (KiB) 文字制限を使用して、クライアントによって生成された不透明な値を提供します。 このヘッダーを使用して、クライアント側のアクティビティとサーバーが受信する要求を関連付けるよう強くお勧めします。 詳細については、「Azure Blob Storageの監視」を参照してください。

要求本文

[なし] :

Response

応答は、HTTP ステータス コード、一連の応答ヘッダー、および応答本文で構成されます。

status code

操作に成功すると、状態コード 200 (OK) が返されます。 セカンダリの読み取りが有効になっていないセカンダリロケーション エンドポイントで操作が呼び出されると、エラーで HTTP 状態コード 403 が InsufficientAccountPermissions 返されます。

応答ヘッダー

この操作の応答には、次のヘッダーが含まれています。 応答には追加の標準 HTTP ヘッダーも含まれます。 すべての標準ヘッダーは 、HTTP/1.1 プロトコル仕様に準拠しています。

応答ヘッダー 説明
x-ms-request-id 行われた要求を一意に識別し、それを使用して要求のトラブルシューティングを行うことができます。 詳細については、「 API 操作のトラブルシューティング」を参照してください。
x-ms-version 応答に使用される操作のバージョンを指定します。 詳細については、「Azure Storage サービスのバージョン管理」を参照してください。
Date サービスによって生成される UTC 日付/時刻値。応答が開始された時刻を示します。
x-ms-client-request-id 要求とそれに対応する応答のトラブルシューティングに使用できます。 このヘッダーの値 x-ms-client-request-id は、要求に存在し、ASCII 文字が 1,024 文字以下の場合、ヘッダーの値と等しくなります。 ヘッダーが x-ms-client-request-id 要求に存在しない場合、このヘッダーは応答に存在しません。

応答本文

応答本文の形式は次のとおりです。

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

応答本文の要素を次の表に示します。

応答ヘッダー 説明
Status 2 次拠点の状態。 次のいずれかの値になります。

- live: セカンダリの場所がアクティブで操作可能であることを示します。
- bootstrap: プライマリロケーションからセカンダリロケーションへの初期同期が進行中であることを示します。 これは通常、レプリケーションが最初に有効になったときに発生します。
- 使用不可: セカンダリの場所が一時的に使用できないことを示します。
LastSyncTime GMT での秒単位の日付/時刻の値です。 この値より前のすべてのプライマリ書き込みでは、セカンダリでの読み取り操作が可能であることが保証されます。 この時点以降のプライマリ書き込みでは、読み取りに使用できる場合と使用できない場合があります。

が使用できない場合は、値が空である可能性 LastSyncTime があります。 これは、レプリケーションの状態が bootstrap または unavailable の場合に発生する可能性があります。

geo レプリケーションは継続的に有効になっていますが、 LastSyncTime 結果にはサービスからのキャッシュされた値が反映され、数分ごとに更新される場合があります。

承認

Azure Storage でデータ アクセス操作を呼び出す場合は、承認が必要です。 操作は、以下で Get Blob Service Stats 説明するように承認できます。

重要

Microsoft では、マネージド ID でMicrosoft Entra IDを使用して、Azure Storage への要求を承認することをお勧めします。 Microsoft Entra IDは、共有キーの承認と比較して優れたセキュリティと使いやすさを提供します。

Azure Storage では、Microsoft Entra ID を使用して BLOB データへの要求を承認することがサポートされています。 Microsoft Entra IDでは、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、セキュリティ プリンシパルにアクセス許可を付与できます。 セキュリティ プリンシパルには、ユーザー、グループ、アプリケーション サービス プリンシパル、または Azure マネージド ID を指定できます。 セキュリティ プリンシパルは、OAuth 2.0 トークンを返すためにMicrosoft Entra IDによって認証されます。 その後、そのトークンを、Blob service に対する要求を認可するために使用できます。

Microsoft Entra IDを使用した承認の詳細については、「Microsoft Entra IDを使用して BLOB へのアクセスを承認する」を参照してください。

アクセス許可

Microsoft Entraユーザー、グループ、マネージド ID、またはサービス プリンシパルが操作を呼び出Get Blob Service Statsすために必要な RBAC アクションと、このアクションを含む最小特権の組み込み Azure RBAC ロールを次に示します。

Azure RBAC を使用したロールの割り当ての詳細については、「 BLOB データにアクセスするための Azure ロールの割り当て」を参照してください。

注釈

geo 冗長レプリケーションを使用すると、Azure Storage は数百マイル離れた 2 つの場所でデータを永続的に維持します。 両方の場所で、Azure ストレージは継続的にデータの複数の正常なレプリカを維持します。

geo 冗長ペアには、次のものが含まれます。

  • プライマリの場所: データの読み取り、作成、更新、または削除を行う場所。 プライマリの場所は、Azure クラシック ポータル ( 米国中北部など) を使用してアカウントを作成するときに選択したリージョンに存在します。

  • セカンダリの場所: データのレプリケート先の場所。 セカンダリの場所は、プライマリ リージョンと自動的に地理的にペアになったリージョンに存在します。 ストレージ アカウントで読み取 りアクセス geo 冗長レプリケーション が有効になっている場合は、セカンダリの場所から読み取り専用アクセスを使用できます。 読み取りアクセス geo 冗長レプリケーションの詳細については、「 データの冗長性」を参照してください。

データの読み取り、作成、更新、または削除を行う場所は、1 次ストレージ アカウント拠点です。 プライマリの場所は、Azure Management Azure クラシック ポータル ( 米国中北部など) を使用してアカウントを作成するときに選択したリージョンに存在します。 データのレプリケート先の場所が、2 次拠点です。 セカンダリの場所は、プライマリ リージョンと自動的に地理的にペアになっているリージョンに存在します。 読み取りアクセスの地理冗長レプリケーションがストレージ アカウントで有効な場合は、2 次拠点から読み取り専用アクセスを使用できます。 読み取りアクセス geo 冗長レプリケーションの詳細については、「 データの冗長性」を参照してください。

セカンダリ エンドポイントに対する読み取り操作の要求を作成するには、Blob Storage からの読み取りに使用する URI のアカウント名に を追加 -secondary します。 たとえば、 Blob の取得 操作のセカンダリ URI は と https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob似ています。

請求

価格要求は、Blob Storage REST API を介して直接、または Azure Storage クライアント ライブラリを介して Blob Storage API を使用するクライアントから送信できます。 これらの要求では、トランザクションあたりの料金が発生します。 トランザクションの種類は、アカウントの課金方法に影響します。 たとえば、読み取りトランザクションは、書き込みトランザクションとは異なる課金カテゴリに計上されます。 次の表は、ストレージ アカウントの種類に基づく要求の課金カテゴリ Get Blob Service Stats を示しています。

操作 ストレージ アカウントの種類 課金カテゴリ
Get Blob Service Stats Premium ブロック BLOB
Standard 汎用 v2		 その他の操作
Get Blob Service Stats Standard 汎用 v1 操作を読み取ります。

指定した課金カテゴリの価格については、「Azure Blob Storage価格」を参照してください。

要求と応答の例

操作のサンプル要求を次に 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>

こちらもご覧ください

アカウントに対する操作 (Blob Storage)