Aplikacja jednostronicowa udostępnia zawartość statyczną z S3 za pośrednictwem CloudFront i używa klastra EKS do obsługi żądań API. Użytkownicy czasami zgłaszają, że witryna nie działa, mimo że strona indeksowa i sprawdzenia klastra EKS wyglądają na sprawne. Jakie dodatkowe monitorowanie proaktywnie wykryje awarię witryny, zanim zgłoszą ją użytkownicy?

Poprawna odpowiedź to utworzenie canary monitora heartbeat CloudWatch Synthetics, który wskazuje na w pełni kwalifikowaną nazwę domeny (FQDN) witryny. Canary Synthetics symuluje interakcje użytkownika z aplikacją, sprawdzając dostępność i wydajność witryny od strony klienta. Monitor heartbeat regularnie wysyła proste żądanie HTTP/S do FQDN witryny, co pozwala na proaktywne wykrycie niedostępności, nawet jeśli pliki statyczne w S3 i klaster EKS działają poprawnie. Utworzenie canary API CloudWatch Synthetics do monitorowania dostępności punktów końcowych API klastra EKS jest ważne, ale nie wykryje problemów z dostępnością samej witryny, jeśli strona indeksowa nie jest serwowana prawidłowo. Utworzenie monitora aplikacji CloudWatch RUM dla FQDN witryny zbiera dane telemetryczne dotyczące wydajności i błędy JavaScript z prawdziwych sesji użytkowników, ale nie jest proaktywnym wykrywaniem awarii, ponieważ opiera się na aktywności użytkowników. Utworzenie monitora aplikacji CloudWatch RUM, który jest ukierunkowany na punkty końcowe API klastra EKS, również zbiera dane od prawdziwych użytkowników i dotyczy tylko API, a nie ogólnej dostępności witryny.