Análisis del modo de error para aplicaciones de Azure

  • Artículo

El análisis del modo de error (FMA) es un proceso de creación de resistencia en un sistema mediante la identificación de posibles puntos de error en el sistema. El FMA debe formar parte de las fases de diseño y arquitectura, de modo que pueda generar una recuperación de errores en el sistema desde el principio.

Este es el proceso general para realizar un FMA:

  1. Identifique todos los componentes del sistema. Incluya dependencias externas, como proveedores de identidades, servicios de terceros, etc.

  2. Para cada componente, identifique los posibles errores que se puedan producir. Un único componente puede tener más de un modo de error. Por ejemplo, debería considerar los errores de lectura y escritura por separado, ya que el impacto y los posibles pasos de mitigación serán diferentes.

  3. Clasifique por orden de prioridad cada modo de error según su riesgo general. Tenga en cuenta estos factores:

    • Cuál es la probabilidad de que se produzca el error. ¿Es relativamente frecuente? ¿Extremadamente poco común? No necesita números exactos, ya que la finalidad es realizar una clasificación por orden de prioridad.
    • ¿Cuál es el impacto en la aplicación, en términos de disponibilidad, pérdida de datos, costo económico e interrupción de la actividad comercial?

  4. Para cada modo de error, determine cómo responderá y se recuperará la aplicación. Tenga en cuenta los inconvenientes en lo relativo al costo y a la complejidad de la aplicación.

Como punto de partida para el proceso FMA, este artículo contiene un catálogo de los posibles modos de error y los pasos de mitigación. El catálogo está organizado por tecnología o servicio de Azure, además de una categoría general para el diseño en el nivel de aplicación. El catálogo no es exhaustivo pero abarca muchos de los principales servicios de Azure.

App Service

La aplicación de App Service se cierra.

Detección. Causas posibles:

  • Cierre esperado

    • Un operador cierra la aplicación; por ejemplo, mediante Azure Portal.
    • La aplicación se ha descargado porque estaba inactiva. (Solo si el valor Always On está deshabilitado).

  • Cierre inesperado

    • La aplicación se bloquea.
    • Una instancia de la máquina virtual de App Service deja de estar disponible.

El registro Application_End detectará el cierre del dominio de aplicación (bloqueo del proceso de software) que es la única manera de detectar los cierres del dominio de aplicación.

Recuperación:

  • Si se trata de un cierre esperado, utilice el evento de cierre de la aplicación para cerrarla correctamente. Por ejemplo, en ASP.NET, utilice el método Application_End.
  • Si la aplicación se ha descargado mientras estaba inactiva, se reiniciará automáticamente en la siguiente solicitud. No obstante, incurrirá en el costo de "arranque en frío".
  • Para evitar que la aplicación se descargue mientras está inactiva, habilite el valor Always On en la aplicación web. Consulte Configuración de aplicaciones web en Azure App Service.
  • Para evitar que un operador cierre la aplicación, establezca un bloqueo de recurso con el nivel ReadOnly. Consulte Bloqueo de recursos con Azure Resource Manager.
  • Si la aplicación se bloquea o una máquina virtual de App Service deja de estar disponible, App Service reinicia automáticamente la aplicación.

Diagnóstico. Registros de aplicaciones y registros de servidor web. Consulte Habilitación del registro de diagnóstico para aplicaciones web en Azure App Service.

Un usuario determinado realiza repetidamente solicitudes incorrectas o sobrecarga el sistema.

Detección. Autentique los usuarios e incluya los identificadores de usuario en los registros de aplicaciones.

Recuperación:

Diagnóstico. Registre todas las solicitudes de autenticación.

Se implementó una actualización incorrecta.

Detección. Supervise el mantenimiento de la aplicación mediante Azure Portal (consulte Supervisión del rendimiento de la aplicación web de Azure) o bien implemente el patrón de supervisión de puntos de conexión de mantenimiento.

Recuperación: Use varias ranuras de implementación y revierta a la última implementación correcta conocida. Para más información, consulte Basic web application (Aplicación web básica).

Microsoft Entra ID

Errores de autenticación de OpenID Connect.

Detección. Los posibles modos de error son:

  1. Microsoft Entra ID no está disponible o no se puede acceder a él debido a un problema de red. Se produce un error en el redireccionamiento al punto de conexión de autenticación y el middleware de OpenID Connect genera una excepción.
  2. El inquilino de Microsoft Entra no existe. El redireccionamiento al punto de conexión de autenticación devuelve un código de error HTTP y el middleware de OpenID Connect genera una excepción.
  3. El usuario no se puede autenticar. No es necesaria ninguna estrategia de detección; Microsoft Entra ID controla los errores de inicio de sesión.

Recuperación:

  1. Detecte las excepciones no controladas en el middleware.
  2. Controle eventos AuthenticationFailed.
  3. Redireccione al usuario a una página de error.
  4. El usuario lo reintenta.

Se produce un error al escribir datos en Azure Search.

Detección. Detecte errores Microsoft.Rest.Azure.CloudException.

Recuperación:

El SDK de .NET de Search realiza reintentos automáticamente después de los errores transitorios. Las excepciones producidas por el cliente SDK deben tratarse como errores no transitorios.

La directiva de reintentos predeterminada usa la interrupción exponencial. Para utilizar una directiva de reintentos diferente, llame a SetRetryPolicy en la clase SearchIndexClient o SearchServiceClient. Para más información, consulte el artículo sobre reintentos automáticos.

Diagnóstico. Use el análisis del tráfico de búsqueda.

Se produce un error al leer datos de Azure Search.

Detección. Detecte errores Microsoft.Rest.Azure.CloudException.

Recuperación:

El SDK de .NET de Search realiza reintentos automáticamente después de los errores transitorios. Las excepciones producidas por el cliente SDK deben tratarse como errores no transitorios.

La directiva de reintentos predeterminada usa la interrupción exponencial. Para utilizar una directiva de reintentos diferente, llame a SetRetryPolicy en la clase SearchIndexClient o SearchServiceClient. Para más información, consulte el artículo sobre reintentos automáticos.

Diagnóstico. Use el Análisis del tráfico de búsqueda.

Cassandra

Se produce un error al leer o escribir en un nodo.

Detección. Detecte la excepción. Para clientes. NET, suele ser System.Web.HttpException. Otros clientes pueden tener otros tipos de excepción. Para más información, consulte Cassandra error handling done right (Correcto control de errores en Cassandra).

Recuperación:

  • Cada cliente de Cassandra tiene sus propias directivas y funcionalidades de reintento. Para más información, consulte Cassandra error handling done right (Correcto control de errores en Cassandra).
  • Use una implementación en modo compatible con bastidor, con nodos de datos distribuidos a través de los dominios de error.
  • Implemente en varias regiones con coherencia de cuórum local. Si se produce un error no transitorio, conmute por error a otra región.

Diagnóstico. Registros de aplicación

Servicio en la nube

Los roles web o de trabajo se cierran inesperadamente.

Detección. Se desencadena el evento RoleEnvironment.Stopping.

Recuperación. Invalide el método RoleEntryPoint.OnStop para limpiar correctamente. Para más información, consulte la entrada Modo correcto de controlar eventos OnStop de Azure (blog).

Azure Cosmos DB

Se produce un error en la lectura de datos.

Detección. Detecte System.Net.Http.HttpRequestException o Microsoft.Azure.Documents.DocumentClientException.

Recuperación:

  • El SDK vuelve a ejecutar automáticamente los intentos erróneos. Para establecer el número de reintentos y el tiempo de espera máximo, configure ConnectionPolicy.RetryOptions. Las excepciones que genera el cliente se encuentran más allá de la directiva de reintentos o no son errores transitorios.
  • Si Azure Cosmos DB limita el cliente, devuelve un error HTTP 429. Compruebe el código de estado en DocumentClientException. Si recibe el error 429 constantemente, considere la posibilidad de aumentar el valor de rendimiento de la colección.
    • Si está utilizando la API de MongoDB, el servicio devuelve el código de error 16500 durante la limitación.
  • Habilite la redundancia de zona cuando trabaje con una región que admita zonas de disponibilidad. Cuando se usa la redundancia de zona, Azure Cosmos DB conmutará por error automáticamente en caso de una interrupción de zona. Para obtener más información, consulte Lograr una alta disponibilidad con Azure Cosmos DB.
  • Si va a diseñar una solución de varias regiones, replique la base de datos de Azure Cosmos DB en dos o más regiones. Todas las réplicas son legibles. Con los SDK de cliente, especifique el parámetro PreferredLocations. Se trata de una lista ordenada de las regiones de Azure. Todas las lecturas se enviarán a la primera región disponible en la lista. Si se produce un error en la solicitud, el cliente intentará las demás regiones en la lista, en orden. Para obtener más información, consulte Configuración de la distribución global de Azure Cosmos DB for NoSQL.

Diagnóstico. Registre todos los errores en el lado cliente.

Se produce un error en la escritura de datos.

Detección. Detecte System.Net.Http.HttpRequestException o Microsoft.Azure.Documents.DocumentClientException.

Recuperación:

  • El SDK vuelve a ejecutar automáticamente los intentos erróneos. Para establecer el número de reintentos y el tiempo de espera máximo, configure ConnectionPolicy.RetryOptions. Las excepciones que genera el cliente se encuentran más allá de la directiva de reintentos o no son errores transitorios.
  • Si Azure Cosmos DB limita el cliente, devuelve un error HTTP 429. Compruebe el código de estado en DocumentClientException. Si recibe el error 429 constantemente, considere la posibilidad de aumentar el valor de rendimiento de la colección.
  • Habilite la redundancia de zona cuando trabaje con una región que admita zonas de disponibilidad. Cuando se usa redundancia de zona, Azure Cosmos DB replica de forma sincrónica todas las escrituras entre zonas de disponibilidad. Para obtener más información, consulte Lograr una alta disponibilidad con Azure Cosmos DB.
  • Si va a diseñar una solución de varias regiones, replique la base de datos de Azure Cosmos DB en dos o más regiones. Si se produce un error en la región primaria, se promoverá otra región para la escritura. También puede desencadenar una conmutación por error manualmente. El SDK realiza la detección y el enrutamiento automáticos, por lo que el código de la aplicación continúa funcionando después de una conmutación por error. Durante el período de conmutación por error (normalmente minutos), las operaciones de escritura tendrán una latencia superior, según va encontrando el SDK la nueva región de escritura. Para obtener más información, consulte Configuración de la distribución global de Azure Cosmos DB for NoSQL.
  • Como acción de reserva, conserve el documento en una cola de copia de seguridad y procese la cola más adelante.

Diagnóstico. Registre todos los errores en el lado cliente.

Queue Storage

Se produce un error al escribir un mensaje en Azure Queue Storage constantemente.

Detección. Después de N reintentos, todavía se produce un error en la operación de escritura.

Recuperación:

  • Almacene los datos en una memoria caché local y reenvíe las escrituras al almacenamiento más adelante, cuando el servicio esté disponible.
  • Cree una cola secundaria y escriba en esa cola si la cola principal no está disponible.

Diagnóstico. Use las métricas de almacenamiento.

La aplicación no puede procesar un mensaje concreto de la cola.

Detección. Específica de la aplicación. Por ejemplo, el mensaje contiene datos no válidos o se produce un error en la lógica de negocios por algún motivo.

Recuperación:

Mueva el mensaje a una cola independiente. Ejecute un proceso independiente para examinar los mensajes de dicha cola.

Considere la posibilidad de usar colas de mensajería de Azure Service Bus, lo que proporciona una funcionalidad de cola de mensajes fallidos con este fin.

Nota

Si usa colas de Storage con WebJobs, el SDK de WebJobs proporciona control de mensajes dudosos integrado. Consulte Uso del almacenamiento de colas de Azure con el SDK de WebJobs.

Diagnóstico. Utilice el registro de aplicaciones.

Azure Cache for Redis

Se produce un error de lectura en la memoria caché.

Detección. Detecte StackExchange.Redis.RedisConnectionException.

Recuperación:

  1. Reinténtelo con los errores transitorios. Azure Cache for Redis admite el reintento integrado. Para más información, consulte Directrices de reintento de Azure Cache for Redis.
  2. Trate los errores no transitorios como un error de caché y recurra al origen de datos original.

Diagnóstico. Use el diagnóstico de Azure Cache for Redis.

Se produce un error de escritura en la memoria caché.

Detección. Detecte StackExchange.Redis.RedisConnectionException.

Recuperación:

  1. Reinténtelo con los errores transitorios. Azure Cache for Redis admite el reintento integrado. Para más información, consulte Directrices de reintento de Azure Cache for Redis.
  2. Si el error no es transitorio, podrá omitirlo y permitir que otras transacciones escriban en la memoria caché más adelante.

Diagnóstico. Use el diagnóstico de Azure Cache for Redis.

SQL Database

No se puede conectar a la base de datos en la región primaria.

Detección. Se produce un error de conexión.

Recuperación:

  • Habilitación de la redundancia de zona. Al habilitar la redundancia de zona, Azure SQL Database replicará automáticamente las escrituras en varias zonas de disponibilidad de Azure dentro de las regiones admitidas. Para obtener más información, consulte Disponibilidad con redundancia de zona.

  • Habilite la replicación geográfica. Si va a diseñar una solución de varias regiones, considere la posibilidad de habilitar la replicación geográfica activa de SQL Database.

    Requisito previo: la base de datos debe configurarse para una replicación geográfica activa. Consulte Replicación geográfica activa para SQL Database.

    La réplica usa una cadena de conexión diferente, por lo que deberá actualizar la cadena de conexión en la aplicación.

El cliente se ha quedado sin conexiones en el grupo de conexiones.

Detección. Detecte errores System.InvalidOperationException.

Recuperación:

  • Vuelva a intentar la operación.
  • Como plan de mitigación, aísle los grupos de conexiones para cada caso de uso, a fin de que un solo caso de uso no pueda dominar todas las conexiones.
  • Aumente el número máximo de conexiones.

Diagnóstico. Registros de aplicaciones.

Se alcanzó el límite de conexiones de base de datos.

Detección. Azure SQL Database limita el número de trabajos, inicios de sesión y sesiones simultáneos. Los límites dependen del nivel de servicio. Para más información, consulte Límites de recursos de Azure SQL Database.

Para detectar estos errores, detecte System.Data.SqlClient.SqlException y compruebe el valor de SqlException.Number para el código de error SQL. Para obtener una lista de los códigos de error pertinentes, consulte Códigos de error de SQL para aplicaciones cliente de SQL Database: Errores de conexión de base de datos y otros problemas.

Recuperación. Estos errores se consideran transitorios por lo que al reintentarlo, es posible que se resuelva el problema. Si se producen constantemente estos errores, considere la posibilidad de escalar la base de datos.

Diagnóstico. - La consulta sys.event_log devuelve las conexiones realizadas correctamente, los errores de conexión y los interbloqueos.

Mensajería de Service Bus

Se produce un error al leer un mensaje de una cola de Service Bus.

Detección. Detecte excepciones desde el cliente SDK. La clase base para las excepciones de Service Bus es MessagingException. Si el error es transitorio, la propiedad IsTransient es true.

Para más información, consulte Excepciones de mensajería de Service Bus.

Recuperación:

  1. Reinténtelo con los errores transitorios. Consulte las Directrices de reintento de Service Bus.
  2. Los mensajes que no se pueden entregar a cualquier receptor se colocan en una cola de mensajes fallidos. Use esta cola para ver qué mensajes no se pudieron recibir. No hay limpieza automática de la cola de mensajes fallidos. Los mensajes permanecen allí hasta que los recupere explícitamente. Consulte la Información general de colas de mensajes fallidos de Service Bus.

Se produce un error al escribir un mensaje en una cola de Service Bus.

Detección. Detecte excepciones desde el cliente SDK. La clase base para las excepciones de Service Bus es MessagingException. Si el error es transitorio, la propiedad IsTransient es true.

Para más información, consulte Excepciones de mensajería de Service Bus.

Recuperación:

  • El cliente de Service Bus realiza reintentos automáticamente tras los errores transitorios. De forma predeterminada, usa la interrupción exponencial. Tras el período de tiempo de expiración máximo o el número máximo de reintentos, el cliente genera una excepción. Para más información, consulte las Directrices de reintento de Service Bus.

  • Si se supera la cuota de la cola, el cliente devuelve una QuotaExceededException. El mensaje de excepción proporciona más detalles. Purgue algunos mensajes de la cola antes de reintentarlo y considere la posibilidad de usar el patrón Circuit Breaker para evitar reintentos continuos mientras se supera la cuota. Además, asegúrese de que la propiedad BrokeredMessage.TimeToLive no esté establecida demasiado alta.

  • Dentro de una región, se puede mejorar la resistencia mediante temas o colas con particiones. Se asigna una cola o un tema sin particiones a un almacén de mensajería. Si este almacén de mensajería no está disponible, se producirá un error en todas las operaciones de esa cola o tema. Una cola o tema con particiones está particionado entre varios almacenes de mensajería.

  • Use la redundancia de zona para replicar automáticamente los cambios entre varias zonas de disponibilidad. Si se produce un error en una zona de disponibilidad, la conmutación por error se producirá automáticamente. Para más información, consulte Procedimientos recomendados para aislar aplicaciones ante desastres e interrupciones de Service Bus.

  • Si va a diseñar una solución de varias regiones, cree dos espacios de nombres de Service Bus en regiones diferentes y replique los mensajes. Puede usar una replicación activa o pasiva.

    • Replicación activa: el cliente envía todos los mensajes a ambas colas. El receptor escucha en ambas colas. Etiquete los mensajes con un identificador único, para que el cliente pueda descartar los mensajes duplicados.
    • Replicación pasiva: el cliente envía el mensaje a una cola. Si se produce un error, el cliente recurre a la otra cola. El receptor escucha en ambas colas. Este enfoque reduce el número de mensajes duplicados que se envían. Sin embargo, el receptor todavía debe controlar los mensajes duplicados.

    Para más información, consulte el ejemplo de GeoReplication y los Procedimientos recomendados para aislar aplicaciones ante desastres e interrupciones de Service Bus.

Mensaje duplicado.

Detección. Examine las propiedades MessageId y DeliveryCount del mensaje.

Recuperación:

  • Si es posible, diseñe las operaciones de procesamiento de mensajes para que sean idempotentes. En caso contrario, almacene identificadores de mensaje de los mensajes que ya se han procesado y compruebe el identificador antes de procesar un mensaje.

  • Habilite la detección de duplicados, mediante la creación de la cola con RequiresDuplicateDetection establecido en true. Con este valor, Service Bus elimina automáticamente cualquier mensaje que se envíe con el mismo MessageId que un mensaje anterior. Tenga en cuenta lo siguiente:

    • Este valor impide que se pongan en la cola mensajes duplicados. No impide que un receptor procese el mismo mensaje más de una vez.
    • La detección de duplicados tiene un período de tiempo. Si se envía un duplicado más allá de este período, no se detectará.

Diagnóstico. Registre mensajes duplicados.

La aplicación no puede procesar un mensaje concreto de la cola.

Detección. Específica de la aplicación. Por ejemplo, el mensaje contiene datos no válidos o se produce un error en la lógica de negocios por algún motivo.

Recuperación:

Hay dos modos de error que se deben tener en cuenta.

  • El receptor detecta el error. En este caso, mueva el mensaje a la cola de mensajes fallidos. Posteriormente, ejecute un proceso independiente para examinar los mensajes de la cola de mensajes fallidos.
  • Se produce un error en el receptor en medio del procesamiento del mensaje; por ejemplo, debido a una excepción no controlada. Para controlar este caso, utilice el modo PeekLock. En este modo, si expira el bloqueo, el mensaje pasa a estar disponible para otros receptores. Si el mensaje supera el número máximo de entregas o el período de vida, el mensaje se mueve automáticamente a la cola de mensajes fallidos.

Para más información, consulte Introducción a las colas de mensajes fallidos de Service Bus.

Diagnóstico. Siempre que la aplicación mueva un mensaje a la cola de mensajes fallidos, escribe un evento en los registros de aplicaciones.

Storage

Se produce un error al escribir datos en Azure Storage.

Detección. El cliente recibe mensajes de error al escribir.

Recuperación:

  1. Reintente la operación para recuperarse de errores transitorios. La directiva de reintentos en el SDK de cliente trata esto automáticamente.

  2. Implemente el patrón Circuit Breaker para evitar sobrecargar el almacenamiento.

  3. Si se produce un error en N reintentos, realice una acción de reserva correcta. Por ejemplo:

    • Almacene los datos en una memoria caché local y reenvíe las escrituras al almacenamiento más adelante, cuando el servicio esté disponible.
    • Si la acción de escritura se encontraba en un ámbito transaccional, compense la transacción.

Diagnóstico. Use las métricas de almacenamiento.

Se produce un error al leer datos de Azure Storage.

Detección. El cliente recibe mensajes de error al leer.

Recuperación:

  1. Reintente la operación para recuperarse de errores transitorios. La directiva de reintentos en el SDK de cliente trata esto automáticamente.
  2. Para el almacenamiento de RA-GRS, si se produce un error en la lectura desde el punto de conexión principal, intente leer desde el punto de conexión secundario. El SDK de cliente trata esto automáticamente. Consulte el artículo sobre replicación de Azure Storage.
  3. Si se produce un error en N reintentos, realice una acción de reserva para ejecutar una degradación correcta. Por ejemplo, si una imagen de producto no se puede recuperar desde el almacenamiento, muestre una imagen de marcador de posición genérica.

Diagnóstico. Use las métricas de almacenamiento.

Máquina virtual

Se produce un error en la conexión a una máquina virtual de back-end.

Detección. Errores de conexión de red.

Recuperación:

  • Implemente al menos dos máquinas virtuales de back-end en un conjunto de disponibilidad, detrás de un equilibrador de carga.
  • Si el error de conexión es transitorio, a veces TCP reintentará enviar correctamente el mensaje.
  • Implemente una directiva de reintentos en la aplicación.
  • En el caso de los errores persistentes o no transitorios, implemente el patrón Circuit Breaker.
  • Si la máquina virtual que realiza la llamada supera el límite de salida de la red, se llenará la cola de salida. Si la cola de salida está constantemente llena, considere la posibilidad de un escalado horizontal.

Diagnóstico. Registre eventos en los límites del servicio.

Una instancia de la máquina virtual de App Service ha dejado de estar disponible o no tiene mantenimiento.

Detección. Configure un sondeo de mantenimiento de una instancia de Load Balancer que indique si la instancia de la máquina virtual tiene un estado correcto. El sondeo debe comprobar si las funciones críticas están respondiendo correctamente.

Recuperación. Para cada capa de aplicación, colocar varias instancias de máquina virtual en el mismo conjunto de disponibilidad y colocar un equilibrador de carga delante de las máquinas virtuales. Cuando un sondeo de mantenimiento no responde, la instancia de Load Balancer deja de enviar nuevas conexiones a la instancia sin mantenimiento.

Diagnóstico. - Use el análisis de registros de Load Balancer.

  • Configure el sistema de supervisión para controlar todos los puntos de conexión de supervisión de mantenimiento.

Un operador cierra accidentalmente una máquina virtual.

Detección. N/D

Recuperación. Establezca un bloqueo de recurso con el nivel ReadOnly. Consulte Bloqueo de recursos con Azure Resource Manager.

Diagnóstico. Use los Registros de actividad de Azure.

Trabajos web

El trabajo continuo deja de ejecutarse cuando el host SCM está inactivo.

Detección. Pase un token de cancelación a la función de WebJob. Para más información, consulte el cierre correcto.

Recuperación. Habilite el valor Always On en la aplicación web. Para obtener más información, consulte Ejecución de tareas en segundo plano con WebJobs.

Diseño de aplicación

La aplicación no puede controlar un pico en las solicitudes entrantes.

Detección. Depende de la aplicación. Síntomas típicos:

  • El sitio web comienza a devolver códigos de error HTTP 5xx.
  • Los servicios dependientes, como base de datos o almacenamiento, comienzan a limitar las solicitudes. Busque errores HTTP, como HTTP 429 (demasiadas solicitudes), en función del servicio.
  • La longitud de la cola HTTP aumenta.

Recuperación:

  • Escale horizontalmente para controlar el aumento de la carga.

  • Mitigue los errores para evitar que unos errores en cascada interrumpan toda la aplicación. Entre las estrategias de mitigación se incluyen:

    • Implemente el patrón Throttling para evitar sobrecargar los sistemas de back-end.
    • Use Queue-Based Load Leveling para almacenar en búfer las solicitudes y procesarlas a un ritmo adecuado.
    • Dé prioridad a determinados clientes. Por ejemplo, si la aplicación tiene planes de tarifa gratuitos y de pago, limite los clientes del plan de tarifa gratuito, pero no los de pago. Consulte el patrón de cola de prioridad.

Diagnóstico. Use el registro de diagnóstico de App Service. Use un servicio como Azure Log Analytics, Application Insights o New Relic para que le ayuden a comprender los registros de diagnóstico.

Hay un ejemplo disponible aquí. Usa Polly para estas excepciones:

  • 429: limitaciones
  • 408: tiempo de expiración
  • 401: no autorizado
  • 503 o 5xx: servicio no disponible

Se produce un error en una de las operaciones en un flujo de trabajo o una transacción distribuida.

Detección. Después de N reintentos, sigue produciendo un error.

Recuperación:

  • Como plan de mitigación, implemente el patrón Scheduler Agent Supervisor para administrar todo el flujo de trabajo.
  • No lo intente de nuevo en los tiempos de expiración. Hay una tasa de éxito baja para este error.
  • Ponga el trabajo en la cola para volver a intentarlo más tarde.

Diagnóstico. Inicie sesión en todas las operaciones (correctas y erróneas), incluidas las acciones de compensación. Utilice los identificadores de correlación para que pueda realizar un seguimiento de todas las operaciones dentro de la misma transacción.

Se produce un error en una llamada a un servicio remoto.

Detección. Código de error HTTP.

Recuperación:

  1. Reinténtelo con los errores transitorios.
  2. Si se produce un error en la llamada después de N reintentos, realice una acción de reserva. (Específica de la aplicación).
  3. Implemente el patrón Circuit Breaker para evitar errores en cascada.

Diagnóstico. Registre todos los errores de llamadas remotas.

Pasos siguientes

Consulte Resistencia y dependencias en Azure Well-Architected Framework. Programar la recuperación de errores en el sistema debe formar parte de las fases de arquitectura y diseño desde el principio para evitar el riesgo de que se produzcan errores.