권장되는 경보

측정 기준: ApiName, 스테이지

경보 설명: 이 경보는 높은 비율의 클라이언트 측 오류를 감지합니다. 이는 권한 부여 또는 클라이언트 요청 매개변수에 문제가 있음을 의미할 수 있습니다. 리소스가 제거되었거나 클라이언트가 존재하지 않는 리소스를 요청하고 있음을 의미할 수도 있습니다. CloudWatch Logs를 활성화하고 4XX 오류의 원인이 될 수 있는 오류가 있는지 확인해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 리소스 및 방법별로 이 지표를 확인하고 오류의 원인을 좁히는 것도 고려해 보세요. 구성된 제한 한도를 초과하여 오류가 발생할 수도 있습니다. 응답 및 로그에서 예상치 못한 오류가 429개라는 높은 비율로 보고되는 경우 이 가이드에 따라 문제를 해결하세요.

인텐트: 이 경보는 API Gateway 요청에 대해 높은 비율의 클라이언트 측 오류를 탐지할 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 제안된 임곗값은 전체 요청의 5% 이상에서 4XX 오류가 발생하는 경우를 감지합니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 4XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ApiName, 스테이지

경보 설명: 이 경보는 높은 비율의 서버 측 오류 감지에 도움이 됩니다. 이는 API 백엔드, 네트워크 또는 API 게이트웨이와 백엔드 API 간의 통합에 문제가 있음을 나타낼 수 있습니다. 이 설명서는 5xx 오류의 원인을 해결하는 데 도움이 될 수 있습니다.

인텐트: 이 경보는 API Gateway 요청에 대해 높은 비율의 서버 측 오류를 탐지할 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 제안된 임곗값은 전체 요청의 5% 이상에서 5XX 오류가 발생하는 경우를 감지합니다. 그러나 허용 가능한 오류 발생률뿐만 아니라 요청의 트래픽에 따라 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대한 허용 가능한 오류 발생율을 확인한 다음 그에 따라 임곗값을 조정할 수도 있습니다. 자주 발생하는 5XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ApiName, 스테이지

경보 설명: 이 경보는 REST API 단계에서 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 잘못된 엔드포인트 사용과 같이 API를 호출하는 애플리케이션과 관련된 문제를 나타내는 지표일 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.

인텐트: 이 경보는 REST API 단계에서 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 요청을 수신하는 경우 이 경보를 생성하는 것이 좋습니다. 자세한 CloudWatch 지표를 활성화하고 방법 및 리소스별 정상 트래픽 볼륨을 예측할 수 있는 경우, 각 리소스 및 방법에 대한 트래픽 볼륨 감소를 보다 세밀하게 모니터링할 수 있도록 대체 경보를 생성하는 것이 좋습니다. 이 경보는 일정하고 일관된 트래픽이 예상되지 않는 API에는 권장되지 않습니다.

통계: SampleCount

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 요청 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: ApiName, 스테이지, 리소스, 방법

경보 설명: 이 경보는 해당 스테이지에서 REST API 리소스 및 방법에 대해 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 잘못된 엔드포인트 사용과 같이 API를 호출하는 애플리케이션과 관련된 문제를 나타내는 지표일 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.

인텐트: 이 경보는 해당 단계의 REST API 리소스 및 방법에 대해 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 요청을 수신하는 경우 이 경보를 생성하는 것이 좋습니다. 이 경보는 일정하고 일관된 트래픽이 예상되지 않는 API에는 권장되지 않습니다.

통계: SampleCount

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 요청 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: ApiId, 스테이지

경보 설명: 이 경보는 HTTP API 단계에서 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 잘못된 엔드포인트 사용과 같이 API를 호출하는 애플리케이션과 관련된 문제를 나타내는 지표일 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.

인텐트: 이 경보는 HTTP API 단계에서 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 요청을 수신하는 경우 이 경보를 생성하는 것이 좋습니다. 자세한 CloudWatch 지표를 활성화하고 경로별 정상 트래픽 볼륨을 예측할 수 있는 경우, 각 경로에 대한 트래픽 볼륨 감소를 보다 세밀하게 모니터링할 수 있도록 대체 경보를 생성하는 것이 좋습니다. 이 경보는 일정하고 일관된 트래픽이 예상되지 않는 API에는 권장되지 않습니다.

통계: SampleCount

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 요청 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: ApiId, 스테이지, 리소스, 방법

경보 설명: 이 경보는 해당 단계의 HTTP API에 대해 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 잘못된 엔드포인트 사용과 같이 API를 호출하는 애플리케이션과 관련된 문제를 나타내는 지표일 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.

인텐트: 이 경보는 해당 스테이지에서 HTTP API 경로에 대해 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 요청을 수신하는 경우 이 경보를 생성하는 것이 좋습니다. 이 경보는 일정하고 일관된 트래픽이 예상되지 않는 API에는 권장되지 않습니다.

통계: SampleCount

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 요청 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: ApiId, 스테이지

경보 설명: 이 경보는 스테이지에서 API 요청에 대한 통합 지연 시간이 높은지 감지하는 데 도움이 됩니다. IntegrationLatency 지표 값을 백엔드의 해당 지연 시간 지표(예: Lambda 통합에 대한 Duration 지표)와 상호 연관시킬 수 있습니다. 이를 통해 성능 문제로 인해 API 백엔드가 클라이언트의 요청을 처리하는 데 더 오랜 시간이 걸리는지 또는 초기화 또는 콜드 시작으로 인해 다른 오버헤드가 발생하는지 확인할 수 있습니다. 또한 API에 CloudWatch Logs를 활성화하고 로그에서 높은 지연 시간 문제를 일으킬 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 또한 통합 지연 시간의 원인을 좁히는 데 도움이 되도록 상세한 CloudWatch 지표를 활성화하고 경로별로 이 지표를 확인하는 것도 고려해 보세요.

인텐트: 이 경보는 스테이지의 API Gateway 요청에서 통합 지연 시간이 긴 경우를 감지할 수 있습니다. WebSocket API에는 이 경보를 사용하는 것이 좋으며, HTTP API에는 지연 시간 지표에 대한 별도의 경보 권장 사항이 이미 있으므로 HTTP API의 경우 선택 사항으로 간주합니다. 자세한 CloudWatch 지표를 활성화하고 경로별로 통합 지연 시간 성능 요구 사항이 다른 경우, 각 경로의 통합 지연 시간을 보다 세밀하게 모니터링하려면 대체 경보를 생성하는 것이 좋습니다.

통계: p90

권장 임곗값: 2000.0

임곗값 정당화: 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 그러나 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: ApiId, 스테이지, 경로

경보 설명: 이 경보는 스테이지에서 경로에 대한 WebSocket API 요청의 통합 지연 시간이 높은지 감지하는 데 도움이 됩니다. IntegrationLatency 지표 값을 백엔드의 해당 지연 시간 지표(예: Lambda 통합에 대한 Duration 지표)와 상호 연관시킬 수 있습니다. 이를 통해 성능 문제로 인해 API 백엔드가 클라이언트의 요청을 처리하는 데 더 오랜 시간이 걸리는지 또는 초기화 또는 콜드 시작으로 인해 다른 오버헤드가 발생하는지 확인할 수 있습니다. 또한 API에 CloudWatch Logs를 활성화하고 로그에서 높은 지연 시간 문제를 일으킬 수 있는 오류가 있는지 확인하는 것도 고려해 보세요.

인텐트: 이 경보는 스테이지의 경로에 대한 API Gateway 요청에서 통합 지연 시간이 긴 경우를 감지할 수 있습니다.

통계: p90

권장 임곗값: 2000.0

임곗값 정당화: 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 그러나 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: ApiName, 스테이지

경보 설명: 이 경보는 스테이지에서 높은 지연 시간을 감지합니다. IntegrationLatency 지표 값을 찾아 API 백엔드 지연 시간을 확인하세요. 두 지표가 대부분 일치하면 API 백엔드가 지연 시간 증가의 원인이므로 문제가 있는지 조사해야 합니다. CloudWatch Logs를 활성화하고 긴 지연 시간을 유발할 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 리소스 및 방법별로 이 지표를 확인하고 지연 시간의 원인을 좁히는 것도 고려해 보세요. 해당하는 경우 Lambda를 사용한 문제 해결 또는 엣지 최적화 API 엔드포인트 문제 해결 가이드를 참조하세요.

인텐트: 이 경보는 스테이지의 API Gateway 요청에서 지연 시간이 긴 경우를 감지할 수 있습니다. 자세한 CloudWatch 지표를 활성화하고 각 방법 및 리소스에 대한 지연 시간 성능 요구 사항이 다른 경우, 각 리소스 및 방법의 지연 시간을 보다 세밀하게 모니터링하려면 대체 경보를 생성하는 것이 좋습니다.

통계: p90

권장 임곗값: 2500.0

임곗값 정당화: 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 그러나 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: ApiName, 스테이지, 리소스, 방법

경보 설명: 이 경보는 스테이지에서 리소스와 방법에 대해 높은 지연 시간을 감지합니다. IntegrationLatency 지표 값을 찾아 API 백엔드 지연 시간을 확인하세요. 두 지표가 대부분 일치하면 API 백엔드가 지연 시간 증가의 원인이므로 성능 문제가 있는지 조사해야 합니다. CloudWatch Logs를 활성화하고 긴 지연 시간을 유발할 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 해당하는 경우 Lambda를 사용한 문제 해결 또는 엣지 최적화 API 엔드포인트 문제 해결 가이드를 참조하세요.

인텐트: 이 경보는 스테이지의 API Gateway 요청에서 리소스와 방법에 대해 지연 시간이 긴 경우를 감지할 수 있습니다.

통계: p90

권장 임곗값: 2500.0

임곗값 정당화: 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 그러나 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: ApiId, 스테이지

경보 설명: 이 경보는 스테이지에서 높은 지연 시간을 감지합니다. IntegrationLatency 지표 값을 찾아 API 백엔드 지연 시간을 확인하세요. 두 지표가 대부분 일치하면 API 백엔드가 지연 시간 증가의 원인이므로 성능 문제가 있는지 조사해야 합니다. CloudWatch Logs를 활성화하고 긴 지연 시간을 유발할 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 경로별로 이 지표를 확인하고 지연 시간의 원인을 좁히는 것도 고려해 보세요. 해당하는 경우 Lambda 통합을 사용한 문제 해결 가이드도 참조할 수 있습니다.

인텐트: 이 경보는 스테이지의 API Gateway 요청에서 지연 시간이 긴 경우를 감지할 수 있습니다. 자세한 CloudWatch 지표를 활성화하고 경로별로 지연 시간 성능 요구 사항이 다른 경우, 각 경로의 지연 시간을 보다 세밀하게 모니터링하려면 대체 경보를 생성하는 것이 좋습니다.

통계: p90

권장 임곗값: 2500.0

임곗값 정당화: 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 하지만 이 값을 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮출 수 있습니다. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: ApiId, 스테이지, 리소스, 방법

경보 설명: 이 경보는 스테이지에서 경로에 대해 높은 지연 시간을 감지합니다. IntegrationLatency 지표 값을 찾아 API 백엔드 지연 시간을 확인하세요. 두 지표가 대부분 일치하면 API 백엔드가 지연 시간 증가의 원인이므로 성능 문제가 있는지 조사해야 합니다. CloudWatch Logs를 활성화하고 긴 지연 시간을 유발할 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 해당하는 경우 Lambda 통합을 사용한 문제 해결 가이드도 참조할 수 있습니다.

인텐트: 이 경보는 스테이지의 경로에 대한 API Gateway 요청에서 지연 시간이 긴 경우를 감지할 수 있습니다.

통계: p90

권장 임곗값: 2500.0

임곗값 정당화: 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 하지만 이 값을 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: ApiId, 스테이지

경보 설명: 이 경보는 높은 비율의 클라이언트 측 오류를 감지합니다. 이는 권한 부여 또는 클라이언트 요청 매개변수에 문제가 있음을 의미할 수 있습니다. 경로가 제거되었거나 클라이언트가 API에 없는 경로를 요청하고 있음을 의미할 수도 있습니다. CloudWatch Logs를 활성화하고 4xx 오류의 원인이 될 수 있는 오류가 있는지 확인해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 경로별로 이 지표를 확인하고 오류의 원인을 좁히는 것도 고려해 보세요. 구성된 제한 한도를 초과하여 오류가 발생할 수도 있습니다. 응답 및 로그에서 예상치 못한 오류가 429개라는 높은 비율로 보고되는 경우 이 가이드에 따라 문제를 해결하세요.

인텐트: 이 경보는 API Gateway 요청에 대해 높은 비율의 클라이언트 측 오류를 탐지할 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 제안된 임곗값은 전체 요청의 5% 이상에서 4xx 오류가 발생하는 경우를 감지합니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 4xx 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ApiId, 스테이지

경보 설명: 이 경보는 높은 비율의 서버 측 오류 감지에 도움이 됩니다. 이는 API 백엔드, 네트워크 또는 API 게이트웨이와 백엔드 API 간의 통합에 문제가 있음을 나타낼 수 있습니다. 이 설명서는 5xx 오류의 원인을 해결하는 데 도움이 될 수 있습니다.

인텐트: 이 경보는 API Gateway 요청에 대해 높은 비율의 서버 측 오류를 탐지할 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 제안된 임곗값은 전체 요청의 5% 이상에서 5xx 오류가 발생하는 경우를 감지합니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 5xx 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ApiId, 스테이지

경보 설명: 이 경보는 WebSocket API 단계에서 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 클라이언트가 API를 호출할 때 잘못된 엔드포인트 사용 문제 또는 백엔드에서 클라이언트에 메시지를 보내는 데 문제가 있음을 나타낼 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.

인텐트: 이 경보는 WebSocket API 단계에서 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 메시지를 수신 및 전송하는 경우 이 경보를 생성하는 것이 좋습니다. 자세한 CloudWatch 지표를 활성화하고 경로별 정상 트래픽 볼륨을 예측할 수 있는 경우, 각 경로에 대한 트래픽 볼륨 감소를 보다 세밀하게 모니터링할 수 있도록 대체 경보를 생성하는 것이 좋습니다. 일정하고 일관된 트래픽이 예상되지 않는 API에는 이 경보를 권장하지 않습니다.

통계: SampleCount

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 메시지 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: ApiId, 스테이지, 경로

경보 설명: 이 경보는 해당 스테이지에서 WebSocket API 경로에 대해 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 클라이언트가 API를 호출할 때 잘못된 엔드포인트 사용 문제 또는 백엔드에서 클라이언트에 메시지를 보내는 데 문제가 있음을 나타낼 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.

인텐트: 이 경보는 해당 스테이지에서 WebSocket API 경로에 대해 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 메시지를 수신 및 전송하는 경우 이 경보를 생성하는 것이 좋습니다. 일정하고 일관된 트래픽이 예상되지 않는 API에는 이 경보를 권장하지 않습니다.

통계: SampleCount

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 메시지 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: ApiId, 스테이지

경보 설명: 이 경보는 높은 비율의 클라이언트 오류를 감지합니다. 이는 권한 부여 또는 메시지 매개변수에 문제가 있음을 의미할 수 있습니다. 경로가 제거되었거나 클라이언트가 API에 없는 경로를 요청하고 있음을 의미할 수도 있습니다. CloudWatch Logs를 활성화하고 4xx 오류의 원인이 될 수 있는 오류가 있는지 확인해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 경로별로 이 지표를 확인하고 오류의 원인을 좁히는 것도 고려해 보세요. 구성된 제한 한도를 초과하여 오류가 발생할 수도 있습니다. 응답 및 로그에서 예상치 못한 오류가 429개라는 높은 비율로 보고되는 경우 이 가이드에 따라 문제를 해결하세요.

인텐트: 이 경보는 WebSocket API Gateway 메시지에 대해 높은 비율의 클라이언트 오류를 탐지할 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 제안된 임곗값은 전체 요청의 5% 이상에서 4xx 오류가 발생하는 경우를 감지합니다. 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 4xx 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ApiId, 스테이지

경보 설명: 이 경보는 높은 비율의 실행 오류 감지에 도움이 됩니다. 이는 통합으로 인한 5xx 오류, 권한 문제 또는 통합의 성공적인 호출을 방해하는 기타 요인(예: 통합이 제한 또는 삭제되는 경우)이 원인일 수 있습니다. API의 CloudWatch Logs를 활성화하고 로그에서 오류의 유형과 원인을 확인해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 경로별로 이 지표를 확인하고 오류의 원인을 좁히는 것도 고려해 보세요. 이 설명서는 모든 연결 오류의 원인을 해결하는 데 도움이 될 수 있습니다.

인텐트: 이 경보는 WebSocket API Gateway 메시지에 대해 높은 비율의 실행 오류를 탐지할 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 제안된 임곗값은 전체 요청의 5% 이상에서 실행 오류가 발생하는 경우를 감지합니다. 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 실행 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: AutoScalingGroupName

경보 설명: 이 경보는 그룹의 용량이 워크로드에 필요한 용량보다 낮을 경우 이를 감지하는 데 도움이 됩니다. 문제를 해결하려면 조정 활동에서 시작 실패가 있는지 확인하고 원하는 용량 구성이 올바른지 확인하세요.

인텐트: 이 경보는 Auto Scaling 그룹에서 시작 실패 또는 시작 일시 중단으로 인한 낮은 가용성을 감지할 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 임곗값은 워크로드 실행에 필요한 최소 용량이어야 합니다. 대부분의 경우 이 값을 GroupDesiredCapacity 지표와 일치하도록 설정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: LESS_THAN_THRESHOLD

차원: CertificateArn

경보 설명: 이 경보는 ACM에서 관리하거나 ACM으로 가져온 인증서가 만료 날짜에 가까워지는 시기를 감지하는 데 도움이 됩니다. 이를 통해 서비스 중단을 초래할 수 있는 예기치 않은 인증서 만료를 방지할 수 있습니다. 경보가 ‘경보’ 상태로 전환되면 즉각적인 조치를 취하여 인증서를 갱신하거나 다시 가져와야 합니다. ACM 관리형 인증서에 대한 내용은 인증서 갱신 프로세스의 지침을 참조하세요. 가져온 인증서는 다시 가져오기 프로세스의 지침을 참조하세요.

의도: 이 경보는 다가올 인증서 만료에 대해 사전에 알릴 수 있습니다. 충분한 사전 알림이 제공되어 수동 개입이 가능하므로, 인증서가 만료되기 전에 갱신하거나 교체할 수 있습니다. 이렇게 하면 TLS 지원 서비스의 보안 및 가용성을 유지할 수 있습니다. ‘경보’로 전환되면 인증서 상태를 즉시 조사하고, 필요한 경우 갱신 프로세스를 시작합니다.

통계: Minimum

권장 임곗값: 44.0

임곗값 근거: 44일 임곗값으로 조기 경고와 잘못된 경보 방지 기능이 서로 균형을 이룰 수 있도록 합니다. 자동 갱신이 실패할 경우 수동 개입을 할 수 있을 만한 충분한 시간이 주어집니다. 인증서 갱신 프로세스 및 운영 응답 시간에 따라 이 값을 조정합니다.

기간: 86400

경보를 보낼 데이터 포인트: 1

평가 기간: 1

비교 연산자: LESS_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: DistributionId, Region=Global

경보 설명: 이 경보는 오리진 서버의 5xx 오류 응답 비율을 모니터링하여 CloudFront 서비스에 문제가 있는지 감지하는 데 도움이 됩니다. 서버 관련 문제를 이해하는 데 도움이 되는 오리진의 오류 응답 문제 해결을 참조하세요. 또한 추가 메트릭을 활성화하고 자세한 오류 메트릭을 확인하세요.

인텐트: 이 경보는 오리진 서버의 요청 처리 문제 또는 CloudFront와 오리진 서버 간의 통신 문제를 감지하는 데 사용됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 5xx 응답의 허용 오차에 따라 크게 달라집니다. 과거 데이터와 추세를 분석한 다음 그에 따라 임곗값을 설정할 수 있습니다. 5xx 오류는 일시적인 문제로 인해 발생할 수 있으므로 경보가 너무 민감하지 않도록 임곗값을 0보다 큰 값으로 설정하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: DistributionId, Region=Global

경보 설명: 경보는 오리진 서버가 응답하는 데 시간이 너무 오래 걸리는지 모니터링하는 데 도움이 됩니다. 서버가 응답하는 데 시간이 너무 오래 걸리면 타임아웃이 발생할 수 있습니다. 지속적으로 높은 OriginLatency 값이 발생하는 경우 오리진 서버의 애플리케이션에서 지연된 응답을 찾아서 수정하기를 참조하세요.

인텐트: 이 경보는 오리진 서버가 응답하는 데 시간이 너무 오래 걸리는 문제를 감지하는 데 사용됩니다.

통계: p90

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 오리진 응답 제한 시간의 약 80% 값을 계산하고 그 결과를 임곗값으로 사용해야 합니다. 이 지표가 오리진 응답 제한 시간 값에 지속적으로 근접할 경우 504 오류가 발생할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: DistributionId, FunctionName, Region=Global

경보 설명: 이 경보는 CloudFront Functions의 검증 오류를 모니터링하여 오류를 해결하기 위한 조치를 취할 수 있도록 도와줍니다. CloudWatch 함수 로그를 분석하고 함수 코드를 검토하여 문제의 근본 원인을 찾아 해결합니다. CloudFront Functions의 일반적인 구성 오류를 이해하려면 엣지 함수에 대한 제한을 참조하세요.

인텐트: 이 경보는 CloudFront Functions의 검증 오류를 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: 0보다 큰 값은 검증 오류를 나타냅니다. 검증 오류는 CloudFront Functions를 CloudFront로 넘겨줄 때 문제가 있다는 것을 의미하므로 임곗값을 0으로 설정하는 것이 좋습니다. 예를 들어 CloudFront는 요청을 처리하기 위해 HTTP 호스트 헤더가 필요합니다. 사용자가 CloudFront Functions 코드에서 호스트 헤더를 삭제하는 것을 막을 방법은 없습니다. 하지만 CloudFront가 응답을 받고 호스트 헤더가 누락된 경우 CloudFront에서 검증 오류가 발생합니다.

기간: 60

경보를 보낼 데이터 포인트: 2

평가 기간: 2

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: DistributionId, FunctionName, Region=Global

경보 설명: 이 경보는 CloudFront Functions의 실행 오류를 모니터링하여 오류를 해결하기 위한 조치를 취할 수 있도록 도와줍니다. CloudWatch 함수 로그를 분석하고 함수 코드를 검토하여 문제의 근본 원인을 찾아 해결합니다.

인텐트: 이 경보는 CloudFront Functions의 실행 오류를 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: 실행 오류는 런타임에 발생하는 코드에 문제가 있음을 나타내므로 임곗값을 0으로 설정하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: DistributionId, FunctionName, Region=Global

경보 설명: 이 경보는 CloudFront Functions의 제한 여부를 모니터링하는 데 도움이 됩니다. 함수가 제한되면 실행 시간이 너무 오래 걸린다는 의미입니다. 함수 제한을 방지하려면 함수 코드를 최적화하는 것이 좋습니다.

인텐트: 이 경보는 문제에 대응하고 해결하여 원활한 고객 경험을 제공할 수 있도록 CloudFront Functions가 제한되는 시점을 감지합니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: 함수 제한 문제를 더 빨리 해결할 수 있도록 임곗값을 0으로 설정하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: UserPool, UserPoolClient

경보 설명: 이 경보는 제한이 발생한 요청 수를 모니터링합니다. 사용자가 지속적으로 병목 현상을 겪는 경우 서비스 할당량 증가를 요청하여 한도를 늘려야 합니다. 할당량 증가를 요청하는 방법은 Amazon Cognito의 할당량 섹션을 참조하세요. 사전 조치를 취하려면 사용 할당량 추적을 고려해 보세요.

인텐트: 이 경보는 제한된 가입 요청의 발생을 모니터링하는 데 도움이 됩니다. 가입 경험의 저하를 완화하기 위한 조치를 언제 실행해야 하는지 알 수 있습니다. 지속적인 요청 제한은 사용자의 가입 경험에 부정적인 영향을 미칩니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 제대로 프로비저닝된 사용자 풀에서는 여러 데이터 포인트에 걸쳐 제한이 발생하지 않아야 합니다. 따라서 예상 워크로드의 일반적인 임곗값은 0이어야 합니다. 버스트가 빈번하고 불규칙한 워크로드의 경우 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 결정한 다음 그에 따라 임곗값을 조정할 수 있습니다. 제한이 발생한 요청은 다시 시도하여 애플리케이션에 미치는 영향을 최소화해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: UserPool, UserPoolClient

경보 설명: 이 경보는 제한이 발생한 사용자 인증 요청 수를 모니터링합니다. 사용자가 지속적으로 병목 현상을 겪는 경우 서비스 할당량 증가를 요청하여 한도를 늘려야 할 수 있습니다. 할당량 증가를 요청하는 방법은 Amazon Cognito의 할당량 섹션을 참조하세요. 사전 조치를 취하려면 사용 할당량 추적을 고려해 보세요.

인텐트: 이 경보는 제한된 가입 요청의 발생을 모니터링하는 데 도움이 됩니다. 가입 경험의 저하를 완화하기 위한 조치를 언제 실행해야 하는지 알 수 있습니다. 지속적인 요청 제한은 부정적인 사용자 인증 경험입니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 제대로 프로비저닝된 사용자 풀에서는 여러 데이터 포인트에 걸쳐 제한이 발생하지 않아야 합니다. 따라서 예상 워크로드의 일반적인 임곗값은 0이어야 합니다. 버스트가 빈번하고 불규칙한 워크로드의 경우 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 결정한 다음 그에 따라 임곗값을 조정할 수 있습니다. 제한이 발생한 요청은 다시 시도하여 애플리케이션에 미치는 영향을 최소화해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: UserPool, UserPoolClient

경보 설명: 요청의 트래픽에 적합하고 토큰 새로 고침 요청의 허용 가능한 제한과 일치하도록 임곗값을 설정할 수 있습니다. 제한은 너무 많은 요청으로부터 시스템을 보호하는 데 사용됩니다. 하지만 정상 트래픽에 대한 프로비저닝이 부족한지 모니터링하는 것도 중요합니다. 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 찾은 다음 경보 임곗값을 허용 가능한 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 민감해질 수 있습니다.

인텐트: 이 경보는 제한된 토큰 새로 고침 요청의 발생을 모니터링하는 데 도움이 됩니다. 이를 통해 잠재적 문제를 완화하고 원활한 사용자 경험과 인증 시스템의 상태 및 안정성을 보장하기 위한 조치를 언제 실행해야 하는지 알 수 있습니다. 지속적인 요청 제한은 부정적인 사용자 인증 경험입니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 요청의 트래픽과 토큰 새로 고침 요청에 대한 허용 가능한 제한에 적합하게 임곗값을 설정/조정할 수 있습니다. 제한은 너무 많은 요청으로부터 시스템을 보호하기 위한 것이지만, 정상 트래픽에 대한 프로비저닝이 부족한지 모니터링하고 이로 인해 제한이 발생하는지 확인하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 확인하고, 임곗값을 일반적인 허용 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 민감해질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: UserPool, UserPoolClient, IdentityProvider

경보 설명: 이 경보는 제한이 발생한 ID 페더레이션 요청 수를 모니터링합니다. 제한이 지속적으로 발생하는 경우 서비스 할당량 증가를 요청하여 한도를 늘려야 할 수 있습니다. 할당량 증가를 요청하는 방법은 Amazon Cognito의 할당량 섹션을 참조하세요.

인텐트: 이 경보는 제한된 ID 페더레이션 요청의 발생을 모니터링하는 데 도움이 됩니다. 이를 통해 성능 병목 현상이나 잘못된 구성에 사전 대응하고 사용자에게 원활한 인증 경험을 제공할 수 있습니다. 지속적인 요청 제한은 부정적인 사용자 인증 경험입니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 요청의 트래픽에 적합하고 ID 페더레이션 요청의 허용 가능한 제한과 일치하도록 임곗값을 설정할 수 있습니다. 제한은 너무 많은 요청으로부터 시스템을 보호하는 데 사용됩니다. 하지만 정상 트래픽에 대한 프로비저닝이 부족한지 모니터링하는 것도 중요합니다. 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 찾은 다음 임곗값을 허용 가능한 제한 수준보다 높은 값으로 설정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 민감해질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: 없음

경보 설명: 이 경보는 계정의 읽기 용량이 프로비저닝된 한도에 도달하는지 여부를 감지합니다. 이 경우 읽기 용량 사용량에 대한 계정 할당량을 늘릴 수 있습니다. Service Quotas를 사용하여 읽기 용량 단위의 현재 할당량을 확인하고 증가를 요청할 수 있습니다.

인텐트: 이 경보는 계정의 읽기 용량 사용률이 프로비저닝된 읽기 용량 사용률에 근접하는지 여부를 감지할 수 있습니다. 사용률이 최대 한도에 도달하면 DynamoDB가 읽기 요청을 제한하기 시작합니다.

통계: Maximum

권장 임곗값: 80.0

임곗값 정당화: 임곗값을 80%로 설정하면 최대 용량에 도달하기 전에 계정 한도 상향 조정과 같은 조치를 실행하여 제한을 방지할 수 있습니다.

기간: 300

경보를 보낼 데이터 포인트: 2

평가 기간: 2

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: 없음

경보 설명: 이 경보는 계정의 쓰기 용량이 프로비저닝된 한도에 도달하는지 여부를 감지합니다. 이 경우 쓰기 용량 사용량에 대한 계정 할당량을 늘릴 수 있습니다. Service Quotas를 사용하여 쓰기 용량 단위의 현재 할당량을 확인하고 증가를 요청할 수 있습니다.

인텐트: 이 경보는 계정의 쓰기 용량 사용률이 프로비저닝된 쓰기 용량 사용률에 근접하는지 여부를 감지할 수 있습니다. 사용률이 최대 한도에 도달하면 DynamoDB가 쓰기 요청을 제한하기 시작합니다.

통계: Maximum

권장 임곗값: 80.0

임곗값 정당화: 임곗값을 80%로 설정하면 최대 용량에 도달하기 전에 계정 한도 상향 조정과 같은 조치를 실행하여 제한을 방지할 수 있습니다.

기간: 300

경보를 보낼 데이터 포인트: 2

평가 기간: 2

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TableName, DelegatedOperation

경보 설명: 이 경보는 Kinesis 데이터 스트림으로의 복제에서 지연을 감지합니다. 정상 작동 시 AgeOfOldestUnreplicatedRecord는 밀리초 단위여야 합니다. 이 수는 실패한 복제 시도가 고객이 제어하는 구성 선택으로 인해 발생한 경우 시도 횟수를 기준으로 증가합니다. 복제 시도 실패로 이어질 수 있는 고객이 제어하는 구성의 예로는 Kinesis 데이터 스트림 용량이 과소 프로비저닝되어 과도한 제한이 발생하는 경우 또는 Kinesis 데이터 스트림의 액세스 정책을 수동으로 업데이트하여 DynamoDB가 데이터 스트림에 데이터를 추가하지 못하는 경우가 있습니다. 이 지표를 가능한 한 낮게 유지하려면 적절한 Kinesis 데이터 스트림 용량을 프로비저닝하고 DynamoDB의 권한이 변경되지 않도록 해야 합니다.

인텐트: 이 경보는 실패한 복제 시도와 그에 따른 Kinesis 데이터 스트림으로의 복제 지연을 모니터링할 수 있습니다.

통계: Maximum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 밀리초 단위로 측정된 원하는 복제 지연에 따라 임곗값을 설정합니다. 이 값은 워크로드의 요구 사항 및 예상 성능에 따라 달라집니다.

기간: 300

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TableName, DelegatedOperation

경보 설명: 이 경보는 DynamoDB가 Kinesis 데이터 스트림으로 복제하지 못한 레코드 수를 감지합니다. 34KB보다 큰 특정 항목은 Kinesis Data Streams의 1MB 항목 크기 제한보다 큰 데이터 레코드를 변경하기 위해 크기가 확장될 수 있습니다. 이 크기 확장은 34KB보다 큰 이러한 항목에 많은 수의 부울 또는 빈 속성 값을 포함할 때 발생합니다. 부울 및 빈 속성 값은 DynamoDB에 1바이트로 저장되지만, Kinesis Data Streams 복제를 위한 표준 JSON을 사용하여 직렬화되면 최대 5바이트까지 확장합니다. DynamoDB는 이러한 변경 레코드를 Kinesis 데이터 스트림에 복제할 수 없습니다. DynamoDB는 이러한 변경 데이터 레코드를 건너뛰고 자동으로 후속 레코드의 복제를 계속합니다.

인텐트: 이 경보는 Kinesis 데이터 스트림의 항목 크기 제한 때문에 DynamoDB가 Kinesis 데이터 스트림에 복제하지 못한 레코드 수를 모니터링할 수 있습니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: DynamoDB가 복제에 실패한 모든 레코드를 감지하려면 임곗값을 0으로 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 1

평가 기간: 1

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TableName

경보 설명: 이 경보는 DynamoDB 테이블에 대해 제한이 발생하는 읽기 요청 수가 많은지 여부를 감지합니다. 문제를 해결하려면 Amazon DynamoDB의 제한 문제 해결을 참조하세요.

인텐트: 이 경보는 DynamoDB 테이블에 대한 읽기 요청의 지속적인 제한을 감지할 수 있습니다. 읽기 요청의 지속적인 제한은 워크로드 읽기 작업에 부정적인 영향을 미치고 시스템의 전반적인 효율성을 감소시킬 수 있습니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 허용 가능한 제한 수준을 고려하여 DynamoDB 테이블의 예상 읽기 트래픽에 따라 임곗값을 설정합니다. 프로비저닝이 부족하고 일관된 제한이 발생하지 않는지 모니터링하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한 수준을 찾은 다음 임곗값을 일반적인 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션 또는 서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 항목: TableName, GlobalSecondaryIndexName

경보 설명: 이 경보는 DynamoDB 테이블의 글로벌 보조 인덱스에 대해 제한이 발생하는 읽기 요청 수가 많은지 여부를 감지합니다. 문제를 해결하려면 Amazon DynamoDB의 제한 문제 해결을 참조하세요.

인텐트: 이 경보는 DynamoDB 테이블의 글로벌 보조 인덱스에 대한 읽기 요청의 지속적인 제한을 감지할 수 있습니다. 읽기 요청의 지속적인 제한은 워크로드 읽기 작업에 부정적인 영향을 미치고 시스템의 전반적인 효율성을 감소시킬 수 있습니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 허용 가능한 제한 수준을 고려하여 DynamoDB 테이블의 예상 읽기 트래픽에 따라 임곗값을 설정합니다. 프로비저닝이 부족하고 일관된 제한이 발생하지 않는지 모니터링하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한 수준을 찾은 다음 임곗값을 허용 가능한 일반적인 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션 또는 서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TableName, ReceivingRegion

경보 설명: 경보는 글로벌 테이블의 특정 리전에 있는 복제본이 소스 리전보다 뒤처지는지 감지합니다. AWS 리전의 성능이 저하되고 해당 리전에 복제 테이블이 있는 경우에 지연 시간이 증가할 수 있습니다. 이 경우 애플리케이션의 읽기 및 쓰기 작업을 다른 AWS 리전으로 일시적으로 리디렉션할 수 있습니다. 2017.11.29(레거시)의 글로벌 테이블을 사용하는 경우 각 복제 테이블의 WCU(쓰기 용량 단위)가 동일한지 확인해야 합니다. 용량 관리를 위한 모범 사례 및 요구 사항의 권장 사항을 따를 수도 있습니다.

인텐트: 경보는 특정 리전의 복제 테이블이 다른 리전의 변경 내용을 복제하는 데 뒤쳐지는지 여부를 감지할 수 있습니다. 이로 인해 복제본이 다른 복제본과 다를 수 있습니다. 각 AWS 리전의 복제 지연 시간을 알고 복제 지연 시간이 계속 증가할 경우 알림을 보내는 것이 좋습니다. 테이블 복제는 글로벌 테이블에만 적용됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 사용 사례에 따라 크게 달라집니다. 일반적으로 3분이 넘는 복제 지연 시간은 조사 원인입니다. 복제 지연의 심각도와 요구 사항을 검토하고 과거 추세를 분석한 다음 그에 따라 임곗값을 선택합니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TableName, Operation

경보 설명: 이 경보는 DynamoDB 테이블 작업(경보에서 Operation의 차원 값으로 표시됨)에서 높은 지연 시간을 감지합니다. Amazon DynamoDB의 지연 시간 문제를 해결하려면 문제 해결 문서를 참조하세요.

인텐트: 이 경보는 DynamoDB 테이블 작업의 높은 지연 시간을 감지할 수 있습니다. 작업 지연 시간이 길어지면 시스템의 전체 효율성에 부정적인 영향을 미칠 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: DynamoDB는 GetItem, PutItem 등과 같은 싱글톤 작업에 대해 평균적으로 10밀리초 미만의 지연 시간을 지원합니다. 하지만 워크로드와 관련된 작업 유형 및 테이블의 지연 시간에 대한 허용 가능한 허용 오차를 기반으로 임곗값을 설정할 수 있습니다. 이 지표의 과거 데이터를 분석하여 테이블 작업에 대한 일반적인 지연 시간을 찾은 다음 임곗값을 작업의 심각한 지연을 나타내는 숫자로 설정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TableName

경보 설명: 이 경보는 DynamoDB 테이블 요청에서 지속적으로 많은 시스템 오류를 감지합니다. 5xx 오류가 계속 발생하면 AWS서비스 상태 대시보드를 열어 서비스와 관련된 운영 문제를 확인하세요. 이 경보를 사용하면 DynamoDB에서 장기간 내부 서비스 문제가 발생하는 경우 알림을 받을 수 있으며, 이를 통해 클라이언트 애플리케이션이 직면하고 있는 문제와의 상관 관계를 파악할 수 있습니다. 자세한 내용은 DynamoDB 오류 처리를 참조하세요.

인텐트: 이 경보는 DynamoDB 테이블 요청에 대한 지속적인 시스템 오류를 감지할 수 있습니다. 시스템 오류는 DynamoDB의 내부 서비스 오류를 나타내며 클라이언트가 겪고 있는 문제와의 상관 관계를 파악하는 데 도움이 됩니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 허용 가능한 시스템 오류 수준을 고려하여 예상 트래픽에 따라 임곗값을 설정합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 수를 찾은 다음 그에 따라 임곗값을 조정할 수 있습니다. 시스템 오류는 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TableName, DelegatedOperation

경보 설명: 이 경보는 변경 데이터 캡처를 Kinesis로 복제하는 동안 Kinesis 데이터 스트림에 의해 제한되는 레코드를 감지합니다. 이러한 제한은 Kinesis 데이터 스트림 용량이 충분하지 않기 때문에 발생합니다. 제한이 지나치게 많고 자주 발생하는 경우 관찰된 테이블의 쓰기 처리량에 비례하여 Kinesis 스트림 샤드 수를 늘려야 할 수 있습니다. Kinesis 데이터 스트림의 크기 결정에 대한 자세한 내용은 Kinesis 데이터 스트림의 초기 크기 결정을 참조하세요.

인텐트: 이 경보는 Kinesis 데이터 스트림 용량이 부족하여 Kinesis 데이터 스트림에 의해 제한된 레코드 수를 모니터링할 수 있습니다.

통계: Maximum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 예외적으로 사용량이 최고조에 달할 때 약간의 제한이 발생할 수 있지만, 복제 지연 시간이 길어지지 않도록 제한된 레코드 수를 가능한 한 낮게 유지해야 합니다(DynamoDB가 Kinesis 데이터 스트림으로 제한된 레코드의 전송을 다시 시도). 정기적으로 과도한 제한을 포착하는 데 도움이 될 수 있는 숫자로 임곗값을 설정합니다. 또한 이 지표의 과거 데이터를 분석하여 애플리케이션 워크로드에 적합한 제한 속도를 찾을 수 있습니다. 사용 사례에 따라 애플리케이션에서 허용할 수 있는 값으로 임곗값을 조정합니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: 없음

경보 설명: 이 경보는 DynamoDB 테이블 요청에서 지속적으로 많은 사용자 오류를 감지합니다. 문제가 지속되는 동안 클라이언트 애플리케이션 로그를 확인하여 요청이 잘못된 이유를 확인할 수 있습니다. HTTP 상태 코드 400을 확인하여 발생하는 오류 유형을 확인하고 그에 따라 조치를 취할 수 있습니다. 유효한 요청을 생성하려면 애플리케이션 로직을 수정해야 할 수 있습니다.

인텐트: 이 경보는 DynamoDB 테이블 요청에 대한 지속적인 사용자 오류를 감지할 수 있습니다. 요청된 작업에 대한 사용자 오류는 클라이언트가 잘못된 요청을 생성하고 실패했음을 의미합니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 클라이언트 측 오류를 감지하려면 임곗값을 0으로 설정합니다. 또는 매우 적은 수의 오류로 인해 경보가 트리거되지 않게 하려면 더 높은 값으로 설정할 수 있습니다. 요청 시 사용 사례와 트래픽에 따라 결정합니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TableName

경보 설명: 이 경보는 DynamoDB 테이블에 대해 제한이 발생하는 쓰기 요청 수가 많은지 여부를 감지합니다. 문제를 해결하려면 Amazon DynamoDB의 제한 문제 해결을 참조하세요.

인텐트: 이 경보는 DynamoDB 테이블에 대한 쓰기 요청의 지속적인 제한을 감지할 수 있습니다. 쓰기 요청의 지속적인 제한은 워크로드 쓰기 작업에 부정적인 영향을 미치고 시스템의 전반적인 효율성을 감소시킬 수 있습니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 허용 가능한 제한 수준을 고려하여 DynamoDB 테이블의 예상 쓰기 트래픽에 따라 임곗값을 설정합니다. 프로비저닝이 부족하고 일관된 제한이 발생하지 않는지 모니터링하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한 수준을 찾은 다음 임곗값을 허용 가능한 일반적인 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 항목: TableName, GlobalSecondaryIndexName

경보 설명: 이 경보는 DynamoDB 테이블의 글로벌 보조 인덱스에 대해 제한이 발생하는 쓰기 요청 수가 많은지 여부를 감지합니다. 문제를 해결하려면 Amazon DynamoDB의 제한 문제 해결을 참조하세요.

인텐트: 이 경보는 DynamoDB 테이블의 글로벌 보조 인덱스에 대한 쓰기 요청의 지속적인 제한을 감지할 수 있습니다. 쓰기 요청의 지속적인 제한은 워크로드 쓰기 작업에 부정적인 영향을 미치고 시스템의 전반적인 효율성을 감소시킬 수 있습니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 허용 가능한 제한 수준을 고려하여 DynamoDB 테이블의 예상 쓰기 트래픽에 따라 임곗값을 설정합니다. 프로비저닝이 부족하고 일관된 제한이 발생하지 않는지 모니터링하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한 수준을 찾은 다음 임곗값을 허용 가능한 일반적인 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

차원: VolumeId, InstanceId

경보 설명: 이 경보는 Amazon EBS 볼륨의 IO 성능을 모니터링하는 데 도움이 됩니다. 이 검사는 Amazon EBS 볼륨의 기반이 되는 스토리지 하위 시스템의 하드웨어 또는 소프트웨어 문제, Amazon EC2 인스턴스의 Amazon EBS 볼륨 연결 가능성에 영향을 미치는 물리적 호스트의 하드웨어 문제 등 Amazon EBS 인프라의 근본적인 문제를 탐지하고, 인스턴스와 Amazon EBS 볼륨 간의 연결 문제를 감지할 수 있습니다. 멈춘 IO 검사가 실패하면 AWS에서 문제를 해결할 때까지 기다리거나, 영향을 받는 볼륨을 교체하거나 볼륨이 연결된 인스턴스를 중지하고 다시 시작하는 등의 조치를 취할 수 있습니다. 대부분의 경우 이 지표가 실패하면 Amazon EBS는 몇 분 내에 볼륨을 자동으로 진단하고 복구합니다.

의도: 이 경보는 Amazon EBS 볼륨의 상태를 감지하여 해당 볼륨이 손상되어 I/O 작업을 완료할 수 없게 된 시기를 확인할 수 있습니다.

통계: Maximum

권장 임곗값: 1.0

임곗값 정당화: 상태 확인이 실패하면 이 지표의 값은 1입니다. 임곗값은 상태 확인이 실패할 때마다 경보가 ALARM 상태가 되도록 설정됩니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: InstanceId

경보 설명: 이 경보는 EC2 인스턴스의 CPU 사용률을 모니터링하는 데 도움이 됩니다. 애플리케이션에 따라 지속적으로 높은 사용률 수준이 정상일 수 있습니다. 그러나 성능이 저하되고 애플리케이션이 디스크 I/O, 메모리 또는 네트워크 리소스의 제약을 받지 않는 경우 CPU 한도가 초과되면 리소스 병목 현상이나 애플리케이션 성능 문제가 발생할 수 있습니다. CPU 사용률이 높으면 CPU 사용량이 더 많은 인스턴스로 업그레이드해야 할 수도 있습니다. 세부 모니터링을 활성화한 경우 기간을 300초가 아닌 60초로 변경할 수 있습니다. 자세한 내용은 인스턴스에 대한 세부 모니터링 활성화 또는 비활성화를 참조하세요.

인텐트: 이 경보는 높은 CPU 사용률을 감지하는 데 사용됩니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 일반적으로 CPU 사용률 임곗값을 70~80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 시스템의 경우 지속적으로 높은 CPU 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 CPU 사용률 데이터를 분석하여 사용량을 식별하고 시스템에 적합한 CPU 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.

기간: 300

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: InstanceId

경보 설명: 이 경보는 시스템 상태 확인 및 인스턴스 상태 확인 모두를 모니터링하는 데 도움이 됩니다. 둘 중 한나의 상태 확인이 실패하는 경우 이 경보는 ALARM 상태여야 합니다.

인텐트: 이 경보는 시스템 상태 확인 실패와 인스턴스 상태 확인 실패를 비롯한 인스턴스의 근본적인 문제를 감지하는 데 사용됩니다.

통계: Maximum

권장 임곗값: 1.0

임곗값 정당화: 상태 확인이 실패하면 이 지표의 값은 1입니다. 임곗값은 상태 확인이 실패할 때마다 경보가 ALARM 상태가 되도록 설정됩니다.

기간: 300

경보를 보낼 데이터 포인트: 2

평가 기간: 2

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: InstanceId

경보 설명: 이 경보는 인스턴스에 연결된 Amazon EBS 볼륨이 연결 가능하고 I/O 작업을 완료할 수 있는지 모니터링할 수 있습니다. 이 상태 확인은 다음과 같은 컴퓨팅 또는 Amazon EBS 인프라의 기본 문제를 감지합니다.

연결된 EBS 상태 확인에 실패하면 Amazon이 문제를 해결할 때까지 기다리거나 영향을 받는 볼륨을 교체 또는 인스턴스 중지 후 재시작 등의 조치를 취할 수 있습니다.

인텐트: 이 경보는 인스턴스에 연결된 연결할 수 없는 Amazon EBS 볼륨을 감지하는 데 사용됩니다. 이로 인해 I/O 작업이 실패할 수 있습니다.

통계: Maximum

권장 임곗값: 1.0

임곗값 정당화: 상태 확인이 실패하면 이 지표의 값은 1입니다. 임곗값은 상태 확인이 실패할 때마다 경보가 ALARM 상태가 되도록 설정됩니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: CacheClusterId, CacheNodeId

경보 설명: 이 경보는 데이터베이스 엔진 프로세스와 인스턴스에서 실행 중인 기타 프로세스를 포함하여 전체 ElastiCache 인스턴스의 CPU 사용률을 모니터링하는 데 도움이 됩니다. AWS Elasticache는 Memcached와 Redis OSS의 두 가지 엔진 유형을 지원합니다. Memcached 노드에서 CPU 사용률이 높아지면 인스턴스 유형을 확장하거나 새 캐시 노드를 추가하는 것을 고려해야 합니다. Redis OSS에서는 주 워크로드가 읽기 요청인 경우 캐시 클러스터에 읽기 전용 복제본을 추가하는 것을 고려해야 합니다. 주 워크로드가 쓰기 요청이라면 클러스터형 모드에서 실행하는 경우 샤드를 추가하여 더 많은 프라이머리 노드에 워크로드를 분산하고, Redis OSS를 비클러스터형 모드에서 실행하는 경우 인스턴스 유형을 확장하는 것을 고려해야 합니다.

인텐트: 이 경보는 ElastiCache 호스트의 높은 CPU 사용률을 감지하는 데 사용됩니다. 엔진이 아닌 프로세스를 포함하여 전체 인스턴스의 CPU 사용량을 폭넓게 파악하면 도움이 됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 임곗값을 애플리케이션의 중요한 CPU 사용률 수준을 반영하는 백분율로 설정합니다. Memcached의 경우 엔진은 최대 num_threads 코어를 사용할 수 있습니다. Redis OSS에서는 엔진이 대부분 단일 스레드이지만 I/O 가속화를 위해 가능한 경우 추가 코어를 사용할 수 있습니다. 대부분의 경우 임곗값을 사용 가능한 CPU의 약 90%로 설정할 수 있습니다. Redis OSS는 단일 스레드이기 때문에 실제 임곗값은 노드 총용량의 일부로 계산해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: CacheClusterId, CacheNodeId

경보 설명: 이 경보는 높은 연결 수를 감지하며 이는 과부하 또는 성능 문제를 나타낼 수 있습니다. CurrConnections가 계속 증가하면 사용 가능한 65,000개의 연결이 고갈될 수 있습니다. 이는 애플리케이션 측에서 연결이 잘못 종료되고 서버 측에서는 설정된 상태로 남아 있는 것일 수 있습니다. 연결 풀링 또는 유휴 연결 제한 시간을 사용하여 클러스터에 대한 연결 수를 제한하거나, Redis OSS의 경우 클러스터에서 tcp-keepalive를 조정하여 잠재적 데드 피어를 탐지하고 종료하는 방안을 고려해 보세요.

인텐트: 경보를 통해 ElastiCache 클러스터의 성능 및 안정성에 영향을 미칠 수 있는 높은 연결 수를 식별할 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 클러스터의 허용 가능한 연결 범위에 따라 크게 달라집니다. ElastiCache 클러스터의 용량 및 예상 워크로드를 검토하고, 정기적인 사용 중 과거 연결 수를 분석하여 기준을 설정한 다음 그에 따라 임곗값을 선택합니다. 각 노드는 최대 65,000개의 동시 연결을 지원합니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: CacheClusterId

경보 설명: 이 경보는 클러스터의 메모리 사용률을 모니터링하는 데 도움이 됩니다. DatabaseMemoryUsagePercentage가 100%에 도달하면 Redis OSS maxmemory 정책이 트리거되고 선택한 정책에 따라 제거가 발생할 수 있습니다. 캐시에 제거 정책과 일치하는 객체가 없는 경우 쓰기 작업이 실패합니다. 일부 워크로드는 제거를 예상하거나 제거에 의존하지만 그렇지 않은 경우 클러스터의 메모리 용량을 늘려야 합니다. 프라이머리 노드를 추가하여 클러스터를 확장하거나 더 큰 노드 유형을 사용하여 클러스터를 확장할 수 있습니다. 자세한 내용은 Redis OSS 클러스터용 ElastiCache 확장을 참조하세요.

인텐트: 이 경보는 클러스터의 높은 메모리 사용률을 감지하여 클러스터에 쓸 때 오류를 방지할 수 있습니다. 애플리케이션에서 제거가 발생할 것으로 예상되지 않는 경우 클러스터를 확장해야 하는 시기를 알면 도움이 됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 애플리케이션의 메모리 요구 사항과 ElastiCache 클러스터의 메모리 용량에 따라 임곗값을 클러스터의 중요 메모리 사용량 수준을 반영하는 백분율로 설정해야 합니다. 과거 메모리 사용량 데이터를 허용 가능한 메모리 사용량 임곗값에 대한 참조로 사용할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: CacheClusterId

경보 설명: 이 경보는 ElastiCache 인스턴스에서 Redis OSS 엔진 스레드의 CPU 사용률을 모니터링하는 데 도움이 됩니다. 엔진의 CPU 사용량이 높은 일반적인 이유는 CPU 사용량이 높은 오래 실행되는 명령, 많은 요청 수, 짧은 시간 내에 새 클라이언트 연결 요청 증가, 캐시에 새 데이터를 저장할 메모리가 충분하지 않을 경우 강제 제거 등이 있습니다. 노드를 추가하거나 인스턴스 유형을 확장하여 Redis OSS 클러스터용 ElastiCache를 확장하는 것을 고려해야 합니다.

인텐트: 이 경보는 Redis OSS 엔진 스레드의 높은 CPU 사용률을 감지하는 데 사용됩니다. 데이터베이스 엔진 자체의 CPU 사용량을 모니터링하는 경우에 유용합니다.

통계: Average

권장 임곗값: 90.0

임곗값 정당화: 임곗값을 애플리케이션의 중요한 엔진 CPU 사용률 수준을 반영하는 백분율로 설정합니다. 애플리케이션과 예상 워크로드를 사용하여 클러스터를 벤치마킹하고 EngineCPUUtilization과 성능의 상관 관계를 참조한 다음 그에 따라 임곗값을 설정할 수 있습니다. 대부분의 경우 임곗값을 사용 가능한 CPU의 약 90%로 설정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: CacheClusterId

경보 설명: 이 경보는 ElastiCache 클러스터의 복제 상태를 모니터링하는 데 도움이 됩니다. 복제 지연이 길어지면 프라이머리 노드나 복제본이 복제 속도를 따라갈 수 없다는 뜻입니다. 쓰기 작업이 너무 많으면 프라이머리 노드를 추가하여 클러스터를 확장하거나 더 큰 노드 유형을 사용하여 확장하는 것을 고려해 보세요. 자세한 내용은 Redis OSS 클러스터용 ElastiCache 확장을 참조하세요. 읽기 요청량이 너무 많아 읽기 전용 복제본에 과부하가 걸리면 읽기 전용 복제본을 추가하는 것이 좋습니다.

인텐트: 이 경보는 프라이머리 노드의 데이터 업데이트와 복제본 노드와의 동기화 사이에서 지연을 감지하는 데 사용됩니다. 읽기 전용 복제본 클러스터 노드의 데이터 일관성을 보장하는 데 도움이 됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 애플리케이션의 요구 사항과 복제 지연의 잠재적 영향에 따라 임곗값을 설정합니다. 허용 가능한 복제 지연에 대해서는 애플리케이션의 예상 쓰기 속도와 네트워크 상황을 고려해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 ECS 클러스터의 높은 CPU 예약을 감지하는 데 도움이 됩니다. CPU 예약이 높으면 클러스터에 등록된 해당 작업에 사용할 CPU가 부족하다는 의미일 수 있습니다. 문제를 해결하려면 용량을 추가하거나 클러스터를 확장하거나 Auto Scaling을 설정합니다.

인텐트: 경보는 클러스터의 작업에 예약된 총 CPU 단위 수가 클러스터에 등록된 총 CPU 단위에 도달하는지 여부를 감지하는 데 사용됩니다. 이를 통해 클러스터를 확장해야 하는 시기를 알 수 있습니다. 클러스터의 총 CPU 단위에 도달하면 작업에 사용할 CPU가 부족해질 수 있습니다. EC2 용량 공급자의 관리 규모 조정이 활성화되거나 Fargate를 용량 공급자에 연결한 경우에는 이 경보를 사용하지 않는 것이 좋습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: CPU 예약 임곗값을 80%로 설정합니다. 또는 클러스터 특성에 따라 더 낮은 값을 선택해도 됩니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 ECS 서비스의 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 진행 중인 ECS 배포가 없는 경우 CPU 사용률이 최대치를 초과하면 리소스 병목 현상이나 애플리케이션 성능 문제가 있다는 의미일 수 있습니다. 문제를 해결하려면 CPU 제한을 늘리면 됩니다.

인텐트: 이 경보는 Amazon ECS 서비스의 높은 CPU 사용률을 감지하는 데 사용됩니다. CPU 사용률이 지속적으로 높으면 리소스 병목 현상이나 애플리케이션 성능 문제가 있다는 의미일 수 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 정당화: CPU 사용률에 대한 서비스 지표가 사용률 100%를 초과할 수 있습니다. 그러나 다른 서비스에 영향을 미치지 않도록 높은 CPU 사용률 지표를 모니터링하는 것이 좋습니다. 임곗값을 약 80~85%로 설정합니다. 향후 다른 서비스에서 문제가 발생하지 않도록 실제 사용량을 반영하여 작업 정의를 업데이트하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 Amazon ECS 태스크에 연결된 Amazon EBS 볼륨의 높은 스토리지 사용률을 감지하는 데 도움이 됩니다. Amazon EBS 볼륨의 사용률이 지속적으로 높으면 사용량을 확인하고 새 태스크의 볼륨 크기를 늘릴 수 있습니다.

의도: 이 경보는 Amazon ECS 태스크에 연결된 Amazon EBS 볼륨의 높은 스토리지 사용률을 탐지하는 데 사용됩니다. 스토리지 사용률이 지속적으로 높으면 Amazon EBS 볼륨이 가득 차서 컨테이너에 장애가 발생할 수 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: Amazon EBS 파일 시스템 사용률의 임곗값을 약 80%로 설정할 수 있습니다. 허용 가능한 스토리지 사용률을 기준으로 이 값을 조정할 수 있습니다. 읽기 전용 스냅샷 볼륨의 경우 사용률이 높다면 볼륨의 크기가 적절하다는 의미일 수 있습니다. 활성 데이터 볼륨의 경우 스토리지 사용률이 높으면 애플리케이션이 대량의 데이터를 쓰고 있다는 의미일 수 있습니다. 이로 인해 용량이 충분하지 않은 경우에는 컨테이너가 실패할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 Amazon ECS 클러스터의 높은 메모리 예약을 감지하는 데 도움이 됩니다. 메모리 예약이 많으면 클러스터의 리소스 병목 현상이 나타날 수 있습니다. 문제를 해결하려면 서비스 작업의 성능을 분석하여 작업의 메모리 사용률을 최적화할 수 있는지 확인하세요. 또한 메모리를 더 등록하거나 Auto Scaling을 설정할 수 있습니다.

인텐트: 경보는 클러스터의 작업에 예약된 총 메모리 단위가 클러스터에 등록된 총 메모리 단위에 도달하는지 여부를 감지하는 데 사용됩니다. 이를 통해 클러스터를 확장해야 하는 시기를 알 수 있습니다. 클러스터의 총 메모리 단위에 도달하면 클러스터가 새 작업을 시작하지 못할 수 있습니다. EC2 용량 공급자의 관리 규모 조정이 활성화되거나 Fargate를 용량 공급자에 연결한 경우에는 이 경보를 사용하지 않는 것이 좋습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 메모리 예약 임곗값을 80%로 설정합니다. 클러스터 특성에 따라 이 값을 더 낮게 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 Amazon ECS 서비스의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 진행 중인 Amazon ECS 배포가 없는 경우 메모리 사용률이 최대치를 초과하면 리소스 병목 현상이나 애플리케이션 성능 문제가 있다는 의미일 수 있습니다. 문제를 해결하려면 메모리 제한을 늘리면 됩니다.

의도: 이 경보는 Amazon ECS 서비스의 높은 메모리 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 리소스 병목 현상이나 애플리케이션 성능 문제가 있다는 의미일 수 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 정당화: 메모리 사용률에 대한 서비스 지표가 사용률 100%를 초과할 수 있습니다. 그러나 다른 서비스에 영향을 미치지 않도록 높은 메모리 사용률 지표를 모니터링하는 것이 좋습니다. 임곗값을 약 80%로 설정합니다. 향후 다른 서비스에서 문제가 발생하지 않도록 실제 사용량을 반영하여 작업 정의를 업데이트하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 ECS 서비스에 대한 서버 측 오류 수가 많을 경우 이를 감지하는 데 도움이 됩니다. 이는 오류가 발생하여 서버가 요청을 처리할 수 없게 되었음을 의미할 수 있습니다. 문제를 해결하려면 애플리케이션 로그를 확인하세요.

인텐트: 이 경보는 ECS 서비스에 대한 많은 서버 측 오류 수를 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 평균 트래픽의 약 5%에 해당하는 값을 계산하고 이 값을 임곗값의 시작점으로 사용합니다. RequestCount 지표를 사용하여 평균 트래픽을 확인할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 5XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 ECS 서비스 요청에 대한 높은 목표 응답 시간을 감지하는 데 도움이 됩니다. 이는 문제가 발생하여 서비스에서 요청을 제 시간에 처리할 수 없게 되었음을 의미할 수 있습니다. 문제를 해결하려면 CPU 사용률 지표를 확인하고 서비스에 CPU가 부족한지 확인하거나 서비스에서 사용하는 다른 다운스트림 서비스의 CPU 사용률을 확인하세요.

인텐트: 이 경보는 ECS 서비스 요청에 대한 높은 목표 응답 시간을 감지하는 데 사용됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 사용 사례에 따라 크게 달라집니다. 서비스의 목표 응답 시간에 대한 중요도 및 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 Fargate 클러스터에서 활용되는 높은 임시 스토리지를 탐지하는 데 도움이 됩니다. 임시 스토리지가 지속적으로 높은 경우 임시 스토리지 사용량을 확인하고 임시 스토리지를 늘릴 수 있습니다.

의도: 이 경보는 Fargate 클러스터의 높은 임시 스토리지 사용량을 탐지하는 데 사용됩니다. 임시 스토리지 사용률이 지속적으로 높으면 디스크가 가득 차서 컨테이너에 장애가 발생할 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 근거: 임곗값을 임시 스토리지 크기의 약 90%로 설정합니다. Fargate 클러스터의 허용 가능한 임시 스토리지 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 시스템의 경우 사용률이 지속적으로 높은 임시 스토리지를 사용하는 것이 정상일 수 있지만 다른 시스템의 경우 컨테이너 장애로 이어질 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 Amazon ECS 서비스에서 실행 중인 작업 수가 적은 것을 탐지하는 데 도움이 됩니다. 실행 중인 작업 수가 너무 적으면 애플리케이션이 서비스 로드를 처리할 수 없어 성능 문제가 발생할 수 있습니다. 실행 중인 작업이 없는 경우 Amazon ECS 서비스를 사용할 수 없거나 배포 문제가 있을 수 있습니다.

의도: 이 경보는 실행 중인 작업 수가 너무 적은지 여부를 탐지하는 데 사용됩니다. 실행 중인 작업이 지속적으로 적다는 것은 Amazon ECS 서비스 배포 또는 성능 문제를 의미할 수 있습니다.

통계: Average

권장 임곗값: 0.0

임곗값 근거: Amazon ECS 서비스의 최소 실행 작업 수를 기준으로 임곗값을 조정할 수 있습니다. 실행 중인 작업 수가 0인 경우 Amazon ECS 서비스를 사용할 수 없습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 Amazon ECS 클러스터에서 작업의 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 작업 CPU 사용률이 지속적으로 높으면 작업을 최적화하거나 CPU 예약을 늘려야 할 수도 있습니다.

의도: 이 경보는 Amazon ECS 클러스터의 작업에 대한 높은 CPU 사용률을 감지하는 데 사용됩니다. CPU 사용률이 지속적으로 높으면 작업이 스트레스를 받고 있으며, 성능을 유지하기 위해 더 많은 CPU 리소스 또는 최적화가 필요할 수도 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 작업 CPU 예약의 약 80%로 설정합니다. 작업에 허용 가능한 CPU 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 CPU 사용률이 정상일 수도 있지만, 다른 경우에는 성능 문제를 나타내거나 리소스가 더 필요할 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 작업 CPU 사용률이 지속적으로 높으면 작업을 최적화하거나 CPU 예약을 늘려야 할 수도 있습니다.

의도: 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 CPU 사용률을 감지하는 데 사용됩니다. CPU 사용률이 지속적으로 높으면 작업이 스트레스를 받고 있으며, 성능을 유지하기 위해 더 많은 CPU 리소스 또는 최적화가 필요할 수도 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 작업 CPU 예약의 약 80%로 설정합니다. 작업에 허용 가능한 CPU 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 CPU 사용률이 정상일 수도 있지만, 다른 경우에는 성능 문제를 나타내거나 리소스가 더 필요할 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 예약된 CPU와 비교하여 Amazon ECS 클러스터의 컨테이너에서 사용하는 CPU 단위의 비율을 모니터링합니다. ContainerCpuUtilized/ContainerCpuReserved 비율을 기반으로 컨테이너가 CPU 한도에 근접하는 시기를 감지하는 데 도움이 됩니다.

의도: 이 경보는 Amazon ECS 클러스터의 컨테이너가 ContainerCpuUtilized/ContainerCpuReserved로 계산된 예약 CPU 용량의 높은 비율을 사용하는 시기를 감지합니다. 지속적으로 높은 값은 컨테이너가 CPU 한도에 가깝게 운영되고 있다는 것을 나타내며, 용량 조정이 필요할 수도 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 컨테이너 CPU 사용률의 약 80%로 설정합니다. 그러면 컨테이너가 CPU 사용률의 정상적인 변동이 허용되는 동안 컨테이너가 CPU 용량 한도에 근접할 때 조기 경고가 제공됩니다. 임곗값은 워크로드 특성 및 성능 요구 사항에 따라 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 예약된 CPU와 비교하여 Amazon ECS 서비스에 속하는 컨테이너에서 사용하는 CPU 단위의 비율을 모니터링합니다. ContainerCpuUtilized/ContainerCpuReserved 비율을 기반으로 컨테이너가 CPU 한도에 근접하는 시기를 감지하는 데 도움이 됩니다.

의도: 이 경보는 Amazon ECS 서비스에 속하는 컨테이너가 ContainerCpuUtilized/ContainerCpuReserved로 계산된 예약 CPU 용량의 높은 비율을 사용하는 시기를 감지합니다. 지속적으로 높은 값은 컨테이너가 CPU 한도에 가깝게 운영되고 있다는 것을 나타내며, 용량 조정이 필요할 수도 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 컨테이너 CPU 사용률의 약 80%로 설정합니다. 그러면 컨테이너가 CPU 사용률의 정상적인 변동이 허용되는 동안 컨테이너가 CPU 용량 한도에 근접할 때 조기 경고가 제공됩니다. 임곗값은 워크로드 특성 및 성능 요구 사항에 따라 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 Amazon ECS 클러스터에서 작업의 높은 임시 스토리지 사용률을 감지하는 데 도움이 됩니다. 스토리지 사용률이 지속적으로 높으면 스토리지 사용률을 최적화하거나 스토리지 예약을 늘려야 할 수도 있습니다.

의도: 이 경보는 Amazon ECS 클러스터의 작업에 대한 높은 임시 스토리지 사용률을 감지하는 데 사용됩니다. 스토리지 사용률이 지속적으로 높으면 작업에 디스크 공간이 부족하여 제대로 작동하려면 더 많은 스토리지 리소스 또는 최적화가 필요할 수도 있다는 것을 나타낼 수 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 작업 임시 스토리지 예약의 약 80%로 설정합니다. 작업에 허용 가능한 스토리지 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 CPU 사용률이 정상일 수도 있지만, 다른 경우에는 잠재적인 디스크 공간 문제 또는 더 많은 스토리이에 대한 필요성을 나타낼 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 임시 스토리지 사용률을 감지하는 데 도움이 됩니다. 스토리지 사용률이 지속적으로 높으면 스토리지 사용률을 최적화하거나 스토리지 예약을 늘려야 할 수도 있습니다.

의도: 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 임시 스토리지 사용률을 감지하는 데 사용됩니다. 스토리지 사용률이 지속적으로 높으면 작업에 디스크 공간이 부족하여 제대로 작동하려면 더 많은 스토리지 리소스 또는 최적화가 필요할 수도 있다는 것을 나타낼 수 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 작업 임시 스토리지 예약의 약 80%로 설정합니다. 작업에 허용 가능한 스토리지 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 CPU 사용률이 정상일 수도 있지만, 다른 경우에는 잠재적인 디스크 공간 문제 또는 더 많은 스토리이에 대한 필요성을 나타낼 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 Amazon ECS 클러스터에서 작업의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 메모리 사용률이 지속적으로 높으면 작업을 최적화하거나 메모리 예약을 늘려야 할 수도 있습니다.

의도: 이 경보는 Amazon ECS 클러스터의 작업에 대한 높은 메모리 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 작업이 메모리 압력를 받고 있으며, 안정성을 유지하기 위해 더 많은 메모리 리소스 또는 최적화가 필요할 수도 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 작업 메모리 예약의 약 80%로 설정합니다. 작업에 허용 가능한 메모리 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 메모리 사용률이 정상일 수도 있지만, 다른 경우에는 메모리 압력를 나타내거나 리소스가 더 필요할 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 메모리 사용률이 지속적으로 높으면 작업을 최적화하거나 메모리 예약을 늘려야 할 수도 있습니다.

의도: 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 메모리 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 작업이 메모리 압력를 받고 있으며, 안정성을 유지하기 위해 더 많은 메모리 리소스 또는 최적화가 필요할 수도 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 작업 메모리 예약의 약 80%로 설정합니다. 작업에 허용 가능한 메모리 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 메모리 사용률이 정상일 수도 있지만, 다른 경우에는 메모리 압력를 나타내거나 리소스가 더 필요할 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 Amazon ECS 클러스터에서 컨테이너의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 메모리 사용률이 지속적으로 높으면 컨테이너를 최적화하거나 메모리 예약을 늘려야 할 수 있습니다.

의도: 이 경보는 Amazon ECS 클러스터의 컨테이너에 대한 높은 메모리 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 컨테이너 메모리 압력를 받고 있으며, 안정성을 유지하기 위해 더 많은 메모리 리소스 또는 최적화가 필요할 수도 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 컨테이너 메모리 예약의 약 80%로 설정합니다. 컨테이너에 허용 가능한 메모리 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 메모리 사용률이 정상일 수도 있지만, 다른 경우에는 메모리 압력를 나타내거나 리소스가 더 필요할 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 Amazon ECS 서비스에 속하는 컨테이너의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 메모리 사용률이 지속적으로 높으면 컨테이너를 최적화하거나 메모리 예약을 늘려야 할 수 있습니다.

의도: 이 경보는 Amazon ECS 서비스의 높은 컨테이너 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 컨테이너 메모리 압력를 받고 있으며, 안정성을 유지하기 위해 더 많은 메모리 리소스 또는 최적화가 필요할 수도 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 컨테이너 메모리 예약의 약 80%로 설정합니다. 컨테이너에 허용 가능한 메모리 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 메모리 사용률이 정상일 수도 있지만, 다른 경우에는 메모리 압력를 나타내거나 리소스가 더 필요할 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: InstanceId, ContainerInstanceId, ClusterName

경보 설명: 이 경보는 Amazon ECS 클러스터의 높은 파일 시스템 사용률을 탐지하는 데 도움이 됩니다. 파일 시스템 사용률이 지속적으로 높으면 디스크 사용량을 확인합니다.

의도: 이 경보는 Amazon ECS 클러스터의 높은 파일 시스템 사용률을 탐지하는 데 사용됩니다. 파일 시스템 사용률이 지속적으로 높으면 리소스 병목 현상이나 애플리케이션 성능 문제를 의미할 수 있으며, 이로 인해 새 작업이 실행되지 않을 수 있습니다.

통계: Average

권장 임곗값: 90.0

임곗값 근거: 파일 시스템 사용률의 임곗값을 약 90~95%로 설정할 수 있습니다. Amazon ECS 클러스터의 허용 가능한 파일 시스템 용량 수준을 기준으로 이 값을 조정할 수 있습니다. 일부 시스템의 경우 파일 시스템 사용률이 지속적으로 높으면 정상일 뿐 문제가 아닌 것일 수 있지만, 다른 시스템에서는 문제의 원인이 되어 성능 문제로 이어지고 새 작업을 실행하지 못하게 될 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 작업에서 사용되는 CPU 유닛의 총 백분율을 감지하는 데 도움이 됩니다.

인텐트: 이 경보는 높은 태스크 CPU 사용률을 감지하는 데 사용됩니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 일반적으로 CPU 사용률 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 태스크의 경우 지속적으로 높은 CPU 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 CPU 사용률 데이터를 분석하여 사용량을 식별하고 태스크에 적합한 CPU 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 작업에서 사용되는 메모리의 총 비율을 감지하는 데 도움이 됩니다.

인텐트: 이 경보는 높은 메모리 사용률을 감지하는 데 사용됩니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 일반적으로 메모리 사용률 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 태스크의 경우 지속적으로 높은 메모리 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 메모리 사용률 데이터를 분석하여 사용량을 식별하고 태스크에 적합한 메모리 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_OR_EQUAL_TO_THRESHOLD

측정기준: ContainerName, ClusterName, ServiceName

경보 설명: 이 경보는 컨테이너에서 사용 중인 CPU 유닛의 총 백분율을 감지하는 데 도움이 됩니다.

인텐트: 이 경보는 높은 태스크 CPU 사용률을 감지하는 데 사용됩니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 일반적으로 CPU 사용률 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 컨테이너의 경우 지속적으로 높은 CPU 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 CPU 사용률 데이터를 분석하여 사용량을 식별하고 컨테이너에 적합한 CPU 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: ContainerName, ClusterName, ServiceName

경보 설명: 이 경보는 컨테이너에서 사용 중인 메모리 유닛의 총 백분율을 감지하는 데 도움이 됩니다.

의도: 이 경보는 높은 메모리 사용률을 감지하는 데 사용됩니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 일반적으로 메모리 사용률 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 컨테이너의 경우 지속적으로 높은 메모리 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 메모리 사용률 데이터를 분석하여 사용량을 식별하고 태스크에 적합한 메모리 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 작업에서 사용 중인 임시 스토리지의 총 백분율을 감지하는 데 도움이 됩니다.

인텐트: 이 경보는 태스크에 대한 높은 Amazon EBS 파일 시스템 사용률을 탐지하는 데 사용됩니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 Amazon EBS 파일 시스템 크기의 약 80%로 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, ServiceName

경보 설명: 이 경보는 작업에서 사용 중인 임시 스토리지의 총 백분율을 감지하는 데 도움이 됩니다.

인텐트: 이 경보는 태스크에 대한 높은 임시 스토리지 사용량을 탐지하는 데 사용됩니다. 임시 스토리지 사용률이 지속적으로 높으면 디스크가 가득 차서 태스크에 장애가 발생할 수 있습니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 임곗값을 임시 스토리지 크기의 약 80%로 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: FileSystemId

경보 설명: 이 경보는 워크로드가 파일 시스템에서 사용할 수 있는 I/O 한도 내에서 유지되게 하는 데 도움이 됩니다. 지표가 지속적으로 I/O 한도에 도달하는 경우 애플리케이션을 최대 I/O 성능 모드로 사용하는 파일 시스템으로 이동하는 것을 고려해 보세요. 문제를 해결하려면 파일 시스템에 연결된 클라이언트와 파일 시스템을 제한하는 클라이언트의 애플리케이션을 확인합니다.

인텐트: 이 경보는 파일 시스템이 범용 성능 모드의 I/O 제한에 얼마나 가깝게 도달해있는지를 감지하는 데 사용됩니다. I/O 비율이 지속적으로 높으면 I/O 요청에 따라 파일 시스템을 충분히 확장할 수 없고, 파일 시스템을 사용하는 애플리케이션에서 파일 시스템이 리소스 병목 현상을 일으킬 수 있다는 의미일 수 있습니다.

통계: Average

권장 임곗값: 100.0

임곗값 정당화: 파일 시스템이 I/O 한도에 도달하면 읽기 및 쓰기 요청에 대한 응답이 느려질 수 있습니다. 따라서 파일 시스템을 사용하는 애플리케이션에 영향을 미치지 않도록 지표를 모니터링하는 것이 좋습니다. 임곗값은 약 100%로 설정할 수 있습니다. 하지만 파일 시스템 특성에 따라 이 값을 더 낮게 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: FileSystemId

경보 설명: 이 경보는 파일 시스템 사용에 적용할 수 있는 버스트 크레딧 밸런스가 있는지 확인하는 데 도움이 됩니다. 사용 가능한 버스트 크레딧이 없는 경우 낮은 처리량으로 인해 파일 시스템에 대한 애플리케이션 액세스가 제한됩니다. 지표가 일관되게 0으로 떨어지면 처리량 모드를 탄력적 또는 프로비저닝된 처리량 모드로 변경하는 것이 좋습니다.

인텐트: 이 경보는 파일 시스템의 낮은 버스트 크레딧 밸런스를 감지하는 데 사용됩니다. 지속적으로 낮은 버스트 크레딧 밸런스는 처리량 저하 및 I/O 지연 시간 증가를 나타내는 지표가 될 수 있습니다.

통계: Average

권장 임곗값: 0.0

임곗값 정당화: 파일 시스템에서 버스트 크레딧이 부족하고 기준 처리량이 더 낮은 경우에도 EFS는 모든 파일 시스템에 1MiBps의 측정된 처리량을 계속 지원합니다. 하지만 파일 시스템이 애플리케이션의 리소스 병목 현상으로 작용하지 않도록 지표의 버스트 크레딧 밸런스가 낮은지 모니터링하는 것이 좋습니다. 임곗값은 약 0바이트로 설정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: LESS_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 EKS 클러스터의 워커 노드에서 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 워커 노드를 CPU가 더 큰 인스턴스로 교체하거나 시스템을 수평적으로 확장해야 할 수 있습니다.

인텐트: 이 경보는 시스템 성능이 저하되지 않도록 EKS 클러스터에 있는 워커 노드의 CPU 사용률을 모니터링하는 데 도움이 됩니다.

통계: Maximum

권장 임곗값: 80.0

임곗값 정당화: 시스템에서 영향을 받기 시작하기 전에 문제를 디버깅할 충분한 시간을 확보할 수 있도록 임곗값을 80% 이하로 설정하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 EKS 클러스터의 워커 노드에서 높은 파일 시스템 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 워커 노드를 업데이트하여 디스크 볼륨을 늘리거나 수평적으로 확장해야 할 수 있습니다.

경보 설명: 이 경보는 EKS 클러스터의 워커 노드에서 높은 파일 시스템 사용률을 모니터링하는 데 도움이 됩니다. 사용률이 100%에 도달하면 애플리케이션 장애, 디스크 I/O 병목 현상, 포드 제거 또는 노드가 완전히 응답하지 않게 될 수 있습니다.

통계: Maximum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 디스크 압력이 충분하면(즉 디스크가 꽉 차면) 노드가 비정상으로 표시되고 포드가 노드에서 제거됩니다. 디스크 압력이 큰 노드의 포드는 사용 가능한 파일 시스템이 kubelet에 설정된 제거 임곗값보다 낮을 경우에 제거됩니다. 클러스터에서 노드가 제거되기 전에 대응할 충분한 시간을 확보할 수 있도록 경보 임곗값을 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName

경보 설명: 이 경보는 EKS 클러스터의 워커 노드에서 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 포드 복제본 수를 조정하거나 애플리케이션을 최적화해야 할 수 있습니다.

인텐트: 이 경보는 시스템 성능이 저하되지 않도록 EKS 클러스터에 있는 워커 노드의 메모리 사용률을 모니터링하는 데 도움이 됩니다.

통계: Maximum

권장 임곗값: 80.0

임곗값 정당화: 시스템에서 영향을 받기 시작하기 전에 문제를 디버깅할 충분한 시간을 확보할 수 있도록 임곗값을 80% 이하로 설정하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, Namespace, Service

경보 설명: 이 경보는 EKS 클러스터의 포드에서 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 영향을 받는 포드의 CPU 한도를 늘려야 할 수 있습니다.

인텐트: 이 경보는 EKS 클러스터의 Kubernetes 서비스에 속하는 포드의 CPU 사용률을 모니터링하는 데 도움이 되며 이를 통해 서비스의 포드가 예상보다 높은 CPU를 소비하고 있는지 빠르게 식별할 수 있습니다.

통계: Maximum

권장 임곗값: 80.0

임곗값 정당화: 시스템에서 영향을 받기 시작하기 전에 문제를 디버깅할 충분한 시간을 확보할 수 있도록 임곗값을 80% 이하로 설정하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: ClusterName, Namespace, Service

경보 설명: 이 경보는 EKS 클러스터의 포드에서 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 영향을 받는 포드의 메모리 한도를 늘려야 할 수 있습니다.

인텐트: 이 경보는 시스템 성능이 저하되지 않도록 EKS 클러스터에 있는 포드의 메모리 사용률을 모니터링하는 데 도움이 됩니다.

통계: Maximum

권장 임곗값: 80.0

임곗값 정당화: 시스템에서 영향을 받기 시작하기 전에 문제를 디버깅할 충분한 시간을 확보할 수 있도록 임곗값을 80% 이하로 설정하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: 없음

경보 설명: 이 경보는 대상 스로틀링을 식별하는 데 도움이 됩니다. 대상 스로틀링 오류를 방지하려면 간접 호출 로드를 분산하도록 유연한 시간대를 구성하거나, 대상 서비스를 활용하여 한도를 늘리는 것이 좋습니다.

의도: 이 경보는 일정 지연을 일으킬 수 있는 대상 스로틀링 오류를 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 0.0

임곗값 근거: 대상 스로틀링 오류가 지속적으로 0보다 큰 경우 일정 전송이 지연됩니다. 일부 시스템의 경우에는 짧은 기간의 대상 스로틀링 오류는 정상일 수 있지만, 다른 시스템의 경우에는 문제가 될 수 있습니다. 이 경보의 임곗값인 datapointsToAlarm을 설정하고, 그에 따라 evaluationPeriods를 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: 없음

경보 설명: 이 경보는 Amazon EventBridge 스케줄러에 의한 간접 호출 스로틀링을 식별하는 데 도움이 됩니다. 간접 호출 스로틀링 오류를 방지하려면 간접 호출 로드를 분산하도록 유연한 시간대를 구성하거나, 간접 호출 스로틀링 한도를 늘리는 것이 좋습니다.

의도: 이 경보는 Amazon EventBridge 스케줄러 간접 호출 스로틀링 오류를 감지하는 데 사용되며, 이로 인해 일정 지연이 발생할 수 있습니다.

통계: Sum

권장 임곗값: 0.0

임곗값 근거: 간접 호출 스로틀링 오류가 지속적으로 0보다 큰 경우 일정 전송이 지연됩니다. 일부 시스템의 경우에는 짧은 기간의 간접 호출 스로틀링 오류는 정상일 수 있지만, 다른 시스템의 경우에는 문제가 될 수 있습니다. 이 경보의 임곗값인 datapointsToAlarm을 설정하고, 그에 따라 evaluationPeriods를 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: 없음

경보 설명: 이 경보는 Amazon EventBridge 스케줄러에서 삭제한 간접 호출을 식별하는 데 도움이 됩니다. 일정에 대한 DLQ를 구성하여 조사하는 것이 좋습니다.

의도: 이 경보는 Amazon EventBridge 스케줄러에서 삭제한 간접 호출을 감지하는 데 사용됩니다. 모든 일정에 DLQ를 올바르게 구성한 경우 삭제된 간접 호출이 DLQ에 표시되며 이 경보 설정을 건너뛸 수 있습니다.

통계: Sum

권장 임곗값: 0.0

임곗값 근거: 삭제된 간접 호출을 감지하려면 임곗값을 0으로 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 1

평가 기간: 1

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: 없음

경보 설명: 이 경보는 Amazon EventBridge 스케줄러에서 구성한 DLQ로 전송하지 못한 호출을 식별하는 데 도움이 됩니다. 지표가 지속적으로 0보다 큰 경우 DLQ 구성을 수정하여 문제를 해결합니다. InvocationsFailedToBeSentToDeadLetterCount_metrics를 사용하여 문제를 확인합니다.

의도: 이 경보는 Amazon EventBridge 스케줄러에서 구성한 DLQ로 전송하지 못한 호출을 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 0.0

임곗값 근거: 구성된 DLQ로 전송하지 못한 간접 호출을 감지하려면 임곗값을 0으로 설정합니다. 재시도 가능한 오류도 이 지표에 표시되므로, 이 경보의 datapointsToAlarm은 15로 설정되었습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: StreamName

경보 설명: 이 경보는 반복자 최대 수명이 너무 높은 경우 이를 감지할 수 있습니다. 실시간 데이터 처리 애플리케이션의 경우 지연 허용치에 따라 데이터 보존을 구성합니다. 이는 보통 몇 분 이내입니다. 기록 데이터를 처리하는 애플리케이션의 경우 이 지표를 사용하여 캐치업 속도를 모니터링합니다. 데이터 손실을 막는 빠른 해결책은 문제를 해결하는 동안 보존 기간을 늘리는 것입니다. 또한 소비자 애플리케이션에서 레코드를 처리하는 작업자 수를 늘릴 수 있습니다. 반복자 수명이 점점 증가하는 가장 일반적인 원인은 물리적 리소스가 부족하거나 레코드 처리 로직이 스트림 처리량의 증가에 따라 조정되지 않기 때문입니다. 자세한 내용은 링크를 참조하세요.

인텐트: 이 경보는 스트림의 데이터가 너무 오래 보존되거나 레코드 처리 속도가 너무 느려 만료되는 것을 감지하는 데 사용됩니다. 이를 통해 스트림 보존 기간의 100%에 도달한 후에도 데이터 손실을 방지할 수 있습니다.

통계: Maximum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 스트림 보존 기간 및 레코드의 처리 지연 허용 한도에 따라 크게 달라집니다. 요구 사항을 검토하고 과거 추세를 분석한 다음 임곗값을 심각한 처리 지연을 나타내는 밀리초로 설정합니다. 반복자 수명이 보존 기간(기본적으로 24시간, 최대 365일까지 구성 가능)의 50%를 경과하면 레코드 만료로 인해 데이터가 손실될 위험이 있습니다. 지표를 모니터링하여 샤드가 이 한도에 도달하지 않게 할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: StreamName

경보 설명: 이 지표는 소비자가 스트림에서 데이터를 성공적으로 읽을 때마다 증가합니다. GetRecords는 예외가 발생해도 데이터를 반환하지 않습니다. 가장 일반적인 예외는 ProvisionedThroughputExceededException입니다. 스트림에 대한 요청 속도가 너무 높거나 주어진 시간 동안 사용 가능한 처리량이 이미 제공되었기 때문입니다. 요청의 횟수 또는 크기를 줄입니다. 자세한 내용은 Amazon Kinesis Data Streams 개발자 안내서의 스트림 제한 및 AWS의 오류 재시도 및 지수 백오프를 참조하세요.

인텐트: 이 경보는 소비자가 스트림에서 레코드를 검색하는 데 실패하는지 여부를 감지할 수 있습니다. 이 지표에 대해 경보를 설정하면 오류율 증가 또는 검색 성공 감소 등 데이터 소비 관련 문제를 사전에 감지할 수 있습니다. 이를 통해 적시에 조치를 취하여 잠재적 문제를 해결하고 원활한 데이터 처리 파이프라인을 유지할 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 스트림에서 레코드 검색의 중요도에 따라 실패한 레코드에 대한 애플리케이션의 허용 범위를 기반으로 임곗값을 설정합니다. 임곗값은 성공한 작업에 해당하는 비율이어야 합니다. 과거 GetRecords 지표 데이터를 허용 가능한 실패율에 대한 참조로 사용할 수 있습니다. 또한 실패한 레코드는 다시 시도될 수 있으므로 임곗값을 설정할 때는 재시도를 고려해야 합니다. 이렇게 하면 일시적 스파이크로 인해 불필요한 경보가 트리거되는 것을 방지할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: StreamName

경보 설명: 이 경보는 실패한 PutRecord 작업 수가 임곗값을 초과할 때 이를 감지합니다. 데이터 생산자 로그를 조사하여 실패의 근본 원인을 찾습니다. 가장 일반적인 이유는 ProvisionedThroughputExceededException 문제를 일으킨 샤드의 프로비저닝 처리량이 충분하지 않기 때문입니다. 스트림에 대한 요청 속도가 너무 높거나 샤드로 인제스트하려는 처리량이 너무 높아서 발생합니다. 요청의 횟수 또는 크기를 줄입니다. 자세한 내용은 스트림 제한 및 AWS의 오류 재시도 및 지수 백오프를 참조하세요.

인텐트: 이 경보는 스트림으로의 레코드 수집 실패 여부를 감지할 수 있습니다. 스트림에 데이터를 쓸 때 발생하는 문제를 식별하는 데 도움이 됩니다. 이 지표에 경보를 설정하면 제작자가 스트림에 데이터를 게시할 때 발생하는 문제(예: 오류율 증가 또는 레코드 게시 성공 감소)를 사전에 감지할 수 있습니다. 이를 통해 적시에 조치를 취하여 잠재적 문제를 해결하고 신뢰할 수 있는 데이터 수집 프로세스를 유지할 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 서비스에서 데이터 수집 및 처리의 중요도에 따라 실패한 레코드에 대한 애플리케이션의 허용 범위를 기반으로 임곗값을 설정합니다. 임곗값은 성공한 작업에 해당하는 비율이어야 합니다. 과거 PutRecord 지표 데이터를 허용 가능한 실패율에 대한 참조로 사용할 수 있습니다. 또한 실패한 레코드는 다시 시도될 수 있으므로 임곗값을 설정할 때는 재시도를 고려해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: StreamName

경보 설명: 이 경보는 실패한 PutRecords 수가 임곗값을 초과할 때 이를 감지합니다. Kinesis Data Streams는 각 PutRecords 요청의 모든 레코드를 처리하려고 시도하지만 단일 레코드 장애가 발생해도 후속 레코드 처리가 중단되지 않습니다. 이러한 실패의 주요 원인은 스트림 또는 개별 샤드의 처리량 초과입니다. 일반적인 원인은 트래픽 스파이크와 네트워크 지연 현상으로 인해 레코드가 스트림에 일정하지 않게 도착하는 것입니다. 따라서 성공적으로 처리되지 않은 레코드를 찾아 후속 호출에서 재시도해야 합니다. 자세한 내용은 PutRecords 사용 시 실패 처리를 참조하세요.

인텐트: 이 경보는 일괄 작업을 사용하여 스트림에 레코드를 넣을 때 일관된 오류를 감지할 수 있습니다. 이 지표에 경보를 설정하면 실패한 레코드의 증가를 사전에 감지하고 적시에 조치를 취하여 근본적인 문제를 해결하며 원활하고 안정적인 데이터 수집 프로세스를 보장할 수 있습니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 실패한 레코드에 대한 애플리케이션의 허용 범위를 반영하여 실패 레코드 수로 임곗값을 설정합니다. 과거 데이터를 허용 가능한 실패 값에 대한 참조로 사용할 수 있습니다. 또한 실패한 레코드는 후속 PutRecords 호출에서 재시도될 수 있으므로 임곗값을 설정할 때 재시도를 고려해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: StreamName

경보 설명: 경보는 읽기 처리량 용량 제한을 초래하는 레코드 수를 추적합니다. 지속적으로 제한이 발생하는 경우 스트림에 샤드를 추가하여 프로비저닝된 읽기 처리량을 늘리는 것을 고려해야 합니다. 스트림에서 실행 중인 소비자 애플리케이션이 두 개 이상이고 GetRecords 한도를 공유하는 경우 Enhanced Fan-Out을 통해 새 소비자 애플리케이션을 등록하는 것이 좋습니다. 샤드를 추가해도 제한 수가 줄어들지 않으면 특정 “핫” 샤드가 다른 샤드보다 더 많이 읽히고 있을 수 있습니다. 향상된 모니터링을 활성화하고 “핫” 샤드를 찾아 분할합니다.

인텐트: 이 경보는 소비자가 프로비저닝된 읽기 처리량(보유한 샤드 수에 따라 결정됨)을 초과할 경우 제한되는지 여부를 감지할 수 있습니다. 이 경우 스트림에서 읽을 수 없게 되며 스트림이 백업을 시작할 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 일반적으로 제한이 발생한 요청은 재시도될 수 있으므로 임곗값을 0으로 설정하면 경보가 너무 민감해집니다. 하지만 지속적인 제한은 스트림의 읽기에 영향을 줄 수 있으므로 경보를 트리거해야 합니다. 애플리케이션 및 재시도 구성에 대해 제한이 발생한 요청에 따라 임곗값을 백분율로 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: StreamName, ConsumerName

경보 설명: 이 경보는 애플리케이션의 레코드 처리 지연이 임곗값을 초과할 때 이를 감지합니다. 다운스트림 애플리케이션에 대한 API 작업 실패와 같은 일시적인 문제로 인해 지표가 갑자기 증가할 수 있습니다. 이러한 문제가 지속적으로 발생하는지 조사해야 합니다. 일반적인 원인은 물리적 리소스가 충분하지 않거나 스트림 처리량 증가에 따라 확장되지 않는 레코드 처리 로직 때문에 소비자가 레코드를 충분히 빠르게 처리하지 못하는 것입니다. 중요 경로에서 호출을 차단하면 레코드 처리 속도가 느려지는 경우가 많습니다. 샤드 수를 늘려 병렬 처리를 늘릴 수 있습니다. 또한 수요가 최고조에 달할 때는 기본 프로세싱 노드에 충분한 물리적 리소스가 있는지 확인해야 합니다.

인텐트: 이 경보는 스트림의 샤드 이벤트 구독 지연을 감지할 수 있습니다. 이는 처리 지연을 나타내며 소비자 애플리케이션의 성능 또는 전체 스트림 상태와 관련된 잠재적 문제를 식별하는 데 도움이 될 수 있습니다. 처리 지연이 심각해지면 병목 현상이나 소비자 애플리케이션 비효율성을 조사하고 해결하여 실시간 데이터 처리를 보장하고 데이터 백로그를 최소화해야 합니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 애플리케이션이 허용할 수 있는 지연에 따라 크게 달라집니다. 애플리케이션의 요구 사항을 검토하고 과거 추세를 분석한 다음 그에 따라 임곗값을 선택합니다. SubscribeToShard 호출이 성공하면 소비자는 최대 5분 동안 지속적인 연결을 통해 SubscribeToShardEvent 이벤트를 수신하기 시작합니다. 이 시간이 지난 후 계속 레코드를 수신하려면 SubscribeToShard를 다시 호출하여 구독을 갱신해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: StreamName

경보 설명: 이 경보는 쓰기 처리량 용량 제한을 초래하는 레코드 수가 임곗값에 도달했을 때 이를 감지합니다. 생산자가 프로비저닝된 쓰기 처리량(보유한 샤드 수에 따라 결정됨)을 초과하면 전송이 제한되고 레코드를 스트림에 넣을 수 없게 됩니다. 지속적인 제한 문제를 해결하려면 스트림에 샤드를 추가하는 것을 고려해야 합니다. 이렇게 하면 프로비저닝된 쓰기 처리량이 증가하고 향후 제한이 방지됩니다. 레코드를 수집할 때 파티션 키 선택도 고려해야 합니다. 무작위 파티션 키는 가급적 스트림의 샤드 전체에 균등하게 레코드를 분산시키기 때문에 선호됩니다.

인텐트: 이 경보는 스트림이나 샤드의 제한으로 인해 생산자가 레코드 작성을 거부당하는지 여부를 감지할 수 있습니다. 스트림이 Provisioned 모드인 경우 이 경보를 설정하면 데이터 스트림이 한도에 도달했을 때 사전 조치를 취할 수 있으므로 프로비저닝된 용량을 최적화하거나 적절한 조정 조치를 취하여 데이터 손실을 방지하고 원활한 데이터 처리를 유지할 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 일반적으로 제한이 발생한 요청은 재시도될 수 있으므로 임곗값을 0으로 설정하면 경보가 너무 민감해집니다. 하지만 지속적인 제한은 스트림 쓰기에 영향을 미칠 수 있으므로 이를 감지하도록 경보 임곗값을 설정해야 합니다. 애플리케이션 및 재시도 구성에 대해 제한이 발생한 요청에 따라 임곗값을 백분율로 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: 없음

경보 설명: 이 경보는 Lambda 함수의 동시성이 계정의 리전 수준 동시성 한도에 근접하는지 모니터링하는 데 도움이 됩니다. 동시 실행 한도에 도달하면 함수에 제한이 발생하기 시작합니다. 제한 현상을 방지하려면 다음 작업을 수행할 수 있습니다.

인텐트: 이 경보는 Lambda 함수의 동시성이 계정의 리전 수준 동시성 할당량에 근접하는지 사전에 감지하여 조치를 취할 수 있도록 해줍니다. ClaimedAccountConcurrency가 계정의 리전 수준 동시성 할당량에 도달하면 함수가 제한됩니다. 예약 동시성(RC) 또는 프로비저닝된 동시성(PC)을 사용하는 경우 이 경보를 사용하면 ConcurrentExecutions보다 동시성 사용률을 더 잘 파악할 수 있습니다.

통계: Maximum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 리전 내 계정에 설정된 동시 접속자 수 할당량의 약 90%의 값을 계산하고 그 결과를 임곗값으로 사용해야 합니다. 기본적으로 리전 내 모든 함수에 걸쳐 사용자 계정의 동시성 할당량은 1,000입니다. 하지만 Service Quotas 대시보드에서 계정의 할당량을 확인해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: FunctionName

경보 설명: 이 경보는 높은 오류 수를 감지합니다. 오류에는 코드에서 발생하는 예외와 Lambda 런타임에서 발생하는 예외가 포함됩니다. 함수와 관련된 로그를 확인하여 문제를 진단할 수 있습니다.

인텐트: 경보는 함수 호출 시 오류 수가 많은 경우를 감지하는 데 도움이 됩니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 임곗값을 0보다 큰 수로 설정합니다. 정확한 값은 애플리케이션의 오류 허용 오차에 따라 달라질 수 있습니다. 함수가 처리하는 호출의 중요도를 이해해야 합니다. 일부 애플리케이션의 경우 어떠한 오류도 허용되지 않을 수 있지만 다른 애플리케이션에서는 일정한 오차 범위를 허용할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: FunctionName

경보 설명: 이 경보는 제한이 발생한 간접 호출 요청 수가 많음을 감지합니다. 스케일 업에 사용할 수 있는 동시성이 없는 경우 제한이 발생합니다. 이 문제를 해결할 몇 가지 방법이 있습니다. 1) 이 리전의 AWS Support에 동시성 증가를 요청합니다. 2) 함수의 성능 문제를 식별하고 처리 속도를 개선하여 처리량을 개선합니다. 3) 함수를 간접 호출할 때마다 더 많은 메시지가 처리되도록 함수의 배치 크기를 늘립니다.

인텐트: 경보는 Lambda 함수에 대해 많은 수의 제한된 간접 호출 요청 수를 감지하는 데 도움이 됩니다. 제한으로 인해 요청이 계속 거부되는지, 지속적인 제한을 피하기 위해 Lambda 함수 성능을 개선하거나 동시성 용량을 늘려야 하는지를 파악해야 합니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 임곗값을 0보다 큰 수로 설정합니다. 정확한 임곗값은 애플리케이션의 허용 오차에 따라 달라질 수 있습니다. 함수의 사용 및 조정 요구 사항에 따라 임곗값을 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: FunctionName

경보 설명: 이 경보는 Lambda 함수가 이벤트를 처리하는 데 오랜 시간이 걸리는 것을 감지합니다. 함수 코드가 변경되어 함수를 실행하는 데 시간이 더 오래 걸리거나 함수의 종속성이 더 오래 걸리기 때문에 지속 시간이 길어질 수 있습니다.

인텐트: 이 경보는 Lambda 함수의 긴 실행 기간을 감지할 수 있습니다. 런타임 기간이 길면 함수를 간접 호출하는 데 시간이 더 오래 걸리고 Lambda가 더 많은 수의 이벤트를 처리하는 경우 간접 호출의 동시 실행 용량에도 영향을 미칠 수 있습니다. Lambda 함수의 실행 시간이 계속 예상보다 길어지는지 파악해야 합니다.

통계: p90

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 기간 임곗값은 애플리케이션과 워크로드, 성능 요구 사항에 따라 달라집니다. 고성능 요구 사항의 경우 임곗값을 더 짧은 시간으로 설정하여 함수가 기대치를 충족하는지 확인합니다. 또한 기간 지표에 대한 과거 데이터를 분석하여 소요 시간이 함수의 예상 성능과 일치하는지 확인한 다음 임곗값을 과거 평균보다 긴 시간으로 설정할 수 있습니다. 임곗값을 구성된 함수의 제한 시간보다 낮게 설정해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: FunctionName

경보 설명: 이 경보는 함수의 동시성이 계정의 리전 수준 동시성 한도에 근접하는지 모니터링하는 데 도움이 됩니다. 동시 실행 한도에 도달하면 함수에 제한이 발생하기 시작합니다. 제한 현상을 방지하려면 다음 작업을 수행할 수 있습니다.

예약된 동시성 및 프로비저닝된 동시성 사용률을 더 잘 파악하려면 대신 새 지표 ClaimedAccountConcurrency에 경보를 설정하세요.

인텐트: 이 경보는 함수의 동시성이 계정의 리전 수준 동시성 할당량에 근접하는지 사전에 감지하여 조치를 취할 수 있도록 해줍니다. 함수가 계정의 리전 수준 동시성 할당량에 도달하면 함수가 제한됩니다.

통계: Maximum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 임곗값을 해당 리전의 계정에 설정된 동시성 할당량의 약 90%로 설정합니다. 기본적으로 리전 내 모든 함수에 걸쳐 사용자 계정의 동시성 할당량은 1,000입니다. 하지만 AWS 지원팀에 문의하여 계정의 할당량을 늘릴 수 있으므로 계정 할당량을 확인합니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: function_name

경보 설명: 이 경보는 Lambda 함수의 메모리 사용률이 구성된 한도에 근접하는지 감지하는 데 사용됩니다. 문제 해결을 위해 1) 코드 최적화를 시도합니다. 2) 메모리 요구량을 정확하게 예측하여 메모리 할당량을 적절하게 조정합니다. 이에 대한 내용은 Lambda Power Tuning을 참조하세요. 3) 연결 풀링을 사용합니다. RDS 데이터베이스의 연결 풀링에 대한 내용은 Lambda와 함께 Amazon RDS Proxy 사용을 참조하세요. 4) 호출 사이에 대량의 데이터를 메모리에 저장하지 않도록 함수를 설계하는 것도 고려해 볼 수 있습니다.

인텐트: 이 경보는 Lambda 함수의 메모리 사용률이 구성된 한도에 근접하는지 감지하는 데 사용됩니다.

통계: Average

입곗값 제안: 90.0

임곗값 정당화: 메모리 사용률이 할당된 메모리의 90%를 초과할 때 경보를 받으려면 임곗값을 90%로 설정합니다. 메모리 사용량에 대한 워크로드가 우려되는 경우 이 값을 더 낮게 조정할 수 있습니다. 또한 이 지표의 과거 데이터를 확인하고 그에 따라 임곗값을 설정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: NatGatewayId

경보 설명: 이 경보는 NAT 게이트웨이가 새 연결에 포트를 할당할 수 없는 경우를 감지하는 데 도움이 됩니다. 이 문제를 해결하려면 NAT 게이트웨이의 포트 할당 오류 해결을 참조하세요.

인텐트: 이 경보는 NAT 게이트웨이가 소스 포트를 할당할 수 없는지 여부를 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: ErrorPortAllocation의 값이 0보다 크면 NATGateway를 통해 인기 있는 단일 대상에 대한 동시 연결이 너무 많이 열려 있음을 의미합니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: NatGatewayId

경보 설명: 이 경보는 NAT 게이트웨이가 패킷을 삭제한 시점을 감지하는 데 도움이 됩니다. 이는 NAT 게이트웨이 문제로 인해 발생할 수 있으므로 AWS 서비스 상태 대시보드에서 해당 리전의 AWS NAT 게이트웨이 상태를 확인합니다. 이를 통해 NAT 게이트웨이를 사용하는 트래픽과 관련된 네트워크 문제의 상관 관계를 파악할 수 있습니다.

인텐트: 이 경보는 NAT 게이트웨이가 패킷을 삭제하는지 여부를 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: NAT 게이트웨이 총 트래픽의 0.01%를 계산하고 이 결과를 임곗값으로 사용해야 합니다. NAT 게이트웨이 트래픽의 과거 데이터를 사용하여 임곗값을 결정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: VPC Id, VPC 엔드포인트 Id, 엔드포인트 유형,서브넷 Id, 서비스 이름

경보 설명: 이 경보는 엔드포인트에서 삭제한 패킷 수를 모니터링하여 엔드포인트 또는 엔드포인트 서비스가 비정상인지 여부를 감지하는 데 도움이 됩니다. VPC 엔드포인트에 도착하는 크기가 8500바이트보다 큰 패킷은 삭제됩니다. 문제 해결은 인터페이스 VPC 엔드포인트와 엔드포인트 서비스 간의 연결 문제를 참조하세요.

인텐트: 이 경보는 엔드포인트 또는 엔드포인트 서비스가 비정상인지 여부를 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 사용 사례에 따라 임곗값을 설정합니다. 엔드포인트 또는 엔드포인트 서비스의 비정상 상태를 파악하려면 엄청난 데이터 손실이 발생하기 전에 문제를 해결할 수 있도록 임곗값을 낮게 설정해야 합니다. 과거 데이터를 사용하여 삭제된 패킷의 허용 범위를 파악하고 그에 따라 임곗값을 설정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: 서비스 Id, 로드 밸런서 Arn, Az

경보 설명: 이 경보를 사용하면 엔드포인트로 전송되는 재설정 패킷 수를 기반으로 엔드포인트 서비스의 비정상 대상을 탐지할 수 있습니다. 서비스 소비자와의 연결 오류를 디버깅할 때 서비스가 RstPacketsSent 지표를 사용하여 연결을 재설정하는지 또는 네트워크 경로에서 다른 오류가 발생하는지 확인할 수 있습니다.

인텐트: 이 경보는 엔드포인트 서비스의 비정상 대상을 탐지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 임곗값은 사용 사례에 따라 다릅니다. 사용 사례에서 대상이 비정상인 것을 허용할 수 있는 경우 임곗값을 높게 설정할 수 있습니다. 사용 사례에서 대상이 비정상인 것을 허용할 수 없는 경우 임곗값을 매우 낮게 설정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 지속적으로 높은 CPU 사용률을 모니터링하는 데 도움이 됩니다. CPU 사용률은 비유휴 시간을 측정합니다. 향상된 모니터링 또는 성능 개선 도우미를 사용하여 MariaDB, MySQL, Oracle 및 PostgreSQL에 대해 CPU 시간(guest, irq, wait, nice 등)을 가장 많이 소비하는 대기 시간을 검토하는 것이 좋습니다. 그런 다음, CPU를 가장 많이 소비하는 쿼리를 평가합니다. 워크로드를 조정할 수 없는 경우 더 큰 DB 인스턴스 클래스로 이동하는 것을 고려합니다.

의도: 이 경보는 매우 긴 응답 시간과 시간 초과를 방지하기 위해 지속적으로 높은 CPU 사용률을 탐지하는 데 사용됩니다. CPU 사용률의 마이크로 버스팅을 확인하려는 경우 경보 평가 시간을 더 짧게 설정할 수 있습니다.

통계: Average

권장 임곗값: 90.0

임곗값 근거: CPU 사용률이 무작위로 급증해도 데이터베이스 성능이 저하되지는 않지만 CPU가 계속 높게 유지되면 향후 데이터베이스 요청에 방해가 될 수 있습니다. 전체 데이터베이스 워크로드에 따라 RDS/Aurora 인스턴스의 CPU가 높으면 전체 성능이 저하될 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 많은 수의 연결을 탐지합니다. 기존 연결을 검토하여 '비활동' 상태이거나 제대로 닫히지 않은 연결을 종료합니다. 연결 풀링을 사용하여 새 연결 수를 제한하는 것이 좋습니다. 또는 더 많은 메모리를 가진 클래스를 사용하도록 DB 인스턴스 크기를 늘려서 'max_connections'의 기본값을 높이거나, 워크로드를 지원할 수 있는 경우 RDS와 Aurora MySQL 및 PostgreSQL에서 현재 클래스의 'max_connections' 값을 늘립니다.

의도: 이 경보는 최대 DB 연결 수에 도달했을 때 연결이 거부되는 것을 방지하는 데 사용됩니다. DB 인스턴스 클래스를 자주 변경하는 경우 메모리와 기본 최대 연결 수가 변경되므로 이 경보는 사용하지 않는 것이 좋습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 근거: 허용되는 연결 수는 DB 인스턴스 클래스의 크기 및 프로세스/연결과 관련된 데이터베이스 엔진별 파라미터에 따라 달라집니다. 데이터베이스의 최대 연결 수의 90~95% 사이 값을 계산하고 해당 결과를 임곗값으로 사용해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 남아 있는 낮은 비율의 처리량 크레딧을 모니터링하는 데 도움이 됩니다. 문제 해결은 RDS의 대기 시간 문제를 참조하세요.

의도: 이 경보는 버스트 버킷에 남아 있는 낮은 비율의 처리량 크레딧을 탐지하는 데 사용됩니다. 바이트 밸런스 비율이 낮으면 처리량 병목 문제가 발생할 수 있습니다. Aurora PostgreSQL 인스턴스에는 이 경보를 사용하지 않는 것이 좋습니다.

통계: Average

권장 임곗값: 10.0

임곗값 근거: 처리량 크레딧 밸런스가 10% 미만이면 나쁨으로 간주되므로 임곗값을 적절히 설정해야 합니다. 애플리케이션이 워크로드에 대해 낮은 처리량을 허용할 수 있는 경우 더 낮은 임곗값을 설정할 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: LESS_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 남아 있는 낮은 비율의 IOPS 크레딧을 모니터링하는 데 도움이 됩니다. 문제 해결은 RDS의 대기 시간 문제를 참조하세요.

의도: 이 경보는 버스트 버킷에 남아 있는 낮은 비율의 I/O 크레딧을 탐지하는 데 사용됩니다. IOPS 밸런스 비율이 낮으면 IOPS 병목 문제가 발생할 수 있습니다. Aurora 인스턴스에는 이 경보를 사용하지 않는 것이 좋습니다.

통계: Average

권장 임곗값: 10.0

임곗값 근거: IOPS 크레딧 밸런스가 10% 미만이면 나쁨으로 간주되므로 임곗값을 적절히 설정합니다. 애플리케이션이 워크로드에 대해 낮은 IOPS를 허용할 수 있는 경우 더 낮은 임곗값을 설정할 수도 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: LESS_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 데이터베이스 연결이 급증하거나 인스턴스가 높은 메모리 압박을 받고 있음을 의미할 수 있는 사용 가능한 메모리 부족을 모니터링하는 데 도움이 됩니다. FreeableMemory 외에도 SwapUsage에 대한 CloudWatch 지표를 모니터링하여 메모리 부족을 확인합니다. 인스턴스 메모리 소비가 자주 너무 높으면 워크로드를 확인하거나 인스턴스 클래스를 업그레이드해야 합니다. Aurora 리더 DB 인스턴스의 경우 클러스터에 리더 DB 인스턴스를 추가하는 것을 고려합니다. Aurora 문제 해결에 대한 자세한 내용은 여유 메모리 부족 문제를 참조하세요.

의도: 이 경보는 메모리 부족으로 인한 연결 거부를 방지하는 데 사용됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 근거: 워크로드 및 인스턴스 클래스에 따라 임곗값을 다르게 설정하는 것이 적절할 수 있습니다. 가용 메모리가 장기간 동안 전체 메모리의 25% 미만으로 떨어지지 않는 것이 좋습니다. Aurora의 경우 임곗값을 5%에 가깝게 설정할 수 있습니다. 지표가 0에 가까울수록 DB 인스턴스가 최대한 스케일 업되었음을 의미하기 때문입니다. 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: LESS_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 사용 가능한 로컬 스토리지 부족을 모니터링하는 데 도움이 됩니다. Aurora PostgreSQL 호환 버전은 오류 로그와 임시 파일을 저장하는 데 로컬 스토리지를 사용합니다. Aurora MySQL은 로컬 스토리지를 사용하여 오류 로그, 일반 로그, 느린 쿼리 로그, 감사 로그 및 비 InnoDB 임시 테이블을 저장합니다. 이러한 로컬 스토리지 볼륨은 Amazon EBS Store에서 백업하며, 더 큰 D 인스턴스 클래스를 사용하여 확장할 수 있습니다. 문제 해결을 위해서는 Aurora PostgreSQL 호환과 MySQL 호환을 확인하세요.

의도: 이 경보는 Aurora Serverless v2 이상을 사용하지 않는 경우 Aurora DB 인스턴스가 로컬 스토리지 한도에 얼마나 근접했는지 탐지하는 데 사용됩니다. 임시 테이블 및 로그 파일과 같은 비영구 데이터를 로컬 스토리지에 저장하면 로컬 스토리지 용량이 초과될 수 있습니다. 이 경보를 통해 DB 인스턴스의 로컬 스토리지가 부족해질 때 발생하는 공간 부족 오류를 방지할 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 근거: 볼륨 사용 속도와 추세를 기반으로 사용 가능한 스토리지 양의 약 10~20%를 계산한 다음, 해당 결과를 임곗값으로 사용하여 볼륨이 한도에 도달하기 전에 사전에 조치를 취해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 사용 가능한 스토리지 공간이 부족한지 감시합니다. 스토리지 용량 한도에 자주 도달하는 경우 데이터베이스 스토리지 스케일 업을 고려합니다. 애플리케이션의 예기치 않은 수요 증가에 대비해 약간의 버퍼를 포함합니다. 또는 RDS 스토리지 Auto Scaling을 활성화하는 것도 고려합니다. 또한 사용하지 않거나 오래된 데이터 및 로그를 삭제하여 더 많은 공간을 확보하는 것도 고려합니다. 자세한 내용은 RDS 스토리지 부족 문서 및 PostgreSQL 스토리지 문제 문서를 참조하세요.

의도: 이 경보는 스토리지 가득 참 문제를 방지하는 데 도움이 됩니다. 이렇게 하면 데이터베이스 인스턴스의 스토리지가 부족할 때 발생하는 가동 중지를 방지할 수 있습니다. 스토리지 Auto Scaling을 활성화했거나 데이터베이스 인스턴스의 스토리지 용량을 자주 변경하는 경우에는 이 경보를 사용하지 않는 것이 좋습니다.

통계: Minimum

권장 임곗값: 상황에 따라 다름

임곗값 근거: 임곗값은 현재 할당된 스토리지 공간에 따라 달라집니다. 일반적으로 할당된 스토리지 공간의 10% 값을 계산하고 해당 결과를 임곗값으로 사용해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 PostgreSQL의 트랜잭션 ID 랩어라운드를 방지하는 데 도움이 됩니다. 이 블로그의 문제 해결 단계를 참조하여 문제를 조사하고 해결합니다. 또한 이 블로그를 참조하여 autovacuum 개념, 일반적인 문제 및 모범 사례에 대해 더 자세히 알아볼 수 있습니다.

의도: 이 경보는 PostgreSQL의 트랜잭션 ID 랩어라운드를 방지하는 데 사용됩니다.

통계: Average

권장 임곗값: 1.0E9

임곗값 근거: 이 임곗값을 10억으로 설정하면 문제를 조사할 시간을 확보할 수 있습니다. 기본 autovacuum_freeze_max_age 값은 2억입니다. 가장 오래된 트랜잭션의 기간이 10억이면 autovacuum은 이 임곗값을 2억 개의 트랜잭션 ID 목표 미만으로 유지하는 데 문제가 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 1

평가 기간: 1

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 긴 읽기 지연 시간을 모니터링하는 데 도움이 됩니다. 스토리지 지연 시간이 길면 워크로드가 리소스 제한을 초과하기 때문입니다. 인스턴스 및 할당된 스토리지 구성을 기준으로 I/O 사용률을 검토할 수 있습니다. Amazon RDS 인스턴스의 IOPS 병목 현상으로 인해 발생하는 Amazon EBS 볼륨의 대기 시간 문제를 해결하려면 어떻게 해야 합니까?를 참조하세요. Aurora의 경우 I/O-Optimized 스토리지 구성이 있는 인스턴스 클래스로 전환할 수 있습니다. 지침은 Planning I/O in Aurora를 참조하세요.

의도: 이 경보는 긴 읽기 지연 시간을 탐지하는 데 사용됩니다. 데이터베이스 디스크는 일반적으로 읽기/쓰기 지연 시간이 짧지만 작업 지연 시간이 길어질 수 있는 문제가 있을 수 있습니다.

통계: p90

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 사용 사례에 따라 크게 달라집니다. 읽기 지연 시간이 20밀리초보다 길면 조사가 필요할 수 있습니다. 애플리케이션의 읽기 작업 지연 시간이 길어질 수 있는 경우 더 높은 임곗값을 설정할 수도 있습니다. 읽기 지연 시간의 중요도와 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 알람은 복제본이 기본 인스턴스보다 뒤처진 시간(초)을 파악하는 데 도움이 됩니다. PostgreSQL 읽기 전용 복제본은 원본 데이터베이스 인스턴스에서 사용자 트랜잭션이 발생하지 않는 경우 최대 5분의 복제 지연을 보고합니다. ReplicaLag 지표가 0에 도달하면 복제본이 기본 DB 인스턴스를 따라잡은 것입니다. ReplicaLag 지표가 -1을 반환하는 경우 복제가 현재 활성 상태가 아닙니다. RDS PostgreSQL과 관련된 지침은 복제 모범 사례를 참조하고 ReplicaLag 및 관련 오류 문제 해결은 ReplicaLag 문제 해결을 참조하세요.

의도: 이 경보는 기본 인스턴스의 장애 시 발생할 수 있는 데이터 손실을 반영하는 복제 지연을 탐지할 수 있습니다. 복제본이 기본 인스턴스보다 너무 뒤쳐져 기본 인스턴스에 장애가 발생하면 복제본에서 기본 인스턴스에 있던 데이터가 누락됩니다.

통계: Maximum

권장 임곗값: 60.0

임곗값 근거: 일반적으로 허용되는 지연은 애플리케이션에 따라 다릅니다. 60초를 넘지 않는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 긴 쓰기 지연 시간을 모니터링하는 데 도움이 됩니다. 스토리지 지연 시간이 길면 워크로드가 리소스 제한을 초과하기 때문입니다. 인스턴스 및 할당된 스토리지 구성을 기준으로 I/O 사용률을 검토할 수 있습니다. Amazon RDS 인스턴스의 IOPS 병목 현상으로 인해 발생하는 Amazon EBS 볼륨의 대기 시간 문제를 해결하려면 어떻게 해야 합니까?를 참조하세요. Aurora의 경우 I/O-Optimized 스토리지 구성이 있는 인스턴스 클래스로 전환할 수 있습니다. 지침은 Planning I/O in Aurora를 참조하세요.

의도: 이 경보는 긴 쓰기 지연 시간을 탐지하는 데 사용됩니다. 데이터베이스 디스크는 일반적으로 읽기/쓰기 지연 시간이 짧지만 작업 지연 시간이 길어지는 문제가 발생할 수 있습니다. 이를 모니터링하면 디스크 지연 시간이 예상만큼 낮은지 확인할 수 있습니다.

통계: p90

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 사용 사례에 따라 크게 달라집니다. 쓰기 지연 시간이 20밀리초보다 길면 조사가 필요할 수 있습니다. 애플리케이션의 쓰기 작업 지연 시간이 길어질 수 있는 경우 더 높은 임곗값을 설정할 수도 있습니다. 쓰기 지연 시간의 중요도와 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 높은 DB 로드를 모니터링하는 데 도움이 됩니다. 프로세스 수가 vCPUs 수를 초과하면 프로세스가 대기열에 추가되기 시작합니다. 대기열이 늘어나면 성능에 영향이 있습니다. DB 로드가 최대 vCPU를 초과하는 경우가 많고 기본 대기 상태가 CPU인 경우 CPU에 과부하가 걸립니다. 이 경우 성능 개선 도우미/향상된 모니터링에서 CPUUtilization, DBLoadCPU 및 대기 중인 작업을 모니터링할 수 있습니다. 연결 수를 인스턴스에 맞게 조절하거나, CPU 로드가 높은 SQL 쿼리를 미세 조정하거나, 인스턴스 클래스의 크기를 늘리는 것이 좋습니다. 대기 상태의 인스턴스가 높고 일관적이라는 것은 해결해야 할 병목 현상이나 리소스 경합 문제가 있을 수 있음을 나타냅니다.

의도: 이 경보는 높은 DB 로드를 탐지하는 데 사용됩니다. DB 로드가 높으면 DB 인스턴스에서 성능 문제가 발생할 수 있습니다. 이 경보는 서버리스 DB 인스턴스에는 해당되지 않습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 근거: 최대 vCPU 값은 DB 인스턴스의 vCPU(가상 CPU) 코어 수에 따라 결정됩니다. 최대 vCPU에 따라 다른 임곗값이 적절할 수 있습니다. 이상적으로 DB 로드가 vCPU 라인을 넘지 않아야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBClusterIdentifier

경보 설명: 이 경보는 낮은 잔여 총 볼륨을 모니터링하는 데 도움이 됩니다. 남은 총 볼륨이 크기 제한에 도달하면 클러스터는 공간 부족 오류를 보고합니다. Aurora 스토리지는 클러스터 볼륨의 데이터에 따라 자동으로 규모가 조정되며 DB 엔진 버전에 따라 최대 128TiB 또는 64TiB까지 확장됩니다. 더 이상 필요하지 않은 테이블과 데이터베이스를 삭제하여 스토리지를 줄이는 것을 고려합니다. 자세한 내용은 스토리지 조정을 확인하세요.

의도: 이 경보는 Aurora 클러스터가 볼륨 크기 제한에 얼마나 근접했는지 탐지하는 데 사용됩니다. 이 경보는 클러스터의 공간이 부족할 때 발생하는 공간 부족 오류를 방지할 수 있습니다. 이 경보는 Aurora MySQL에만 권장됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 근거: 볼륨 사용량 증가 속도 및 추세를 기준으로 실제 크기 제한의 10~20%를 계산한 다음, 해당 결과를 임곗값으로 사용하여 볼륨이 제한에 도달하기 전에 사전 조치를 취해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_THRESHOLD

측정기준: DBClusterIdentifier, 역할=WRITER

경보 설명: 이 경보는 Aurora writer 인스턴스 복제의 오류 상태를 모니터링하는 데 도움이 됩니다. 자세한 내용은 AWS 리전 간 Aurora MySQL DB 클러스터 복제를 참조하세요. 문제 해결은 Aurora MySQL 복제 문제를 참조하세요.

의도: 이 경보는 작성자 인스턴스가 오류 상태이고 소스를 복제할 수 없는지 여부를 탐지하는 데 사용됩니다. 이 경보는 Aurora MySQL에만 권장됩니다.

통계: Average

권장 임곗값: -1.0

임곗값 근거: 복제본이 오류 상태인 경우 Aurora MySQL에서 이 값을 게시하므로 임곗값으로 -1을 사용하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 2

평가 기간: 2

비교 연산자: LESS_THAN_OR_EQUAL_TO_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 Aurora DB 인스턴스에서 차단된 높은 트랜잭션 수를 모니터링하는 데 도움이 됩니다. 차단된 트랜잭션은 롤백 또는 커밋으로 종료될 수 있습니다. 높은 동시성, 트랜잭션 유휴 또는 장기 실행 트랜잭션으로 인해 트랜잭션이 차단될 수 있습니다. 문제 해결은 Aurora MySQL 설명서를 참조하세요.

의도: 이 경보는 트랜잭션 롤백 및 성능 저하를 방지하기 위해 Aurora DB 인스턴스에서 많은 수의 차단된 트랜잭션을 탐지하는 데 사용됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 근거: ActiveTransactions 지표를 사용하여 인스턴스의 전체 트랜잭션 중 5%를 계산하고 해당 결과를 임곗값으로 사용해야 합니다. 또한 차단된 트랜잭션의 중요도와 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 Aurora 클러스터의 지속적으로 낮은 캐시 적중률을 모니터링하는 데 도움이 됩니다. 적중률이 낮다면 이 DB 인스턴스에 대한 쿼리가 디스크로 자주 이동한다는 뜻입니다. 문제를 해결하려면 워크로드를 조사하여 어떤 쿼리가 이 동작을 일으키는지 확인하고 DB 인스턴스 RAM 권장 사항 문서를 참조하세요.

의도: 이 경보는 Aurora 인스턴스의 지속적인 성능 저하를 방지하기 위해 일관되게 낮은 캐시 적중률을 탐지하는 데 사용됩니다.

통계: Average

권장 임곗값: 80.0

임곗값 근거: 버퍼 캐시 적중률의 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 10

평가 기간: 10

비교 연산자: LESS_THAN_THRESHOLD

측정기준: DBClusterIdentifier, 역할=WRITER

경보 설명: 이 경보는 라이터 DB 인스턴스의 가동 중지 시간이 짧은지 모니터링하는 데 도움이 됩니다. 라이터 DB 인스턴스는 재부팅, 유지 관리, 업그레이드 또는 장애 조치로 인해 다운될 수 있습니다. 클러스터의 장애 조치로 인해 가동 시간이 0에 도달하고 클러스터에 하나 이상의 Aurora 복제본이 있으면 실패 이벤트 중에 Aurora 복제본이 기본 라이터 인스턴스로 승격됩니다. DB 클러스터의 가용성을 높이려면 두 개 이상의 서로 다른 가용 영역에 하나 이상의 Aurora 복제본을 생성하는 것을 고려합니다. 자세한 내용은 Aurora 가동 중지에 영향을 미치는 요인을 참조하세요.

의도: 이 경보는 Aurora 라이터 DB 인스턴스의 가동 중지 여부를 탐지하는 데 사용됩니다. 이를 통해 중단 또는 장애 조치로 인해 발생하는 라이터 인스턴스의 장기 실행 장애를 방지할 수 있습니다.

통계: Average

권장 임곗값: 0.0

임곗값 근거: 실패 이벤트로 인해 잠시 중단이 발생하며 그 동안 읽기 및 쓰기 작업은 예외와 함께 실패합니다. 하지만, 일반적인 서비스 복구 시간은 60초 미만이지만 대부분 30초 미만에 복원됩니다.

기간: 60

경보를 보낼 데이터 포인트: 2

평가 기간: 2

비교 연산자: LESS_THAN_OR_EQUAL_TO_THRESHOLD

측정기준: DBInstanceIdentifier

경보 설명: 이 경보는 Aurora 인스턴스의 일관되게 높은 롤백 세그먼트 기록 길이를 모니터링하는 데 도움이 됩니다. InnoDB 기록 목록 길이가 길면 오래된 행 버전, 쿼리 및 데이터베이스 종료가 많아 속도가 느려진 것입니다. 자세한 내용 및 문제 해결은 InnoDB 기록 목록 길이가 크게 늘어남을 참조하세요.

의도: 이 경보는 일관되게 긴 롤백 세그먼트 기록 길이를 탐지하는 데 사용됩니다. 이를 통해 Aurora 인스턴스에서 지속적인 성능 저하와 높은 CPU 사용률을 방지할 수 있습니다. 이 경보는 Aurora MySQL에만 권장됩니다.

통계: Average

권장 임곗값: 1000000.0

임곗값 근거: 이 임곗값을 100만으로 설정하면 문제를 조사할 시간을 확보할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정기준: DBClusterIdentifier, 역할=WRITER

경보 설명: 이 경보는 높은 스토리지 네트워크 처리량을 모니터링하는 데 도움이 됩니다. 스토리지 네트워크 처리량이 EC2 인스턴스의 총 네트워크 대역폭을 초과할 경우 읽기 및 쓰기 지연 시간이 길어져 성능이 저하될 수 있습니다. AWS 콘솔에서 EC2 인스턴스 유형을 확인할 수 있습니다. 문제 해결을 위해 쓰기/읽기 지연 시간에 대한 변경 사항을 확인하고 이 지표에서도 경보가 발생했는지 평가합니다. 경보가 발생한 경우 경보가 트리거된 시간 동안의 워크로드 패턴을 평가합니다. 이를 통해 워크로드를 최적화하여 총 네트워크 트래픽 양을 줄일 수 있는지 확인할 수 있습니다. 이것이 불가능한 경우 인스턴스 크기 조정을 고려해야 할 수도 있습니다.

의도: 이 경보는 높은 스토리지 네트워크 처리량을 탐지하는 데 사용됩니다. 높은 처리량을 탐지하면 네트워크 패킷 손실과 성능 저하를 방지할 수 있습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 근거: EC2 인스턴스 유형의 총 네트워크 대역폭의 약 80~90%를 계산한 다음, 해당 결과를 임곗값으로 사용하여 네트워크 패킷이 영향을 받기 전에 사전 조치를 취해야 합니다. 또한 스토리지 네트워크 처리량의 중요도와 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: HealthCheckId

경보 설명: 이 경보는 상태 검사기에 따라 비정상 엔드포인트를 탐지하는 데 도움이 됩니다. 장애가 발생하여 비정상 상태가 된 이유를 이해하려면 Route 53 Health Check Console의 상태 검사기 탭을 사용하여 각 리전의 상태와 상태 확인의 마지막 실패를 확인합니다. 상태 탭에는 엔드포인트가 비정상으로 보고된 이유도 표시됩니다. 문제 해결 단계를 참조하세요.

인텐트: 이 경보는 Route53 상태 검사기를 사용하여 비정상 엔드포인트를 탐지합니다.

통계: Average

권장 임곗값: 1.0

임곗값 정당화: 엔드포인트가 정상이면 상태가 1로 보고됩니다. 1 미만이면 모두 비정상입니다.

기간: 60

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: BucketName, FilterId

경보 설명: 이 경보를 통해 클라이언트 요청에 대한 응답으로 생성된 4xx 오류 상태 코드의 총 개수를 보고할 수 있습니다. 예를 들어 403 오류 코드는 잘못된 IAM 정책을 나타내고, 404 오류 코드는 클라이언트 애플리케이션이 제대로 작동하지 않음을 나타낼 수 있습니다. S3 서버 액세스 로깅을 일시적으로 활성화하면 HTTP 상태 및 오류 코드 필드를 사용하여 문제의 원인을 정확히 찾아낼 수 있습니다. 오류 코드에 대한 자세한 내용은 오류 응답을 참조하세요.

인텐트: 이 경보는 일반적인 4xx 오류 발생률에 대한 기준을 만드는 데 사용되므로 설정 문제를 나타낼 수 있는 비정상이 있는지 확인할 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 권장 임곗값은 전체 요청의 5% 이상에서 4XX 오류가 발생하는지 감지하는 것입니다. 자주 발생하는 4XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다. 허용 가능한 수준의 4XX 오류를 고려하여 요청 로드에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: BucketName, FilterId

경보 설명: 이 경보는 많은 수의 서버 측 오류 감지에 도움이 됩니다. 이러한 오류는 클라이언트가 요청을 했지만 서버가 완료하지 못했음을 나타냅니다. 이를 통해 애플리케이션이 S3로 인해 직면한 문제의 상관 관계를 파악할 수 있습니다. 오류를 효율적으로 처리하거나 줄이는 데 도움이 되는 자세한 내용은 성능 설계 패턴 최적화를 참조하세요. 오류는 S3 문제로 인해 발생할 수도 있으므로 AWS 서비스 상태 대시보드에서 해당 리전의 Amazon S3 상태를 확인합니다.

인텐트: 이 경보는 5xx 오류로 인해 애플리케이션에 문제가 발생하는지 감지하는 데 도움이 될 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 전체 요청의 5% 이상에서 5XXError가 발생하는지 감지하도록 임곗값을 설정하는 것이 좋습니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: SourceBucket, DestinationBucket, RuleId

경보 설명: 이 경보는 복제 실패를 이해하는 데 도움이 됩니다. 이 지표는 S3 CRR 또는 S3 SRR을 사용하여 복제된 새 객체의 상태를 추적하고 S3 배치 복제를 사용하여 복제된 기존 객체도 추적합니다. 자세한 내용은 복제 문제 해결을 참조하세요.

인텐트: 이 경보는 실패한 복제 작업이 있는지 감지하는 데 사용됩니다.

통계: Maximum

권장 임곗값: 0.0

임곗값 정당화: 이 지표는 작업이 성공하면 값을 0으로 내보내고, 1분 동안 수행된 복제 작업이 없는 경우에는 아무 것도 출력하지 않습니다. 지표가 0보다 큰 값을 내보내는 경우 복제 작업은 실패입니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: AccessPointName, DataSourceARN

경보 설명: 이 경보는 클라이언트 요청에 대한 응답으로 생성된 4xx 오류 상태 코드의 총 개수를 보고하는 데 도움이 됩니다. S3 서버 액세스 로깅을 일시적으로 활성화하면 HTTP 상태 및 오류 코드 필드를 사용하여 문제의 원인을 정확히 찾아낼 수 있습니다.

인텐트: 이 경보는 일반적인 4xx 오류 발생률에 대한 기준을 만드는 데 사용되므로 설정 문제를 나타낼 수 있는 비정상이 있는지 확인할 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 전체 요청의 5% 이상에서 4XXError가 발생하는지 감지하도록 임곗값을 설정하는 것이 좋습니다. 자주 발생하는 4XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다. 허용 가능한 수준의 4XX 오류를 고려하여 요청 로드에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: AccessPointName, DataSourceARN

경보 설명: 이 경보는 많은 수의 서버 측 오류 감지에 도움이 됩니다. 이러한 오류는 클라이언트가 요청을 했지만 서버가 완료하지 못했음을 나타냅니다. 이러한 오류는 S3 문제로 인해 발생할 수도 있으므로 AWS 서비스 상태 대시보드에서 해당 리전의 Amazon S3 상태를 확인합니다. 이를 통해 애플리케이션이 S3로 인해 직면한 문제의 상관 관계를 파악할 수 있습니다. 이러한 오류를 효율적으로 처리하거나 줄이는 데 도움이 되는 자세한 내용은 성능 설계 패턴 최적화를 참조하세요.

인텐트: 이 경보는 5xx 오류로 인해 애플리케이션에 문제가 발생하는지 감지하는 데 도움이 될 수 있습니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 전체 요청의 5% 이상에서 5XX 오류가 발생하는지 감지하도록 임곗값을 설정하는 것이 좋습니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: AccessPointName, DataSourceARN

경보 설명: 이 경보는 S3 Object Lambda에 대한 호출에서 장애(500s)를 감지하고 진단하는 데 도움이 됩니다. 이러한 오류는 요청에 대한 응답을 담당하는 Lambda 함수의 오류 또는 잘못된 구성으로 인해 발생할 수 있습니다. 객체 Lambda 액세스 포인트와 관련된 Lambda 함수의 CloudWatch 로그 스트림을 조사하면 S3 객체 Lambda의 응답을 기반으로 문제의 원인을 정확히 찾아낼 수 있습니다.

인텐트: 이 경보는 WriteGetObjectResponse 호출에서 발생하는 4xx 클라이언트 오류를 탐지하는 데 사용됩니다.

통계: Average

권장 임곗값: 0.05

임곗값 정당화: 전체 요청의 5% 이상에서 4XXError가 발생하는지 감지하도록 임곗값을 설정하는 것이 좋습니다. 자주 발생하는 4XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다. 허용 가능한 수준의 4XX 오류를 고려하여 요청 로드에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TopicName

경보 설명: 이 경보는 게시된 SNS 메시지 수가 너무 적을 때 이를 감지할 수 있습니다. 문제 해결을 위해 게시자가 보내는 트래픽이 적은 이유를 확인합니다.

인텐트: 이 경보를 사용하면 알림 게시의 현저한 저하를 사전에 모니터링하고 감지할 수 있습니다. 이를 통해 애플리케이션 또는 비즈니스 프로세스의 잠재적 문제를 식별하여 적절한 조치를 취해 예상되는 알림 흐름을 유지할 수 있습니다. 시스템에서 처리하는 트래픽이 최소화될 것으로 예상되면 이 경보를 생성해야 합니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 게시되는 메시지 수는 애플리케이션에 게시될 것으로 예상되는 메시지 수와 일치해야 합니다. 또한 과거 데이터, 추세 및 트래픽을 분석하여 적절한 임곗값을 찾을 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: TopicName

경보 설명: 이 경보는 전달된 SNS 메시지 수가 너무 적을 때 이를 감지할 수 있습니다. 이는 의도하지 않은 엔드포인트 구독 취소나 메시지 지연을 유발하는 SNS 이벤트 때문일 수 있습니다.

인텐트: 이 경보는 전송된 메시지 양의 감소를 감지하는 데 도움이 됩니다. 시스템에서 처리하는 트래픽이 최소화될 것으로 예상되면 이 경보를 생성해야 합니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 전달되는 메시지 수는 생성된 예상 메시지 수 및 소비자 수와 일치해야 합니다. 또한 과거 데이터, 추세 및 트래픽을 분석하여 적절한 임곗값을 찾을 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: TopicName

경보 설명: 이 경보는 실패한 SNS 메시지 수가 너무 많을 때 이를 감지할 수 있습니다. 실패한 알림 문제를 해결하려면 CloudWatch Logs에 로깅을 활성화합니다. 로그를 확인하면 실패한 구독자와 해당 구독자가 반환하는 상태 코드를 찾는 데 도움이 될 수 있습니다.

인텐트: 이 경보를 통해 알림 전달과 관련된 문제를 사전에 발견하고 적절한 조치를 취해 문제를 해결할 수 있습니다.

통계: Sum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 실패한 알림의 영향에 따라 크게 달라집니다. 최종 사용자에게 제공되는 SLA, 내결함성, 알림의 중요도를 검토하고 과거 데이터를 분석한 다음 그에 따라 임곗값을 선택합니다. SQS, Lambda 또는 Firehose 구독만 있는 주제의 경우 실패한 알림 수는 0이어야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TopicName

경보 설명: 이 경보는 게시자 또는 구독자의 잠재적 문제를 모니터링하고 해결하는 데 도움이 됩니다. 게시자가 잘못된 속성을 가진 메시지를 게시하고 있는지 또는 구독자에게 부적절한 필터가 적용되었는지 확인합니다. 또한 CloudWatch Logs를 분석하여 문제의 근본 원인을 찾을 수 있습니다.

인텐트: 경보는 게시된 메시지가 유효하지 않은지 또는 구독자에게 부적절한 필터가 적용되었는지 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: 잘못된 속성은 게시자의 실수인 경우가 많습니다. 정상 시스템에서는 잘못된 속성이 예상되지 않으므로 임곗값을 0으로 설정하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TopicName

경보 설명: 이 경보는 게시자 또는 구독자의 잠재적 문제를 모니터링하고 해결하는 데 도움이 됩니다. 게시자가 메시지 본문이 잘못된 메시지를 게시하고 있는지 또는 구독자에게 부적절한 필터가 적용되었는지 확인합니다. 또한 CloudWatch Logs를 분석하여 문제의 근본 원인을 찾을 수 있습니다.

인텐트: 경보는 게시된 메시지가 유효하지 않은지 또는 구독자에게 부적절한 필터가 적용되었는지 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: 잘못된 메시지 본문은 게시자의 실수인 경우가 많습니다. 정상 시스템에서는 잘못된 메시지 본문이 예상되지 않으므로 임곗값을 0으로 설정하는 것이 좋습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TopicName

경보 설명: 이 경보는 DLQ(Dead Letter Queue)로 이동되는 메시지 수를 모니터링하는 데 도움이 됩니다.

인텐트: 경보는 DLQ(Dead Letter Queue)로 이동된 메시지를 감지하는 데 사용됩니다. SNS가 SQS, Lambda 또는 Firehose와 결합된 경우 이 경보를 생성하는 것이 좋습니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: 구독자 유형과 상관없이 정상 시스템에서는 메시지를 DLQ(Dead Letter Queue)로 이동해서는 안 됩니다. 메시지가 대기열에 도착하면 알림을 받는 것이 좋습니다. 근본 원인을 식별하여 해결할 수 있고 DLQ(Dead Letter Queue)에 있는 메시지를 다시 입력하여 데이터 손실을 방지할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TopicName

경보 설명: 이 경보는 DLQ(Dead Letter Queue)로 이동할 수 없는 메시지를 모니터링하는 데 도움이 됩니다. DLQ(Dead Letter Queue)가 존재하고 올바르게 구성되어 있는지 확인합니다. 또한 SNS에 DLQ(Dead Letter Queue) 액세스 권한이 있는지도 확인합니다. 자세한 내용은 DLQ(Dead Letter Queue) 설명서를 참조하세요.

인텐트: 경보는 DLQ(Dead Letter Queue)로 이동하지 못한 메시지를 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: 메시지를 DLQ(Dead Letter Queue)로 이동할 수 없는 경우는 거의 항상 실수입니다. 권장 임곗값은 0입니다. 즉, 대기열이 구성되면 처리에 실패한 모든 메시지가 DLQ(Dead Letter Queue)에 도달할 수 있어야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TopicName

경보 설명: 이 경보는 SNS에서 메시지를 전송할 수 있는 계정 할당량이 충분한지 모니터링하는 데 도움이 됩니다. 할당량에 도달하면 SNS에서 SMS 메시지를 전송할 수 없습니다. 사용자의 월별 SMS 지출 할당량 설정 또는 AWS에서 지출 할당량 증가 요청에 대한 자세한 내용은 SMS 메시징 기본 설정을 참조하세요.

인텐트: 이 경보는 계정에 SMS 메시지가 성공적으로 전송되기에 충분한 할당량이 있는지 확인하는 데 사용됩니다.

통계: Maximum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 계정의 할당량(계정 지출 한도)에 따라 임곗값을 설정합니다. 할당량 증가를 요청할 시간을 확보할 수 있도록 할당량 한도에 도달했음을 충분히 일찍 알려주는 임곗값을 선택합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: TopicName

경보 설명: 이 경보는 SMS 메시지 전송 실패율을 모니터링하는 데 도움이 됩니다. Cloudwatch Logs를 설정하여 장애의 특성을 파악하고 이에 따라 조치를 취할 수 있습니다.

인텐트: 이 경보는 SMS 메시지 전송 실패를 탐지하는 데 사용됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: SMS 메시지 전송 실패에 대한 허용 한도에 맞춰 경보 임곗값을 설정합니다.

기간: 60

경보를 보낼 데이터 포인트: 5

평가 기간: 5

비교 연산자: GREATER_THAN_THRESHOLD

측정 기준: QueueName

경보 설명: 이 경보는 대기열에 있는 가장 오래된 메시지의 수명을 감시합니다. 이 경보를 사용하여 소비자가 원하는 속도로 SQS 메시지를 처리하고 있는지 모니터링할 수 있습니다. 소비자 수 또는 소비자 처리량을 늘려 메시지 사용 기간을 줄이는 방안을 고려해 보세요. 이 지표를 ApproximateNumberOfMessagesVisible와 함께 사용하여 대기열 백로그의 크기 및 메시지 처리 속도를 결정할 수 있습니다. 메시지가 처리되기 전에 삭제되는 것을 방지하려면 잠재적 독약 메시지를 차단하도록 DLQ(Dead Letter Queue)를 구성하는 것이 좋습니다.

인텐트: 이 경보는 QueueName 대기열에 있는 가장 오래된 메시지의 보존 기간이 너무 긴지 여부를 감지하는 데 사용됩니다. 긴 기간은 메시지가 충분히 빨리 처리되지 않았거나 대기열에 남아 처리할 수 없는 독약 메시지가 있다는 의미일 수 있습니다.

통계: Maximum

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 예상 메시지 처리 시간에 따라 크게 달라집니다. 과거 데이터를 사용하여 평균 메시지 처리 시간을 계산한 다음, 임곗값을 대기열의 소비자가 예상한 최대 SQS 메시지 처리 시간보다 50% 더 높게 설정할 수 있습니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: QueueName

경보 설명: 이 경보는 QueueName와 관련하여 많은 수의 처리 중 메시지를 감지하는 데 도움이 됩니다. 문제 해결을 위해 메시지 백로그 감소를 확인하세요.

인텐트: 이 경보는 대기열에 있는 많은 수의 처리 중인 메시지를 탐지하는 데 사용됩니다. 소비자가 가시성 제한 시간 내에 메시지를 삭제하지 않으면 대기열이 폴링될 때 메시지가 대기열에 다시 나타납니다. FIFO 대기열의 경우 처리 중 메시지가 최대 20,000개까지 있을 수 있습니다. 이 할당량에 도달해도 SQS는 오류 메시지를 반환하지 않습니다. FIFO 대기열은 처음 2만 개의 메시지를 검토하여 사용 가능한 메시지 그룹을 결정합니다. 즉, 단일 메시지 그룹에 메시지 백로그가 있는 경우 백로그에서 메시지를 성공적으로 사용할 때까지 나중에 대기열로 전송된 다른 메시지 그룹의 메시지를 사용할 수 없습니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 이 경보의 권장 임곗값은 처리 중인 예상 메시지 수에 따라 크게 달라집니다. 과거 데이터를 사용하여 처리 중인 최대 예상 메시지 수를 계산하고 임곗값을 이 값의 50% 이상으로 설정할 수 있습니다. 대기열의 소비자가 대기열에서 메시지를 처리하지만 삭제하지는 않는 경우 이 수가 갑자기 증가합니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: QueueName

경보 설명: 이 경보는 메시지 대기열 백로그가 예상보다 커지는지 감시하며 소비자가 너무 느리거나 소비자가 충분하지 않음을 나타냅니다. 이 경보가 ALARM 상태가 되면 소비자 수를 늘리거나 소비자 속도를 높이는 것을 고려해 보세요.

인텐트: 이 경보는 활성 대기열의 메시지 수가 너무 많아 소비자가 메시지를 처리하는 속도가 느리거나 메시지를 처리할 소비자가 충분하지 않은지 여부를 감지하는 데 사용됩니다.

통계: Average

권장 임곗값: 상황에 따라 다름

임곗값 정당화: 표시되는 메시지 수가 예상보다 많으면 소비자가 메시지를 예상 속도로 처리하지 못하고 있음을 나타냅니다. 이 임곗값을 설정할 때 과거 데이터를 고려해야 합니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: QueueName

경보 설명: 이 경보는 QueueName와 관련하여 생산자로부터 전송되는 메시지가 없는지 감지하는 데 도움이 됩니다. 문제 해결을 위해 생산자가 메시지를 보내지 않는 이유를 확인합니다.

인텐트: 이 경보는 생산자가 메시지 전송을 중단하는 시점을 감지하는 데 사용됩니다.

통계: Sum

권장 임곗값: 0.0

임곗값 정당화: 전송된 메시지 수가 0인 경우 생산자는 메시지를 보내지 않습니다. 이 대기열의 TPS가 낮으면 그에 따라 EvaluationPeriods 수를 늘립니다.

기간: 60

경보를 보낼 데이터 포인트: 15

평가 기간: 15

비교 연산자: LESS_THAN_OR_EQUAL_TO_THRESHOLD

측정 기준: VpnId

경보 설명: 이 경보는 하나 이상의 터널 상태가 DOWN인지 파악하는 데 도움이 됩니다. 문제 해결을 위해 VPN 터널 문제 해결을 참조하세요.

인텐트: 이 경보는 하나 이상의 터널이 이 VPN의 DOWN 상태에 있는지 감지하여 영향을 받는 VPN 문제를 해결하는 데 사용됩니다. 터널이 하나만 구성된 네트워크의 경우 이 경보는 항상 ALARM 상태에 있습니다.

통계: Minimum

권장 임곗값: 1.0

임곗값 정당화: 값이 1보다 작으면 하나 이상의 터널이 DOWN 상태임을 나타냅니다.

기간: 300

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: LESS_THAN_THRESHOLD

측정 기준: TunnelIpAddress

경보 설명: 이 경보는 터널의 상태가 DOWN인지 파악하는 데 도움이 됩니다. 문제 해결을 위해 VPN 터널 문제 해결을 참조하세요.

인텐트: 이 경보는 터널이 DOWN 상태에 있는지 감지하여 영향을 받는 VPN 문제를 해결하는 데 사용됩니다. 터널이 하나만 구성된 네트워크의 경우 이 경보는 항상 ALARM 상태에 있습니다.

통계: Minimum

권장 임곗값: 1.0

임곗값 정당화: 값이 1보다 작으면 터널이 DOWN 상태임을 나타냅니다.

기간: 300

경보를 보낼 데이터 포인트: 3

평가 기간: 3

비교 연산자: LESS_THAN_THRESHOLD