Una aplicación de una sola página sirve contenido estático desde S3 a través de CloudFront y utiliza un clúster de EKS para las solicitudes de API. Los usuarios a veces dicen que el sitio está caído, aunque la página de índice y las comprobaciones del clúster de EKS parecen correctas. ¿Qué monitoreo adicional detectará proactivamente una interrupción del sitio antes de que los usuarios la reporten?

La opción correcta es crear un canary de monitor de latidos de CloudWatch Synthetics que apunte al FQDN del sitio web. Un canary de latidos realiza una solicitud HTTP/S simple al punto final especificado y verifica el código de estado HTTP, el tiempo de carga y la presencia de una cadena en la respuesta. Esto simula el comportamiento de un usuario que intenta acceder al sitio, detectando proactivamente problemas de disponibilidad general del sitio web (como problemas de DNS, certificados SSL o conectividad a S3/CloudFront) antes de que los usuarios los reporten. La creación de un canary de API de CloudWatch Synthetics para monitorear los puntos finales de la API del clúster de EKS es útil, pero no detectaría problemas con la entrega del contenido estático del sitio web, que es lo que los usuarios reportan como "caído". Los monitores de aplicación de CloudWatch RUM (Real User Monitoring) recopilan datos de usuarios reales, lo que es valioso para el rendimiento y los errores de JavaScript, pero no detectan una interrupción del sitio antes de que los usuarios la experimenten. Además, un monitor de RUM para los puntos finales de la API del clúster de EKS solo monitorearía las API, no la disponibilidad general del sitio estático.