Firma migrowała swoją aplikację do klastra Amazon EKS na EC2 i włączyła automatyczne skalowanie w oparciu o użycie procesora. Pod dużym obciążeniem aplikacja zgłasza błędy pamięci i nie skaluje się wystarczająco. Firma musi zbierać i analizować metryki pamięci w czasie. Jaka kombinacja kroków pozwoli to osiągnąć? (Wybierz trzy.)

Dołączenie polityki CloudWatchAgentServerPolicy do profilu instancji IAM jest konieczne, aby agent CloudWatch miał uprawnienia do wysyłania metryk do CloudWatch. Wdrożenie ujednoliconego agenta CloudWatch na instancjach EC2 (i wbudowanie go w AMI dla nowych węzłów) jest kluczowe do zbierania metryk pamięci z węzłów i podów. Agent CloudWatch jest odpowiedzialny za zbieranie szczegółowych danych o wydajności. Analiza metryki podmemoryutilization w przestrzeni nazw ContainerInsights z wymiarem Service pozwala monitorować użycie pamięci przez aplikację na poziomie poda, co jest kluczowe dla diagnozowania problemów z brakiem pamięci i skalowaniem. Pozostałe opcje są nieprawidłowe, ponieważ: Polityka IAM jest przypisywana do profilu instancji, a nie do roli konta usługi dla klastra w kontekście zbierania metryk z instancji EC2. ADOT Collector jest używany głównie do zbierania danych telemetrycznych (metryk, logów, śladów) w formacie OpenTelemetry, a nie jest podstawowym narzędziem do zbierania standardowych metryk pamięci EC2/EKS dla CloudWatch Container Insights. nodememoryutilization z wymiarem ClusterName monitoruje użycie pamięci na poziomie węzła, a nie na poziomie poda/usługi, co jest bardziej istotne dla problemów z aplikacją.