Obtener estadísticas del servicio Blob
La Get Blob Service Stats
operación recupera estadísticas relacionadas con la replicación de Azure Blob Storage. La operación solo está disponible en el punto de conexión de ubicación secundaria cuando la replicación con redundancia geográfica con acceso de lectura está habilitada para la cuenta de almacenamiento.
Solicitud
Puede construir la solicitud de la Get Blob Service Stats
siguiente manera. Se recomienda usar HTTPS. Reemplace myaccount
por el nombre de la cuenta de almacenamiento y tenga en cuenta que el sufijo -secondary
es necesario:
Método | URI de solicitud | Versión de HTTP |
---|---|---|
GET | https://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats |
HTTP/1.1 |
Nota
El URI siempre debe incluir una barra diagonal (/) para separar el nombre de host de la ruta de acceso y las partes de la consulta. En el caso de esta operación, la parte de la ruta de acceso del URI está vacía.
Parámetros del identificador URI
Puedes especificar los siguientes parámetros adicionales en el URI de la solicitud:
Parámetro | Descripción |
---|---|
Timeout |
Opcional. El parámetro timeout se expresa en segundos. |
Encabezados de solicitud
En la tabla siguiente se describen los encabezados de solicitud requeridos y opcionales.
Encabezado de solicitud | Descripción |
---|---|
Authorization |
Necesario. Especifica el esquema de autorización, el nombre de cuenta y la firma. Para obtener más información, vea Autorización de solicitudes a Azure Storage. |
Date or x-ms-date |
Necesario. Especifica la hora universal coordinada (UTC) de la solicitud. Para obtener más información, vea Autorización de solicitudes a Azure Storage. |
x-ms-version |
Necesario para todas las solicitudes autorizadas. Especifica la versión de la operación que se utiliza para esta solicitud. Para obtener más información, vea Versiones de los servicios de Azure Storage. |
x-ms-client-request-id |
Opcional. Proporciona un valor opaco generado por el cliente con un límite de caracteres de 1 kibibyte (KiB) que se registra en los registros cuando se configura el registro. Se recomienda encarecidamente usar este encabezado para correlacionar las actividades del lado cliente con las solicitudes que recibe el servidor. Para obtener más información, consulte Supervisión de Azure Blob Storage. |
Cuerpo de la solicitud
Ninguno.
Response
La respuesta incluye un código de estado HTTP, un conjunto de encabezados de respuesta y un cuerpo de respuesta
status code
Una operación correcta devuelve el código de estado 200 Correcto. Cuando se llama a una operación en un punto de conexión de ubicación secundario que no está habilitado para una lectura secundaria, devuelve un código de estado HTTP de 403 con un InsufficientAccountPermissions
error.
Encabezados de respuesta
La respuesta para esta operación incluye los encabezados siguientes. La respuesta también incluye otros encabezados HTTP estándar. Todos los encabezados estándar se ajustan a la especificación del protocolo HTTP/1.1.
Encabezado de respuesta | Descripción |
---|---|
x-ms-request-id |
Identifica de forma única la solicitud que se realizó y puede usarla para solucionar problemas de la solicitud. Para más información, consulte Solución de problemas de operaciones de API. |
x-ms-version |
Especifica la versión de la operación que se usa para la respuesta. Para obtener más información, vea Versiones de los servicios de Azure Storage. |
Date |
Valor de fecha y hora UTC generado por el servicio, que indica la hora en que se inició la respuesta. |
x-ms-client-request-id |
Se puede usar para solucionar problemas de solicitudes y sus respuestas correspondientes. El valor de este encabezado es igual al valor del x-ms-client-request-id encabezado si está presente en la solicitud y el valor no superior a 1024 caracteres ASCII visibles. Si el x-ms-client-request-id encabezado no está presente en la solicitud, este encabezado no está presente en la respuesta. |
Response body
El formato del cuerpo de respuesta es el siguiente:
<?xml version="1.0" encoding="utf-8"?>
<StorageServiceStats>
<GeoReplication>
<Status>live|bootstrap|unavailable</Status>
<LastSyncTime>sync-time|<empty></LastSyncTime>
</GeoReplication>
</StorageServiceStats>
Los elementos del cuerpo de respuesta se describen en la tabla siguiente:
Encabezado de respuesta | Descripción |
---|---|
Status |
El estado de la ubicación secundaria. Los valores posibles son: - live : indica que la ubicación secundaria está activa y operativa.- bootstrap : indica que la sincronización inicial desde la ubicación principal a la ubicación secundaria está en curso. Normalmente, esto ocurre cuando la replicación está habilitada por primera vez.- no disponible: indica que la ubicación secundaria no está disponible temporalmente. |
LastSyncTime |
Valor de fecha/hora según GMT, al segundo. Se garantiza que todas las escrituras principales que preceden a este valor estén disponibles para las operaciones de lectura en la base de datos secundaria. Las escrituras principales después de este momento en el tiempo podrían o no estar disponibles para las lecturas. El valor puede estar vacío si LastSyncTime no está disponible. Esto puede ocurrir si el estado de replicación es bootstrap o unavailable .Aunque la replicación geográfica está habilitada continuamente, el LastSyncTime resultado puede reflejar un valor almacenado en caché del servicio, que se actualiza cada pocos minutos. |
Authorization
La autorización es necesaria al llamar a cualquier operación de acceso a datos en Azure Storage. Puede autorizar la Get Blob Service Stats
operación como se describe a continuación.
Importante
Microsoft recomienda usar Microsoft Entra ID con identidades administradas para autorizar solicitudes a Azure Storage. Microsoft Entra ID proporciona una mayor seguridad y facilidad de uso en comparación con la autorización de clave compartida.
Azure Storage admite el uso de Microsoft Entra ID para autorizar solicitudes a datos de blobs. Con Microsoft Entra ID, puede usar el control de acceso basado en rol de Azure (RBAC de Azure) para conceder permisos a una entidad de seguridad. La entidad de seguridad puede ser un usuario, un grupo, una entidad de servicio de aplicación o una identidad administrada de Azure. La entidad de seguridad se autentica mediante Microsoft Entra ID para devolver un token de OAuth 2.0. Después, el token se puede usar para autorizar una solicitud en Blob service.
Para más información sobre la autorización mediante Microsoft Entra ID, consulte Autorización del acceso a blobs mediante Microsoft Entra ID.
Permisos
A continuación se muestra la acción de RBAC necesaria para que un usuario, grupo, identidad administrada o entidad de servicio Microsoft Entra llame a la Get Blob Service Stats
operación y el rol RBAC integrado con privilegios mínimos que incluya esta acción:
- Acción RBAC de Azure:Microsoft.Storage/storageAccounts/blobServices/read
- Rol integrado con privilegios mínimos:Colaborador de la cuenta de almacenamiento
Para más información sobre cómo asignar roles mediante RBAC de Azure, consulte Asignación de un rol de Azure para el acceso a datos de blobs.
Comentarios
Con la replicación con redundancia geográfica, Azure Storage mantiene los datos de forma duradera en dos ubicaciones separadas por cientos de kilómetros. En las dos ubicaciones, Azure Storage mantiene constantemente réplicas en estado correcto de los datos.
Un par con redundancia geográfica incluye:
Una ubicación principal : ubicación donde se leen, crean, actualizan o eliminan datos. La ubicación principal existe en la región que elija al crear una cuenta a través del Portal de Azure clásico (por ejemplo, Centro-norte de EE. UU.).
Una ubicación secundaria : la ubicación en la que se replican los datos. La ubicación secundaria reside en una región que se empareja geográficamente automáticamente con la región primaria. El acceso de solo lectura está disponible desde la ubicación secundaria si la replicación con redundancia geográfica con acceso de lectura está habilitada para la cuenta de almacenamiento. Para obtener más información sobre la replicación con redundancia geográfica con acceso de lectura, consulte Redundancia de datos.
La ubicación en la que lee, crea, actualiza o elimina los datos es la ubicación de la cuenta de almacenamiento principal. La ubicación principal existe en la región que elija en el momento en que cree una cuenta a través del Portal de Administración de Azure clásico de Azure, por ejemplo, Centro-norte de EE. UU. La ubicación en la que se replican los datos es la ubicación secundaria. La ubicación secundaria reside en una región que se empareja geográficamente automáticamente con la región primaria. El acceso de solo lectura está disponible en la ubicación secundaria, si la replicación con redundancia geográfica con acceso de lectura está habilitada para la cuenta de almacenamiento. Para más información sobre la replicación con redundancia geográfica con acceso de lectura, consulte Redundancia de datos.
Para construir una solicitud para una operación de lectura en el punto de conexión secundario, anexe -secondary
al nombre de cuenta en el URI que se usa para leer de Blob Storage. Por ejemplo, un URI secundario para la operación Get Blob será similar a https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob
.
Facturación
Las solicitudes de precios se pueden originar en clientes que usan las API de Blob Storage, ya sea directamente a través de la API rest de Blob Storage o de una biblioteca cliente de Azure Storage. Estas solicitudes acumulan cargos por transacción. El tipo de transacción afecta a cómo se cobra la cuenta. Por ejemplo, las transacciones de lectura se acumulan en una categoría de facturación diferente que las transacciones de escritura. En la tabla siguiente se muestra la categoría de facturación de Get Blob Service Stats
las solicitudes basadas en el tipo de cuenta de almacenamiento:
Operación | Tipo de cuenta de almacenamiento | Categoría de facturación |
---|---|---|
Obtener estadísticas del servicio Blob | Blobs en bloques Premium De uso general, estándar, v2 |
Otras operaciones |
Obtener estadísticas del servicio Blob | De uso general, estándar, v1 | Lee operaciones. |
Para obtener información sobre los precios de la categoría de facturación especificada, consulte precios Azure Blob Storage.
Solicitud y respuesta de ejemplo
Esta es una solicitud de ejemplo para la Get Blob Service Stats
operación:
GET http://myaccount-secondary.blob.core.windows.net/?restype=service&comp=stats HTTP/1.1
La solicitud se envía con los encabezados siguientes:
x-ms-version: 2013-08-15
x-ms-date: Wed, 23 Oct 2013 22:08:44 GMT
Authorization: SharedKey myaccount:CY1OP3O3jGFpYFbTCBimLn0Xov0vt0khH/E5Gy0fXvg=
El código de estado y los encabezados de respuesta se devuelven de la forma siguiente:
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
La respuesta incluye el cuerpo XML siguiente.
<?xml version="1.0" encoding="utf-8"?>
<StorageServiceStats>
<GeoReplication>
<Status>live</Status>
<LastSyncTime> Wed, 23 Oct 2013 22:05:54 GMT</LastSyncTime>
</GeoReplication>
</StorageServiceStats>