Azure Monitor 경고 문제 해결
이 문서에서는 Azure Monitor 경고 및 알림의 일반적인 문제를 설명합니다. Azure Monitor 경고는 모니터링 데이터에서 중요한 조건이 발견되면 사전에 알려줍니다.
Azure 메트릭 또는 로그 검색 경고 문제 해결에 대한 자세한 내용은 다음을 참조하세요.
문제 해결 전
경고가 의도한 대로 실행되지만 적절한 알림이 예상대로 수행되지 않는 경우 먼저 작업 그룹을 테스트하여 제대로 구성되었는지 확인합니다.
그렇지 않으면 이 문서의 나머지 부분에 있는 정보를 사용하여 문제를 해결합니다.
예상 이메일을 받지 못했습니다.
Azure Portal에서 발생한 경고를 볼 수 있지만 구성한 이메일을 받지 못한 경우 다음 단계를 수행합니다.
이메일이 경고 처리 규칙에 의해 억제되었나요?
포털에서 발생한 경고를 클릭하여 확인하고 표시되지 않은 작업 그룹에 대해 기록 탭을 확인합니다.
"Azure Resource Manager 역할에 이메일 보내기" 작업 유형인가요?
이 작업을 수행하면 구독 범위 및 사용자 또는 그룹 유형의 Azure Resource Manager 역할 할당만 보입니다. 리소스 수준 또는 리소스 그룹 수준이 아닌 구독 수준에서 역할을 할당했는지 확인합니다.
이메일 서버와 사서함에서 외부 이메일을 받고 있나요?
다음 세 주소의 이메일이 차단되지 않았는지 확인합니다.
- azure-noreply@microsoft.com
- azureemail-noreply@microsoft.com
- alerts-noreply@mail.windowsazure.com
일반적으로 내부 메일 목록 또는 배포 목록으로 외부 이메일 주소의 이메일을 차단합니다. 위의 이메일 주소에서 오는 메일을 허용하는지 확인합니다. 테스트하려면 작업 그룹에 일반 업무용 이메일 주소(메일 그룹 아님)를 추가하고 해당 이메일에 경고가 도착하는지 확인합니다.
받은 편지함 규칙이나 스팸 필터에 의해 이메일이 처리되었나요?
해당 이메일을 삭제하거나 다른 폴더로 이동하는 받은 편지함 규칙이 없는지 확인합니다. 예를 들어 받은 편지함 규칙은 특정 보낸 사람이나 제목에서 특정 단어를 검색할 수 있습니다. 다음을 확인합니다.
- (Outlook, Gmail과 같은) 이메일 클라이언트의 스팸 설정
- 이메일 서버(예: Exchange, Microsoft 365, G-suite)의 보낸 사람 제한/스팸 설정/격리 설정
- 해당하는 경우 이메일 보안 어플라이언스의 설정(예: Barracuda, Cisco).
실수로 작업 그룹에서 수신을 거부했나요?
참고 항목
작업 그룹에서 구독을 취소하면 배포 목록의 모든 멤버도 구독 취소된다는 점에 유념해야 합니다. 배포 목록 이메일 주소를 계속 사용할 수 있습니다. 그러나 배포 목록 사용자에게 구독을 취소하면 자신만이 아니라 전체 배포 목록의 구독이 취소된다는 사실을 알려야 합니다. 이에 대한 해결 방법은 작업 그룹에 있는 모든 사용자의 이메일 주소를 개별적으로 추가하는 것입니다. 하나의 작업 그룹에는 최대 1000개의 이메일 주소가 포함될 수 있습니다. 그러면 특정 사용자가 구독을 취소하려는 경우 다른 사용자에게 영향을 주지 않고 구독을 취소할 수 있습니다. 또한 어떤 사용자가 구독을 취소했는지 확인할 수도 있습니다.
경고 이메일은 작업 그룹에서 수신을 거부할 수 있는 링크를 제공합니다. 이 작업 그룹에서 실수로 수신을 거부했는지 확인하려면 다음 중 하나를 수행합니다.
- 포털에서 작업 그룹을 열고 상태 열을 확인합니다.
- 이메일에서 수신 거부 확인을 검색합니다.
다시 수신하려면 받은 수신 거부 확인 이메일의 링크를 사용하거나 작업 그룹에서 이메일 주소를 제거한 다음, 다시 추가합니다.
단일 이메일 주소로 많은 이메일을 전송하여 서비스 제한을 초과했나요?
이메일 주소마다 시간당 이메일 100개 이하로 제한됩니다. 이 임계값을 통과하면 더 이상 이메일 알림이 전송되지 않습니다. 이메일 주소가 일시적으로 속도가 제한되었음을 나타내는 메시지를 받았는지 확인합니다.
속도 제한 없이 많은 양의 알림을 받으려면 다음과 같은 다른 작업을 사용하는 것이 좋습니다.
- 웹후크
- 논리 앱
- Azure 함수
- 자동화 Runbook
이러한 작업 중 어느 것도 속도가 제한되지 않습니다.
예상된 SMS, 음성 통화 또는 푸시 알림이 수신되지 않음
포털에서 발생한 경고를 볼 수 있지만 구성한 SMS, 음성 통화 또는 푸시 알림을 받지 못한 경우 다음 단계를 수행합니다.
경고 처리 규칙에 의해 작업이 억제되었나요?
포털에서 발생한 경고를 클릭하여 확인하고 표시되지 않은 작업 그룹에 대해 기록 탭을 확인합니다.
의도하지 않은 경우 경고 처리 규칙을 수정, 사용하지 않도록 설정 또는 삭제할 수 있습니다.
SMS/음성: 전화 번호가 정확한가요?
SMS 작업에서 국가 번호 또는 전화 번호가 정확한지 확인합니다.
SMS/음성: 서비스 제한을 초과했나요?
SMS 및 음성 통화는 전화 번호마다 5분당 알림 1개 이하로 속도가 제한됩니다. 이 임계값을 초과하면 알림이 삭제됩니다.
- 음성 통화 - 통화 기록을 확인하고 이전 5분 내에 Azure에서 다른 통화가 있었는지 확인합니다.
- SMS - 전화 번호에 속도 제한이 설정되어 있음을 나타내는 메시지가 있는지 SMS 기록을 확인합니다.
속도 제한 없이 많은 양의 알림을 받으려면 다음과 같은 다른 작업을 사용하는 것이 좋습니다.
- 웹후크
- 논리 앱
- Azure 함수
- 자동화 Runbook
이러한 작업 중 어느 것도 속도가 제한되지 않습니다.
SMS: 실수로 작업 그룹에서 구독을 취소했나요?
SMS 기록을 열고, 이 특정 작업 그룹(action_group_short_name 회신 사용 안 함 사용) 또는 모든 작업 그룹(회신 중지 사용)에서 SMS 배달을 옵트아웃했는지 확인합니다.
다시 구독하려면 관련 SMS 명령(action_group_short_name 사용 또는 시작)을 보내거나 작업 그룹에서 SMS 작업을 제거한 다음, 다시 추가합니다. 자세한 내용은 작업 그룹의 SMS 경고 동작을 참조하세요.
실수로 휴대폰에서 알림을 차단했나요?
대부분의 휴대폰에서는 특정 전화 번호 또는 짧은 코드에서 통화 또는 SMS를 차단하거나 특정 앱(예: Azure 모바일 앱)의 푸시 알림을 차단할 수 있습니다. 휴대폰에서 알림을 실수로 차단했는지 확인하려면 휴대폰 운영 체제 및 모델에 해당하는 설명서를 검색하거나 다른 전화기 및 전화 번호를 사용하여 테스트합니다.
예상 작업이 트리거되지 않음
포털에서 발생한 경고를 볼 수 있지만 구성된 작업이 트리거되지 않은 경우 다음 단계를 수행합니다.
경고 처리 규칙에 의해 작업이 억제되었나요?
포털에서 발생한 경고를 클릭하여 확인하고 표시되지 않은 작업 그룹에 대해 기록 탭을 확인합니다.
의도하지 않은 경우 경고 처리 규칙을 수정, 사용하지 않도록 설정 또는 삭제할 수 있습니다.
웹후크가 트리거되었나요?
원본 IP 주소가 차단되었나요?
웹후크가 호출되는 IP 주소를 허용 목록에 추가합니다.
웹후크 엔드포인트가 제대로 작동하나요?
구성한 웹후크 엔드포인트가 올바르고 엔드포인트가 제대로 작동하는지 확인합니다. 웹후크 로그를 확인하거나 해당 코드를 계측하여 조사할 수 있습니다(예: 들어오는 페이로드 기록).
Slack 또는 Microsoft Teams를 호출하는 데 올바른 형식을 사용하고 있나요?
이러한 각 엔드포인트에는 특정 JSON 형식이 필요합니다. 이러한 지침을 따라 대신 논리 앱 작업을 구성합니다.웹후크가 응답하지 않았거나 오류가 반환되었나요?
웹후크 작업 그룹은 호출될 때 일반적으로 다음 규칙을 따릅니다.
- 웹후크가 호출될 때 첫 번째 호출이 실패하면 다양한 지연 간격(5초, 20초, 40초)에서 최소 1회 이상, 최대 5회(5회 다시 시도) 다시 시도합니다.
- 1번째 시도와 2번째 시도 사이의 대기 시간은 5초입니다.
- 2번째 시도와 3번째 시도 사이의 대기 시간은 20초입니다.
- 3번째 시도와 4번째 시도 사이의 대기 시간은 5초입니다.
- 4번째와 5번째 시도 사이의 대기 시간은 40초입니다.
- 5번째와 6번째 시도 사이의 대기 시간은 5초입니다.
- 웹후크 호출 다시 시도가 실패한 후 15분 동안 엔드포인트를 호출하는 작업 그룹이 없습니다.
- 재시도 논리는 호출을 다시 시도할 수 있다고 가정합니다. 상태 코드: 408, 429, 503, 504 또는
HttpRequestException,WebException또는TaskCancellationException을 사용하면 호출을 다시 시도할 수 있습니다.
- 웹후크가 호출될 때 첫 번째 호출이 실패하면 다양한 지연 간격(5초, 20초, 40초)에서 최소 1회 이상, 최대 5회(5회 다시 시도) 다시 시도합니다.
작업 또는 알림이 두 번 이상 발생함
경고에 대한 알림(예: 이메일 또는 SMS)을 두 번 이상 받았거나 경고 동작(예: 웹후크 또는 Azure 함수)이 여러 번 트리거된 경우 다음 단계를 수행합니다.
정말 동일한 경고인가요?
경우에 따라 유사한 경고가 여러 개 동시에 발생합니다. 따라서 동일한 경고가 작업을 여러 번 트리거한 것처럼 보일 수 있습니다. 예를 들어 이벤트 상태 필드를 필터링하지 않고 이벤트가 시작될 때와 완료(성공 또는 실패)될 때 모두 실행되도록 활동 로그 경고 규칙을 구성할 수 있습니다.
이러한 작업 또는 알림이 다른 경고에서 발생했는지 확인하려면 해당 타임스탬프 및 경고 ID 또는 해당 상관 관계 ID와 같은 경고 세부 정보를 확인합니다. 또는 포털에서 발생한 경고 목록을 확인합니다. 이 경우에 해당하면 경고 규칙 논리를 조정하거나 달리 경고 원본을 구성해야 할 수 있습니다.
작업이 여러 작업 그룹에서 반복되나요?
경고가 발생하면 각 작업 그룹은 독립적으로 처리됩니다. 따라서 여러 개의 트리거된 작업 그룹에 작업(예: 이메일 주소)이 표시되면 작업 그룹당 한 번씩 호출됩니다.
트리거된 작업 그룹을 확인하려면 경고 기록 탭을 확인합니다. 경고 규칙에 정의된 작업 그룹과 경고 처리 규칙에 의해 경고에 추가된 작업 그룹이 모두 표시됩니다.
작업 또는 알림에 예기치 않은 콘텐츠가 있음
대체 이메일 공급자의 사용을 트리거하는 중단이 있었나요?
작업 그룹은 두 개의 서로 다른 메일 공급자를 사용하여 메일 알림 전달을 보장합니다. 기본 메일 공급자는 복원력이 뛰어나고 빠르지만 가끔 중단되는 경우가 있습니다. 중단이 발생하면 보조 이메일 공급자가 이메일 요청을 처리합니다. 보조 공급자는 대체 솔루션일 뿐입니다. 공급자의 차이로 인해 보조 공급자에서 보낸 이메일의 성능이 저하될 수 있습니다. 성능 저하로 인해 메일 서식 및 콘텐츠가 약간 다릅니다. 두 시스템에서 이메일 템플릿이 서로 다르므로 동등성을 유지하는 것은 불가능합니다.
대체 솔루션에서 생성된 알림에는 다음과 같은 메모가 포함되어 있습니다.
“이것은 성능이 저하된 메일 환경입니다. 즉, 서식이 꺼져 있거나 세부 정보가 누락될 수 있습니다. 성능이 저하된 메일 환경에 대한 자세한 내용은 여기를 참조하세요.”
알림에 이 메모가 포함되어 있지 않고 경고를 받았지만 일부 필드가 누락되었거나 올바르지 않다고 생각되는 경우 페이로드 형식을 확인합니다.
경고 규칙을 구성할 때 어떤 형식을 사용했나요?
각 작업 유형(이메일, 웹후크 등)에는 두 가지 형식(기본, 레거시 형식)과 공용 스키마 형식이 있습니다. 작업 그룹을 만들 때 작업의 형식을 지정합니다. 작업 그룹의 다른 작업에는 다른 형식이 있을 수 있습니다.
예를 들어 웹후크 작업의 경우 다음과 같습니다.
작업 수준에 지정된 형식이 원하는 형식인지 확인합니다. 예를 들어 어떤 형식을 기대하며 경고에 응답하는 코드(웹후크, 함수, 논리 앱 등)를 개발했지만 나중에 해당 사용자 또는 다른 사용자가 다른 형식을 지정했습니다.
또한 활동 로그 경고, 로그 검색 경고(Application Insights 및 Log Analytics 모두), 메트릭 경고, 일반적인 경고 스키마 및 사용되지 않는 클래식 메트릭 경고에 대해 페이로드 형식(JSON)을 확인합니다.
검색 결과는 로그 검색 경고 알림에 포함되지 않습니다.
로그 검색 경고 API 버전 2021-08-01부터 검색 결과가 경고 알림 페이로드에서 제거되었습니다. 검색 결과는 이전 API 버전(2018-04-16)으로 만든 경고 규칙에만 사용할 수 있습니다. Azure Portal을 통해 새 경고 규칙을 만들면 기본적으로 최신 버전으로 규칙을 만듭니다. 로그 경고 규칙 만들기 환경의 변경 내용에 따라 업데이트된 버전을 사용하기 위한 변경 내용 및 권장 조정에 대해 알아봅니다.
MetricValue 필드에는 확인된 로그 검색 경고 알림에 대한 "null"이 포함됩니다.
이것은 의도적인 것입니다. 상태 저장 로그 검색 경고는 값 기반이 아닌 시간 기반 확인 논리를 사용합니다. Azure Monitor는 경고가 해결되는 값이 없고 시간이 경과했기 때문에 null 메트릭 값을 보냅니다.
차원 목록이 비어 있거나 경고 제목에 차원 이름이 포함되어 있지 않습니다.
결과를 반환하지 않는 로그 검색 경고 규칙이 있는 경우 경고가 예상대로 실행될 수 있지만 차원 목록이 비어 있거나 경고 제목에 차원 이름이 포함되지 않습니다. 쿼리가 행을 반환하지 않으면 리소스 ID 필드(차원 및 제목 필드를 채우기 위한 기준)가 비어 있습니다.
활동 로그 경고에 정보가 없습니다.
활동 로그 경고는 Azure 리소스 만들기, 업데이트 또는 삭제에 대한 이벤트, 서비스 상태 및 리소스 상태 이벤트, Azure Advisor 및 Azure Policy의 결과 등 Azure 활동 로그에 기록된 이벤트를 기반으로 하는 경고입니다. 활동 로그를 기반으로 경고를 받았지만 필요한 일부 필드가 누락되거나 잘못된 경우 활동 로그 자체의 이벤트를 먼저 확인합니다. Azure 리소스가 활동 로그 이벤트에서 찾고 있는 필드를 작성하지 않은 경우 해당 필드는 해당 경고에 포함되지 않습니다.
사용자 지정 속성이 이메일, SMS 또는 푸시 알림에서 누락되었습니다.
사용자 지정 속성은 웹후크, Azure 함수 또는 논리 앱과 같은 작업에 대한 페이로드에만 전달됩니다. 사용자 지정 속성은 알림(이메일/SMS/푸시)에 포함되지 않습니다.
작업 처리 규칙이 예상대로 작동하지 않음
포털에서 발생한 경고를 볼 수 있지만 관련 경고 처리 규칙이 예상대로 작동하지 않는 경우 다음 단계를 수행합니다.
경고 처리 규칙이 사용하도록 설정되어 있나요?
경고 처리 규칙 상태 필드를 확인하여 관련 작업 역할이 사용하도록 설정되어 있는지 확인합니다. 기본적으로 포털은 사용하도록 설정된 경고 규칙만 표시하지만 필터를 변경하여 모든 규칙을 표시할 수 있습니다.
사용하도록 설정되지 않은 경우 경고 처리 규칙을 선택하고 [사용]을 클릭하여 경고 처리 규칙을 사용하도록 설정할 수 있습니다.
서비스 상태 경고인가요?
서비스 상태 경고는 경고 처리 규칙의 영향을 받지 않습니다. 따라서 서비스 상태 경고가 포함된 범위에 대해 구성된 경고 처리 규칙이 있는 경우 서비스 상태 경고는 범위 내에 있지만 경고 처리 규칙은 영향을 주지 않습니다.
경고 처리 규칙이 경고를 처리했나요?
포털에서 발생한 경고를 선택하고 기록 탭을 확인하여 경고 처리 규칙이 처리되었는지 확인합니다.
다음은 모든 작업 그룹을 표시하지 않는 경고 처리 규칙의 예입니다.
다른 작업 그룹을 추가하는 경고 처리 규칙의 예는 다음과 같습니다.
경고 처리 규칙 범위 및 필터가 발생한 경고와 일치하나요?
경고 처리 규칙이 발생해야 하는데 발생하지 않았거나 발생하지 말아야 하는데 발생한 경우 경고 처리 규칙 범위 및 필터 조건을 주의 깊게 검토하고 경고의 속성과 비교합니다.
Azure Portal에서 경고 처리 규칙을 만들거나 업데이트하거나 삭제하는 문제
경고 처리 규칙을 만들거나 업데이트하거나, 삭제하는 동안 오류가 발생한 경우 다음 단계를 수행합니다.
권한을 확인합니다.
모니터링 Contributor 기본 제공 역할 또는 경고 처리 규칙 및 경고와 관련된 특정 권한이 있어야 합니다.
경고 처리 규칙 매개 변수를 확인합니다.
경고 처리 규칙 설명서 또는 경고 처리 규칙 PowerShell Set-AzAlertProcessingRule 명령을 확인합니다.