Platforma handlowa działa na zestawie skalowania maszyn wirtualnych Azure (VMSS) dla warstwy API, usłudze App Service dla front-endu internetowego i bazie danych Azure SQL Database. Musisz: 1) Otrzymywać alerty, gdy średnie użycie procesora VMSS przekroczy 80% przez 5 minut (powiadomienie dyżurnego przez SMS) oraz gdy przekroczy 95% przez 5 minut (powiadomienie SRE przez PagerDuty). 2) Przesyłać strumieniowo dzienniki diagnostyczne App Service i SQL do obszaru roboczego Log Analytics i archiwizować je na koncie usługi Azure Storage przez 365 dni. 3) Wyzwolić alert, gdy dzienniki App Service zawierają 'OrderTimeoutException' więcej niż 10 razy w ciągu 5 minut. Co należy zaimplementować?

Poprawna odpowiedź spełnia wszystkie wymagania. Dwie reguły alertów metryk Azure Monitor dla VMSS z różnymi progami i grupami akcji to standardowe podejście do powiadomień opartych na progach. Ustawienia diagnostyczne w App Service i Azure SQL umożliwiają przesyłanie dzienników i metryk do Log Analytics (do analizy i alertowania) oraz do konta Storage (do archiwizacji). Alert zaplanowanego zapytania Log Analytics jest idealny do wykrywania wzorców w dziennikach, takich jak wielokrotne wystąpienia 'OrderTimeoutException'. Pozostałe opcje są nieprawidłowe, ponieważ: Dynamiczny alert metryki nie jest przeznaczony do wielu progów z różnymi akcjami. Alerty Activity Log nie monitorują zawartości dzienników aplikacji. Autoscale służy do skalowania, nie do powiadamiania o progach. Azure Policy nie służy do zbierania dzienników diagnostycznych w ten sposób. Smart Alerts nie są przeznaczone do precyzyjnego monitorowania progów. Przesyłanie strumieniowe tylko do Event Hubs wymaga dodatkowej logiki do alertowania. Reguły akcji zmieniają ważność, nie wyzwalają różnych akcji dla różnych progów. Azure Defender for Cloud nie jest podstawowym narzędziem do zbierania dzienników diagnostycznych aplikacji ani do alertowania na podstawie niestandardowych wyjątków w dziennikach.