Supervisión, diagnóstico y solución de problemas de Microsoft Azure Storage (clásico)

Article
04/10/2024

En esta guía se muestra cómo usar características como Azure Storage Analytics, el registro del lado cliente en la biblioteca cliente de Azure Storage y otras herramientas de terceros para identificar, diagnosticar y solucionar problemas relacionados con Azure Storage.

Diagrama que muestra el flujo de información entre las aplicaciones cliente y los servicios de almacenamiento de Azure.

Esta guía está pensada para que la lean principalmente los desarrolladores de servicios en línea que usan los servicios de Azure Storage y los profesionales de TI responsables de administrar este tipo de servicios en línea. Los objetivos de esta guía son:

Para ayudarle a mantener el estado y el rendimiento de las cuentas de Azure Storage.
Para proporcionarle los procesos y herramientas necesarios para ayudarle a decidir si un problema o problema en una aplicación está relacionado con Azure Storage.
Para proporcionar instrucciones accionables para resolver problemas relacionados con Azure Storage.

Nota:

Este artículo se basa en el uso de Storage Analytics métricas y registros a los que se hace referencia como métricas y registros clásicos. Se recomienda usar métricas y registros de Azure Storage en Azure Monitor en lugar de Storage Analytics registros. Para obtener más información, consulte cualquiera de los siguientes artículos:

Información general

Diagnosticar y solucionar problemas en una aplicación distribuida hospedada en un entorno en la nube puede ser más complejo que en entornos tradicionales. Las aplicaciones se pueden implementar en una infraestructura de PaaS o IaaS, local, en un dispositivo móvil o en alguna combinación de estos entornos. Normalmente, el tráfico de red de la aplicación puede atravesar redes públicas y privadas, y la aplicación puede usar varias tecnologías de almacenamiento, como tablas Microsoft Azure Storage, blobs, colas o archivos, además de otros almacenes de datos, como bases de datos relacionales y de documentos.

Para administrar estas aplicaciones correctamente, debe supervisarlas de forma proactiva y comprender cómo diagnosticar y solucionar todos los aspectos de ellas y sus tecnologías dependientes. Como usuario de los servicios de Azure Storage, debe supervisar continuamente los servicios de almacenamiento que la aplicación usa para detectar cambios inesperados en el comportamiento (como tiempos de respuesta más lentos de lo habitual) y usar el registro para recopilar datos más detallados y analizar un problema en profundidad. La información de diagnóstico que obtenga de la supervisión y el registro le ayudará a determinar la causa principal del problema que encontró la aplicación. A continuación, puede solucionar el problema y determinar los pasos adecuados para corregirlo. Azure Storage es un servicio básico de Azure y forma parte importante de la mayoría de las soluciones que los clientes implementan en la infraestructura de Azure. Azure Storage incluye funcionalidades para simplificar la supervisión, el diagnóstico y la solución de problemas de almacenamiento en las aplicaciones basadas en la nube.

Cómo se organiza esta guía

En la sección Supervisión del servicio de almacenamiento se describe cómo supervisar el estado y el rendimiento de los servicios de Azure Storage mediante métricas de Azure Storage Analytics (métricas de almacenamiento).

En la sección Diagnóstico de problemas de almacenamiento se describe cómo diagnosticar problemas mediante el registro de Azure Storage Analytics (registro de almacenamiento). También se describe cómo habilitar el registro del lado cliente mediante las instalaciones de una de las bibliotecas cliente, como la biblioteca cliente de Storage para .NET o el SDK de Azure para Java.

En la sección Seguimiento de un extremo a otro se describe cómo puede correlacionar la información contenida en varios archivos de registro y datos de métricas.

En la sección Guía de solución de problemas se proporcionan instrucciones para solucionar algunos de los problemas comunes relacionados con el almacenamiento que puede encontrar.

La sección Appendices incluye información sobre el uso de otras herramientas, como Wireshark y Netmon para analizar datos de paquetes de red, y Fiddler para analizar mensajes HTTP/HTTPS.

Supervisión del servicio de almacenamiento

Si está familiarizado con la supervisión del rendimiento de Windows, puede considerar las métricas de almacenamiento como un equivalente de Azure Storage de los contadores de Windows Monitor de rendimiento. En Métricas de almacenamiento, encontrará un conjunto completo de métricas (contadores en Windows Monitor de rendimiento terminología), como la disponibilidad del servicio, el número total de solicitudes al servicio o el porcentaje de solicitudes correctas al servicio. Para obtener una lista completa de las métricas disponibles, consulte Storage Analytics Esquema de tabla de métricas. Puede especificar si desea que el servicio de almacenamiento recopile y agregue métricas cada hora o cada minuto. Para obtener más información sobre cómo habilitar métricas y supervisar las cuentas de almacenamiento, consulte Habilitación de métricas de almacenamiento y visualización de datos de métricas.

Puede elegir qué métricas por hora desea mostrar en el Azure Portal y configurar reglas que notifiquen por correo electrónico a los administradores cada vez que una métrica por hora supere un umbral determinado. Para obtener más información, vea Recibir notificaciones de alerta.

Se recomienda revisar Azure Monitor para Storage (versión preliminar). Es una característica de Azure Monitor que ofrece una supervisión completa de las cuentas de Azure Storage mediante la entrega de una vista unificada del rendimiento, la capacidad y la disponibilidad de los servicios de Azure Storage. No es necesario habilitar ni configurar nada, y puede ver inmediatamente estas métricas desde los gráficos interactivos predefinidos y otras visualizaciones incluidas.

El servicio de almacenamiento intenta recopilar métricas, pero es posible que no registre todas las operaciones de almacenamiento.

En el Azure Portal, puede ver métricas como la disponibilidad, el total de solicitudes y los números de latencia promedio de una cuenta de almacenamiento. También se ha configurado una regla de notificación para alertar a un administrador si la disponibilidad cae por debajo de un nivel determinado. Desde la visualización de estos datos, un área posible para la investigación es el porcentaje de éxito de Table Service que está por debajo del 100 % (para obtener más información, consulte la sección Métricas que muestran porcentajes bajos o entradas de registro de análisis que tienen operaciones con el estado de transacción de ClientOtherErrors ).

Debe supervisar continuamente las aplicaciones de Azure para asegurarse de que están en buen estado y funcionan según lo esperado:

Establecer algunas métricas de línea base para la aplicación que le permitirán comparar los datos actuales e identificar los cambios significativos en el comportamiento de Azure Storage y la aplicación. Los valores de las métricas de línea base serán, en muchos casos, específicos de la aplicación, y debe establecerlos al probar el rendimiento de la aplicación.
Registrar métricas de minutos y usarlas para supervisar activamente errores inesperados y anomalías, como picos en los recuentos de errores o tasas de solicitudes.
Registrar métricas por hora y usarlas para supervisar valores medios, como recuentos de errores promedio y tasas de solicitudes.
Investigar posibles problemas mediante herramientas de diagnóstico, como se describe más adelante en la sección Diagnóstico de problemas de almacenamiento .

Los gráficos de la imagen siguiente muestran cómo el promedio que se produce para las métricas por hora puede ocultar los picos de actividad. Las métricas por hora parecen mostrar una tasa constante de solicitudes, mientras que las métricas de minutos revelan las fluctuaciones que realmente tienen lugar.

En el resto de esta sección se describen las métricas que debe supervisar y por qué.

Supervisión del estado del servicio

Puede usar el Azure Portal para ver el estado del servicio Storage (y otros servicios de Azure) en todas las regiones de Azure de todo el mundo. La supervisión le permite ver inmediatamente si un problema fuera del control está afectando al servicio Storage en la región que usa para la aplicación.

El Azure Portal también puede proporcionar notificaciones de incidentes que afectan a los distintos servicios de Azure.

Nota:

Esta información estaba disponible anteriormente, junto con los datos históricos, en el panel de servicio de Azure. Para obtener más información sobre Application Insights para Azure DevOps, consulte Apéndice 5: Supervisión con Application Insights para Azure DevOps.

Capacidad de supervisión

Métricas de almacenamiento solo almacena métricas de capacidad para Blob Service porque los blobs suelen tener en cuenta la mayor proporción de datos almacenados (en el momento de escribir, no es posible usar métricas de almacenamiento para supervisar la capacidad de las tablas y colas). Puede encontrar estos datos en la $MetricsCapacityBlob tabla si ha habilitado la supervisión para Blob Service. Métricas de almacenamiento registra estos datos una vez al día y puede usar el valor de para determinar si la fila contiene una entidad relacionada con datos de usuario (valor data) o datos de RowKey análisis (valor analytics). Cada entidad almacenada contiene información sobre la cantidad de almacenamiento usada (Capacity medida en bytes) y el número actual de contenedores (ContainerCount) y blobs (ObjectCount) en uso en la cuenta de almacenamiento. Para obtener más información sobre las métricas de capacidad almacenadas en la $MetricsCapacityBlob tabla, consulte Storage Analytics Esquema de tabla de métricas.

Nota:

Debe supervisar estos valores para una advertencia temprana de que se está acercando a los límites de capacidad de la cuenta de almacenamiento. En el Azure Portal, puede agregar reglas de alerta para notificarle si el uso de almacenamiento agregado supera o cae por debajo de los umbrales especificados.

Para calcular el tamaño de varios objetos de almacenamiento, como blobs, consulte la entrada de blog Descripción de la facturación de Azure Storage: ancho de banda, transacciones y capacidad.

Supervisión de la disponibilidad

Debe supervisar la disponibilidad de los servicios de almacenamiento en la cuenta de almacenamiento mediante la supervisión del valor de la Availability columna de las tablas de métricas por hora o minutos : $MetricsHourPrimaryTransactionsBlob, $MetricsHourPrimaryTransactionsTable, , $MetricsHourPrimaryTransactionsQueue, $MetricsMinutePrimaryTransactionsBlob, $MetricsMinutePrimaryTransactionsTable, , $MetricsMinutePrimaryTransactionsQueue$MetricsCapacityBlob. La Availability columna contiene un valor de porcentaje que indica la disponibilidad del servicio o la operación de API representada por la fila (muestra RowKey si la fila contiene métricas para el servicio en su conjunto o para una operación de API específica).

Cualquier valor inferior al 100 % indica que se producen errores en algunas solicitudes de almacenamiento. Para ver por qué se producen errores, examine las demás columnas de los datos de métricas que muestran el número de solicitudes con diferentes tipos de error, como ServerTimeoutError. Debería esperar que la Availability caída sea temporalmente inferior al 100 % por motivos como tiempos de espera transitorios del servidor mientras el servicio mueve particiones a solicitudes de mejor equilibrio de carga; la lógica de reintento de la aplicación cliente debe controlar estas condiciones intermitentes. En el artículo Storage Analytics Operaciones registradas y Mensajes de estado se enumeran los tipos de transacción que las métricas de almacenamiento incluyen en su Availability cálculo.

En el Azure Portal, puede agregar reglas de alerta para notificarle si Availability un servicio está por debajo de un umbral especificado.

En la sección Guía de solución de problemas de esta guía se describen algunos problemas comunes del servicio de almacenamiento relacionados con la disponibilidad.

Supervisión del rendimiento

Para supervisar el rendimiento de los servicios de almacenamiento, puede usar las siguientes métricas de las tablas de métricas por hora y minutos.

Los valores de las AverageE2ELatency columnas y AverageServerLatency muestran el tiempo medio que tarda el servicio de almacenamiento o el tipo de operación de API en procesar las solicitudes. AverageE2ELatency es una medida de latencia de un extremo a otro que incluye el tiempo necesario para leer la solicitud y enviar la respuesta además del tiempo necesario para procesar la solicitud (por lo tanto, incluye la latencia de red una vez que la solicitud llega al servicio de almacenamiento); AverageServerLatency es una medida de solo el tiempo de procesamiento y, por tanto, excluye cualquier latencia de red relacionada con la comunicación con el cliente. Consulte la sección Metrics show high AverageE2ELatency and low AverageServerLatency más adelante en esta guía para obtener información sobre por qué podría haber una diferencia significativa entre estos dos valores.
Los valores de las TotalIngress columnas y TotalEgress muestran la cantidad total de datos, en bytes, que entran y salen del servicio de almacenamiento o a través de un tipo de operación de API específico.
Los valores de la TotalRequests columna muestran el número total de solicitudes que recibe el servicio de almacenamiento de la operación de API. TotalRequests es el número total de solicitudes que recibe el servicio de almacenamiento.

Normalmente, supervisará los cambios inesperados en cualquiera de estos valores, ya que esto indica que tiene un problema que requiere investigación.

En el Azure Portal, puede agregar reglas de alerta para notificarle si alguna métrica de rendimiento de este servicio está por debajo o supera un umbral especificado.

En la sección Guía de solución de problemas de esta guía se describen algunos problemas comunes del servicio de almacenamiento relacionados con el rendimiento.

Diagnóstico de problemas de almacenamiento

Hay varias maneras de tener en cuenta un problema o un problema en la aplicación, entre las que se incluyen:

Un error importante que hace que la aplicación se bloquee o deje de funcionar.
Cambios significativos de los valores de línea base en las métricas que supervisa, como se describe en la sección anterior Supervisión del servicio de almacenamiento.
Informa a los usuarios de la aplicación de que alguna operación determinada no se completó según lo esperado o que alguna característica no funciona.
Errores generados en la aplicación que aparecen en los archivos de registro o a través de algún otro método de notificación.

Normalmente, los problemas relacionados con los servicios de almacenamiento de Azure se dividen en una de las cuatro categorías generales:

La aplicación tiene un problema de rendimiento, ya sea notificado por los usuarios o revelado por cambios en las métricas de rendimiento.
Hay un problema con la infraestructura de Azure Storage en una o varias regiones.
La aplicación encuentra un error, ya sea notificado por los usuarios o revelado por un aumento en una de las métricas de recuento de errores que supervisa.
Durante el desarrollo y las pruebas, es posible que esté usando el emulador de almacenamiento local; puede encontrar algunos problemas relacionados específicamente con el uso del emulador de almacenamiento.

En las secciones siguientes se describen los pasos que debe seguir para diagnosticar y solucionar problemas en cada una de estas cuatro categorías. La sección Guía para la solución de problemas más adelante en esta guía proporciona más detalles sobre algunos problemas comunes que puede encontrar.

problemas de Estado del servicio

Estado del servicio problemas suelen estar fuera del control. El Azure Portal proporciona información sobre los problemas en curso con los servicios de Azure, incluidos los servicios de almacenamiento. Si ha optado por Read-Access Geo-Redundant Storage al crear la cuenta de almacenamiento, si los datos no están disponibles en la ubicación principal, la aplicación puede cambiar temporalmente a la copia de solo lectura en la ubicación secundaria. Para leer desde la secundaria, la aplicación debe poder cambiar entre el uso de las ubicaciones de almacenamiento principal y secundaria y poder trabajar en un modo de funcionalidad reducida con datos de solo lectura. Las bibliotecas de cliente de Azure Storage permiten definir una directiva de reintento que puede leer desde el almacenamiento secundario en caso de que se produzca un error en una lectura del almacenamiento principal. La aplicación también debe tener en cuenta que los datos de la ubicación secundaria finalmente son coherentes. Para obtener más información, consulte la entrada de blog Opciones de redundancia de Azure Storage y Almacenamiento con redundancia geográfica de acceso de lectura.

Problemas de rendimiento

El rendimiento de una aplicación puede ser subjetivo, especialmente desde la perspectiva del usuario. Por lo tanto, es importante tener métricas de línea base disponibles para ayudarle a identificar dónde puede haber un problema de rendimiento. Muchos factores pueden afectar al rendimiento de un servicio de almacenamiento de Azure desde la perspectiva de la aplicación cliente. Estos factores pueden funcionar en el servicio de almacenamiento, el cliente o la infraestructura de red; por lo tanto, es importante tener una estrategia para identificar el origen del problema de rendimiento.

Una vez que haya identificado la ubicación probable de la causa del problema de rendimiento a partir de las métricas, puede usar los archivos de registro para encontrar información detallada para diagnosticar y solucionar el problema más adelante.

La sección Guía para la solución de problemas más adelante en esta guía proporciona más información sobre algunos problemas comunes relacionados con el rendimiento que puede encontrar.

Diagnóstico de errores

Los usuarios de la aplicación pueden notificarle los errores notificados por la aplicación cliente. Métricas de almacenamiento también registra recuentos de diferentes tipos de error de los servicios de almacenamiento, como NetworkError, ClientTimeoutError o AuthorizationError. Aunque las métricas de almacenamiento solo registran recuentos de tipos de error diferentes, puede obtener más detalles sobre las solicitudes individuales mediante el examen de los registros del lado servidor, del lado cliente y de red. Normalmente, el código de estado HTTP devuelto por el servicio de almacenamiento proporcionará una indicación de por qué se produjo un error en la solicitud.

Nota:

Recuerde que debe esperar ver algunos errores intermitentes: por ejemplo, errores debidos a condiciones de red transitorias o errores de aplicación.

Los siguientes recursos son útiles para comprender el estado relacionado con el almacenamiento y los códigos de error:

Problemas del emulador de almacenamiento

El SDK de Azure incluye un emulador de almacenamiento que puede ejecutar en una estación de trabajo de desarrollo. Este emulador simula la mayor parte del comportamiento de los servicios de almacenamiento de Azure y es útil durante el desarrollo y las pruebas, lo que le permite ejecutar aplicaciones que usan servicios de Azure Storage sin necesidad de una suscripción de Azure y una cuenta de Almacenamiento de Azure.

En la sección Guía de solución de problemas de esta guía se describen algunos problemas comunes detectados con el emulador de almacenamiento.

Herramientas de registro de almacenamiento

El registro de almacenamiento proporciona el registro del lado servidor de las solicitudes de almacenamiento en la cuenta de almacenamiento de Azure. Para obtener más información sobre cómo habilitar el registro del lado servidor y acceder a los datos de registro, consulte Habilitación del registro de almacenamiento y acceso a los datos de registro.

La biblioteca cliente de Almacenamiento para .NET permite recopilar datos de registro del lado cliente relacionados con las operaciones de almacenamiento realizadas por la aplicación. Para obtener más información, consulte Registro del lado cliente con la biblioteca cliente de almacenamiento de .NET.

Nota:

En algunas circunstancias (como errores de autorización de SAS), un usuario puede notificar un error para el que no puede encontrar datos de solicitud en los registros de almacenamiento del lado servidor. Puede usar las funcionalidades de registro de la biblioteca cliente de Storage para investigar si la causa del problema está en el cliente o usar herramientas de supervisión de red para investigar la red.

Uso de herramientas de registro de red

Puede capturar el tráfico entre el cliente y el servidor para proporcionar información detallada sobre los datos que intercambian el cliente y el servidor y las condiciones de red subyacentes. Entre las herramientas útiles de registro de red se incluyen:

Fiddler es un proxy de depuración web gratuito que permite examinar los encabezados y los datos de carga de los mensajes de solicitud y respuesta HTTP y HTTPS. Para obtener más información, vea Apéndice 1: Uso de Fiddler para capturar el tráfico HTTP y HTTPS.
Microsoft Network Monitor (Netmon) y Wireshark son analizadores de protocolos de red gratuitos que permiten ver información detallada de paquetes para una amplia gama de protocolos de red. Para obtener más información sobre Wireshark, consulte Apéndice 2: Uso de Wireshark para capturar el tráfico de red.
Si desea realizar una prueba de conectividad básica para comprobar que el equipo cliente puede conectarse al servicio azure storage a través de la red, no puede hacerlo mediante la herramienta de ping estándar en el cliente. Sin embargo, puede usar la herramienta tcping para comprobar la conectividad.

En muchos casos, los datos de registro del registro de almacenamiento y la biblioteca cliente de almacenamiento serán suficientes para diagnosticar un problema, pero en algunos escenarios, es posible que necesite la información más detallada que pueden proporcionar estas herramientas de registro de red. Por ejemplo, el uso de Fiddler para ver los mensajes HTTP y HTTPS le permite ver los datos de encabezado y carga enviados hacia y desde los servicios de almacenamiento, lo que le permitiría examinar cómo una aplicación cliente reintenta las operaciones de almacenamiento. Los analizadores de protocolos como Wireshark funcionan en el nivel de paquete, lo que le permite ver los datos TCP, lo que le permitiría solucionar problemas de conectividad y paquetes perdidos.

Seguimiento de un extremo a otro

El seguimiento de un extremo a otro mediante una variedad de archivos de registro es una técnica útil para investigar posibles problemas. Puede usar la información de fecha y hora de los datos de métricas para indicar dónde empezar a buscar en los archivos de registro información detallada que le ayude a solucionar el problema.

Correlación de datos de registro

Al ver registros de aplicaciones cliente, seguimientos de red y registro de almacenamiento del lado servidor, es fundamental poder correlacionar las solicitudes entre los distintos archivos de registro. Los archivos de registro incluyen varios campos diferentes que son útiles como identificadores de correlación. El identificador de solicitud de cliente es el campo más útil para correlacionar las entradas en los distintos registros. Sin embargo, a veces, puede ser útil usar el identificador de solicitud del servidor o las marcas de tiempo. En las secciones siguientes se proporcionan más detalles sobre estas opciones.

Identificador de solicitud de cliente

La biblioteca cliente de Storage genera automáticamente un identificador de solicitud de cliente único para cada solicitud.

En el registro del lado cliente que crea la biblioteca cliente de Storage, el identificador de solicitud de cliente aparece en el Client Request ID campo de cada entrada de registro relacionada con la solicitud.
En un seguimiento de red como el capturado por Fiddler, el identificador de solicitud de cliente es visible en los mensajes de solicitud como el valor de x-ms-client-request-id encabezado HTTP.
En el registro de registro de almacenamiento del lado servidor, el identificador de solicitud de cliente aparece en la columna Id. de solicitud de cliente.

Nota:

Es posible que varias solicitudes compartan el mismo identificador de solicitud de cliente porque el cliente puede asignar este valor (aunque la biblioteca cliente de Storage asigna automáticamente un nuevo valor). Cuando el cliente vuelve a intentar, todos los intentos comparten el mismo identificador de solicitud de cliente. En el caso de un lote enviado desde el cliente, el lote tiene un único identificador de solicitud de cliente.

Identificador de solicitud del servidor

El servicio de almacenamiento genera automáticamente identificadores de solicitud de servidor.

En el registro de registro de almacenamiento del lado servidor, el identificador de solicitud del servidor aparece en la Request ID header columna .
En un seguimiento de red, como el capturado por Fiddler, el identificador de solicitud del servidor aparece en los mensajes de respuesta como el valor de x-ms-request-id encabezado HTTP.
En el registro del lado cliente que crea la biblioteca cliente de Almacenamiento, el identificador de solicitud del servidor aparece en la Operation Text columna de la entrada de registro que muestra los detalles de la respuesta del servidor.

Nota:

El servicio de almacenamiento siempre asigna un identificador de solicitud de servidor único a cada solicitud que recibe, por lo que cada intento de reintento del cliente y todas las operaciones incluidas en un lote tienen un identificador de solicitud de servidor único.

SDK de .NET v12
SDK de .NET v11

En el ejemplo de código siguiente se muestra cómo usar un identificador de solicitud de cliente personalizado.

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

Si la biblioteca cliente de Storage inicia un StorageException elemento en el cliente, la RequestInformation propiedad contiene un RequestResult objeto que incluye una ServiceRequestID propiedad. También puede acceder a un RequestResult objeto desde una OperationContext instancia.

En el ejemplo de código siguiente se muestra cómo establecer un valor personalizado ClientRequestId mediante la asociación de un OperationContext objeto a la solicitud al servicio de almacenamiento. También muestra cómo recuperar el ServerRequestId valor del mensaje de respuesta.

//Parse the connection string for the storage account.
const string ConnectionString = "DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key";
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConnectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

// Create an Operation Context that includes custom ClientRequestId string based on constants defined within the application along with a Guid.
OperationContext oc = new OperationContext();
oc.ClientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

try
{
    CloudBlobContainer container = blobClient.GetContainerReference("democontainer");
    ICloudBlob blob = container.GetBlobReferenceFromServer("testImage.jpg", null, null, oc);  
    var downloadToPath = string.Format("./{0}", blob.Name);
    using (var fs = File.OpenWrite(downloadToPath))
    {
        blob.DownloadToStream(fs, null, null, oc);
        Console.WriteLine("\t Blob downloaded to file: {0}", downloadToPath);
    }
}
catch (StorageException storageException)
{
    Console.WriteLine("Storage exception {0} occurred", storageException.Message);
    // Multiple results may exist due to client side retry logic - each retried operation will have a unique ServiceRequestId
    foreach (var result in oc.RequestResults)
    {
            Console.WriteLine("HttpStatus: {0}, ServiceRequestId {1}", result.HttpStatusCode, result.ServiceRequestID);
    }
}

Marcas de tiempo

También puede usar marcas de tiempo para buscar entradas de registro relacionadas, pero tenga cuidado con cualquier asimetría de reloj entre el cliente y el servidor que pueda existir. Búsqueda más o menos 15 minutos para las entradas del lado servidor coincidentes en función de la marca de tiempo del cliente. Recuerde que los metadatos de blob de los blobs que contienen métricas indican el intervalo de tiempo de las métricas almacenadas en el blob. Este intervalo de tiempo es útil si tiene muchos blobs en métricas para el mismo minuto o hora.

Guía de solución de problemas

Esta sección le ayudará con el diagnóstico y la solución de algunos de los problemas comunes que puede encontrar la aplicación al usar los servicios de Almacenamiento de Azure. Use la lista siguiente para buscar la información relevante para su problema específico.

Árbol de decisión de solución de problemas

¿El problema está relacionado con el rendimiento de uno de los servicios de almacenamiento?

Las métricas muestran una alta latencia averageE2ELatency y una baja averageServerLatency.
Las métricas muestran una latencia baja de AverageE2ELatency y una baja de AverageServerLatency, pero el cliente experimenta una latencia alta.
Las métricas muestran una alta averageServerLatency.
Está experimentando retrasos inesperados en la entrega de mensajes en una cola.

¿El problema está relacionado con la disponibilidad de uno de los servicios de almacenamiento?

Las métricas muestran un aumento en PercentThrottlingError.
Las métricas muestran un aumento en PercentTimeoutError.
Las métricas muestran un aumento en PercentNetworkError.

¿La aplicación cliente recibe una respuesta HTTP 4XX (como 404) de un servicio de almacenamiento?

El cliente recibe mensajes HTTP 403 (prohibido).
El cliente recibe mensajes HTTP 404 (no encontrados).
El cliente recibe mensajes HTTP 409 (conflicto).

Las métricas muestran que las entradas de registro percentSuccess o analytics bajas tienen operaciones con el estado de transacción ClientOtherErrors.

Las métricas de capacidad muestran un aumento inesperado del uso de la capacidad de almacenamiento.

El problema surge del uso del emulador de almacenamiento para el desarrollo o las pruebas.

Tiene problemas para instalar el SDK de Azure para .NET.

Tiene un problema diferente con un servicio de almacenamiento.

Las métricas muestran un promedio alto de 2ELatency y una baja latencia averageServerLatency

En la ilustración siguiente de la herramienta de supervisión de Azure Portal se muestra un ejemplo en el que AverageE2ELatency es significativamente mayor que AverageServerLatency.

Ilustración de la Azure Portal que muestra un ejemplo en el que AverageE2ELatency es significativamente mayor que AverageServerLatency.

El servicio de almacenamiento solo calcula la métrica AverageE2ELatency para las solicitudes correctas y, a diferencia de AverageServerLatency, incluye el tiempo que el cliente tarda en enviar los datos y recibir confirmación del servicio de almacenamiento. Por lo tanto, una diferencia entre AverageE2ELatency y AverageServerLatency podría deberse a que la aplicación cliente es lenta para responder o debido a condiciones en la red.

Nota:

También puede ver E2ELatency y ServerLatency para las operaciones de almacenamiento individuales en los datos del registro de registro de almacenamiento.

Investigación de problemas de rendimiento del cliente

Los posibles motivos para que el cliente responda lentamente incluyen tener un número limitado de conexiones o subprocesos disponibles o tener pocos recursos, como CPU, memoria o ancho de banda de red. Puede resolver el problema modificando el código de cliente para que sea más eficaz (por ejemplo, mediante llamadas asincrónicas al servicio de almacenamiento) o mediante una máquina virtual más grande (con más núcleos y más memoria).

En el caso de los servicios de tabla y cola, el algoritmo Nagle también puede provocar una alta averageE2ELatency en comparación con AverageServerLatency. Para obtener más información, vea Algoritmo de Nagle no es descriptivo para solicitudes pequeñas. Puede deshabilitar el algoritmo Nagle en el código mediante la ServicePointManager clase en el System.Net espacio de nombres. Debe hacerlo antes de realizar llamadas a los servicios de tabla o cola de la aplicación, ya que esto no afecta a las conexiones que ya están abiertas. El ejemplo siguiente procede del Application_Start método en un rol de trabajo.

SDK de .NET v12
SDK de .NET v11

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

var storageAccount = CloudStorageAccount.Parse(connStr);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(storageAccount.QueueEndpoint);
queueServicePoint.UseNagleAlgorithm = false;

Debe comprobar los registros del lado cliente para ver cuántas solicitudes envía la aplicación cliente y comprobar si hay información general. Cuellos de botella de rendimiento relacionados con NET en el cliente, como CPU, recolección de elementos no utilizados de .NET, uso de red o memoria. Como punto de partida para solucionar problemas de aplicaciones cliente de .NET, consulte Depuración, seguimiento y generación de perfiles.

Investigación de problemas de latencia de red

Normalmente, la latencia de extremo a extremo alta causada por la red se debe a condiciones transitorias. Puede investigar problemas de red transitorios y persistentes, como paquetes eliminados, mediante herramientas como Wireshark.

Para obtener más información sobre el uso de Wireshark para solucionar problemas de red, consulte Apéndice 2: Uso de Wireshark para capturar el tráfico de red.

Las métricas muestran una latencia baja de AverageE2ELatency y una baja de AverageServerLatency, pero el cliente experimenta una latencia alta.

En este escenario, la causa más probable es un retraso en las solicitudes de almacenamiento que llegan al servicio de almacenamiento. Debe investigar por qué las solicitudes del cliente no se realizan a través de Blob Service.

Una posible razón para que el cliente retrase el envío de solicitudes es que hay un número limitado de conexiones o subprocesos disponibles.

Además, compruebe si el cliente está realizando varios reintentos e investigue el motivo si es así. Para determinar si el cliente realiza varios reintentos, puede hacer lo siguiente:

Examine los registros de Storage Analytics. Si se producen varios reintentos, verá varias operaciones con el mismo identificador de solicitud de cliente, pero con identificadores de solicitud de servidor diferentes.
Examine los registros de cliente. El registro detallado indicará que se ha producido un reintento.
Depure el código y compruebe las propiedades del OperationContext objeto asociado a la solicitud. Si la operación se ha reintentado, la RequestResults propiedad incluirá varios identificadores de solicitud de servidor únicos. También puede comprobar las horas de inicio y finalización de cada solicitud. Para obtener más información, vea el ejemplo de código en la sección Id. de solicitud de servidor.

Si no hay ningún problema en el cliente, debe investigar posibles problemas de red, como la pérdida de paquetes. Puede usar herramientas como Wireshark para investigar problemas de red.

Para obtener más información sobre el uso de Wireshark para solucionar problemas de red, consulte Apéndice 2: Uso de Wireshark para capturar el tráfico de red.

Las métricas muestran una alta averageServerLatency

En el caso de una alta averageServerLatency para las solicitudes de descarga de blobs, debe usar los registros de registro de almacenamiento para ver si hay solicitudes repetidas para el mismo blob (o conjunto de blobs). En el caso de las solicitudes de carga de blobs, debe investigar el tamaño de bloque que usa el cliente (por ejemplo, los bloques de menos de 64 K de tamaño pueden dar lugar a sobrecargas a menos que las lecturas también estén en menos de 64 K fragmentos) y si varios clientes cargan bloques en el mismo blob en paralelo. También debe comprobar las métricas por minuto en busca de picos en el número de solicitudes que dan lugar a superar los objetivos de escalabilidad por segundo. Para obtener más información, consulte Métricas que muestran un aumento en PercentTimeoutError.

Si ve una alta averageServerLatency para las solicitudes de descarga de blobs cuando hay solicitudes repetidas para el mismo blob o conjunto de blobs, considere la posibilidad de almacenar en caché estos blobs mediante Azure Cache o Azure Content Delivery Network (CDN). Para las solicitudes de carga, puede mejorar el rendimiento mediante un tamaño de bloque mayor. En el caso de las consultas a tablas, también es posible implementar el almacenamiento en caché del lado cliente en clientes que realizan las mismas operaciones de consulta y donde los datos no cambian con frecuencia.

Los valores de AverageServerLatency altos también pueden ser un síntoma de tablas o consultas mal diseñadas que dan lugar a operaciones de examen o que siguen el antipatrón append/prepend. Para obtener más información, consulte Métricas que muestran un aumento en PercentThrottlingError.

Nota:

Puede encontrar una lista de comprobación de rendimiento completa aquí: Microsoft Azure Storage lista de comprobación de rendimiento y escalabilidad.

Está experimentando retrasos inesperados en la entrega de mensajes en una cola

Si experimenta un retraso entre el momento en que una aplicación agrega un mensaje a una cola y el momento en que está disponible para leer de la cola, siga estos pasos para diagnosticar el problema:

Compruebe que la aplicación agrega correctamente los mensajes a la cola. Compruebe que la aplicación no vuelva a intentar el AddMessage método varias veces antes de realizarlo correctamente. Los registros de la biblioteca cliente de Storage mostrarán los reintentos repetidos de las operaciones de almacenamiento.
Compruebe que no hay ningún sesgo de reloj entre el rol de trabajo que agrega el mensaje a la cola y el rol de trabajo que lee el mensaje de la cola. Un sesgo de reloj hace que aparezca como si hubiera un retraso en el procesamiento.
Compruebe si se produce un error en el rol de trabajo que lee los mensajes de la cola. Si un cliente de cola llama al GetMessage método pero no responde con una confirmación, el mensaje permanecerá invisible en la cola hasta que expire el invisibilityTimeout período. En este momento, el mensaje vuelve a estar disponible para su procesamiento.
Compruebe si la longitud de la cola está creciendo con el tiempo. Esto puede ocurrir si no tiene suficientes trabajos disponibles para procesar todos los mensajes que otros trabajadores están colocando en la cola. Además, compruebe las métricas para ver si se producen errores en las solicitudes de eliminación y el recuento de eliminación de la cola en los mensajes, lo que podría indicar intentos repetidos de error para eliminar el mensaje.
Examine los registros de registro de almacenamiento en busca de cualquier operación de cola que tenga valores de E2ELatency y ServerLatency superiores a los esperados durante un período de tiempo más largo de lo habitual.

Las métricas muestran un aumento en PercentThrottlingError

Los errores de limitación se producen cuando se superan los destinos de escalabilidad de un servicio de almacenamiento. El servicio de almacenamiento se limita para asegurarse de que ningún solo cliente o inquilino puede usar el servicio a costa de otros usuarios. Para obtener más información, consulte Objetivos de escalabilidad y rendimiento para cuentas de almacenamiento estándar para obtener más información sobre los destinos de escalabilidad de las cuentas de almacenamiento y los destinos de rendimiento de las particiones dentro de las cuentas de almacenamiento.

Si la métrica PercentThrottlingError muestra un aumento en el porcentaje de solicitudes que producen errores con un error de limitación, debe investigar uno de los dos escenarios:

Aumento transitorio de PercentThrottlingError
Aumento permanente del error PercentThrottlingError

Un aumento en PercentThrottlingError a menudo se produce al mismo tiempo que un aumento en el número de solicitudes de almacenamiento o cuando inicialmente está probando la carga de la aplicación. Esto también puede manifestarse en el cliente como mensajes de estado HTTP "503 Server Busy" o "500 Operation Timeout" de las operaciones de almacenamiento.

Aumento transitorio de PercentThrottlingError

Si ve picos en el valor de PercentThrottlingError que coinciden con períodos de alta actividad para la aplicación, puede implementar una estrategia de retroceso exponencial (no lineal) para reintentos en el cliente. Los reintentos de retroceso reducen la carga inmediata en la partición y ayudan a la aplicación a suavizar los picos de tráfico. Para obtener más información sobre cómo implementar directivas de reintento mediante la biblioteca de cliente de Storage, consulte el espacio de nombres Microsoft.Azure.Storage.RetryPolicies.

Nota:

También puede ver picos en el valor de PercentThrottlingError que no coinciden con períodos de alta actividad para la aplicación. La causa más probable es que el servicio de almacenamiento mueva particiones para mejorar el equilibrio de carga.

Aumento permanente de PercentThrottlingError

Si ve un valor constantemente alto para PercentThrottlingError después de un aumento permanente en los volúmenes de transacciones o al realizar las pruebas de carga iniciales en la aplicación, debe evaluar cómo la aplicación usa particiones de almacenamiento y si se está acercando a los objetivos de escalabilidad de una cuenta de almacenamiento. Por ejemplo, si ve errores de limitación en una cola (que cuenta como una sola partición), considere la posibilidad de usar colas adicionales para distribuir las transacciones entre varias particiones. Si ve errores de limitación en una tabla, debe considerar la posibilidad de usar un esquema de partición diferente para distribuir las transacciones entre varias particiones mediante un intervalo más amplio de valores de clave de partición. Una causa común de este problema es el antipatrón anteponer o anexar donde se selecciona la fecha como clave de partición y, a continuación, todos los datos de un día determinado se escriben en una partición: bajo carga, esto puede dar lugar a un cuello de botella de escritura. Considere un diseño de creación de particiones diferente o evalúe si el uso de Blob Storage podría ser una mejor solución. Además, compruebe si la limitación se produce como resultado de picos en el tráfico e investigue formas de suavizar el patrón de solicitudes.

Si distribuye las transacciones entre varias particiones, debe tener en cuenta los límites de escalabilidad establecidos para la cuenta de almacenamiento. Por ejemplo, si usó diez colas, cada una procesando el máximo de 2000 1 KB por segundo, estará en el límite general de 20 000 mensajes por segundo para la cuenta de almacenamiento. Si necesita procesar más de 20 000 entidades por segundo, considere la posibilidad de usar varias cuentas de almacenamiento. También debe tener en cuenta que el tamaño de las solicitudes y entidades tiene un impacto en cuando el servicio de almacenamiento limita a los clientes. Si tiene solicitudes y entidades más grandes, es posible que se le limite antes.

El diseño ineficaz de consultas también puede hacer que alcance los límites de escalabilidad de las particiones de tabla. Por ejemplo, una consulta con un filtro que solo selecciona el uno por ciento de las entidades de una partición, pero que examina todas las entidades de una partición, tendrá que acceder a cada entidad. Cada lectura de entidad contará para el número total de transacciones en esa partición; por lo tanto, puede alcanzar fácilmente los objetivos de escalabilidad.

Nota:

Las pruebas de rendimiento deben revelar cualquier diseño de consulta ineficaz en la aplicación.

Las métricas muestran un aumento en PercentTimeoutError

Las métricas muestran un aumento en PercentTimeoutError para uno de los servicios de almacenamiento. Al mismo tiempo, el cliente recibe un gran volumen de mensajes de estado HTTP "Tiempo de espera de la operación 500" de las operaciones de almacenamiento.

Nota:

Es posible que vea errores de tiempo de espera temporalmente a medida que el servicio de almacenamiento equilibra las solicitudes moviendo una partición a un nuevo servidor.

La métrica PercentTimeoutError es una agregación de las siguientes métricas: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError y SASServerTimeoutError.

Los tiempos de espera del servidor se deben a un error en el servidor. Los tiempos de espera de cliente se producen porque una operación en el servidor ha superado el tiempo de espera especificado por el cliente; por ejemplo, un cliente que usa la biblioteca cliente de Storage puede establecer un tiempo de espera para una operación mediante la ServerTimeout propiedad de la QueueRequestOptions clase .

Los tiempos de espera del servidor indican un problema con el servicio de almacenamiento que requiere una investigación adicional. Puede usar métricas para ver si alcanza los límites de escalabilidad del servicio e identificar los picos de tráfico que podrían estar causando este problema. Si el problema es intermitente, puede deberse a la actividad de equilibrio de carga en el servicio. Si el problema es persistente y no se debe a que la aplicación alcance los límites de escalabilidad del servicio, debe generar un problema de soporte técnico. Para los tiempos de espera de cliente, debe decidir si el tiempo de espera se establece en un valor adecuado en el cliente y cambiar el valor de tiempo de espera establecido en el cliente o investigar cómo puede mejorar el rendimiento de las operaciones en el servicio de almacenamiento, por ejemplo, mediante la optimización de las consultas de tabla o la reducción del tamaño de los mensajes.

Las métricas muestran un aumento en PercentNetworkError

Las métricas muestran un aumento en PercentNetworkError para uno de los servicios de almacenamiento. La métrica PercentNetworkError es una agregación de las siguientes métricas: NetworkError, AnonymousNetworkError y SASNetworkError. Se producen cuando el servicio de almacenamiento detecta un error de red cuando el cliente realiza una solicitud de almacenamiento.

La causa más común de este error es la desconexión de un cliente antes de que expire un tiempo de espera en el servicio de almacenamiento. Investigue el código del cliente para comprender por qué y cuándo se desconecta del servicio de almacenamiento. También puede usar Wireshark o Tcping para investigar los problemas de conectividad de red del cliente. Estas herramientas se describen en los Anexos.

El cliente recibe mensajes HTTP 403 (prohibidos)

Si la aplicación cliente produce errores HTTP 403 (prohibido), una causa probable es que el cliente esté usando una firma de acceso compartido (SAS) expirada cuando envía una solicitud de almacenamiento (aunque otras causas posibles incluyen sesgo de reloj, claves no válidas y encabezados vacíos). Si una clave SAS expirada es la causa, no verá ninguna entrada en los datos de registro de registro de almacenamiento del lado servidor. En la tabla siguiente se muestra un ejemplo del registro del lado cliente generado por la biblioteca cliente de Storage que muestra este problema que se produce:

Origen	Detalles	Detalles	Identificador de solicitud de cliente	Texto de la operación
Microsoft.Azure.Storage	Information	3	85d077ab-...	`Starting operation with location Primary per location mode PrimaryOnly.`
Microsoft.Azure.Storage	Information	3	85d077ab -...	`Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request.`
Microsoft.Azure.Storage	Information	3	85d077ab -...	`Waiting for response.`
Microsoft.Azure.Storage	Advertencia	2	85d077ab -...	`Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden.`
Microsoft.Azure.Storage	Information	3	85d077ab -...	`Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = .`
Microsoft.Azure.Storage	Advertencia	2	85d077ab -...	`Exception thrown during the operation: The remote server returned an error: (403) Forbidden..`
Microsoft.Azure.Storage	Information	3	85d077ab -...	`Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden..`
Microsoft.Azure.Storage	Information	3	85d077ab -...	`The next location has been set to Primary, based on the location mode.`
Microsoft.Azure.Storage	Error	1	85d077ab -...	`Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden.`

En este escenario, debe investigar por qué el token de SAS expira antes de que el cliente envíe el token al servidor:

Normalmente, no debe establecer una hora de inicio al crear una SAS para que un cliente la use inmediatamente. Si hay pequeñas diferencias de reloj entre el host que genera la SAS con la hora actual y el servicio de almacenamiento, es posible que el servicio de almacenamiento reciba una SAS que aún no es válida.
No establezca un tiempo de expiración muy corto en una SAS. De nuevo, las pequeñas diferencias de reloj entre el host que genera la SAS y el servicio de almacenamiento pueden dar lugar a que una SAS expire aparentemente antes de lo previsto.
¿El parámetro version de la clave SAS (por ejemplo, sv=2015-04-05) coincide con la versión de la biblioteca cliente de Storage que usa? Se recomienda usar siempre la versión más reciente de la biblioteca cliente de Storage.
Si vuelve a generar las claves de acceso de almacenamiento, es posible que se invalide cualquier token de SAS existente. Este problema puede surgir si genera tokens de SAS con un tiempo de expiración largo para que las aplicaciones cliente almacenen en caché.

Si usa la biblioteca cliente de Storage para generar tokens de SAS, es fácil crear un token válido. Sin embargo, si usa la API REST de Almacenamiento y construye los tokens de SAS a mano, consulte Delegación del acceso con una firma de acceso compartido.

El cliente recibe mensajes HTTP 404 (no encontrados)

Si la aplicación cliente recibe un mensaje HTTP 404 (no encontrado) del servidor, esto implica que el objeto que el cliente estaba intentando usar (por ejemplo, una entidad, una tabla, un blob, un contenedor o una cola) no existe en el servicio de almacenamiento. Hay varias razones posibles para ello, como:

El cliente u otro proceso eliminó previamente el objeto.
Problema de autorización de firma de acceso compartido (SAS).
El código JavaScript del lado cliente no tiene permiso para acceder al objeto.
Error de red.

El cliente u otro proceso eliminó previamente el objeto

En escenarios en los que el cliente intenta leer, actualizar o eliminar datos en un servicio de almacenamiento, normalmente es fácil identificar en los registros del lado servidor una operación anterior que eliminó el objeto en cuestión del servicio de almacenamiento. A menudo, los datos de registro muestran que otro usuario o proceso eliminó el objeto. En el registro de registro de almacenamiento del lado servidor, las columnas operation-type y requested-object-key se muestran cuando un cliente eliminó un objeto.

En el escenario en el que un cliente intenta insertar un objeto, es posible que no sea inmediatamente obvio por qué esto da como resultado una respuesta HTTP 404 (no encontrado), dado que el cliente está creando un nuevo objeto. Sin embargo, si el cliente está creando un blob, debe poder encontrar el contenedor de blobs. Si el cliente está creando un mensaje, debe poder encontrar una cola. Y si el cliente agrega una fila, debe poder encontrar la tabla.

Puede usar el registro del lado cliente de la biblioteca cliente de Storage para obtener una comprensión más detallada de cuándo el cliente envía solicitudes específicas al servicio de almacenamiento.

El siguiente registro del lado cliente generado por la biblioteca cliente de Storage muestra el problema cuando el cliente no encuentra el contenedor para el blob que está creando. Este registro incluye detalles de las siguientes operaciones de almacenamiento:

ID de solicitud	Operación
07b26a5d-...	`DeleteIfExists` para eliminar el contenedor de blobs. Tenga en cuenta que esta operación incluye una `HEAD` solicitud para comprobar la existencia del contenedor.
e2d06d78...	`CreateIfNotExists` para crear el contenedor de blobs. Tenga en cuenta que esta operación incluye una `HEAD` solicitud que comprueba la existencia del contenedor. `HEAD` devuelve un mensaje 404, pero continúa.
de8b1c3c-...	`UploadFromStream` para crear el blob. Se produce un error en la `PUT` solicitud con un mensaje 404.

Entradas de registro:

ID de solicitud	Texto de la operación
07b26a5d-...	`Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.`
07b26a5d-...	`StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.`
07b26a5d-...	`Waiting for response.`
07b26a5d-...	`Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = "0x8D14D2DC63D059B".`
07b26a5d-...	`Response headers were processed successfully, proceeding with the rest of the operation.`
07b26a5d-...	`Downloading response body.`
07b26a5d-...	`Operation completed successfully.`
07b26a5d-...	`Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer`.
07b26a5d-...	`StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.`
07b26a5d-...	`Waiting for response.`
07b26a5d-...	`Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = .`
07b26a5d-...	`Response headers were processed successfully, proceeding with the rest of the operation.`
07b26a5d-...	`Downloading response body.`
07b26a5d-...	`Operation completed successfully.`
e2d06d78-...	`Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.`
e2d06d78-...	`StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.`
e2d06d78-...	`Waiting for response.`
de8b1c3c-...	`Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt.`
de8b1c3c-...	`StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt.`
de8b1c3c-...	`Preparing to write request data.`
e2d06d78-...	`Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..`
e2d06d78-...	`Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = .`
e2d06d78-...	`Response headers were processed successfully, proceeding with the rest of the operation.`
e2d06d78-...	`Downloading response body.`
e2d06d78-...	`Operation completed successfully.`
e2d06d78-...	`Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer.`
e2d06d78-...	`StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container.`
e2d06d78-...	`Waiting for response.`
de8b1c3c-...	`Writing request data.`
de8b1c3c-...	`Waiting for response.`
e2d06d78-...	`Exception thrown while waiting for response: The remote server returned an error: (409) Conflict..`
e2d06d78-...	`Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = .`
e2d06d78-...	`Downloading error response body.`
de8b1c3c-...	`Exception thrown while waiting for response: The remote server returned an error: (404) Not Found..`
de8b1c3c-...	`Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = .`
de8b1c3c-...	`Exception thrown during the operation: The remote server returned an error: (404) Not Found..`
de8b1c3c-...	`Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found..`
e2d06d78-...	`Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict..`

En este ejemplo, el registro muestra que el cliente intercala solicitudes del CreateIfNotExists método (id. de solicitud e2d06d78...) con las solicitudes del UploadFromStream método (de8b1c3c-...). Este intercalado se produce porque la aplicación cliente invoca estos métodos de forma asincrónica. Modifique el código asincrónico del cliente para asegurarse de que crea el contenedor antes de intentar cargar los datos en un blob de ese contenedor. Lo ideal es crear todos los contenedores de antemano.

Un problema de autorización de firma de acceso compartido (SAS)

Si la aplicación cliente intenta usar una clave SAS que no incluye los permisos necesarios para la operación, el servicio de almacenamiento devuelve un mensaje HTTP 404 (no encontrado) al cliente. Al mismo tiempo, también verá un valor distinto de cero para SASAuthorizationError en las métricas.

En la tabla siguiente se muestra un mensaje de registro del lado servidor de ejemplo del archivo de registro de registro de almacenamiento:

Nombre	Valor
Hora de inicio de la solicitud	2014-05-30T06:17:48.4473697Z
Tipo de operación	GetBlobProperties
Estado de la solicitud	SASAuthorizationError
Código de estado HTTP	404
Tipo de autenticación	Sas
Tipo de servicio	Blob
Dirección URL de la solicitud	`https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt`
	?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&; api-version=2014-02-14
Encabezado de identificador de solicitud	<Encabezado de identificador de solicitud>
Identificador de solicitud de cliente	<Identificador de solicitud de cliente>

Investigue por qué la aplicación cliente intenta realizar una operación para la que no se le han concedido permisos.

El código JavaScript del lado cliente no tiene permiso para acceder al objeto

Si usa un cliente JavaScript y el servicio de almacenamiento devuelve mensajes HTTP 404, compruebe los siguientes errores de JavaScript en el explorador:

SEC7120: el origen http://localhost:56309 no se encuentra en el encabezado Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: error de red 0x80070005, se deniega el acceso.

Nota:

Puede usar F12 Developer Tools en Internet Explorer para realizar un seguimiento de los mensajes intercambiados entre el explorador y el servicio de almacenamiento al solucionar problemas de JavaScript del lado cliente.

Estos errores se producen porque el explorador web implementa la misma restricción de seguridad de directiva de origen que impide que una página web llame a una API en un dominio diferente del dominio del que procede la página.

Para solucionar el problema de JavaScript, puede configurar el uso compartido de recursos entre orígenes (CORS) para el servicio de almacenamiento al que está accediendo el cliente. Para obtener más información, consulte Compatibilidad con el uso compartido de recursos entre orígenes (CORS) para servicios de Azure Storage.

En el ejemplo de código siguiente se muestra cómo configurar blob service para permitir que JavaScript que se ejecuta en el dominio contoso acceda a un blob en el servicio blob storage:

SDK de .NET v12
SDK de .NET v11

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

CloudBlobClient client = new CloudBlobClient(blobEndpoint, new StorageCredentials(accountName, accountKey));
// Set the service properties.
ServiceProperties sp = client.GetServiceProperties();
sp.DefaultServiceVersion = "2013-08-15";
CorsRule cr = new CorsRule();
cr.AllowedHeaders.Add("*");
cr.AllowedMethods = CorsHttpMethods.Get | CorsHttpMethods.Put;
cr.AllowedOrigins.Add("http://www.contoso.com");
cr.ExposedHeaders.Add("x-ms-*");
cr.MaxAgeInSeconds = 5;
sp.Cors.CorsRules.Clear();
sp.Cors.CorsRules.Add(cr);
client.SetServiceProperties(sp);

Error de red

En algunas circunstancias, la pérdida de paquetes de red puede provocar que el servicio de almacenamiento devuelva mensajes HTTP 404 al cliente. Por ejemplo, cuando la aplicación cliente elimina una entidad del servicio de tabla, verá que el cliente inicia una excepción de almacenamiento que informa de un mensaje de estado "HTTP 404 (no encontrado)" desde table service. Al investigar la tabla en el servicio de almacenamiento de tablas, verá que el servicio eliminó la entidad según lo solicitado.

Los detalles de la excepción en el cliente incluyen el identificador de solicitud (7e84f12d...) asignado por table service para la solicitud. Puede usar esta información para buscar los detalles de la solicitud en los registros de almacenamiento del lado servidor mediante la búsqueda en la request-id-header columna del archivo de registro. También puede usar las métricas para identificar cuándo se producen errores como este y, a continuación, buscar en los archivos de registro en función del momento en que las métricas registraron este error. Esta entrada de registro muestra que se produjo un error en la eliminación con un mensaje de estado "HTTP (404) Client Other Error". La misma entrada de registro también incluye el identificador de solicitud generado por el cliente en la client-request-id columna (813ea74f...).

El registro del lado servidor también incluye otra entrada con el mismo client-request-id valor (813ea74f...) para una operación de eliminación correcta para la misma entidad y desde el mismo cliente. Esta operación de eliminación correcta tuvo lugar muy poco antes de que se produjera un error en la solicitud de eliminación.

La causa más probable de este escenario es que el cliente envió una solicitud de eliminación para la entidad a Table Service, que se realizó correctamente pero no recibió una confirmación del servidor (quizás debido a un problema de red temporal). A continuación, el cliente reintentó automáticamente la operación (con el mismo client-request-id) y se produjo un error en este reintento porque la entidad ya se había eliminado.

Si este problema se produce con frecuencia, debe investigar por qué el cliente no recibe confirmaciones de Table Service. Si el problema es intermitente, debe interceptar el error "HTTP (404) No encontrado" y registrarlo en el cliente, pero permitir que el cliente continúe.

El cliente recibe mensajes HTTP 409 (conflicto)

En la tabla siguiente se muestra una extracción del registro del lado servidor para dos operaciones de cliente: DeleteIfExists seguida inmediatamente con CreateIfNotExists el mismo nombre de contenedor de blobs. Cada operación de cliente da como resultado dos solicitudes enviadas al servidor, en primer lugar una GetContainerProperties solicitud para comprobar si el contenedor existe, seguida de la DeleteContainer solicitud o CreateContainer .

Timestamp	Operación	Resultado	Nombre del contenedor	Identificador de solicitud de cliente
05:10:13.7167225	`GetContainerProperties`	200	mmcont	c9f52c89-...
05:10:13.8167325	`DeleteContainer`	202	mmcont	c9f52c89-...
05:10:13.8987407	`GetContainerProperties`	404	mmcont	bc881924-...
05:10:14.2147723	`CreateContainer`	409	mmcont	bc881924-...

El código de la aplicación cliente elimina y, a continuación, vuelve a crear inmediatamente un contenedor de blobs con el mismo nombre: el CreateIfNotExists método (id. de solicitud de cliente bc881924-...) finalmente produce un error HTTP 409 (conflicto). Cuando un cliente elimina contenedores de blobs, tablas o colas, hay un breve período antes de que el nombre vuelva a estar disponible.

La aplicación cliente debe usar nombres de contenedor únicos cada vez que cree nuevos contenedores si el patrón de eliminación o recreación es común.

Las métricas muestran que las entradas de registro percentSuccess o analytics bajas tienen operaciones con el estado de transacción ClientOtherErrors.

La métrica PercentSuccess captura el porcentaje de operaciones que se realizaron correctamente en función de su código de estado HTTP. Las operaciones con códigos de estado de 2XX cuentan como correctas, mientras que las operaciones con códigos de estado en los intervalos 3XX, 4XX y 5XX se cuentan como incorrectas y reducen el valor de la métrica PercentSuccess . En los archivos de registro de almacenamiento del lado servidor, estas operaciones se registran con un estado de transacción de ClientOtherErrors.

Es importante tener en cuenta que estas operaciones se han completado correctamente y, por tanto, no afectan a otras métricas, como la disponibilidad. Algunos ejemplos de operaciones que se ejecutan correctamente, pero que pueden dar lugar a códigos de estado HTTP incorrectos, incluyen:

ResourceNotFound (no encontrado 404), por ejemplo, desde una GET solicitud a un blob que no existe.
ResourceAlreadyExists (conflicto 409), por ejemplo, de una CreateIfNotExist operación donde el recurso ya existe.
ConditionNotMet (No modificado 304), por ejemplo, desde una operación condicional como cuando un cliente envía un ETag valor y un encabezado HTTP If-None-Match para solicitar una imagen solo si se ha actualizado desde la última operación.

Puede encontrar una lista de códigos de error comunes de la API REST que los servicios de almacenamiento devuelven en la página Códigos de error de la API rest común.

Las métricas de capacidad muestran un aumento inesperado del uso de la capacidad de almacenamiento

Si ve cambios repentinos e inesperados en el uso de la capacidad en la cuenta de almacenamiento, puede investigar los motivos examinando primero las métricas de disponibilidad; por ejemplo, un aumento en el número de solicitudes de eliminación con errores podría dar lugar a un aumento en la cantidad de almacenamiento de blobs que usa como operaciones de limpieza específicas de la aplicación que podría haber esperado que estén liberando espacio puede que no funcione como se esperaba (por ejemplo, porque los tokens de SAS usados para liberar espacio han expirado).

El problema surge del uso del emulador de almacenamiento para el desarrollo o la prueba

Normalmente, el emulador de almacenamiento se usa durante el desarrollo y las pruebas para evitar el requisito de una cuenta de almacenamiento de Azure. Los problemas comunes que pueden producirse al usar el emulador de almacenamiento son:

La característica "X" no funciona en el emulador de almacenamiento.
Error "El valor de uno de los encabezados HTTP no está en el formato correcto" al usar el emulador de almacenamiento.
La ejecución del emulador de almacenamiento requiere privilegios administrativos.

La característica "X" no funciona en el emulador de almacenamiento

El emulador de almacenamiento no admite todas las características de los servicios de almacenamiento de Azure, como el servicio de archivos. Para obtener más información, consulte Uso del emulador de Azure Storage para desarrollo y pruebas.

Para aquellas características que el emulador de almacenamiento no admite, use el servicio azure storage en la nube.

Error "El valor de uno de los encabezados HTTP no está en el formato correcto" al usar el emulador de almacenamiento

Está probando la aplicación que usa la biblioteca cliente de Storage en el emulador de almacenamiento local y las llamadas al método como CreateIfNotExists error con el mensaje de error "El valor de uno de los encabezados HTTP no está en el formato correcto". Esto indica que la versión del emulador de almacenamiento que usa no admite la versión de la biblioteca cliente de almacenamiento que usa. La biblioteca cliente de Storage agrega el encabezado x-ms-version a todas las solicitudes que realiza. Si el emulador de almacenamiento no reconoce el valor en el x-ms-version encabezado, rechaza la solicitud.

Puede usar los registros de cliente de la biblioteca de almacenamiento para ver el valor del x-ms-version header que está enviando. También puede ver el valor de x-ms-version header si usa Fiddler para realizar un seguimiento de las solicitudes de la aplicación cliente.

Este escenario suele producirse si instala y usa la versión más reciente de la biblioteca cliente de Storage sin actualizar el emulador de almacenamiento. Debe instalar la versión más reciente del emulador de almacenamiento o usar el almacenamiento en la nube en lugar del emulador para el desarrollo y las pruebas.

La ejecución del emulador de almacenamiento requiere privilegios administrativos

Se le pedirán credenciales de administrador al ejecutar el emulador de almacenamiento. Esto solo se produce al inicializar el emulador de almacenamiento por primera vez. Después de inicializar el emulador de almacenamiento, no necesita privilegios administrativos para volver a ejecutarlo.

Para obtener más información, consulte Uso del emulador de Azure Storage para desarrollo y pruebas. También puede inicializar el emulador de almacenamiento en Visual Studio, que también requerirá privilegios administrativos.

Tiene problemas para instalar el SDK de Azure para .NET.

Al intentar instalar el SDK, se produce un error al intentar instalar el emulador de almacenamiento en el equipo local. El registro de instalación contiene uno de los siguientes mensajes:

CAQuietExec: Error: No se puede acceder a la instancia de SQL
CAQuietExec: Error: No se puede crear una base de datos

La causa es un problema con la instalación de LocalDB existente. De forma predeterminada, el emulador de almacenamiento usa LocalDB para conservar los datos cuando simula los servicios de almacenamiento de Azure. Puede restablecer la instancia de LocalDB ejecutando los siguientes comandos en una ventana del símbolo del sistema antes de intentar instalar el SDK.

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

El delete comando quita los archivos de base de datos antiguos de instalaciones anteriores del emulador de almacenamiento.

Tiene un problema diferente con un servicio de almacenamiento

Si las secciones de solución de problemas anteriores no incluyen el problema que tiene con un servicio de almacenamiento, debe adoptar el siguiente enfoque para diagnosticar y solucionar el problema.

Compruebe las métricas para ver si hay algún cambio con respecto al comportamiento previsto de la línea base. A partir de las métricas, puede determinar si el problema es transitorio o permanente y qué operaciones de almacenamiento afecta al problema.
Puede usar la información de métricas para ayudarle a buscar en los datos de registro del lado servidor información más detallada sobre los errores que se producen. Esta información puede ayudarle a solucionar el problema y resolverlo.
Si la información de los registros del lado servidor no es suficiente para solucionar el problema correctamente, puede usar los registros del lado cliente de la biblioteca cliente de Storage para investigar el comportamiento de la aplicación cliente y herramientas como Fiddler y Wireshark para investigar la red.

Para obtener más información sobre el uso de Fiddler, consulte Apéndice 1: Uso de Fiddler para capturar el tráfico HTTP y HTTPS.

Para obtener más información sobre el uso de Wireshark, consulte Apéndice 2: Uso de Wireshark para capturar el tráfico de red.

Apéndices

En los anexos se describen varias herramientas que puede resultarle útiles al diagnosticar y solucionar problemas con Azure Storage (y otros servicios). Estas herramientas no forman parte de Azure Storage y algunas son productos de terceros. Por lo tanto, las herramientas que se describen en estos anexos no están cubiertas por ningún contrato de soporte técnico que pueda tener con Microsoft Azure o Azure Storage. Por lo tanto, como parte del proceso de evaluación, debe examinar las opciones de licencia y soporte técnico disponibles de los proveedores de estas herramientas.

Apéndice 1: Uso de Fiddler para capturar tráfico HTTP y HTTPS

Fiddler es una herramienta útil para analizar el tráfico HTTP y HTTPS entre la aplicación cliente y el servicio de almacenamiento de Azure que usa.

Nota:

Fiddler puede descodificar el tráfico HTTPS. Debe leer cuidadosamente la documentación de Fiddler para comprender cómo lo hace y sus implicaciones en la seguridad.

En este apéndice se proporciona un breve tutorial sobre cómo configurar Fiddler para capturar el tráfico entre la máquina local donde ha instalado Fiddler y los servicios de Almacenamiento de Azure.

Después de iniciar Fiddler, comenzará a capturar el tráfico HTTP y HTTPS en el equipo local. A continuación se muestran algunos comandos útiles para controlar Fiddler:

Detenga y empiece a capturar tráfico. En el menú principal, vaya a Archivo y, a continuación, seleccione Capturar tráfico para activar y desactivar la captura.
Guarde los datos de tráfico capturados. En el menú principal, vaya a Archivo, seleccione Guardar y, a continuación, seleccione Todas las sesiones. Esto le permite guardar el tráfico en un archivo de archivo de sesión. Puede volver a cargar un archivo de sesión más adelante para su análisis o enviarlo si se solicita al soporte técnico de Microsoft.

Para limitar la cantidad de tráfico que captura Fiddler, puede usar los filtros que configure en la pestaña Filtros . En la captura de pantalla siguiente se muestra un filtro que captura solo el tráfico enviado al contosoemaildist.table.core.windows.net punto de conexión de almacenamiento:

Captura de pantalla que muestra un filtro que captura solo el tráfico enviado al punto de conexión de almacenamiento de contosoemaildist.table.core.windows.net.

Apéndice 2: Uso de Wireshark para capturar el tráfico de red

Wireshark es un analizador de protocolos de red que le permite ver información detallada de paquetes para una amplia gama de protocolos de red.

En el procedimiento siguiente se muestra cómo capturar información detallada de paquetes para el tráfico desde la máquina local en la que instaló Wireshark al servicio de tabla en la cuenta de Azure Storage.

Inicie Wireshark en el equipo local.
En la sección Inicio , seleccione la interfaz de red local o las interfaces que están conectadas a Internet.
Seleccione Opciones de captura.
Agregue un filtro al cuadro de texto Capturar filtro . Por ejemplo, host contosoemaildist.table.core.windows.net configurará Wireshark para capturar solo los paquetes enviados al punto de conexión de table service o desde él en la cuenta de almacenamiento contosoemaildist . Consulte la lista completa de filtros de captura.
Seleccione Inicio. Wireshark capturará ahora todos los paquetes enviados al punto de conexión de Table Service o desde él a medida que use la aplicación cliente en el equipo local.
Cuando haya terminado, seleccione Capturar>detener en el menú principal.
Para guardar los datos capturados en un archivo de captura de Wireshark, seleccione Guardar> archivo en el menú principal.

WireShark resaltará los errores que existan en la ventana de lista de paquetes . También puede usar la ventana Información de experto (seleccione Analizar>información de experto) para ver un resumen de errores y advertencias.

Captura de pantalla que muestra la ventana Información de expertos, donde puede ver un resumen de errores y advertencias.

También puede elegir ver los datos TCP como la capa de aplicación los ve haciendo clic con el botón derecho en los datos TCP y seleccionando Seguir Stream TCP. Esto resulta útil si capturó el volcado sin un filtro de captura. Para obtener más información, vea Following TCP Streams (Siguiente secuencias TCP).

Captura de pantalla que muestra cómo ver los datos TCP a medida que la capa de aplicación los ve.

Nota:

Para obtener más información sobre el uso de Wireshark, consulte la Guía de usuarios de Wireshark.

Apéndice 4: Uso de Excel para ver métricas y datos de registro

Muchas herramientas permiten descargar los datos de métricas de almacenamiento de Azure Table Storage en un formato delimitado que facilita la carga de los datos en Excel para su visualización y análisis. Los datos de registro de almacenamiento de Azure Blob Storage ya están en un formato delimitado que puede cargar en Excel. Sin embargo, deberá agregar los encabezados de columna adecuados en función de la información de Storage Analytics formato de registro y Storage Analytics esquema de tabla de métricas.

Para importar los datos de registro de almacenamiento en Excel después de descargarlos de Blob Storage:

En el menú Datos , seleccione Desde texto.
Vaya al archivo de registro que desea ver y seleccione Importar.
En el paso 1 del Asistente para importación de texto, seleccione Delimitado.

En el paso 1 del Asistente para importación de texto, seleccione Punto y coma como único delimitador y elija comilla doble como calificador de texto. A continuación, seleccione Finalizar y elija dónde colocar los datos en el libro.

Apéndice 5: Supervisión con Application Insights para Azure DevOps

También puede usar la característica Application Insights para Azure DevOps como parte de la supervisión de rendimiento y disponibilidad. Esta herramienta puede:

Asegúrese de que el servicio web está disponible y tiene capacidad de respuesta. Tanto si la aplicación es un sitio web como una aplicación de dispositivo que usa un servicio web, puede probar la dirección URL cada pocos minutos desde ubicaciones de todo el mundo y avisarle si hay un problema.
Diagnostique rápidamente cualquier problema de rendimiento o excepciones en el servicio web. Averigüe si la CPU u otros recursos se están estirando, obtenga seguimientos de pila de excepciones y busque fácilmente en seguimientos de registro. Si el rendimiento de la aplicación cae por debajo de los límites aceptables, Microsoft puede enviarle un correo electrónico. Puede supervisar los servicios web de .NET y Java.

Puede encontrar más información en ¿Qué es Application Insights?

Pasos siguientes

Para obtener más información sobre el análisis en Azure Storage, consulte estos recursos:

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.

Comparteix a través de

Supervisión, diagnóstico y solución de problemas de Microsoft Azure Storage (clásico)

Información general

Cómo se organiza esta guía

Supervisión del servicio de almacenamiento

Supervisión del estado del servicio

Capacidad de supervisión

Supervisión de la disponibilidad

Supervisión del rendimiento

Diagnóstico de problemas de almacenamiento

problemas de Estado del servicio

Problemas de rendimiento

Diagnóstico de errores

Problemas del emulador de almacenamiento

Herramientas de registro de almacenamiento

Uso de herramientas de registro de red

Seguimiento de un extremo a otro

Correlación de datos de registro

Identificador de solicitud de cliente

Identificador de solicitud del servidor

Marcas de tiempo

Guía de solución de problemas

Las métricas muestran un promedio alto de 2ELatency y una baja latencia averageServerLatency

Investigación de problemas de rendimiento del cliente

Investigación de problemas de latencia de red

Las métricas muestran una latencia baja de AverageE2ELatency y una baja de AverageServerLatency, pero el cliente experimenta una latencia alta.

Las métricas muestran una alta averageServerLatency

Está experimentando retrasos inesperados en la entrega de mensajes en una cola

Las métricas muestran un aumento en PercentThrottlingError

Aumento transitorio de PercentThrottlingError

Aumento permanente de PercentThrottlingError

Las métricas muestran un aumento en PercentTimeoutError

Las métricas muestran un aumento en PercentNetworkError

El cliente recibe mensajes HTTP 403 (prohibidos)

El cliente recibe mensajes HTTP 404 (no encontrados)

El cliente u otro proceso eliminó previamente el objeto

Un problema de autorización de firma de acceso compartido (SAS)

El código JavaScript del lado cliente no tiene permiso para acceder al objeto

Error de red

El cliente recibe mensajes HTTP 409 (conflicto)

Las métricas muestran que las entradas de registro percentSuccess o analytics bajas tienen operaciones con el estado de transacción ClientOtherErrors.

Las métricas de capacidad muestran un aumento inesperado del uso de la capacidad de almacenamiento

El problema surge del uso del emulador de almacenamiento para el desarrollo o la prueba

La característica "X" no funciona en el emulador de almacenamiento

Error "El valor de uno de los encabezados HTTP no está en el formato correcto" al usar el emulador de almacenamiento

La ejecución del emulador de almacenamiento requiere privilegios administrativos

Tiene problemas para instalar el SDK de Azure para .NET.

Tiene un problema diferente con un servicio de almacenamiento

Apéndices

Apéndice 1: Uso de Fiddler para capturar tráfico HTTP y HTTPS

Apéndice 2: Uso de Wireshark para capturar el tráfico de red

Apéndice 4: Uso de Excel para ver métricas y datos de registro

Apéndice 5: Supervisión con Application Insights para Azure DevOps

Pasos siguientes

Ponte en contacto con nosotros para obtener ayuda

Comentaris

Recursos addicionals