Share via

Resistencia de detección de servicios (versión preliminar)

  • Artículo

Con la resistencia de Azure Container Apps, puede evitar, detectar y recuperar de forma proactiva errores de solicitud de servicio mediante directivas de resistencia sencillas. En este artículo, obtendrá información sobre cómo configurar directivas de resistencia de Azure Container Apps al iniciar solicitudes mediante la detección del servicio de Azure Container Apps.

Nota:

Actualmente, las directivas de resistencia no se pueden aplicar a las solicitudes realizadas mediante la API de invocación del servicio de Dapr.

Las directivas están en vigor para cada solicitud a una aplicación de contenedor. Puede adaptar las directivas a la aplicación de contenedor que acepta solicitudes con configuraciones como:

  • Número de reintentos
  • Tiempo de espera y reintento
  • Coincidencias de reintento
  • Errores consecutivos del disyuntor y otros

En la captura de pantalla siguiente se muestra cómo una aplicación usa una directiva de reintento para intentar recuperarse de solicitudes con error.

Diagram demonstrating container app to container app resiliency using a container app's service name.

Directivas de resistencia admitidas

Configuración de directivas de resistencia

Tanto si configura directivas de resistencia mediante Bicep, la CLI o Azure Portal, solo puede aplicar una directiva por aplicación de contenedor.

Al aplicar una directiva a una aplicación de contenedor, las reglas se aplican a todas las solicitudes realizadas a esa aplicación de contenedor, no a las solicitudes realizadas desde esa aplicación de contenedor. Por ejemplo, una directiva de reintento se aplica a una aplicación de contenedor denominada App B. Todas las solicitudes entrantes realizadas a la aplicación B vuelven a intentarlo automáticamente en caso de error. Sin embargo, no se garantiza que las solicitudes salientes enviadas por la aplicación B vuelvan a intentarlo en caso de error.

En el ejemplo de resistencia siguiente se muestran todas las configuraciones disponibles.

resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-11-02-preview' = {
  name: 'my-app-resiliency-policies'
  parent: '${appName}'
  properties: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
        connectionTimeoutInSeconds: 5
    }
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                        exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-status-codes'
                '5xx'
                'reset'
                'connect-failure'
                'retriable-4xx'
            ]
        }
    } 
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
    tcpConnectionPool: {
        maxConnections: 100
    }
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
  }
}

Especificaciones de directiva

Tiempos de espera

Los tiempos de espera se usan para finalizar con antelación las operaciones de larga duración. La directiva de tiempo de espera incluye las siguientes propiedades.

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Metadatos Obligatorio Descripción Ejemplo
responseTimeoutInSeconds Sí Tiempo de espera para una respuesta de la aplicación de contenedor. 15
connectionTimeoutInSeconds Sí Tiempo de espera para establecer una conexión a la aplicación de contenedor. 5

Retries

Defina tcpRetryPolicy o una estrategia httpRetryPolicy para las operaciones con errores. La directiva de reintentos incluye las siguientes configuraciones.

httpRetryPolicy

properties: {
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                       exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-headers'
                'retriable-status-codes'
            ]
        }
    } 
}
Metadatos Obligatorio Descripción Ejemplo
maxRetries Sí Número máximo de reintentos que se ejecutarán para una solicitud HTTP con errores. 5
retryBackOff Sí Supervise las solicitudes y apague todo el tráfico al servicio afectado cuando se cumplen los criterios de tiempo de espera y reintento. N/D
retryBackOff.initialDelayInMilliseconds Sí Retraso entre el primer error y el primer reintento. 1000
retryBackOff.maxIntervalInMilliseconds Sí Retraso máximo entre los reintentos. 10000
matches Sí Establezca valores de coincidencia para limitar cuándo la aplicación debe intentar un reintento. headers, httpStatusCodes, errors
matches.headers Y* Vuelva a intentarlo cuando la respuesta de error incluya un encabezado específico. *Los encabezados solo son propiedades necesarias si especifica la propiedad de error retriable-headers. Obtenga más información sobre las coincidencias de encabezado disponibles. X-Content-Type
matches.httpStatusCodes Y* Vuelva a intentarlo cuando la respuesta devuelva un código de estado específico. *Los códigos de estado solo son propiedades necesarias si especifica la propiedad de error retriable-status-codes. 502, 503
matches.errors Sí Solo reintenta cuando la aplicación devuelve un error específico. Obtenga más información sobre los errores disponibles. connect-failure, reset
Coincidencias de encabezado

Si especificó el error retriable-headers, puede usar las siguientes propiedades de coincidencia de encabezado para reintentar cuando la respuesta incluya un encabezado específico.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Metadatos Descripción
prefixMatch Los reintentos se realizan en función del prefijo del valor del encabezado.
exactMatch Los reintentos se realizan en función de una coincidencia exacta del valor del encabezado.
suffixMatch Los reintentos se realizan en función del sufijo del valor del encabezado.
regexMatch Los reintentos se realizan en función de una regla de expresión regular donde el valor del encabezado debe coincidir con el patrón regex.
Errors

Puede realizar reintentos en cualquiera de los siguientes errores:

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
Metadatos Descripción
retriable-headers Encabezados de respuesta HTTP que desencadenan un reintento. Se realiza un reintento si alguna de las coincidencias de encabezado coincide con los encabezados de respuesta. Obligatorio si desea volver a intentarlo en los encabezados coincidentes.
retriable-status-codes Códigos de estado HTTP que deben desencadenar reintentos. Obligatorio si desea reintentar en los códigos de estado coincidentes.
5xx Vuelva a intentarlo si el servidor responde con cualquier código de respuesta 5xx.
reset Vuelva a intentarlo si el servidor no responde.
connect-failure Vuelva a intentarlo si se produjo un error en una solicitud debido a una conexión errónea con la aplicación de contenedor.
retriable-4xx Vuelva a intentarlo si la aplicación de contenedor responde con un código de respuesta de la serie 400, como 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Metadatos Obligatorio Descripción Ejemplo
maxConnectAttempts Sí Establezca el número máximo de intentos de conexión (maxConnectionAttempts) para reintentar en conexiones con error. 3

Interruptores

Las directivas de disyuntor especifican si una réplica de aplicación de contenedor se quita temporalmente del grupo de equilibrio de carga en función de desencadenadores como el número de errores consecutivos.

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
Metadatos Obligatorio Descripción Ejemplo
consecutiveErrors Sí Número consecutivo de errores antes de que una réplica de aplicación de contenedor se quite temporalmente del equilibrio de carga. 5
intervalInSeconds Sí Cantidad de tiempo que se da para determinar si se quita o restaura una réplica del grupo de equilibrio de carga. 10
maxEjectionPercent Sí Porcentaje máximo de réplicas de aplicaciones de contenedor con errores para expulsar del equilibrio de carga. Quita al menos un host independientemente del valor. 50

Grupos de conexiones

La agrupación de conexiones de Azure Container App mantiene un grupo de conexiones establecidas y reutilizables a aplicaciones de contenedor. Este grupo de conexiones reduce la sobrecarga de crear y anular conexiones individuales para cada solicitud.

Los grupos de conexiones permiten especificar el número máximo de solicitudes o conexiones permitidas para un servicio. Estos límites controlan el número total de conexiones simultáneas para cada servicio. Cuando se alcanza este límite, las nuevas conexiones no se establecen en ese servicio hasta que se liberan o cierran las conexiones existentes. Este proceso de administración de conexiones impide que las solicitudes agoten los recursos y mantiene una administración de conexiones eficaz.

httpConnectionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
Metadatos Obligatorio Descripción Ejemplo
http1MaxPendingRequests Sí Se usa para las solicitudes http1. Número máximo de conexiones abiertas a una aplicación de contenedor. 1024
http2MaxRequests Sí Se usa para las solicitudes http2. Número máximo de solicitudes simultáneas a una aplicación de contenedor. 1024

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metadatos Obligatorio Descripción Ejemplo
maxConnections Sí Número máximo de conexiones simultáneas a una aplicación de contenedor. 100

Observabilidad de resistencia

Puede realizar la observabilidad de resistencia a través de las métricas y los registros del sistema de la aplicación de contenedor.

Registros de resistencia

En la sección Supervisión de la aplicación de contenedor, seleccione Registros.

Screenshot demonstrating where to find the logs for your container app.

En el panel Registros, escriba y ejecute una consulta para encontrar resistencia a través de los registros del sistema de aplicaciones de contenedor. Por ejemplo, ejecute una consulta similar a la siguiente para buscar eventos de resistencia y mostrar lo siguiente:

  • Marca de fecha
  • Nombre del entorno
  • Nombre de la aplicación de contenedor
  • Tipo de resistencia y motivo
  • Mensajes de registro
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

Haga clic en Ejecutar para ejecutar la consulta y ver los resultados.

Screenshot showing resiliency query results based on provided query example.

Métricas de resistencia

En el menú Supervisión de la aplicación de contenedor, seleccione Métricas. En el panel Métricas, seleccione los filtros siguientes:

  • Ámbito del nombre de la aplicación de contenedor.
  • Espacio de nombres de Métricas estándar.
  • Métricas de resistencia del menú desplegable.
  • Cómo desea ver los datos agregados en los resultados (por promedio, por número máximo, etc.).
  • Duración del tiempo (últimos 30 minutos, últimas 24 horas, etc.).

Screenshot demonstrating how to access the resiliency metrics filters for your container app.

Por ejemplo, si establece la métrica Reintentos de solicitud de resistencia en el ámbito de la aplicación de prueba con agregación Promedio para buscar dentro de un período de tiempo de 30 minutos, los resultados son similares a los siguientes:

Screenshot showing the results from example metrics filters for resiliency.

Contenido relacionado

Consulte cómo funciona la resistencia para los Componentes de Dapr en Azure Container Apps.