소매 플랫폼은 API 계층에 Azure Virtual Machine Scale Set(VMSS), 웹 프런트엔드에 App Service, Azure SQL Database를 사용합니다. 다음을 구현해야 합니다. 1) VMSS 평균 CPU가 5분 동안 80%를 초과하면 경고(온콜 담당자에게 SMS로 알림), 5분 동안 95%를 초과하면 경고(PagerDuty를 통해 SRE에게 호출). 2) App Service 및 SQL 진단 로그를 Log Analytics 작업 영역으로 스트리밍하고 365일 동안 Azure Storage에 보관합니다. 3) App Service 로그에 'OrderTimeoutException'이 5분 동안 10회 이상 포함되면 경고를 트리거합니다. 무엇을 구현해야 할까요?

VMSS CPU 경고의 경우, 두 가지 다른 임계값과 알림 방법이 필요하므로 각각 다른 작업 그룹에 연결된 두 개의 Azure Monitor 메트릭 경고 규칙을 생성하는 것이 올바른 접근 방식입니다. 진단 로그의 경우, App Service 및 Azure SQL에 대한 진단 설정을 구성하여 로그와 메트릭을 Log Analytics 작업 영역과 Azure Storage 계정으로 모두 보내야 합니다. Log Analytics는 쿼리 및 경고에 사용되고, Storage 계정은 365일 보관 요구 사항을 충족합니다. 'OrderTimeoutException' 경고의 경우, Log Analytics 작업 영역으로 스트리밍된 App Service 로그에서 특정 문자열을 검색하는 Log Analytics 예약된 쿼리 경고를 생성하여 요구 사항을 충족할 수 있습니다. 다른 옵션들은 다음과 같은 이유로 올바르지 않습니다. 단일 구독 간 동적 메트릭 경고는 두 가지 다른 임계값과 알림을 처리하기에 적합하지 않습니다. 활동 로그 진단은 App Service 및 SQL 진단 로그를 수집하지 않습니다. Azure Monitor Autoscale은 경고가 아닌 스케일링을 위한 것이며, Azure Policy는 로그 수집에 직접 사용되지 않습니다. 메트릭 경고는 App Service 로그의 특정 문자열을 감지할 수 없습니다. Smart Alerts는 동적 임계값을 사용하지만, 요구 사항은 고정 임계값을 지정합니다. Event Hubs로만 스트리밍하는 것은 365일 보관 요구 사항을 충족하지 않습니다. Azure Monitor 작업 규칙은 경고 심각도를 변경할 수 있지만, 두 가지 다른 임계값에 대한 두 가지 다른 알림을 처리하지 않습니다. Azure Defender for Cloud는 진단 수집 및 특정 예외에 대한 경고를 처리하는 주요 도구가 아닙니다.