기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
모니터링 작동 방식
AWS Managed Services(AMS)의 모니터링 아키텍처에 대한 다음 그래픽을 참조하세요.
다음 다이어그램은 AMS 다중 계정 랜딩 존 및 AMS 단일 계정 랜딩 존 모니터링 워크플로에 대한 개략적인 개요를 제공합니다.
생성: 계정 온보딩 시 AMS는 관리형 계정에서 생성된 모든 리소스에 대한 기준 모니터링(CloudWatch(CW) 경보 및 CW 이벤트 규칙의 조합)을 구성합니다. 기준 모니터링 구성은 CW 경보가 트리거되거나 CW 이벤트가 생성될 때 알림을 생성합니다.
집계:
다중 계정 랜딩 존: 알림은 애플리케이션 및 코어 조직 단위 계정 내의 리소스에서 생성되며 보안 계정을 통해 전달하여 AMS 모니터링 시스템으로 전송됩니다.
단일 계정 랜딩 존: 리소스에서 생성된 모든 알림은 계정의 SNS 주제로 전달하여 AMS 모니터링 시스템으로 전송됩니다.
AMS가 EC2 알림을 그룹화하는 방법을 구성할 수도 있습니다. AMS는 동일한 EC2 인스턴스와 관련된 모든 알림을 단일 인시던트로 그룹화하거나 기본 설정에 따라 알림당 하나의 인시던트를 생성합니다. Cloud Service Delivery Manager 또는 Cloud Architect와 협력하여 언제든지이 구성을 변경할 수 있습니다. 이는 다중 계정 랜딩 존을 사용하든 단일 계정 랜딩 존을 사용하든 동일한 방식으로 작동합니다.
처리 중: AMS는 알림을 분석하고 영향 가능성을 기반으로 처리합니다. 알림은 다음에 설명된 대로 처리됩니다.
알려진 고객 영향이 있는 알림: 이로 인해 새 인시던트 보고서가 생성되고 AMS는 인시던트 관리 프로세스를 따릅니다. 인시던트 관리에 대한 자세한 내용은 섹션을 참조하세요AMS 인시던트 대응.
알림 예: Amazon EC2 인스턴스가 시스템 상태 확인에 실패하고 AMS는 인스턴스를 중지했다가 다시 시작하여 인스턴스 복구를 시도합니다.
고객에게 미치는 영향이 불확실한 알림: 이러한 유형의 알림의 경우 AMS는 인시던트 보고서를 보내며, 대부분의 경우 AMS가 조치를 취하기 전에 영향을 확인하도록 요청합니다. 그러나 인프라 관련 검사를 통과하면 AMS는 인시던트 보고서를 보내지 않습니다.
예: Amazon EC2 인스턴스에서 10분 이상 >85% CPU 사용률에 대한 알림은 사용량에 따라이 동작이 예상될 수 있으므로 인시던트로 즉시 분류할 수 없습니다. 이 예제에서 AMS Automation은 리소스에 대한 인프라 관련 검사를 수행합니다. 이러한 검사가 통과하면 CPU 사용량이 99%를 초과하더라도 AMS는 알림 알림을 보내지 않습니다. 자동화가 리소스에서 인프라 관련 검사가 실패하고 있음을 감지하면 AMS는 알림 알림을 보내고 완화가 필요한지 확인합니다. 알림은이 단원에서 자세히 설명합니다. AMS는 알림에서 완화 옵션을 제공합니다. 알림이 인시던트임을 확인하는 알림에 회신하면 AMS가 새 인시던트 보고서를 생성하고 AMS 인시던트 관리 프로세스가 시작됩니다. "고객 영향 없음" 또는 3일 동안 전혀 응답하지 않음 응답을 수신하는 서비스 알림은 해결됨으로 표시되고 해당 알림은 해결됨으로 표시됩니다.
고객 영향이 없는 알림: 평가 후 AMS가 알림에 고객에게 영향이 없다고 판단하면 알림이 종료됩니다.
예를 들어,는 교체가 필요하지만 이후 해당 인스턴스가 종료되었음을 EC2 인스턴스에 AWS Health 알립니다.
EC2 인스턴스 그룹화된 알림
동일한 EC2 인스턴스의 알림을 단일 인시던트로 그룹화하도록 AMS 모니터링을 구성할 수 있습니다. Cloud Service Delivery Manager 또는 Cloud Architect가 이를 구성할 수 있습니다. 각 AMS 관리형 계정에 대해 구성할 수 있는 파라미터는 4개입니다.
범위: 계정 전체 또는 태그 기반 중 하나를 선택합니다.
해당 계정의 모든 EC2 인스턴스에 적용되는 구성을 지정하려면 범위 = 계정 전체를 선택합니다.
특정 태그가 있는 해당 계정의 EC2 인스턴스에만 적용되는 구성을 지정하려면 범위 = 태그 기반을 선택합니다.
그룹화 규칙: 클래식 또는 인스턴스를 선택합니다.
계정의 모든 리소스에 대해 인스턴스 수준 그룹화를 구성하려면 범위 = 계정 전체 및 그룹화 규칙 = 인스턴스를 선택합니다.
인스턴스 수준 그룹화를 사용하도록 계정의 특정 리소스를 구성하려면 해당 인스턴스에 태그를 지정한 다음 범위 = 태그 기반 및 그룹화 규칙 = 인스턴스 수준을 선택합니다.
계정의 알림에 인스턴스 그룹화를 사용하지 않으려면 그룹화 규칙 = 클래식을 선택합니다.
참여 옵션: 없음, 보고서만 또는 기본값을 선택합니다.
구성이 활성 상태인 동안 AMS가 인시던트를 생성하거나 해당 리소스의 경보에 대한 자동화를 실행하지 않도록 하려면 없음을 선택합니다.
구성이 활성화되어 있는 동안 AMS가 인시던트를 생성하거나 해당 리소스에서 경보에 대한 자동화를 실행하지 않고 자동 복구 Systems Manager 문서를 실행하지 않고 보고에 이러한 이벤트의 레코드를 포함하려면 보고서만 선택합니다. 이는 상호 작용하는 인시던트 지원 사례의 양을 줄이고 일부 리소스의 일부 인시던트가 비프로덕션 계정의 인시던트와 같이 즉각적인 주의가 필요하지 않은 경우에 유용할 수 있습니다.
AMS가 알림을 처리하고, 자동화를 실행하고, 필요한 경우 인시던트 사례를 생성하려면 기본값을 선택합니다.
해결 시간: 24시간, 48시간 또는 72시간을 선택합니다. 마지막으로 인시던트 사례가 자동으로 종료되는 시점을 구성합니다. 마지막 사례 대응의 시간이 구성된 이후 해결 값에 도달하면 인시던트가 종료됩니다.
경고 알림
알림 처리의 일환으로 영향 분석을 기반으로 AWS Managed Services(AMS)는 인시던트를 생성하고 영향을 확인할 수 있는 문제 해결을 위한 인시던트 관리 프로세스를 시작합니다. 영향을 확인할 수 없는 경우 AMS는 서비스 알림을 통해 계정과 연결된 이메일 주소로 알림 알림을 보냅니다. 일부 시나리오에서는이 알림이 전송되지 않습니다. 예를 들어 인프라 관련 검사가 높은 CPU 사용률 알림을 통과하면 알림이 전송되지 않습니다. 자세한 내용은의 알림 처리 프로세스를 위한 AMS 모니터링 아키텍처 다이어그램을 참조하세요모니터링 작동 방식.
태그 기반 알림
태그를 사용하여 리소스에 대한 알림 알림을 다른 이메일 주소로 보냅니다. 여러 개발자 팀이 동일한 계정을 사용할 때 단일 이메일 주소로 전송된 알림으로 인해 혼동이 발생할 수 있으므로 태그 기반 알림은 사용하는 것이 가장 좋습니다. 태그 기반 알림은 선택한 EC2 인스턴스 그룹화된 알림 설정의 영향을 받지 않습니다.
태그 기반 알림으로 다음을 수행할 수 있습니다.
특정 이메일 주소로 알림 전송:
key = OwnerTeamEmail,를 사용하여 특정 이메일 주소로 전송해야 하는 알림이 있는 리소스에 태그를 지정합니다value =.EMAIL_ADDRESS여러 이메일 주소로 알림 전송: 여러 이메일 주소를 사용하려면 쉼표로 구분된 값 목록을 지정합니다. 예,
key =,OwnerTeamEmailvalue =. 값 필드의 총 문자 수는 260자를 초과할 수 없습니다.EMAIL_ADDRESS_1,EMAIL_ADDRESS_2,EMAIL_ADDRESS_3, ...사용자 지정 태그 키 사용: 사용자 지정 태그 키를 사용하려면 태그 기반 통신에 대한 자동 알림을 활성화하는 데 명시적으로 동의하는 이메일에 사용자 지정 태그 키 이름을 CSDM에 제공합니다. 모든 인스턴스와 리소스에서 고객 응대 태그에 동일한 태그 지정 전략을 사용하는 것이 가장 좋습니다.
참고
키 값 OwnerTeamEmail은 카멜 형식일 필요는 없습니다. 그러나 태그는 대/소문자를 구분하므로 권장 형식을 사용하는 것이 좋습니다.
이메일 주소는 도메인에서 로컬 부분을 분리하려면 "at sign"(@)을 사용하여 완전히 지정해야 합니다. 잘못된 이메일 주소의 예: Team.AppATabc.xyz 또는 john.doe. 태그 지정 전략에 대한 일반적인 지침은 AWS 리소스 태그 지정을 참조하세요. 태그에 개인 식별 정보(PII)를 추가하지 마세요. 가능하면 배포 목록 또는 별칭을 사용합니다.
태그 기반 알림은 EC2, Elastic Block Store(EBS), Elastic Load Balancing(ELB), Application Load Balancer(ALB), Network Load Balancer, Relational Database Service(RDS), OpenSearch, Elastic File System(EFS), FSx 및 Site-to-Site VPN과 같은 Amazon 서비스의 리소스에 대해 지원됩니다.
