Tengo un servicio que está registrado con dos grupos objetivo: alby wwwalb.
El albgrupo objetivo es para solicitudes internas y el wwwalbgrupo objetivo es para solicitudes externas.
Cuando implemento mi servicio, se inicia como debería y comienza a aceptar solicitudes. Al mirar el registro de acceso, puedo ver que tanto el albcomo wwwalbel servicio sondean. Como el servicio se ejecuta en 3 zonas, veo 3 solicitudes para cada zona, 6 en total.
- - - [19/Jun/2022:20:45:28 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:28 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:28 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:30 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:30 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:30 +0200] "GET /api/system/status HTTP/1.1" 204 -
A pesar de esto, el servicio finalmente se retira porque los grupos destinatarios creen que el servicio no es saludable. De hecho, nunca parece pensar que el servicio sea saludable.
Una llamada API para verificar el grupo objetivo me dice lo siguiente:
{
"TargetHealthDescriptions": [
{
"Target": {
"Id": "10.1.143.94",
"Port": 8182,
"AvailabilityZone": "eu-north-1b"
},
"HealthCheckPort": "8182",
"TargetHealth": {
"State": "unhealthy",
"Reason": "Target.FailedHealthChecks",
"Description": "Health checks failed"
}
}
]
}
He estado analizando las métricas del grupo objetivo y las configuraciones del balanceador de carga desde hace un tiempo, pero simplemente no puedo encontrar nada sobre la configuración que pueda explicar este comportamiento. La configuración de verificación de estado también me parece bien:
Recientemente agregué el wwwalb, así que creo que de alguna manera tener este servicio en dos grupos objetivo causa esto. Por otra parte, AWS respalda y explica tener un servicio en dos grupos objetivo.
¿Hay alguna manera de obtener más detalles de AWS sobre la causa real de este problema? ¿Alguna forma de investigar por qué AWS cree que el servicio está fallando?
Respuesta1
Normalmente establezco mi umbral no saludable en algo más alto que mi umbral saludable. Así como 2 llamadas exitosas con un intervalo de 10 segundos son saludables, 6 llamadas fallidas con un intervalo de 10 segundos no son saludables.
Dicho esto, no debería importar y tu configuración debería funcionar. Cuando un objetivo se registra, se produce un estado "inicial". Durante ese tiempo, AWS intenta validar las comprobaciones de estado y solo debe cambiar a un estado saludable si las comprobaciones de estado son exitosas.
El proceso de registro puede tardar unos minutos en completarse y comenzar los controles de salud.
¿Está seguro de que su aplicación no responde correctamente y luego falla durante un tiempo suficiente como para volver a fallar? ¿O es realmente que tarda demasiado en arrancar y nunca sale del estado "inicial"?