Resistencia de detección de servicios
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.
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.
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.
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.).
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:
Contenido relacionado
Consulte cómo funciona la resistencia para los Componentes de Dapr en Azure Container Apps.