Compartir a través de


Solución de problemas de disponibilidad en cuentas de Almacenamiento de Azure

Este artículo le ayuda a investigar los cambios en la disponibilidad (como el número de solicitudes con errores). Estos cambios en la disponibilidad a menudo se pueden identificar mediante la supervisión de métricas de almacenamiento en Azure Monitor. Para obtener información general sobre el uso de métricas y registros en Azure Monitor, consulte los artículos siguientes:

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 métrica de disponibilidad . La métrica disponibilidad contiene un valor de porcentaje. Se calcula tomando el valor total de las solicitudes facturables y dividiéndolo por el número de solicitudes aplicables, incluidas las solicitudes que generaron errores inesperados.

Cualquier valor inferior al 100 % indica que se producen errores en algunas solicitudes de almacenamiento. Para ver por qué se produce un error, examine la dimensión ResponseType para ver los tipos de error, como ServerTimeoutError. Debería esperar que la disponibilidad esté temporalmente por debajo del 100 % por motivos como tiempos de espera transitorios del servidor mientras el servicio mueve particiones a solicitudes de equilibrio de carga mejores; la lógica de reintento de la aplicación cliente debe controlar estas condiciones intermitentes.

Puede usar las características de Azure Monitor para alertarle si la disponibilidad de un servicio está por debajo de un umbral que especifique.

Las métricas muestran un aumento de los errores de limitación

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 el valor ClientThrottlingError o ServerBusyError de la dimensión ResponseType 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

A menudo se produce un aumento en los errores de limitación al mismo tiempo que un aumento en el número de solicitudes de almacenamiento o cuando se está probando inicialmente 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 los errores de limitación

Si ve picos de errores de limitación que coinciden con períodos de alta actividad para la aplicación, implemente 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 cliente de Storage, vea la propiedad RetryOptions.MaxRetries .

Nota:

También puede ver picos en errores de limitación 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 los errores de limitación

Si ve un valor alto de forma coherente para los errores de limitación después de un aumento permanente de 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, considere 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 debido a 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ó 10 colas, cada una procesando el máximo de 2000 mensajes de 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 afecta 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 de los errores de tiempo de espera

Los errores de tiempo de espera se producen cuando la dimensión ResponseType es igual a ServerTimeoutError o ClientTimeout.

Las métricas muestran un aumento de los errores de tiempo de espera de 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.

Los tiempos de espera del servidor (ServerTimeOutError) se deben a un error en el servidor. Los tiempos de espera de cliente (ClientTimeout) 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.

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 de los errores de red

Los errores de red se producen cuando la dimensión ResponseType es igual a NetworkError. Se producen cuando un 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 herramientas de análisis de red de terceros para investigar problemas de conectividad de red del cliente.

Vea también

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.