Supervisión, diagnóstico y solución de problemas de Microsoft Azure Storage (clásicos)
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.
Esta guía está dirigida, principalmente, a los desarrolladores de servicios en línea que usan los servicios de Azure Storage y a los profesionales de TI responsables de administrar esos servicios en línea. Los objetivos de esta guía son:
- Ayudarle a mantener el estado y el rendimiento de las cuentas de Azure Storage.
- Proporcionarle las herramientas y los procesos necesarios para que le resulte más fácil averiguar si un problema de una aplicación está relacionado con Azure Storage.
- Proporcionarle una guía para que pueda actuar y resolver problemas relacionados con Azure Storage.
Nota:
Este artículo se basa en el uso de métricas y registros de Storage Analytics denominados métricas y registros clásicos. Se recomienda usar los registros y las métricas de Azure Storage en Azure Monitor en lugar de los registros de Storage Analytics. Para más información, consulte cualquiera de los siguientes artículos:
Información general
Diagnosticar y solucionar problemas en una aplicación distribuida que está hospedada en un entorno de nube puede ser más complicado que en los entornos tradicionales. Las aplicaciones se pueden implementar en una infraestructura PaaS o IaaS, en una ubicación local, en un dispositivo móvil o en varios de estos entornos combinados. 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 de 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 problemas de 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 usa la aplicación para detectar cambios inesperados en el comportamiento (como tiempos de respuesta más lentos que habituales) 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. Luego puede solucionar el problema y determinar los pasos adecuados para remediarlo. Azure Storage es un servicio principal de Azure y forma una parte importante de la mayoría de las soluciones que los clientes implementan en la infraestructura de Azure. Azure Storage incluye funcionalidades que permiten simplificar la supervisión, el diagnóstico y la solución de problemas de almacenamiento de las aplicaciones basadas en la nube.
Organización de la 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 de solución de problemas para 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 los datos de paquetes de red, y Fiddler para analizar mensajes HTTP/HTTPS.
Supervisión del servicio de almacenamiento
Si conoce la supervisión de rendimiento de Windows, las métricas de Almacenamiento son algo así como los contadores del monitor de rendimiento de Windows, pero en Azure Storage. En Métricas de almacenamiento, encontrará un conjunto completo de métricas (contadores en la terminología de Windows Monitor de rendimiento), como la disponibilidad del servicio, el número total de solicitudes al servicio o el porcentaje de solicitudes correctas al servicio. Si quiere obtener la lista completa de métricas disponibles, consulte Esquema de tabla de métricas de Storage Analytics. Puede especificar si quiere que el servicio de almacenamiento recopile y agregue métricas cada hora o cada minuto. Para más información sobre cómo habilitar las métricas y supervisar las cuentas de almacenamiento, consulte el tema sobre cómo Habilitar las métricas de almacenamiento y ver los datos de métricas.
Puede elegir las métricas horarias que quiere mostrar en Azure Portal y configurar reglas que notifiquen a los administradores por correo electrónico cada vez que una métrica horaria supere un umbral determinado. Para más información, consulte Recibir notificaciones de alerta.
Se recomienda consultar 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, ya que ofrece una vista unificada del rendimiento, la capacidad y la disponibilidad de los servicios de Azure Storage. No es preciso habilitar o 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 Azure Portal, puede ver métricas con cifras sobre la disponibilidad, el número total de solicitudes y la latencia media de una cuenta de almacenamiento. También se configuró una regla de notificación para que se envíe una alerta a un administrador si la disponibilidad desciende por debajo de un nivel determinado. Desde la visualización de estos datos, un área posible para la investigación es que el porcentaje de éxito de Table Service es inferior al 100 % (para obtener más información, consulte la sección Métricas que muestran que las entradas de registro percentSuccess o de análisis bajas tienen operaciones con el estado de transacción de ClientOtherErrors ).
Debe supervisar continuamente las aplicaciones de Azure para asegurarse de que el estado es correcto y el rendimiento es el esperado, haciendo lo siguiente:
- Establecer algunas métricas de línea de 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 de 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 las tasas de solicitudes.
- Registrar métricas horarias y usarlas para supervisar los valores medios, como el número medio de errores y las tasas medias 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 siguiente imagen ilustran cómo el promedio resultante de las métricas horarias puede ocultar picos de actividad. Las métricas horarias parecen mostrar una tasa de solicitudes regular, mientras que las métricas por minuto revelan las fluctuaciones que se están produciendo en realidad.
En el resto de esta sección, se explica qué métricas debe supervisar y por qué.
Supervisión del estado del servicio
Puede usar Azure Portal para ver el estado del servicio Storage (y de otros servicios de Azure) en todas las regiones de Azure del mundo. La supervisión le permite ver inmediatamente si un problema fuera del control afecta al servicio Storage en la región que usa para la aplicación.
Azure Portal también puede proporcionar notificaciones sobre los incidentes que afectan a los diversos servicios de Azure.
Nota:
Anteriormente esta información estaba disponible, junto con los datos históricos, en el Panel de servicios de Azure. Para más información sobre Application Insights para Azure DevOps, consulte el Apéndice 5: Supervisión con Application Insights para Azure DevOps.
Supervisión de la capacidad
Las métricas de almacenamiento solo almacenan las métricas de capacidad de Blob service, porque los blob suelen representar la mayor parte de los datos almacenados (en el momento de la escritura, no se pueden usar las métricas de almacenamiento para supervisar la capacidad de las tablas y las colas). Puede encontrar estos datos en la $MetricsCapacityBlob tabla si ha habilitado la supervisión de Blob service. Las métricas de almacenamiento registran estos datos una vez al día y puede usar el valor de RowKey para determinar si la fila contiene una entidad relacionada con los datos de usuario (valor ) o los datos de análisis (valor dataanalytics). Cada entidad almacenada contiene información sobre la cantidad de almacenamiento utilizado (Capacity medido en bytes) y el número actual de contenedores () y blobs (ObjectCountContainerCount) 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 Esquema de tabla de métricas de Storage Analytics.
Nota:
Debe supervisar estos valores para saber con antelación si se está acercando a los límites de capacidad de la cuenta de almacenamiento. En Azure Portal, puede agregar reglas de alerta para notificarle si el uso de almacenamiento agregado supera o cae por debajo de los umbrales que especifique.
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 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 en las tablas de métricas por hora o minuto: $MetricsHourPrimaryTransactionsBlob, , $MetricsMinutePrimaryTransactionsBlob$MetricsHourPrimaryTransactionsQueue$MetricsMinutePrimaryTransactionsTable$MetricsHourPrimaryTransactionsTable, . $MetricsCapacityBlob$MetricsMinutePrimaryTransactionsQueue La Availability columna contiene un valor de porcentaje que indica la disponibilidad del servicio o la operación de API representada por la fila ( RowKey muestra si la fila contiene métricas para el servicio en su conjunto o para una operación de API específica).
Si el valor es inferior al 100%, significa que algunas solicitudes de almacenamiento no se están realizando correctamente. Puede ver por qué se producen errores examinando las otras columnas de los datos de métricas que muestran los números de solicitudes con tipos de error diferentes, como ServerTimeoutError. Debería esperar ver que Availability se encuentra temporalmente por debajo del 100 % por motivos como los tiempos de espera transitorios del servidor mientras el servicio mueve las particiones a mejores solicitudes de equilibrio de carga; la lógica de reintento de la aplicación cliente debe controlar estas condiciones intermitentes. En el artículo Operaciones registradas y mensajes de estado de Storage Analytics se enumeran los tipos de transacción que las métricas de almacenamiento incluyen en su Availability cálculo.
En Azure Portal, puede agregar reglas de alerta para notificarle si Availability un servicio está por debajo de un umbral que especifique.
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 horarias y por minuto.
- Los valores de las
AverageE2ELatencycolumnas yAverageServerLatencymuestran el promedio de tiempo que tarda el servicio de almacenamiento o el tipo de operación de API en procesar las solicitudes.AverageE2ELatencyes 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 latencia de red una vez que la solicitud llega al servicio de almacenamiento);AverageServerLatencyes una medida del tiempo de procesamiento y, por tanto, excluye cualquier latencia de red relacionada con la comunicación con el cliente. Consulte la sección Métricas show high AverageE2ELatency y low AverageServerLatency más adelante en esta guía para obtener una explicación de por qué podría haber una diferencia significativa entre estos dos valores. - Los valores de las
TotalIngresscolumnas yTotalEgressmuestran 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
TotalRequestscolumna muestran el número total de solicitudes que recibe el servicio de almacenamiento de la operación de API.TotalRequestses 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 Azure Portal, puede agregar reglas de alerta para notificarle si las métricas de rendimiento de este servicio se encuentran por debajo o superan un umbral que especifique.
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 descubrir que existe un problema en la aplicación, entre las que se incluyen las siguientes:
- 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.
- Informes de usuarios de la aplicación que comuniquen que alguna operación concreta no se completó como se esperaba o que alguna característica no está funcionando.
- Errores generados dentro de la aplicación que aparecen en los archivos de registro o en algún otro método de notificación.
Normalmente, los problemas relacionados con los servicios de almacenamiento de Azure entran en una de estas cuatro categorías generales:
- La aplicación tiene un problema de rendimiento, ya sea notificado por los usuarios o revelado por los cambios en las métricas de rendimiento.
- Hay un problema relacionado con la infraestructura de Azure Storage en una o varias regiones.
- La aplicación detecta 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, puede usar el emulador de almacenamiento local; Es posible que encuentre algunos problemas relacionados específicamente con el uso del emulador de almacenamiento.
En las siguientes secciones, se describen los pasos que debe seguir para diagnosticar y resolver los problemas de cada una de estas cuatro categorías. La sección Guía de solución de problemas más adelante en esta guía proporciona más detalles para algunos problemas comunes que puede encontrar.
Problemas de estado del servicio
Los problemas de estado del servicio suelen estar fuera de su control. Azure Portal proporciona información sobre cualquier problema continuo con los servicios de Azure, incluidos los servicios de almacenamiento. Si eligió el almacenamiento con redundancia geográfica con acceso de lectura al crear la cuenta de almacenamiento, si los datos dejaran de estar disponibles en la ubicación principal, la aplicación puede cambiar temporalmente a la copia de solo lectura de la ubicación secundaria. Para leer desde la base de datos secundaria, la aplicación debe poder cambiar entre 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 le permiten definir una directiva de reintentos que pueda leer el almacenamiento secundario si se produce un error al leer el almacenamiento principal. Además, la aplicación tiene que saber que los datos de la ubicación secundaria tienen coherencia final. Para más información, consulte la entrada de blog sobre Azure Storage Redundancy Options and Read Access Geo Redundant Storage.
Problemas de rendimiento
El rendimiento de una aplicación puede ser subjetivo, especialmente desde el punto de vista de los usuarios. Por ello, es importante tener métricas de línea base disponibles con las que le resulte más fácil identificar los casos en los que puede haber un problema de rendimiento. Hay muchos factores que 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.
Después de identificar, a partir de las métricas, la ubicación donde es más probable que se encuentre el motivo del problema de rendimiento, puede usar los archivos de registro para buscar información detallada que le permita seguir diagnosticando y solucionando el problema.
La sección Guía de 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
Puede que los usuarios de la aplicación le notifiquen los errores de los que informa la aplicación cliente. Las métricas de almacenamiento también registran recuentos de diferentes tipos de error de los servicios de almacenamiento, como NetworkError, ClientTimeoutError o AuthorizationError. Las métricas de Almacenamiento solamente registran los recuentos de diversos tipos de errores, pero puede obtener más detalles sobre cada una de las solicitudes examinando los registros del lado servidor, del lado cliente y de la red. Normalmente, el código de estado HTTP que devuelva el servicio de almacenamiento aportará una indicación del motivo de error en la solicitud.
Nota:
Recuerde que debería esperar ver algunos errores intermitentes: por ejemplo, errores debidos a condiciones de red transitorias o errores de aplicación.
Los siguientes recursos resultan útiles para entender los códigos de error y estado relacionados con el almacenamiento:
- Códigos de error comunes de la API REST
- Códigos de error de Blob Service
- Códigos de error de Queue Service
- Códigos de error de Table Service
- Códigos de error del servicio de archivos
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ía 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 almacenamiento de Azure 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 Storage proporciona el registro del lado servidor de las solicitudes de almacenamiento de la cuenta de Azure Storage. Para 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 de cliente de Almacenamiento para .NET le permite recopilar datos de registro del lado cliente relacionados con las operaciones de almacenamiento que realiza la aplicación. Para obtener más información, consulte Registro de cliente con biblioteca de cliente de almacenamiento .NET.
Nota:
En algunas circunstancias (por ejemplo, en el caso de los errores de autorización de SAS), es posible que un usuario informe de un error y que usted no encuentre datos de la solicitud correspondiente en los registros de Almacenamiento del lado servidor. Puede utilizar las funcionalidades de registro de la biblioteca de cliente de Almacenamiento para investigar si la causa del problema se encuentra 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 están intercambiando el cliente y el servidor y sobre las condiciones de la red subyacente. Algunas herramientas útiles de redes son:
- Fiddler es un proxy de depuración web gratuito que permite examinar los encabezados y los datos de carga útil de los mensajes de solicitud y respuesta HTTP y HTTPS. Para más información, consulte el Apéndice 1: Uso de Fiddler para capturar tráfico HTTP y HTTPS.
- Microsoft Network Monitor (Netmon) y Wireshark son analizadores de protocolos de red gratuitos que le permiten ver información detallada del paquete de una amplia variedad de protocolos de red. Para obtener más información sobre Wireshark, consulte el Apéndice 2: Uso de Wireshark para capturar el tráfico de red.
- Si quiere realizar una prueba de conectividad básica para comprobar que el equipo cliente puede conectarse al servicio de almacenamiento de Azure a través de la red, no puede hacerlo con la herramienta de ping estándar que hay en el cliente. Sin embargo, puede usar la herramienta tcping para comprobar la conectividad.
En muchos casos, los datos de registro de Almacenamiento y de la biblioteca de cliente de Almacenamiento bastarán para diagnosticar un problema, pero en algunos escenarios, puede que necesite información más detallada de la que pueden proporcionar estas herramientas de registro de red. Por ejemplo, si usa Fiddler para ver los mensajes HTTP y HTTPS, puede ver los datos de encabezados y cargas que se envían a los servicios de almacenamiento y desde ellos. Con esta información, puede examinar la manera en la que una aplicación cliente reintenta las operaciones de almacenamiento. Los analizadores de protocolos, como Wireshark, operan en el nivel de paquetes, por lo que le permiten ver datos de TCP. Con esta información, podría solucionar los problemas de conectividad y pérdida de paquetes.
Seguimiento integral
La traza de un extremo a otro con diversos archivos de registro es una técnica útil para investigar problemas potenciales. 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 para ayudarle 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 contienen varios campos distintos que resultan útiles como identificadores de correlación. El identificador de solicitud de cliente es el campo más útil que puede usar para poner en correlación las entradas de los diferentes registros. Sin embargo, a veces, puede ser útil usar el identificador de solicitud del servidor o las marcas de tiempo. En las siguientes secciones, se proporcionan más detalles de estas opciones.
Id. de solicitud de cliente
La biblioteca de 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 de cliente de storage, el identificador de solicitud de cliente aparece en el
Client Request IDcampo de cada entrada de registro relacionada con la solicitud. - En un seguimiento de red, como uno capturado por Fiddler, el identificador de solicitud de cliente es visible en los mensajes de solicitud como el valor del
x-ms-client-request-idencabezado HTTP. - En el registro del 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 ese valor (aunque la biblioteca de cliente de Almacenamiento asigne un valor nuevo automáticamente). Si el cliente realiza reintentos, 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 identificador de solicitud de cliente único.
Identificador de solicitud de 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 headercolumna . - En un seguimiento de red, como uno capturado por Fiddler, el identificador de solicitud del servidor aparece en los mensajes de respuesta como el valor del
x-ms-request-idencabezado HTTP. - En el registro del lado cliente que crea la biblioteca cliente de almacenamiento, el identificador de solicitud del servidor aparece en la
Operation Textcolumna 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, de modo que cada reintento del cliente y cada operación incluida en un lote tiene un identificador de solicitud de servidor único.
El código del ejemplo siguiente 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();
}
}
Marcas de tiempo
También puede usar marcas de tiempo para buscar entradas de registro relacionadas, pero tenga cuidado con los posibles sesgos del reloj que pueda haber entre el cliente y el servidor. Busque en un intervalo de entre 15 minutos menos y 15 minutos más para encontrar entradas coincidentes del lado servidor a partir 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 resulta útil si tiene muchos blobs de métricas para el mismo minuto u hora.
Guía de solución de problemas
Con esta sección, le resultará más fácil encargarse del diagnóstico y la solución de algunos de los problemas habituales que pueden producirse en la aplicación al usar los servicios de almacenamiento de Azure. Utilice la siguiente lista para buscar la información relacionada con el problema específico.
Solución de problemas del árbol de decisión
¿El problema está relacionado con el rendimiento de uno de los servicios de almacenamiento?
- Las métricas muestran la latencia mediaE2ELatency alta y la baja averageServerLatency.
- Las métricas muestran una baja latencia de AverageE2ELatency y averageServerLatency baja, pero el cliente está experimentando una latencia alta.
- Las métricas muestran una latencia media media alta.
- Experimenta 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 (por ejemplo, 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 de capacidad muestran un aumento inesperado en el uso de la capacidad de almacenamiento.
El problema surge del uso del emulador de almacenamiento para desarrollo o 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 valor de AverageE2ELatency alto y un valor de AverageServerLatency bajo
La siguiente ilustración de la herramienta de supervisión de Azure Portal muestra un ejemplo en el que el valor de AverageE2ELatency es significativamente más alto que el valor de AverageServerLatency.
El servicio de almacenamiento solamente calcula la métrica AverageE2ELatency de las solicitudes que se llevan a cabo correctamente y, a diferencia de AverageServerLatency, incluye el tiempo que tarda el cliente en enviar los datos y recibir la 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 el valor de E2ELatency y ServerLatency de cada operación de almacenamiento individual en los datos de registro del registro de almacenamiento.
Investigación de problemas de rendimiento del cliente
Las posibles razones para que el cliente responda lentamente incluyen tener un número limitado de conexiones o subprocesos disponibles o estar bajos en 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 latencia AverageE2ELatency en comparación con AverageServerLatency. Para obtener más información, consulte El algoritmo de Nagle no es descriptivo para solicitudes pequeñas. Puede deshabilitar el algoritmo de Nagle en el código mediante la ServicePointManager clase en el System.Net espacio de nombres . Debe hacer esto antes de realizar ninguna llamada a Table service o Queue service en la aplicación, dado que esta acción no afecta a las conexiones que ya están abiertas. El ejemplo siguiente procede del Application_Start método en un rol de trabajo.
var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;
Debe comprobar los registros del lado cliente para ver cuántas solicitudes está enviando la aplicación cliente y comprobar si hay . 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 los problemas de las aplicaciones cliente .NET, consulte Debugging, Tracing, and Profiling(Depuración, seguimiento y generación de perfiles).
Investigación de problemas de latencia de red
Normalmente, la latencia de un extremo a otro provocada por la red se debe a estados transitorios. Puede investigar problemas de red transitorios y persistentes, como paquetes descartados, mediante herramientas como Wireshark.
Para obtener más información sobre el uso de Wireshark para solucionar problemas de red, consulte el Apéndice 2: Uso de Wireshark para capturar el tráfico de red.
Las métricas muestran un valor bajo tanto para AverageE2ELatency como para AverageServerLatency, pero el cliente tiene 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 llegan hasta el servicio BLOB.
Un posible motivo de que el cliente envíe las solicitudes con retraso es que haya un número limitado de subprocesos o conexiones disponibles.
Además, compruebe si el cliente está realizando varios reintentos e investigue el motivo si es así. Para determinar si el cliente está realizando varios reintentos, puede:
- Examinar 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.
- Examinar los registros de cliente. Los registros detallados indicarán que se ha producido un reintento.
- Depure el código y compruebe las propiedades del
OperationContextobjeto asociado a la solicitud. Si la operación se ha reintentado, laRequestResultspropiedad incluirá varios identificadores de solicitud de servidor únicos. También puede comprobar los tiempos de inicio y finalización de cada solicitud. Para más información, consulte el ejemplo de código de la sección Identificador de solicitud de servidor.
Si no hay ningún problema en el cliente, debe investigar los problemas de red potenciales, 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 el Apéndice 2: Uso de Wireshark para capturar el tráfico de red.
Las métricas muestran un valor de AverageServerLatency alto
En el caso de que la AverageServerLatency de las solicitudes de descarga de BLOB sea alta, debe usar los registros del registro de Almacenamiento para ver si se repiten varias solicitudes del mismo BLOB (o conjunto de BLOB). 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 para ver los 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 un valor elevado de 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). Con las solicitudes de carga, puede mejorar el rendimiento utilizando un tamaño de bloques mayor. Para realizar consultas a tablas, también se puede implementar el almacenamiento en caché del lado cliente en los clientes que realizan las mismas operaciones de consulta y cuando los datos no suelen cambiar.
Si los valores de AverageServerLatency son altos, esto también puede ser síntoma de un diseño poco adecuado de las tablas o las consultas que genere operaciones de examen o que siga el antipatrón anexar/anteponer. 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í: Lista de comprobación de rendimiento y escalabilidad de Microsoft Azure Storage.
Observa retrasos inesperados en la entrega de mensajes de una cola
Si experimenta un retraso entre el momento en que una aplicación agrega un mensaje a una cola y el tiempo que está disponible para leer desde la cola, siga estos pasos para diagnosticar el problema:
- Compruebe que la aplicación está agregando correctamente los mensajes a la cola. Compruebe que la aplicación no vuelva a intentar el
AddMessagemétodo varias veces antes de que se realice correctamente. Los registros de la biblioteca de cliente de Almacenamiento muestran todos los reintentos repetidos de las operaciones de almacenamiento. - Compruebe que no hay asimetría 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. Una asimetría de reloj hace que aparezca como si hubiera un retraso en el procesamiento.
- Compruebe si el rol de trabajo que lee los mensajes de la cola no está funcionando correctamente. Si un cliente de cola llama al
GetMessagemétodo pero no responde con una confirmación, el mensaje permanecerá invisible en la cola hasta que expire elinvisibilityTimeoutperíodo. En ese momento, el mensaje volverá a estar disponible para el procesamiento. - Compruebe si la longitud de la cola aumenta con el tiempo. Esto puede ocurrir si no tiene suficientes trabajos disponibles para procesar todos los mensajes que otros trabajos 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 puesta en cola en los mensajes, lo que podría indicar intentos erróneos repetidos para eliminar el mensaje.
- Examine los registros del registro de Almacenamiento para ver si hay operaciones de la cola que tengan valores de E2ELatency y ServerLatency superiores a los que se esperaban durante un período de tiempo más largo de lo habitual.
Las métricas muestran un aumento de PercentThrottlingError
Los errores de limitación se producen cuando supera los objetivos de escalabilidad de un servicio de almacenamiento. El servicio de almacenamiento aplica la limitación para asegurarse de que ningún cliente o inquilino pueda usar el servicio a expensas de otros. Para obtener más información, consulte Objetivos de escalabilidad y rendimiento para cuentas de almacenamiento estándar para obtener detalles sobre los objetivos de escalabilidad de las cuentas de almacenamiento y los objetivos de rendimiento de las particiones que hay 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 estos dos escenarios:
Un aumento de PercentThrottlingError a menudo se produce al mismo tiempo que un aumento en el número de solicitudes de almacenamiento o cuando se prueba inicialmente la carga de la aplicación. Esto también puede manifestarse en el cliente como los mensajes de estado HTTP “503 Servidor ocupado” o “500 Se agotó el tiempo de espera de la operación” de las operaciones de almacenamiento.
Aumento transitorio de PercentThrottlingError
Si ve picos en el valor de PercentThrottlingError que coinciden con períodos de actividad alta 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 más información sobre cómo implementar directivas de reintentos mediante la biblioteca cliente de almacenamiento, consulte el tema sobre 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 actividad alta 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 en 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 usa la aplicación las particiones de almacenamiento y si se aproxima 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 observa errores de limitación en una tabla, tiene que plantearse la opción de usar otro esquema de particiones para repartir las transacciones por varias particiones con una variedad más amplia 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: en carga, esto puede dar lugar a un cuello de botella de escritura. Considere la posibilidad de usar otro diseño de particiones o evalúe si usar el almacenamiento de blobs puede ser una solución más adecuada. Además, compruebe si se está produciendo una limitación como resultado de picos en el tráfico e investigue formas de suavizar el patrón de solicitudes.
Si distribuye las transacciones por varias particiones, aun así, debe ser consciente de 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 de mensajes por segundo, estará en el límite total 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 los clientes. Si tiene solicitudes y entidades más grandes, es posible que se limite antes.
Un diseño ineficiente de las 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 un 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 una de las entidades. Cada lectura de una entidad contará de cara al número total de transacciones de esa partición: por este motivo, puede alcanzar fácilmente los objetivos de escalabilidad.
Nota:
Las pruebas de rendimiento deberían revelar todos los diseños de consulta ineficientes de la aplicación.
Las métricas muestran un aumento de PercentTimeoutError
Las métricas muestran un aumento de PercentTimeoutError en uno de los servicios de almacenamiento. Al mismo tiempo, el cliente recibe un gran volumen de mensajes de estado HTTP “500 Se agotó el tiempo de espera de la operación” de las operaciones de almacenamiento.
Nota:
Puede que, temporalmente, vea errores de tiempo de espera, dado que el servicio de almacenamiento equilibra la carga de las solicitudes moviendo particiones a servidores nuevos.
La métrica PercentTimeoutError es una agregación de las siguientes métricas: ClientTimeoutError, AnonymousClientTimeoutError, SASClientTimeoutError, ServerTimeoutError, AnonymousServerTimeoutError y SASServerTimeoutError.
Los errores de tiempo de espera del servidor son errores del servidor. Los tiempos de espera del 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 errores de tiempo de espera del servidor indican que existe un problema con el servicio de almacenamiento que se debe investigar más. Puede utilizar las métricas para ver si está alcanzando los límites de escalabilidad del servicio y para identificar los picos de tráfico que puedan estar provocando este problema. Si el problema es intermitente, puede que se deba a la actividad de equilibrio de carga del servicio. Si el problema es persistente y no se debe a que la aplicación alcance los límites de escalabilidad del servicio, debe informar al soporte técnico de que existe un problema. En el caso de 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, optimizando las consultas de tabla o reduciendo el tamaño de los mensajes.
Las métricas muestran un aumento de PercentNetworkError
Las métricas muestran un aumento de PercentNetworkError en uno de los servicios de almacenamiento. La métrica PercentNetworkError es la suma de las siguientes métricas: NetworkError, AnonymousNetworkError y SASNetworkError. Se producen cuando el servicio de almacenamiento detecta un error de red al realizar una solicitud de almacenamiento el cliente.
El motivo más común de este error es que un cliente se desconecte antes de que expire un tiempo de espera en el servicio de almacenamiento. Investigue el código en el cliente para comprender por qué y cuándo se desconecta el cliente del servicio de almacenamiento. También puede usar Wireshark o Tcping para investigar problemas de conectividad de red desde el cliente. Estas herramientas se describen en los Apéndices.
El cliente recibe mensajes HTTP 403 (prohibido)
Si la aplicación cliente inicia errores HTTP 403 (prohibido), uno de los motivos más probables es que el cliente esté usando una Firma de acceso compartido (SAS) expirada al enviar una solicitud de almacenamiento (aunque hay otras causas posibles, como un sesgo del reloj, que las claves no sean válidas o que los encabezados estén vacíos). Si una clave SAS expirada es la causa, no verá ninguna entrada en los datos del registro de registro de almacenamiento del lado servidor. En la siguiente tabla, puede ver una muestra del registro del lado cliente generado por la biblioteca de cliente de Almacenamiento que ilustra este problema:
| Source | Nivel de detalle | Nivel de detalle | Id. de solicitud de cliente | Texto de operación |
|---|---|---|---|---|
| Microsoft.Azure.Storage | Información | 3 | 85d077ab-… | Starting operation with location Primary per location mode PrimaryOnly. |
| Microsoft.Azure.Storage | Información | 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 | Información | 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 | Información | 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 | Información | 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 | Información | 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 el motivo por el que el token de SAS expira antes de que el cliente envíe el token al servidor:
- Normalmente, no debe establecer una hora de inicio cuando cree una SAS para que un cliente lo use inmediatamente. Si hay pequeñas diferencias de reloj entre el host que genera la SAS mediante 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 aparentemente expire 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 está usando? Recomendamos usar la última versión de la biblioteca de cliente de Almacenamiento. - Si vuelve a generar las claves de acceso de almacenamiento, esto puede invalidar todos los token de SAS existentes. Este problema puede producirse si genera tokens de SAS con un tiempo de expiración duradero para que los copien en caché las aplicaciones cliente.
Si utiliza la biblioteca cliente de Storage para generar tokens de SAS, es fácil generar un token válido. Sin embargo, si usa la API REST de Storage y construye manualmente los tokens de SAS, consulte Delegación del acceso con una firma de acceso compartido.
El cliente recibe mensajes HTTP 404 (no encontrado)
Si la aplicación cliente recibe un mensaje HTTP 404 (No encontrado) del servidor, significa que el objeto que estaba tratando de usar el cliente (por ejemplo, una entidad, una tabla, un blob, un contenedor o una cola) no existe en el servicio de almacenamiento. Hay varios motivos posibles, por ejemplo:
- El cliente u otro proceso eliminaron anteriormente el objeto
- Problema de autorización de firma de acceso compartido (SAS).
- El código de JavaScript del lado cliente no tiene permiso para acceder al objeto.
- Error de red.
El cliente u otro proceso eliminaron anteriormente 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 el lado servidor una operación anterior que eliminó el objeto en cuestión del servicio de almacenamiento. A menudo, los datos de registro indican que otro usuario u otro proceso eliminaron el objeto. En el registro de Storage del lado servidor, las columnas operation-type y requested-object-key muestran el momento en el que un cliente eliminó un objeto.
En el escenario en el que un cliente está intentando insertar un objeto, es posible que no sea evidente inmediatamente por qué se produce una respuesta HTTP 404 (no encontrada), 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 de cliente de Almacenamiento para comprender de forma más detallada cuándo envía el cliente determinadas solicitudes al servicio de almacenamiento.
El siguiente registro del lado cliente generado por la biblioteca cliente de Storage ilustra el problema que aparece cuando el cliente no puede encontrar el contenedor del blob que está creando. Este registro incluye detalles de las siguientes operaciones de almacenamiento:
| Id. de solicitud | Operación |
|---|---|
| 07b26a5d-... | DeleteIfExists método 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 método para crear el blob. Se produce un error en la PUT solicitud con un mensaje 404. |
Entradas del registro:
| Id. de solicitud | Texto de 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 las solicitudes del CreateIfNotExists método (id. de solicitud e2d06d78...) con las solicitudes del UploadFromStream método (de8b1c3c-...). Esta intercalación se produce porque la aplicación cliente invoca estos métodos de forma asincrónica. Modifique el código asincrónico del cliente para que cree el contenedor antes de tratar de cargar datos en un blob de ese contenedor. Lo ideal es que cree todos los contenedores de antemano.
Un problema de autorización de Firma de acceso compartido (SAS)
Si la aplicación cliente trata de usar una clave SAS que no incluye los permisos necesarios para realizar 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 siguiente tabla, puede ver una muestra de un mensaje de registro del lado servidor del archivo de registro del registro de Almacenamiento:
| Nombre | Value |
|---|---|
| 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 |
| 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> |
| Id. de solicitud de cliente | <Id. de solicitud de cliente> |
Investigue por qué la aplicación cliente está intentando 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 utiliza un cliente de JavaScript y el servicio de almacenamiento devuelve mensajes HTTP 404, compruebe si están los siguientes errores de JavaScript en el explorador:
SEC7120: origen http://localhost:56309 no encontrado en el encabezado Access-Control-Allow-Origin.
SCRIPT7002: XMLHttpRequest: error de red 0x80070005, se deniega el acceso.
Nota:
Puede usar las Herramientas de desarrollo F12 de Internet Explorer para realizar un seguimiento de los mensajes que se intercambian 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 restricción de seguridad directiva del mismo origen , que impide que una página web llame a una API de un dominio que no sea el dominio del que proviene 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 accede el cliente. Para más información, consulte Compatibilidad con Uso compartido de recursos entre orígenes (CORS) para los Servicios de Azure Storage.
El siguiente ejemplo de código muestra cómo configurar el servicio BLOB para permitir que el JavaScript que se ejecuta en el dominio Contoso acceda a un BLOB de su servicio de almacenamiento de BLOB:
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);
Error de red
En algunas circunstancias, la pérdida de paquetes de red puede hacer que el servicio de almacenamiento devuelva mensajes HTTP 404 al cliente. Por ejemplo, cuando la aplicación cliente elimina una entidad del servicio table, verá que el cliente produce una excepción de almacenamiento que informa de un mensaje de estado "HTTP 404 (no encontrado)" del servicio table. Al investigar la tabla del servicio de almacenamiento de tabla, ve que el servicio sí que eliminó la entidad, como se solicitó.
Los detalles de excepción del 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 podría utilizar las métricas para identificar cuándo se producen errores como este y, luego, buscar los archivos de registro teniendo en cuenta el momento en el que las métricas registraron este error. Esta entrada de registro muestra que la eliminación no se realizó correctamente y produjo el mensaje de estado “HTTP (404) Otro error del cliente”. 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 justo antes de la solicitud de eliminación que no se realizó correctamente.
La causa más probable de este escenario es que el cliente envió una solicitud de eliminación para la entidad al servicio table, 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 este reintento produjo un error porque la entidad ya se había eliminado.
Si este problema se produce a menudo, debe investigar por qué el cliente no recibe correctamente las confirmaciones del 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 mediante CreateIfNotExists el mismo nombre de contenedor de blobs. Cada operación de cliente da como resultado dos solicitudes enviadas al servidor, primero una GetContainerProperties solicitud para comprobar si el contenedor existe, seguido de la DeleteContainer solicitud o CreateContainer .
| Timestamp | Operación | Resultado | Nombre del contenedor | Id. 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, tablas o colas de blobs, hay un breve período antes de que el nombre vuelva a estar disponible.
La aplicación cliente debe usar nombres de contenedor únicos siempre que cree nuevos contenedores si el patrón eliminar / volver a crear es común.
Las métricas muestran un PercentSuccess bajo o las entradas de registro de análisis tienen operaciones con el estado de transacción ClientOtherErrors
La métrica PercentSuccess captura el porcentaje de operaciones que se realizaron correctamente de acuerdo con 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 intervalos 3XX, 4XX y 5XX se cuentan como incorrectos y reducen el valor de la métrica PercentSuccess . En los archivos de registro de almacenamiento del servidor, estas operaciones se registran con el estado de transacción ClientOtherErrors.
Es importante tener en cuenta que estas operaciones se han completado correctamente y, por lo tanto, no afectan a otras métricas, como la disponibilidad. Algunos ejemplos de operaciones que se ejecutan correctamente, pero que pueden provocar códigos de estado HTTP incorrectos:
- ResourceNotFound (no encontrado 404), por ejemplo, desde una solicitud a un
GETblob que no existe. - ResourceAlreadyExists (Conflicto 409), por ejemplo, desde una
CreateIfNotExistoperación en la que el recurso ya existe. - ConditionNotMet (no modificado 304), por ejemplo, desde una operación condicional, como cuando un cliente envía un
ETagvalor y un encabezado HTTPIf-None-Matchpara 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 devuelven los servicios de almacenamiento en la página Códigos de error comunes de la API REST.
Las métricas de capacidad muestran un aumento inesperado en el uso de la capacidad de almacenamiento
Si observa cambios repentinos e inesperados en el uso de la capacidad de la cuenta de almacenamiento, puede investigar los motivos consultando, primero, las métricas de disponibilidad: por ejemplo, un aumento en el número de solicitudes de eliminación que no se realizaron correctamente puede provocar un aumento en la cantidad de almacenamiento de blobs que está usando. Esto se debe a que, posiblemente, las operaciones de limpieza específicas de aplicaciones, que esperaba que estuvieran liberando espacio, no funcionen como se esperaba (por ejemplo, porque los tokens de SAS que se usan para liberar espacio expiraron).
El problema se presenta al usar el emulador de almacenamiento para realizar tareas de desarrollo o pruebas
Normalmente, se usa el emulador de almacenamiento durante el desarrollo y las pruebas para evitar el requisito de una cuenta de almacenamiento de Azure. Estos son los problemas más habituales que pueden producirse al utilizar el emulador de almacenamiento:
- 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 Storage
El emulador de almacenamiento no admite todas las características de los servicios de almacenamiento de Azure, como el servicio de archivos. Para más información, consulte Uso del emulador de Azure Storage para desarrollo y pruebas.
Para las características que no admita el emulador de almacenamiento, utilice el servicio de almacenamiento de Azure en la nube.
Error "El valor de uno de los encabezados HTTP no está en el formato correcto" al usar el emulador de Storage
Está probando la aplicación que usa la biblioteca cliente de almacenamiento en el emulador de almacenamiento local y llama a métodos como, por CreateIfNotExists ejemplo, un 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 está usando no admite la versión de la biblioteca cliente de almacenamiento que está usando. La biblioteca cliente de almacenamiento 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 de que x-ms-version header envía. 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.
Normalmente, este escenario se produce si instala y usa la última versión de la biblioteca de cliente de Almacenamiento 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 desarrollo y pruebas.
La ejecución del emulador de almacenamiento requiere privilegios administrativos
El sistema le pregunta por las credenciales de administrador al ejecutar el emulador de almacenamiento. Esto solo sucede 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 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, lo que también requiere privilegios administrativos.
Se producen problemas al instalar el SDK de Azure para .NET
Al intentar instalar el SDK, se produce un error al intentar instalar el emulador de almacenamiento en la máquina 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 la base de datos
La causa es un problema con la instalación de LocalDB existente. De forma predeterminada, el emulador de almacenamiento utiliza LocalDB para hacer que los datos sean persistentes al simular 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 tratar de 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 las instalaciones anteriores del emulador de almacenamiento.
Tiene otro problema distinto relacionado con un servicio de almacenamiento
Si las secciones de solución de problemas anteriores no contienen el problema que tiene con un servicio de almacenamiento, debe adoptar el siguiente método para diagnosticar y solucionar el problema.
- Compruebe las métricas para ver si hay algún cambio en el comportamiento previsto de la línea de base. A partir de las métricas, puede determinar si el problema es transitorio o permanente y qué operaciones de almacenamiento afecta el problema.
- Puede utilizar la información de las métricas para buscar en los datos de registro del lado servidor información más detallada sobre los errores que se producen. Con esta información, puede que le resulte más fácil solucionar el problema.
- 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 el 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 el Apéndice 2: Uso de Wireshark para capturar el tráfico de red.
Apéndices
En los anexos, se describen varias herramientas que pueden resultarle útiles al diagnosticar y solucionar problemas relacionados 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 descritas 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 en 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 está utilizando.
Nota:
Fiddler puede descodificar el tráfico HTTPS. Debe leer detenidamente la documentación de Fiddler para comprender cómo lo hace y sus implicaciones de seguridad.
Este apéndice proporciona un breve tutorial que explica cómo configurar Fiddler para capturar el tráfico entre la máquina local donde tiene instalado Fiddler y los servicios de almacenamiento de Azure.
Una vez iniciado Fiddler, empezará a capturar el tráfico HTTP y HTTPS de la máquina local. Estos son algunos comandos útiles para controlar Fiddler:
- Dejar de capturar tráfico y empezar a capturarlo. En el menú principal, vaya a Archivo y seleccione Capturar tráfico para activar y desactivar la captura.
- Guardar 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 filtros que configure en la pestaña Filtros . En la captura de pantalla siguiente se muestra un filtro que captura solo el contosoemaildist.table.core.windows.net tráfico enviado al punto de conexión de almacenamiento:
Apéndice 2: Uso de Wireshark para capturar tráfico de red
Wireshark es un analizador de protocolos de red que le permite ver información detallada sobre los paquetes de una gran variedad de protocolos de red.
En el siguiente procedimiento, se muestra cómo capturar información detallada sobre los paquetes del tráfico de la máquina local donde instaló Wireshark al servicio Tabla de la cuenta de almacenamiento de Azure.
Inicie Wireshark en la máquina local.
En la sección Start (Inicio), seleccione la interfaz o las interfaces de red locales que están conectadas a Internet.
Seleccione Opciones de captura.
Agregue un filtro al cuadro de texto Capture Filter (Filtro de captura). Por ejemplo,
host contosoemaildist.table.core.windows.netconfigurará Wireshark para capturar solo los paquetes enviados a o desde el punto de conexión de Table Service en la cuenta de almacenamiento contosoemaildist . Consulte la lista completa de filtros de captura.
Seleccione Inicio. Wireshark ahora capturará todos los paquetes enviados a o desde el punto de conexión de Table Service a medida que use la aplicación cliente en el equipo local.
Cuando haya terminado, seleccione Capture Stop (Detener de captura>) 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á todos los errores que haya en la ventana packetlist (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.
Aparte de esto, puede optar por ver los datos de TCP como los ve el nivel de aplicación: para ello, haga clic con el botón derecho en los datos de TCP y elija Follow TCP Stream(Seguir secuencia TCP). Resulta útil si capturó el volcado sin un filtro de captura. Para más información, consulte Following TCP Streams(Siguientes secuencias TCP).
Nota:
Para más información sobre el uso de Wireshark, consulte la Guía del usuario de Wireshark.
Apéndice 4: Uso de Excel para ver métricas y datos de registro
Hay muchas herramientas que le permiten descargar los datos de métricas de Azure Table Storage en un formato delimitado con el que es fácil cargar los datos en Excel para verlos y analizarlos. El almacenamiento de los datos de registro de Azure Blob Storage ya está 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 en Formato de registro de Storage Analytics y Esquema de tabla de métricas de Storage Analytics.
Para importar los datos del registro de Storage en Excel después de descargarlos del almacenamiento de blobs:
- 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 comillas dobles como calificador de texto. A continuación, seleccione Finalizar y elija dónde colocar los datos en el libro.
Apéndice 5: Supervisión mediante Application Insights para Azure DevOps
Asimismo, también puede usar la característica Application Insights para Azure DevOps como parte de la supervisión del rendimiento y la disponibilidad. Esta herramienta puede:
- Comprobar que el servicio web está disponible y responde adecuadamente. 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.
- Diagnosticar rápidamente los problemas de rendimiento o las excepciones del servicio web. Averigüe si la CPU u otros recursos se están ampliando, observe el seguimiento de la pila de las excepciones y busque fácilmente en los seguimientos de registros. Si el rendimiento de la aplicación desciende por debajo de los límites aceptables, Microsoft puede enviarle un correo electrónico. Puede supervisar servicios web de .NET y de Java.
Puede encontrar más información en ¿Qué es Application Insights?
Pasos siguientes
Para más información acerca de los análisis en Azure Storage, consulte estos recursos:
- Supervisión de una cuenta de almacenamiento en Azure Portal
- Storage Analytics
- Métricas de Storage Analytics
- Esquema de las tablas de métricas de Storage Analytics
- Registros de Storage Analytics
- Formato del registro de Storage Analytics
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.