Alarmas recomendadas - Amazon CloudWatch

Alarmas recomendadas

En las siguientes secciones se enumeran las métricas para las que sugerimos configurar las alarmas de las prácticas recomendadas. Para cada métrica, también se muestran las dimensiones, la finalidad de la alarma, el umbral recomendado, la justificación del umbral y el período y el número de puntos de datos.

Es posible que algunas métricas aparezcan dos veces en la lista. Esto sucede cuando se recomiendan diferentes alarmas para diferentes combinaciones de las dimensiones de esa métrica.

Los Puntos de datos para la alarma son el número de puntos de datos que se deben infringir para que la alarma pase al estado de ALARMA. Los Períodos de evaluación son el número de períodos que se tienen en cuenta al evaluar la alarma. Si estos números son los mismos, la alarma pasará al estado de ALARMA solo cuando ese número de períodos consecutivos tenga valores que superen el umbral. Si los Puntos de datos para la alarma son inferiores a los de los Períodos de evaluación, se trata de una alarma de tipo “M de N” y la alarma pasa al estado de ALARMA si al menos los puntos de datos de los Puntos de datos para la alarma incumplen con cualquier conjunto de puntos de datos de los Períodos de evaluación. Para obtener más información, consulte Evaluación de una alarma.

Amazon API Gateway

4XXError

Dimensiones: ApiName, Stage

Descripción de la alarma: esta alarma detecta una tasa elevada de errores del lado del cliente. Esto puede indicar un problema en los parámetros de autorización o de la solicitud del cliente. También, puede significar que se ha eliminado un recurso o que un cliente solicita uno que no existe. Considere la posibilidad de habilitar los Registros de CloudWatch y comprobar si hay algún error que pueda causar los errores 4XX. Además, considere la posibilidad de habilitar las métricas detalladas de CloudWatch para ver esta métrica por recurso y método y, así, reducir la búsqueda del origen de los errores. Los errores también pueden deberse a que se supera la limitación configurada. Si las respuestas y los registros indican tasas altas e inesperadas de errores 429, siga esta guía para solucionar el problema.

Finalidad: esta alarma puede detectar altas tasas de errores del lado del cliente en las solicitudes de la puerta de enlace de la API.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: el umbral sugerido detecta cuándo más del 5 % del total de las solicitudes reciben errores 4XX. Sin embargo, puede ajustar el umbral para adaptarlo al tráfico de las solicitudes y a las tasas de error aceptables. También puede analizar los datos históricos para determinar la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. Los errores 4XX que se producen con frecuencia deben ser objeto de alarma. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede ser demasiado sensible.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

5XXError

Dimensiones: ApiName, Stage

Descripción de la alarma: esta alarma ayuda a detectar una alta tasa de errores del lado del servidor. Esto puede indicar que hay algún problema en el backend de la API, en la red o en la integración entre la puerta de enlace de la API y la API del backend. Esta documentación puede ayudarlo a solucionar la causa de los errores 5XX.

Finalidad: esta alarma puede detectar altas tasas de errores del lado del servidor en las solicitudes de la puerta de enlace de la API.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: el umbral sugerido detecta cuándo más del 5 % del total de las solicitudes reciben errores 5XX. Sin embargo, puede ajustar el umbral para adaptarlo al tráfico de las solicitudes y a las tasas de error aceptables. También, puede analizar los datos históricos para determinar la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. Los errores 5XX que se producen con frecuencia deben ser objeto de alarma. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede ser demasiado sensible.

Período: 60

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: GREATER_THAN_THRESHOLD

Recuento

Dimensiones: ApiName, Stage

Descripción de la alarma: esta alarma ayuda a detectar un volumen de tráfico bajo en la etapa de la API de REST. Esto puede ser un indicador de un problema con la aplicación que llama a la API, como el uso de puntos de conexión incorrectos. También, podría indicar un problema con la configuración o los permisos de la API, lo que hace que los clientes no puedan acceder a ella.

Finalidad: esta alarma puede detectar un volumen de tráfico bajo imprevisto en la fase de la API de REST. Recomendamos que cree esta alarma si la API recibe un número predecible y constante de solicitudes en condiciones normales. Si tiene habilitadas las métricas detalladas de CloudWatch y puede predecir el volumen de tráfico normal por método y recurso, le recomendamos que cree alarmas alternativas para tener una supervisión más detallada de las caídas en el volumen de tráfico para cada recurso y método. Esta alarma no se recomienda para las API que no esperan un tráfico constante y uniforme.

Estadística: SampleCount

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral en función del análisis de datos históricos para determinar cuál es el recuento de solicitudes de referencia esperado para la API. Si se establece el umbral en un valor muy alto, es posible que la alarma sea demasiado sensible en los períodos de tráfico bajo normal y esperado. Por el contrario, si se establece en un valor muy bajo, la alarma podría pasar por alto descensos anómalos más pequeños en el volumen del tráfico.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: LESS_THAN_THRESHOLD

Recuento

Dimensiones: ApiName, Stage, Resource, Method

Descripción de la alarma: esta alarma ayuda a detectar un volumen de tráfico bajo para el recurso y el método de la API de REST en la etapa. Esto puede indicar un problema con la aplicación que llama a la API, como el uso de puntos de conexión incorrectos. También, podría indicar un problema con la configuración o los permisos de la API, lo que hace que los clientes no puedan acceder a ella.

Finalidad: esta alarma puede detectar un volumen de tráfico bajo imprevisto para el recurso y el método de la API de REST en la etapa. Recomendamos que cree esta alarma si la API recibe un número predecible y constante de solicitudes en condiciones normales. Esta alarma no se recomienda para las API que no esperan un tráfico constante y uniforme.

Estadística: SampleCount

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral en función del análisis de datos históricos para determinar cuál es el recuento de solicitudes de referencia esperado para la API. Si se establece el umbral en un valor muy alto, es posible que la alarma sea demasiado sensible en los períodos de tráfico bajo normal y esperado. Por el contrario, si se establece en un valor muy bajo, la alarma podría pasar por alto descensos anómalos más pequeños en el volumen del tráfico.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: LESS_THAN_THRESHOLD

Recuento

Dimensiones: ApiId, Stage

Descripción de la alarma: esta alarma ayuda a detectar un volumen de tráfico bajo en la etapa de la API HTTP. Esto puede indicar un problema con la aplicación que llama a la API, como el uso de puntos de conexión incorrectos. También, podría indicar un problema con la configuración o los permisos de la API, lo que hace que los clientes no puedan acceder a ella.

Finalidad: esta alarma puede detectar un volumen de tráfico bajo imprevisto en la fase de la API HTTP. Recomendamos que cree esta alarma si la API recibe un número predecible y constante de solicitudes en condiciones normales. Si tiene habilitadas las métricas detalladas de CloudWatch y puede predecir el volumen de tráfico normal por ruta, le recomendamos que cree alarmas alternativas a esta función para poder supervisar de forma más detallada las caídas en el volumen de tráfico de cada ruta. Esta alarma no se recomienda para las API que no esperan un tráfico constante y uniforme.

Estadística: SampleCount

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el valor del umbral en función del análisis de datos históricos para determinar cuál es el recuento de solicitudes de referencia esperado para la API. Si se establece el umbral en un valor muy alto, es posible que la alarma sea demasiado sensible en los períodos de tráfico bajo normal y esperado. Por el contrario, si se establece en un valor muy bajo, la alarma podría pasar por alto descensos anómalos más pequeños en el volumen del tráfico.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: LESS_THAN_THRESHOLD

Recuento

Dimensiones: ApiId, Stage, Resource, Method

Descripción de la alarma: esta alarma ayuda a detectar un bajo volumen de tráfico para la ruta de la API HTTP en la etapa. Esto puede indicar un problema con la aplicación que llama a la API, como el uso de puntos de conexión incorrectos. También, podría indicar un problema con la configuración o los permisos de la API, lo que hace que los clientes no puedan acceder a ella.

Finalidad: esta alarma puede detectar un volumen de tráfico bajo imprevisto en la ruta de la API HTTP en la etapa. Recomendamos que cree esta alarma si la API recibe un número predecible y constante de solicitudes en condiciones normales. Esta alarma no se recomienda para las API que no esperan un tráfico constante y uniforme.

Estadística: SampleCount

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el valor del umbral en función del análisis de datos históricos para determinar cuál es el recuento de solicitudes de referencia esperado para la API. Si se establece el umbral en un valor muy alto, es posible que la alarma sea demasiado sensible en los períodos de tráfico bajo normal y esperado. Por el contrario, si se establece en un valor muy bajo, la alarma podría pasar por alto descensos anómalos más pequeños en el volumen del tráfico.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: LESS_THAN_THRESHOLD

IntegrationLatency

Dimensiones: ApiId, Stage

Descripción de la alarma: esta alarma ayuda a detectar si hay una latencia de integración alta para las solicitudes de API en una etapa. Puede correlacionar el valor de la métrica IntegrationLatency con la métrica de la latencia correspondiente de su backend, como la métrica Duration de las integraciones de Lambda. Esto le ayuda a determinar si el backend de la API tarda más tiempo en procesar las solicitudes de los clientes debido a problemas de rendimiento o si hay algún otro tipo de sobrecarga debido a la inicialización o al arranque en frío. Además, considere la posibilidad de habilitar los Registros de CloudWatch para su API y comprobar los registros para detectar cualquier error que pueda causar los problemas de latencia elevada. Asimismo, considere la posibilidad de habilitar las métricas detalladas de CloudWatch para obtener una vista de esta métrica por ruta, lo que le ayudará a ubicar el origen de la latencia de la integración.

Finalidad: esta alarma puede detectar cuándo las solicitudes de la puerta de enlace de la API en una etapa tienen una latencia de integración alta. Recomendamos esta alarma para las API de WebSocket y la consideramos opcional para las API HTTP, porque estas ya tienen recomendaciones de alarma independientes para la métrica de latencia. Si tiene habilitadas las métricas detalladas de CloudWatch y tiene diferentes requisitos de rendimiento de latencia de integración por ruta, le recomendamos que cree alarmas alternativas para tener una supervisión más detallada de la latencia de integración de cada ruta.

Estadística: p90

Umbral recomendado: 2000,0

Justificación del umbral: el valor de umbral sugerido no funciona para todas las cargas de trabajo de la API. Sin embargo, puede utilizarse como punto de partida para el umbral. A continuación, puede elegir diferentes valores de umbral en función de la carga de trabajo y de los requisitos aceptables de latencia, rendimiento y SLA para la API. Si es aceptable que la API tenga una latencia más alta en general, establezca un valor de umbral más alto para que la alarma sea menos sensible. Sin embargo, si se espera que la API proporcione respuestas casi en tiempo real, establezca un valor de umbral más bajo. También, puede analizar los datos históricos para determinar la latencia de referencia esperada para la carga de trabajo de la aplicación y, a continuación, utilizarlos para ajustar el valor del umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

IntegrationLatency

Dimensiones: ApiId, Stage, Route

Descripción de la alarma: esta alarma ayuda a detectar si hay una latencia de integración alta para las solicitudes de la API de WebSocket para una ruta en una etapa. Puede correlacionar el valor de la métrica IntegrationLatency con la métrica de la latencia correspondiente de su backend, como la métrica Duration de las integraciones de Lambda. Esto le ayuda a determinar si el backend de la API tarda más tiempo en procesar las solicitudes de los clientes debido a problemas de rendimiento o si hay algún otro tipo de sobrecarga debido a la inicialización o al arranque en frío. Además, considere la posibilidad de habilitar los Registros de CloudWatch para su API y comprobar los registros para detectar cualquier error que pueda causar los problemas de latencia elevada.

Finalidad: esta alarma puede detectar cuándo las solicitudes de la puerta de enlace de la API para una ruta en una etapa tienen una latencia de integración alta.

Estadística: p90

Umbral recomendado: 2000,0

Justificación del umbral: el valor de umbral sugerido no funciona para todas las cargas de trabajo de la API. Sin embargo, puede utilizarse como punto de partida para el umbral. A continuación, puede elegir diferentes valores de umbral en función de la carga de trabajo y de los requisitos aceptables de latencia, rendimiento y SLA para la API. Si es aceptable que la API tenga una latencia más alta en general, puede establecer un valor de umbral más alto para que la alarma sea menos sensible. Sin embargo, si se espera que la API proporcione respuestas casi en tiempo real, establezca un valor de umbral más bajo. También, puede analizar los datos históricos para determinar la latencia de referencia esperada para la carga de trabajo de la aplicación y, a continuación, utilizarlos para ajustar el valor del umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latency (Latencia)

Dimensiones: ApiName, Stage

Descripción de la alarma: esta alarma detecta una latencia elevada en una etapa. Encuentre el valor de la métrica IntegrationLatency para comprobar la latencia del backend de la API. Si las dos métricas están casi alineadas, el backend de la API es el origen de la latencia más alta, por lo que debería investigar si hay algún problema. Considere también la posibilidad de habilitar los Registros de CloudWatch y comprobar si hay errores que puedan causar la latencia elevada. Además, considere la posibilidad de habilitar métricas detalladas de CloudWatch para ver esta métrica por recurso y método y reducir la búsqueda del origen de la latencia. Si corresponde, consulte las guías ¿Cómo soluciono los problemas de latencia alta en mis solicitudes de API Gateway integradas con Lambda? o ¿Cómo puedo solucionar los problemas de latencia del punto de conexión de mi API de API Gateway optimizada en la periferia?.

Finalidad: esta alarma puede detectar cuándo las solicitudes de la puerta de enlace de la API en una etapa tienen una latencia elevada. Si tiene habilitadas las métricas detalladas de CloudWatch y tiene requisitos de rendimiento de latencia diferentes para cada método y recurso, le recomendamos que cree alarmas alternativas para tener una supervisión más detallada de la latencia de cada recurso y método.

Estadística: p90

Umbral recomendado: 2500,0

Justificación del umbral: el valor de umbral sugerido no funciona para todas las cargas de trabajo de la API. Sin embargo, puede utilizarse como punto de partida para el umbral. A continuación, puede elegir diferentes valores de umbral en función de la carga de trabajo y de los requisitos aceptables de latencia, rendimiento y SLA para la API. Si es aceptable que la API tenga una latencia más alta en general, puede establecer un valor de umbral más alto para que la alarma sea menos sensible. Sin embargo, si se espera que la API proporcione respuestas casi en tiempo real, establezca un valor de umbral más bajo. También, puede analizar los datos históricos para determinar cuál es la latencia de referencia esperada para la carga de trabajo de la aplicación y, a continuación, ajustar el valor del umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latency (Latencia)

Dimensiones: ApiName, Stage, Resource, Method

Descripción de la alarma: esta alarma detecta una latencia elevada para un recurso y un método en una etapa. Encuentre el valor de la métrica IntegrationLatency para comprobar la latencia del backend de la API. Si las dos métricas están casi alineadas, el backend de la API es el origen de la latencia más alta, por lo que debería investigarlo para detectar problemas de rendimiento. Considere también la posibilidad de habilitar los Registros de CloudWatch y comprobar si hay algún error que pueda causar la latencia elevada. También, puede consultar las guías de ¿Cómo soluciono los problemas de latencia alta en mis solicitudes de API Gateway integradas con Lambda? o de ¿Cómo puedo solucionar los problemas de latencia del punto de conexión de mi API de API Gateway optimizada en la periferia?, si es pertinente.

Finalidad: esta alarma puede detectar cuándo las solicitudes de la puerta de enlace de la API de un recurso y un método en una etapa tienen una latencia elevada.

Estadística: p90

Umbral recomendado: 2500,0

Justificación del umbral: el valor de umbral sugerido no funciona para todas las cargas de trabajo de la API. Sin embargo, puede utilizarse como punto de partida para el umbral. A continuación, puede elegir diferentes valores de umbral en función de la carga de trabajo y de los requisitos aceptables de latencia, rendimiento y SLA para la API. Si es aceptable que la API tenga una latencia más alta en general, puede establecer un valor de umbral más alto para que la alarma sea menos sensible. Sin embargo, si se espera que la API proporcione respuestas casi en tiempo real, establezca un valor de umbral más bajo. También, puede analizar los datos históricos para determinar la latencia de referencia esperada para la carga de trabajo de la aplicación y, a continuación, ajustar el valor del umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latency (Latencia)

Dimensiones: ApiId, Stage

Descripción de la alarma: esta alarma detecta una latencia elevada en una etapa. Encuentre el valor de la métrica IntegrationLatency para comprobar la latencia del backend de la API. Si las dos métricas están casi alineadas, el backend de la API es el origen de la latencia más alta, por lo que debería investigarlo para detectar problemas de rendimiento. Considere también la posibilidad de habilitar los Registros de CloudWatch y comprobar si hay algún error que pueda causar la latencia elevada. Además, considere la posibilidad de habilitar las métricas detalladas de CloudWatch para ver esta métrica por ruta y reducir la búsqueda del origen de la latencia. También, puede consultar ¿Cómo soluciono los problemas de latencia alta en mis solicitudes de API Gateway integradas con Lambda?, si corresponde.

Finalidad: esta alarma puede detectar cuándo las solicitudes de la puerta de enlace de la API en una etapa tienen una latencia elevada. Si tiene habilitadas las métricas detalladas de CloudWatch y tiene diferentes requisitos de rendimiento de latencia por ruta, le recomendamos que cree alarmas alternativas para tener una supervisión más detallada de la latencia de cada ruta.

Estadística: p90

Umbral recomendado: 2500,0

Justificación del umbral: el valor de umbral sugerido no funciona para todas las cargas de trabajo de la API. Sin embargo, se puede utilizar como punto de partida para el umbral. Entonces, puede elegir diferentes valores de umbral en función de la carga de trabajo y de los requisitos de latencia aceptable, de rendimiento y de SLA para la API. Si es aceptable que la API tenga una latencia más alta en general, puede establecer un valor de umbral más alto para que sea menos sensible. Sin embargo, si se espera que la API proporcione respuestas casi en tiempo real, establezca un valor de umbral más bajo. También, puede analizar los datos históricos para determinar la latencia de referencia esperada para la carga de trabajo de la aplicación y, a continuación, ajustar el valor del umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latency (Latencia)

Dimensiones: ApiId, Stage, Resource, Method

Descripción de la alarma: esta alarma detecta una latencia elevada para una ruta en una etapa. Encuentre el valor de la métrica IntegrationLatency para comprobar la latencia del backend de la API. Si las dos métricas están casi alineadas, el backend de la API es la fuente de mayor latencia y debe investigarse para detectar problemas de rendimiento. Considere también la posibilidad de habilitar los registros de CloudWatch y comprobar si hay algún error que pueda causar la latencia elevada. También, puede consultar ¿Cómo soluciono los problemas de latencia alta en mis solicitudes de API Gateway integradas con Lambda?, si corresponde.

Finalidad: esta alarma se usa para detectar cuándo las solicitudes de la puerta de enlace de la API para una ruta en una etapa tienen una latencia elevada.

Estadística: p90

Umbral recomendado: 2500,0

Justificación del umbral: el valor de umbral sugerido no funciona para todas las cargas de trabajo de la API. Sin embargo, se puede utilizar como punto de partida para el umbral. A continuación, puede elegir diferentes valores de umbral en función de la carga de trabajo y de los requisitos aceptables de latencia, rendimiento y SLA para la API. Si es aceptable que la API tenga una latencia más alta en general, puede establecer un valor de umbral más alto para que la alarma sea menos sensible. Sin embargo, si se espera que la API proporcione respuestas casi en tiempo real, establezca un valor de umbral más bajo. También, puede analizar los datos históricos para determinar la latencia de referencia esperada para la carga de trabajo de la aplicación y, a continuación, ajustar el valor del umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

4XX

Dimensiones: ApiId, Stage

Descripción de la alarma: esta alarma detecta una tasa elevada de errores del lado del cliente. Esto puede indicar un problema en los parámetros de autorización o de la solicitud del cliente. También podría significar que se eliminó una ruta o que un cliente solicita una que no existe en la API. Considere la posibilidad de habilitar los Registros de CloudWatch y comprobar si hay algún error que pueda causar los errores 4XX. Además, considere la posibilidad de habilitar métricas detalladas de CloudWatch para ver estas métricas por ruta, lo que le ayudará a reducir la búsqueda del origen de los errores. También se pueden producir errores si se supera el valor de limitación configurado. Si las respuestas y los registros indican tasas altas e inesperadas de errores 429, siga esta guía para solucionar el problema.

Finalidad: esta alarma puede detectar altas tasas de errores del lado del cliente en las solicitudes de la puerta de enlace de la API.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: el umbral sugerido detecta cuándo más del 5 % del total de las solicitudes reciben errores 4XX. Sin embargo, puede ajustar el umbral para adaptarlo al tráfico de las solicitudes y a las tasas de error aceptables. También puede analizar los datos históricos para determinar la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. Los errores 4XX que se producen con frecuencia deben ser objeto de alarma. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede ser demasiado sensible.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

5xx

Dimensiones: ApiId, Stage

Descripción de la alarma: esta alarma ayuda a detectar una alta tasa de errores del lado del servidor. Esto puede indicar que hay algún problema en el backend de la API, en la red o en la integración entre la puerta de enlace de la API y la API del backend. Esta documentación puede ayudarle a solucionar la causa de los errores 5XX.

Finalidad: esta alarma puede detectar altas tasas de errores del lado del servidor en las solicitudes de la puerta de enlace de la API.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: el umbral sugerido detecta cuándo más del 5 % del total de las solicitudes reciben errores 5XX. Sin embargo, puede ajustar el umbral para adaptarlo al tráfico de las solicitudes y a las tasas de error aceptables. También, puede analizar los datos históricos para determinar cuál es la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. Los errores 5XX que se producen con frecuencia deben ser objeto de alarma. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede ser demasiado sensible.

Período: 60

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: GREATER_THAN_THRESHOLD

MessageCount

Dimensiones: ApiId, Stage

Descripción de la alarma: esta alarma ayuda a detectar un volumen de tráfico bajo para la etapa de la API de WebSocket. Esto puede indicar un problema cuando los clientes llaman a la API, como el uso de puntos de conexión incorrectos o problemas con el backend al enviar mensajes a los clientes. También, podría indicar un problema con la configuración o los permisos de la API, lo que haría que los clientes no puedan acceder a ella.

Finalidad: esta alarma puede detectar un volumen de tráfico bajo imprevisto para la etapa de la API de WebSocket. Recomendamos que cree esta alarma si la API recibe y envía un número predecible y constante de mensajes en condiciones normales. Si tiene habilitadas las métricas detalladas de CloudWatch y puede predecir el volumen de tráfico normal por ruta, es mejor crear alarmas alternativas a esta, a fin de tener una supervisión más detallada de las caídas en el volumen de tráfico en cada ruta. No recomendamos esta alarma para las API que no esperan un tráfico constante y uniforme.

Estadística: SampleCount

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el valor del umbral en función del análisis de datos históricos para determinar cuál es el recuento de mensajes de referencia esperado para la API. Si se establece el umbral en un valor muy alto, es posible que la alarma sea demasiado sensible en los períodos de tráfico bajo normal y esperado. Por el contrario, si se establece en un valor muy bajo, la alarma podría pasar por alto descensos anómalos más pequeños en el volumen del tráfico.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: LESS_THAN_THRESHOLD

MessageCount

Dimensiones: ApiId, Stage, Route

Descripción de la alarma: esta alarma ayuda a detectar un volumen de tráfico bajo para la ruta de la API de WebSocket en la etapa. Esto puede indicar un problema con los clientes al llamar a la API, como el uso de puntos de conexión incorrectos, o problemas con el backend al enviar mensajes a los clientes. También, podría indicar un problema con la configuración o los permisos de la API, lo que haría que los clientes no puedan acceder a ella.

Finalidad: esta alarma puede detectar un volumen de tráfico bajo imprevisto para la ruta de la API de WebSocket en la etapa. Recomendamos que cree esta alarma si la API recibe y envía un número predecible y constante de mensajes en condiciones normales. No recomendamos esta alarma para las API que no esperan un tráfico constante y uniforme.

Estadística: SampleCount

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral en función del análisis de datos históricos para determinar cuál es el recuento de mensajes de referencia esperado para la API. Si se establece el umbral en un valor muy alto, es posible que la alarma sea demasiado sensible en los períodos de tráfico bajo normal y esperado. Por el contrario, si se establece en un valor muy bajo, la alarma podría pasar por alto descensos anómalos más pequeños en el volumen del tráfico.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: LESS_THAN_THRESHOLD

ClientError

Dimensiones: ApiId, Stage

Descripción de la alarma: esta alarma detecta una alta tasa de errores del cliente. Esto puede indicar un problema en los parámetros de autorización o del mensaje. También podría significar que se eliminó una ruta o que un cliente solicita una que no existe en la API. Considere la posibilidad de habilitar los Registros de CloudWatch y comprobar si hay algún error que pueda causar los errores 4XX. Además, considere la posibilidad de habilitar métricas detalladas de CloudWatch para ver estas métricas por ruta, lo que le ayudará a reducir la búsqueda del origen de los errores. Los errores también pueden deberse a que se supera la limitación configurada. Si las respuestas y los registros indican tasas altas e inesperadas de errores 429, siga esta guía para solucionar el problema.

Finalidad: esta alarma puede detectar altas tasas de errores del cliente en los mensajes de la puerta de enlace de la API de WebSocket.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: el umbral sugerido detecta cuándo más del 5 % del total de las solicitudes reciben errores 4XX. Puede ajustar el umbral para adaptarlo al tráfico de las solicitudes y a sus tasas de error aceptables. También puede analizar los datos históricos para determinar la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. Los errores 4XX que se producen con frecuencia deben ser objeto de alarma. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede ser demasiado sensible.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

ExecutionError

Dimensiones: ApiId, Stage

Descripción de la alarma: esta alarma ayuda a detectar una alta tasa de errores de ejecución. Esto puede deberse a los errores 5XX en la integración, problemas con los permisos u otros factores que impidan la invocación correcta de la integración, como la limitación o la eliminación de la integración. Considere la posibilidad de habilitar los Registros de CloudWatch para su API y comprobar los registros para ver el tipo y la causa de los errores. Además, considere la posibilidad de habilitar las métricas detalladas de CloudWatch para obtener una vista de esta métrica por ruta, lo que le ayudará a reducir la búsqueda del origen de los errores. Esta documentación también puede ayudarle a solucionar la causa de cualquier error de conexión.

Finalidad: esta alarma puede detectar altas tasas de errores de ejecución en los mensajes de la puerta de enlace de la API de WebSocket.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: el umbral sugerido detecta cuándo se producen errores de ejecución en más del 5 % del total de las solicitudes. Puede ajustar el umbral para adaptarlo al tráfico de las solicitudes, así como a sus tasas de error aceptables. Puede analizar los datos históricos para determinar la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. Los errores de ejecución que se producen con frecuencia deben ser objeto de alarma. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede ser demasiado sensible.

Período: 60

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon EC2 Auto Scaling

GroupInServiceCapacity

Dimensiones: AutoScalingGroupName

Descripción de la alarma: esta alarma ayuda a detectar cuando la capacidad del grupo está por debajo de la capacidad deseada requerida para la carga de trabajo. Para solucionar el problema, compruebe si sus actividades de escalado fallaron en el lanzamiento y confirme que la configuración de capacidad deseada es la correcta.

Finalidad: esta alarma puede detectar una baja disponibilidad en su grupo de escalado automático debido a errores de lanzamiento o a lanzamientos suspendidos.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral debe ser la capacidad mínima requerida para ejecutar la carga de trabajo. En la mayoría de los casos, puede configurarse para que coincida con la métrica GroupDesiredCapacity.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: LESS_THAN_THRESHOLD

Amazon CloudFront

5xxErrorRate

Dimensiones: DistributionId, Region=Global

Descripción de la alarma: esta alarma supervisa el porcentaje de respuestas de error 5XX del servidor de origen para ayudarle a detectar si el servicio CloudFront tiene problemas. Consulte Solucionar respuestas de error del origen para obtener información que le ayude a entender los problemas de su servidor. Además, active las métricas adicionales para obtener métricas de error detalladas.

Finalidad: esta alarma se utiliza para detectar problemas al atender las solicitudes del servidor de origen o problemas de comunicación entre CloudFront y el servidor de origen.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida de la tolerancia para las respuestas de 5XX. Puede analizar las tendencias y los datos históricos y, a continuación, establecer el umbral en consecuencia. Dado que los errores 5XX pueden deberse a problemas transitorios, le recomendamos que establezca el umbral en un valor superior a 0 para que la alarma no sea demasiado sensible.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

OriginLatency

Dimensiones: DistributionId, Region=Global

Descripción de la alarma: la alarma ayuda a supervisar si el servidor de origen tarda demasiado en responder. Si el servidor tarda demasiado en responder, es posible que se agote el tiempo de espera. Consulte Buscar y corregir respuestas con retardo desde aplicaciones en su servidor de origen si experimenta valores altos de OriginLatency de forma constante.

Finalidad: esta alarma se utiliza para detectar problemas con un servidor de origen que tarda demasiado en responder.

Estadística: p90

Umbral recomendado: depende de la situación

Justificación del umbral: debe calcular el valor de alrededor del 80 % del tiempo de espera de la respuesta de origen y utilizar el resultado como valor para el umbral. Si esta métrica se acerca con frecuencia al valor de tiempo de espera de la respuesta de origen, es posible que comience a experimentar errores 504.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

FunctionValidationErrors

Dimensiones: DistributionId, FunctionName, Region=Global

Descripción de la alarma: esta alarma ayuda a supervisar los errores de validación de las funciones de CloudFront para que pueda tomar medidas para resolverlos. Analice los registros de funciones de CloudWatch y observe el código de la función para encontrar y resolver la causa raíz del problema. Consulte Restricciones en funciones de la periferia para comprender los errores de configuración habituales de CloudFront Functions.

Finalidad: esta alarma se utiliza para detectar errores de validación en las funciones de CloudFront.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: un valor superior a 0 indica un error de validación. Recomendamos establecer el umbral en 0 porque los errores de validación implican un problema cuando las funciones de CloudFront se devuelven a CloudFront. Por ejemplo, CloudFront necesita el encabezado Host HTTP para procesar una solicitud. No hay nada que impida a un usuario eliminar el encabezado Host del código de las funciones de CloudFront. Sin embargo, cuando CloudFront recibe la respuesta y falta el encabezado del Host, CloudFront devuelve un error de validación.

Período: 60

Puntos de datos para la alarma: 2

Períodos de evaluación: 2

Operador de comparación: GREATER_THAN_THRESHOLD

FunctionExecutionErrors

Dimensiones: DistributionId, FunctionName, Region=Global

Descripción de la alarma: esta alarma le ayuda a supervisar los errores de ejecución de las funciones de CloudFront para que pueda tomar medidas para resolverlos. Analice los registros de funciones de CloudWatch y observe el código de la función para encontrar y resolver la causa raíz del problema.

Finalidad: esta alarma se utiliza para detectar errores de ejecución de las funciones de CloudFront.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: recomendamos establecer el umbral en 0 porque un error de ejecución indica un problema con el código que se produce en tiempo de ejecución.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

FunctionThrottles

Dimensiones: DistributionId, FunctionName, Region=Global

Descripción de la alarma: esta alarma ayuda a supervisar si la función de CloudFront está limitada. Si su función está limitada, significa que está tardando demasiado en ejecutarse. Para evitar limitaciones de funciones, considere optimizar el código de la función.

Finalidad: esta alarma puede detectar cuando la función de CloudFront está restringida para que pueda reaccionar, resolver el problema y ofrecer una experiencia de cliente fluida.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: recomendamos establecer el umbral en 0 para permitir una resolución más rápida de los limitadores de las funciones.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon Cognito

SignUpThrottles

Dimensiones: UserPool, UserPoolClient

Descripción de la alarma: esta alarma supervisa el recuento de solicitudes limitadas. Si los usuarios se ven limitados con frecuencia, debe aumentar el límite mediante una solicitud de aumento en la cuota de servicio. Consulte Cuotas en Amazon Cognito para obtener información acerca de cómo solicitar un aumento de cuotas. Para tomar medidas de forma proactiva, considere la posibilidad de realizar un seguimiento de la cuota de uso.

Finalidad: esta alarma ayuda a supervisar si se producen solicitudes de registro limitadas. Esto puede ayudarle a saber cuándo tomar medidas para mitigar cualquier deterioro en la experiencia de registro. La limitación sostenida de las solicitudes es una experiencia negativa de registro de usuarios.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: un grupo de usuarios bien aprovisionado no debería sufrir ningún tipo de limitación que afecte a varios puntos de datos. Por lo tanto, un umbral típico para una carga de trabajo esperada debería ser cero. En el caso de una carga de trabajo irregular con ráfagas frecuentes, puede analizar los datos históricos para determinar la limitación aceptable de la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. Se debe volver a realizar una solicitud limitada para minimizar el impacto en la aplicación.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

SignInThrottles

Dimensiones: UserPool, UserPoolClient

Descripción de la alarma: esta alarma supervisa el recuento de solicitudes de autenticación de usuarios limitadas. Si los usuarios se ven limitados con frecuencia, es posible que tenga que aumentar el límite mediante una solicitud de aumento de la cuota de servicio. Consulte Cuotas en Amazon Cognito para obtener información acerca de cómo solicitar un aumento de cuotas. Para tomar medidas de forma proactiva, considere la posibilidad de realizar un seguimiento de la cuota de uso.

Finalidad: esta alarma ayuda a supervisar la aparición de solicitudes de inicio de sesión limitadas. Esto puede ayudarle a saber cuándo tomar medidas para mitigar cualquier deterioro en la experiencia de inicio de sesión. La limitación sostenida de las solicitudes es una experiencia de autenticación negativa para los usuarios.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: un grupo de usuarios bien aprovisionado no debería sufrir ningún tipo de limitación que afecte a varios puntos de datos. Por lo tanto, un umbral típico para una carga de trabajo esperada debería ser cero. En el caso de una carga de trabajo irregular con ráfagas frecuentes, puede analizar los datos históricos para determinar la limitación aceptable de la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. Se debe volver a realizar una solicitud limitada para minimizar el impacto en la aplicación.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

TokenRefreshThrottles

Dimensiones: UserPool, UserPoolClient

Descripción de la alarma: puede establecer el valor del umbral para que se adapte al tráfico de la solicitud y para que coincida con la limitación aceptable para las solicitudes de actualización de los tokens. La limitación se utiliza para proteger el sistema de demasiadas solicitudes. Sin embargo, es importante supervisar si también tiene un aprovisionamiento insuficiente para tu tráfico normal. Puede analizar los datos históricos para determinar la limitación aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral de la alarma para que sea superior al nivel de limitación aceptable. La aplicación o el servicio deben volver a intentar las solicitudes limitadas, ya que son transitorias. Por lo tanto, un valor muy bajo para el umbral puede provocar que la alarma sea sensible.

Finalidad: esta alarma ayuda a supervisar la aparición de solicitudes de actualización de tokens limitadas. Esto puede ayudarle a saber cuándo tomar medidas para mitigar cualquier posible problema, a fin de garantizar una experiencia de usuario fluida, y el buen estado y la fiabilidad de su sistema de autenticación. La limitación sostenida de las solicitudes es una experiencia de autenticación negativa para los usuarios.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral también se puede configurar o ajustar para adaptarlo al tráfico de la solicitud, así como a una limitación aceptable para las solicitudes de actualización de los tokens. La limitación se utiliza para proteger el sistema de demasiadas solicitudes. Sin embargo, también es importante supervisar si no está bien aprovisionado para el tráfico normal y comprobar si eso es lo que causa el impacto. Los datos históricos también se pueden analizar para determinar cuál es la limitación aceptable para la carga de trabajo de la aplicación, y el umbral se puede ajustar por encima del nivel de limitación aceptable habitual. La aplicación o el servicio deben volver a intentar las solicitudes limitadas, ya que son transitorias. Por lo tanto, un valor muy bajo para el umbral puede provocar que la alarma sea sensible.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

FederationThrottles

Dimensiones: UserPool, UserPoolClient, IdentityProvider

Descripción de la alarma: esta alarma supervisa el recuento de solicitudes de federación de identidades limitadas. Si observa una limitación constante, esto podría indicar que necesita aumentar el límite mediante una solicitud de un aumento de la cuota de servicio. Consulte Cuotas en Amazon Cognito para obtener información acerca de cómo solicitar un aumento de cuotas.

Finalidad: esta alarma ayuda a supervisar la aparición de solicitudes limitadas de federación de identidades. Esto puede ayudarle a dar respuestas proactivas a los cuellos de botella de rendimiento o a los errores de configuración y garantizar una experiencia de autenticación fluida para sus usuarios. La limitación sostenida de las solicitudes es una experiencia de autenticación negativa para los usuarios.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: puede establecer el umbral para que se adapte al tráfico de la solicitud y para que coincida con la limitación aceptable para las solicitudes de federación de identidades. La limitación se utiliza para proteger el sistema de demasiadas solicitudes. Sin embargo, es importante supervisar si también tiene un aprovisionamiento insuficiente para tu tráfico normal. Puede analizar los datos históricos para encontrar la limitación aceptable para la carga de trabajo de la aplicación y, a continuación, establecer el umbral en un valor superior a su nivel de limitación aceptable. La aplicación o el servicio deben volver a intentar las solicitudes limitadas, ya que son transitorias. Por lo tanto, un valor muy bajo para el umbral puede provocar que la alarma sea sensible.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon DynamoDB

AccountProvisionedReadCapacityUtilization

Dimensiones: None

Descripción de la alarma: esta alarma detecta si la capacidad de lectura de la cuenta está cerca de alcanzar el límite aprovisionado. Si esto ocurre, puede aumentar la cuota de la cuenta para utilizar la capacidad de lectura. Puede ver sus cuotas actuales de unidades de capacidad de lectura y solicitar aumentos mediante Service Quotas.

Finalidad: la alarma puede detectar si la utilización de la capacidad de lectura de la cuenta se acerca a la utilización de la capacidad de lectura aprovisionada. Si la utilización alcanza su límite máximo, DynamoDB comienza a limitar las solicitudes de lectura.

Estadística: Maximum

Umbral recomendado: 80,0

Justificación del umbral: fije el umbral en el 80 %, de modo que se puedan tomar medidas (como aumentar los límites de la cuenta) antes de que alcance su capacidad máxima para evitar la limitación.

Período: 300

Puntos de datos para la alarma: 2

Períodos de evaluación: 2

Operador de comparación: GREATER_THAN_THRESHOLD

AccountProvisionedWriteCapacityUtilization

Dimensiones: None

Descripción de la alarma: esta alarma detecta si la capacidad de escritura de la cuenta está cerca de alcanzar el límite aprovisionado. Si esto ocurre, puede aumentar la cuota de la cuenta para utilizar la capacidad de escritura. Puede ver sus cuotas actuales de unidades de capacidad de escritura y solicitar aumentos mediante Service Quotas.

Finalidad: esta alarma puede detectar si la utilización de la capacidad de escritura de la cuenta se acerca a la utilización de la capacidad de escritura aprovisionada. Si la utilización alcanza su límite máximo, DynamoDB comienza a limitar las solicitudes de escritura.

Estadística: Maximum

Umbral recomendado: 80,0

Justificación del umbral: establezca el umbral en el 80 %, de modo que la acción (como aumentar los límites de la cuenta) se pueda tomar antes de que alcance su capacidad máxima para evitar la limitación.

Período: 300

Puntos de datos para la alarma: 2

Períodos de evaluación: 2

Operador de comparación: GREATER_THAN_THRESHOLD

AgeOfOldestUnreplicatedRecord

Dimensiones: TableName, DelegatedOperation

Descripción de la alarma: esta alarma detecta el retraso en la replicación a un flujo de datos de Kinesis. En funcionamiento normal, AgeOfOldestUnreplicatedRecord debe estar en el orden de los milisegundos. Este número crece según los intentos de replicación fallidos cuando se deben a elecciones de configuración controladas por el cliente. Los ejemplos de las configuraciones controladas por el cliente que provocan intentos de replicación fallidos son una capacidad de flujo de datos de Kinesis subaprovisionada que produce una limitación excesiva o una actualización manual de las políticas de acceso del flujo de datos de Kinesis que evita que DynamoDB agregue datos al flujo de datos. Para mantener esta métrica lo más baja posible, debe garantizar el aprovisionamiento correcto de la capacidad del flujo de datos de Kinesis y asegurarse de que los permisos de DynamoDB no se modifiquen.

Finalidad: esta alarma puede supervisar los intentos de replicación fallidos y el consiguiente retraso en la replicación en el flujo de datos de Kinesis.

Estadística: Maximum

Umbral recomendado: depende de la situación

Justificación del umbral: defina el umbral de acuerdo con el retraso de replicación deseado, medido en milisegundos. Este valor depende de los requisitos de la carga de trabajo y del rendimiento esperado.

Período: 300

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: GREATER_THAN_THRESHOLD

FailedToReplicateRecordCount

Dimensiones: TableName, DelegatedOperation

Descripción de la alarma: esta alarma detecta el número de registros que DynamoDB no pudo replicar en el flujo de datos de Kinesis. Algunos elementos de más de 34 KB podrían expandirse de tamaño para cambiar los registros de datos que superan el límite de tamaño del elemento de 1 MB de Kinesis Data Streams. Esta expansión de tamaño se produce cuando estos elementos mayores a 34 KB incluyen un gran número de valores de atributos booleanos o vacíos. Los valores de atributos booleanos y vacíos se almacenan como 1 byte en DynamoDB, pero se expanden hasta 5 bytes cuando se serializan mediante JSON estándar para la replicación de Kinesis Data Streams. DynamoDB no puede replicar tales registros de cambios en el flujo de datos de Kinesis. DynamoDB omite estos registros de datos de cambios y continúa replicando automáticamente los registros posteriores.

Finalidad: esta alarma puede supervisar el número de registros que DynamoDB no pudo replicar en el flujo de datos de Kinesis debido al límite de tamaño de los elementos de Kinesis Data Streams.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: defina el umbral en 0 para detectar cualquier registro que DynamoDB no pueda replicar.

Período: 60

Puntos de datos para la alarma: 1

Períodos de evaluación: 1

Operador de comparación: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensiones: TableName

Descripción de la alarma: esta alarma detecta si hay un número elevado de solicitudes de lectura que se están limitando para la tabla de DynamoDB. Para solucionar el problema, consulte Solución de problemas de limitación en Amazon DynamoDB.

Finalidad: esta alarma puede detectar una limitación constante de las solicitudes de lectura a la tabla de DynamoDB. La limitación constante de las solicitudes de lectura puede afectar de forma negativa a las operaciones de lectura de la carga de trabajo y reducir la eficiencia general del sistema.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral de acuerdo con el tráfico de lectura esperado para la tabla de DynamoDB, teniendo en cuenta un nivel de limitación aceptable. Es importante supervisar si el aprovisionamiento es insuficiente y si no se está produciendo una limitación constante. También, puede analizar los datos históricos para encontrar el nivel de limitación aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral para que sea superior al nivel de limitación habitual. La aplicación o el servicio deben volver a intentar las solicitudes limitadas, ya que son transitorias. Por lo tanto, un umbral muy bajo puede provocar que la alarma sea demasiado sensible y provocar transiciones de estado no deseadas.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensiones: TableName, GlobalSecondaryIndexName

Descripción de la alarma: esta alarma detecta si se limita un número elevado de solicitudes de lectura en el índice secundario global de la tabla de DynamoDB. Para solucionar el problema, consulte Solución de problemas de limitación en Amazon DynamoDB.

Finalidad: la alarma puede detectar una limitación constante de las solicitudes de lectura del índice secundario global de la tabla de DynamoDB. La limitación constante de las solicitudes de lectura puede afectar de forma negativa a las operaciones de lectura de la carga de trabajo y reducir la eficiencia general del sistema.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral de acuerdo con el tráfico de lectura esperado para la tabla de DynamoDB, teniendo en cuenta un nivel de limitación aceptable. Es importante supervisar si tiene un aprovisionamiento insuficiente y si no se produce una limitación constante. También, puede analizar los datos históricos para encontrar un nivel de limitación aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral para que sea superior al nivel de limitación aceptable habitual. La aplicación o el servicio deben volver a intentar las solicitudes limitadas, ya que son transitorias. Por lo tanto, un umbral muy bajo puede provocar que la alarma sea demasiado sensible y provocar transiciones de estado no deseadas.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

ReplicationLatency

Dimensiones: TableName, ReceivingRegion

Descripción de la alarma: la alarma detecta si la réplica de una región de la tabla global va retrasada respecto a la región de origen. La latencia puede aumentar si una región de AWS se encuentra degradada y tiene una réplica de tabla en esa región. En este caso, puede redirigir temporalmente la actividad de lectura y escritura de la aplicación a otra región de AWS. Si utiliza tablas globales del 29.11.2017 (heredadas), debe comprobar que las unidades de capacidad de escritura (WCU) son idénticas para cada una de las tablas de réplica. También puede asegurarse de seguir las pautas de las Prácticas recomendadas y requisitos para la administración de tablas globales.

Finalidad: la alarma puede detectar si la tabla de réplica de una región se retrasa al replicar los cambios de otra región. Esto podría provocar que su réplica se diferencie de las demás réplicas. Resulta útil conocer la latencia de replicación de cada región de AWS y avisar si esa latencia de replicación aumenta de forma continua. La replicación de la tabla se aplica solo a las tablas globales.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida del caso de uso. Las latencias de replicación superiores a 3 minutos suelen ser motivo de investigación. Revise la importancia y los requisitos del retraso de la replicación, analice las tendencias históricas y, en base a eso, seleccione el umbral.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

SuccessfulRequestLatency

Dimensiones: TableName, Operation

Descripción de la alarma: esta alarma detecta una latencia elevada para el funcionamiento de la tabla de DynamoDB (indicada por el valor de dimensión de la Operation de la alarma). Consulte este documento para solucionar los problemas de latencia en Amazon DynamoDB.

Finalidad: esta alarma puede detectar una latencia elevada para la operación de la tabla de DynamoDB. Una latencia más alta de las operaciones puede afectar de forma negativa a la eficiencia general del sistema.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: DynamoDB proporciona una latencia media de milisegundos de un solo dígito para operaciones únicas como GetItem y PutItem, entre otras. Sin embargo, puede establecer el umbral en función de la tolerancia aceptable para la latencia según el tipo de operación y la tabla implicadas en la carga de trabajo. Puede analizar los datos históricos de esta métrica para encontrar la latencia habitual de la operación de la tabla y, a continuación, establecer el umbral en un número que represente un retraso crítico de la operación.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_THRESHOLD

SystemErrors

Dimensiones: TableName

Descripción de la alarma: esta alarma detecta un número elevado y sostenido de errores del sistema en las solicitudes de tablas de DynamoDB. Si sigue recibiendo errores 5XX, abra el Service Health Dashboard de AWS para comprobar si hay problemas operativos con el servicio. Puede utilizar esta alarma para recibir notificaciones en caso de que se produzca un problema de servicio interno prolongado por parte de DynamoDB y le ayudará a establecer una correlación con el problema al que se enfrenta la aplicación del cliente. Consulte Control de errores con DynamoDB para obtener más información.

Finalidad: esta alarma puede detectar errores de sistema persistentes en las solicitudes de tablas de DynamoDB. Los errores del sistema indican errores de servicio internos desde DynamoDB y ayudan a correlacionarlos con el problema que tiene el cliente.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral de acuerdo con el tráfico esperado, teniendo en cuenta un nivel aceptable de errores del sistema. También, puede analizar los datos históricos para encontrar el recuento de errores aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. La aplicación o el servicio deben volver a reintentar los errores del sistema, ya que son transitorios. Por lo tanto, un umbral muy bajo puede provocar que la alarma sea demasiado sensible y causar transiciones de estado no deseadas.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

ThrottledPutRecordCount

Dimensiones: TableName, DelegatedOperation

Descripción de la alarma: esta alarma detecta los registros que el flujo de datos de Kinesis limita durante la replicación de la captura de datos de cambios en Kinesis. Esta limitación se debe a que la capacidad de flujo de datos de Kinesis es insuficiente. Si experimenta una limitación controlada excesiva y regular, es posible que tenga que aumentar el número de fragmentos del flujo de Kinesis proporcionalmente al rendimiento de escritura observado de la tabla. Para obtener más información sobre cómo determinar el tamaño de un flujo de datos de Kinesis, consulte Determinar el tamaño inicial de un flujo de datos de Kinesis.

Finalidad: esta alarma puede supervisar el número de registros que el flujo de datos de Kinesis limitó debido a la capacidad insuficiente del flujo de datos de Kinesis.

Estadística: Maximum

Umbral recomendado: depende de la situación

Justificación del umbral: es posible que experimente cierta limitación durante los picos de uso excepcionales, pero los registros limitados deben ser lo más bajos posible para evitar una latencia de replicación mayor (DynamoDB vuelve a intentar enviar los registros limitados al flujo de datos de Kinesis). Establezca el umbral en un número que pueda ayudarlo a identificar el exceso de limitación normal. También, puede analizar los datos históricos de esta métrica para encontrar las tasas de limitación aceptables para la carga de trabajo de la aplicación. Ajuste el umbral a un valor que la aplicación pueda tolerar en función del caso de uso.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_THRESHOLD

UserErrors

Dimensiones: None

Descripción de la alarma: esta alarma detecta un número elevado y sostenido de errores de usuario en las solicitudes de tablas de DynamoDB. Puede comprobar los registros de las aplicaciones del cliente durante el período de emisión para comprobar por qué las solicitudes no son válidas. Puede comprobar el código 400 de estado HTTP para ver el tipo de error que se produce y tomar las medidas correspondientes. Es posible que deba corregir la lógica de la aplicación para crear solicitudes válidas.

Finalidad: esta alarma puede detectar errores de usuario persistentes en las solicitudes de tablas de DynamoDB. Los errores de usuario en las operaciones solicitadas significan que el cliente produce solicitudes no válidas y falla.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: defina el umbral en cero para detectar cualquier error del lado del cliente. O puede establecerlo en un valor más alto si quiere evitar que se active la alarma por un número de errores muy bajo. Decida en función del caso de uso y del tráfico de las solicitudes.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensiones: TableName

Descripción de la alarma: esta alarma detecta si se limita un número elevado de solicitudes de escritura en la tabla de DynamoDB. Consulte Solución de problemas de limitación en Amazon DynamoDB para solucionar este problema.

Finalidad: esta alarma puede detectar una limitación constante de las solicitudes de escritura en la tabla de DynamoDB. La limitación constante de las solicitudes de escritura puede afectar de forma negativa a la carga de trabajo de las operaciones de escritura y reducir la eficiencia general del sistema.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral de acuerdo con el tráfico de escritura esperado para la tabla de DynamoDB, teniendo en cuenta un nivel de limitación aceptable. Es importante supervisar si tiene un aprovisionamiento insuficiente y si no se produce una limitación constante. También, puede analizar los datos históricos para determinar el nivel de limitación aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral a un valor superior al nivel de limitación aceptable habitual. La aplicación o el servicio deben volver a intentar las solicitudes limitadas, ya que son transitorias. Por lo tanto, un umbral muy bajo puede provocar que la alarma sea demasiado sensible y causar transiciones de estado no deseadas.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensiones: TableName, GlobalSecondaryIndexName

Descripción de la alarma: esta alarma detecta si se limita un número elevado de solicitudes de escritura para el índice secundario global de la tabla de DynamoDB. Consulte Solución de problemas de limitación en Amazon DynamoDB para solucionar este problema.

Finalidad: esta alarma puede detectar una limitación constante de las solicitudes de escritura para el índice secundario global de la tabla de DynamoDB. La limitación constante de las solicitudes de escritura puede afectar de forma negativa a la carga de trabajo de las operaciones de escritura y reducir la eficiencia general del sistema.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral de acuerdo con el tráfico de escritura esperado para la tabla de DynamoDB, teniendo en cuenta un nivel de limitación aceptable. Es importante supervisar si tiene un aprovisionamiento insuficiente y si no se produce una limitación constante. También, puede analizar los datos históricos para encontrar el nivel de limitación aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral a un valor superior al nivel de limitación aceptable habitual. La aplicación o el servicio deben volver a intentar las solicitudes limitadas, ya que son transitorias. Por lo tanto, un valor muy bajo puede provocar que la alarma sea demasiado sensible y provocar transiciones de estado no deseadas.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

VolumeStalledIOCheck

Dimensiones: VolumeId, InstanceId

Descripción de la alarma: esta alarma lo ayuda a supervisar el rendimiento de E/S de los volúmenes de Amazon EBS. Esta comprobación detecta problemas subyacentes en la infraestructura de Amazon EBS, como problemas de equipo o software en los subsistemas de almacenamiento de los volúmenes de Amazon EBS, problemas de equipo en el host físico que afectan a la accesibilidad de los volúmenes de Amazon EBS desde su instancia de Amazon EC2, y puede detectar problemas de conectividad entre la instancia y los volúmenes de Amazon EBS. Si la comprobación de E/S estancadas falla, puede esperar a que AWS resuelva el problema o tomar medidas, como reemplazar los volúmenes afectados o detener y reiniciar la instancia a la que está asociado el volumen. En la mayoría de los casos, cuando se produce un error en esta métrica, Amazon EBS diagnosticará y recuperará automáticamente el volumen en cuestión de minutos.

Intención: esta alarma puede detectar el estado de sus volúmenes de Amazon EBS para determinar cuándo estos volúmenes están deteriorados y no pueden completar las operaciones de E/S.

Estadística: Maximum

Umbral recomendado: 1,0

Justificación del umbral: cuando falla una comprobación de estado, el valor de esta métrica es 1. El umbral se establece de modo que, siempre que la verificación de estado falle, la alarma esté en estado de ALARMA.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Amazon EC2

CPUUtilization

Dimensiones: InstanceId

Descripción de la alarma: esta alarma ayuda a supervisar el uso de la CPU de una instancia de EC2. En función de la aplicación, puede que los niveles de utilización siempre altos sean normales. Pero, si se degrada el rendimiento y la aplicación no está limitada por la E/S del disco, la memoria o los recursos de red, una CPU al máximo podría indicar un cuello de botella en los recursos o problemas de rendimiento de la aplicación. Un uso elevado de la CPU puede indicar que es necesario actualizar a una instancia con un uso más intensivo de la CPU. Si la supervisión detallada está habilitada, puede cambiar el período a 60 segundos en lugar de 300 segundos. Para obtener más información, consulte Activar o desactivar la supervisión detallada para las instancias.

Finalidad: esta alarma se utiliza para detectar un uso elevado de la CPU.

Estadística: Average

Umbral recomendado: 80,0

Justificación del umbral: en general, puede establecer el umbral de utilización de la CPU entre el 70 y el 80 %. Sin embargo, puede ajustar este valor en función del nivel de rendimiento y las características de la carga de trabajo aceptables. Para algunos sistemas, un uso elevado y constante de la CPU puede ser normal y no indicar un problema, mientras que para otros puede ser un motivo de preocupación. Analice los datos históricos de uso de la CPU para identificar el uso, determinar qué uso de la CPU es aceptable para su sistema y establecer el umbral correspondiente.

Período: 300

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: GREATER_THAN_THRESHOLD

StatusCheckFailed

Dimensiones: InstanceId

Descripción de la alarma: esta alarma ayuda a supervisar las comprobaciones de estado del sistema y las comprobaciones de estado de las instancias. Si alguno de los tipos de verificación de estado falla, esta alarma debería estar en estado de ALARMA.

Finalidad: esta alarma se utiliza para detectar los problemas subyacentes con las instancias, incluidos los fallos en la comprobación del estado del sistema y los fallos en la comprobación del estado de las instancias.

Estadística: Maximum

Umbral recomendado: 1,0

Justificación del umbral: cuando falla una comprobación de estado, el valor de esta métrica es 1. El umbral se establece de modo que, siempre que la verificación de estado falle, la alarma esté en estado de ALARMA.

Período: 300

Puntos de datos para la alarma: 2

Períodos de evaluación: 2

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

StatusCheckFailed_AttachedEBS

Dimensiones: InstanceId

Descripción de la alarma: esta alarma le ayuda a supervisar si se puede acceder a los volúmenes de Amazon EBS adjuntos a una instancia y completar operaciones de E/S. Esta comprobación de estado detecta los problemas subyacentes en el cómputo o en la infraestructura de Amazon EBS, como los siguientes:

  • Problemas de hardware o software en los subsistemas de almacenamiento subyacentes a los volúmenes de Amazon EBS

  • Problemas de hardware en el host físico que afectan a la accesibilidad de los volúmenes de Amazon EBS

  • Problemas de conectividad entre la instancia y los volúmenes de Amazon EBS

Si la métrica de comprobación de estado de EBS adjunta falla, puede esperar a que Amazon resuelva el problema o tomar medidas, como reemplazar los volúmenes afectados o detener y reiniciar la instancia.

Intención: esta alarma se utiliza para detectar volúmenes de Amazon EBS inalcanzables adjuntos a una instancia. Esto puede provocar fallos en las operaciones de E/S.

Estadística: Maximum

Umbral recomendado: 1,0

Justificación del umbral: cuando falla una comprobación de estado, el valor de esta métrica es 1. El umbral se establece de modo que, siempre que la verificación de estado falle, la alarma esté en estado de ALARMA.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Amazon ElastiCache

CPUUtilization

Dimensiones: CacheClusterId, CacheNodeId

Descripción de la alarma: esta alarma ayuda a supervisar el uso de la CPU en toda la instancia de ElastiCache, incluidos los procesos del motor de base de datos y otros procesos que se ejecutan en la instancia. AWS ElastiCache admite dos tipos de motores: Memcached y Redis. Cuando se alcanza un uso elevado de la CPU en un nodo de Memcached, debería considerar la posibilidad de escalar verticalmente el tipo de instancia o agregar nuevos nodos de caché. En el caso de Redis, si la carga de trabajo principal son las solicitudes de lectura, debería considerar agregar más réplicas de lectura al clúster de caché. Si la carga de trabajo principal proviene de las solicitudes de escritura, debería considerar agregar más particiones para distribuir la carga de trabajo entre más nodos principales si ejecuta en modo agrupado o escalar verticalmente el tipo de instancia si ejecuta Redis en modo no agrupado.

Finalidad: esta alarma se utiliza para detectar un uso elevado de la CPU en los hosts de ElastiCache. Resulta útil obtener una visión amplia del uso de la CPU en toda la instancia, incluidos los procesos que no están relacionados con el motor.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral en el porcentaje que refleje un nivel de uso crítico de la CPU para su aplicación. En el caso de Memcached, el motor puede utilizar hasta num_threads núcleos. En el caso de Redis, el motor funciona en gran medida con un solo subproceso, pero puede utilizar núcleos adicionales si están disponibles para acelerar la E/S. En la mayoría de los casos, puede establecer el umbral en alrededor del 90 % de la CPU disponible. Debido a que Redis usa un único subproceso, el valor del umbral real debe calcularse como una fracción de la capacidad total del nodo.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

CurrConnections

Dimensiones: CacheClusterId, CacheNodeId

Descripción de la alarma: esta alarma detecta un número elevado de conexiones, lo que puede indicar problemas de rendimiento o una carga excesiva. Un aumento constante de CurrConnections podría provocar el agotamiento de las 65 000 conexiones disponibles. Puede indicar que las conexiones se cerraron de forma incorrecta en el lado de la aplicación y se dejaron establecidas en el lado del servidor. Debería considerar la posibilidad de utilizar la agrupación de conexiones o los tiempos de espera de conexión inactivos para limitar la cantidad de conexiones realizadas al clúster o, en el caso de Redis, considerar la posibilidad de ajustar tcp-keepalive en su clúster para detectar y eliminar posibles interconexiones inactivas.

Finalidad: la alarma ayuda a identificar los números elevados de conexiones que podrían afectar al rendimiento y la estabilidad del clúster de ElastiCache.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida del rango de conexiones aceptable para el clúster. Revise la capacidad y la carga de trabajo prevista del clúster de ElastiCache y analice los recuentos históricos de conexiones durante el uso habitual para establecer una referencia y, a continuación, seleccione el umbral correspondiente. Recuerde que cada nodo puede admitir hasta 65 000 conexiones simultáneas.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_THRESHOLD

DatabaseMemoryUsagePercentage

Dimensiones: CacheClusterId

Descripción de la alarma: esta alarma le ayuda a supervisar el uso de la memoria del clúster. Cuando DatabaseMemoryUsagePercentage alcanza el 100 %, se activa la política maxmemory de Redis y es posible que se produzcan expulsiones en función de la política seleccionada. Si ningún objeto de la caché coincide con la política de expulsión, las operaciones de escritura fallan. Algunas cargas de trabajo esperan o dependen de las expulsiones, pero, si no es así, tendrá que aumentar la capacidad de memoria del clúster. Puede escalar horizontalmente el clúster si agrega más nodos principales, o bien escalarlo con un nodo de mayor tamaño. Consulte Escalado de clústeres de ElastiCache for Redis para obtener más información.

Finalidad: esta alarma se utiliza para detectar un uso elevado de la memoria del clúster, de modo que pueda evitar errores al escribir en el clúster. Resulta útil saber cuándo necesitará escalar verticalmente el clúster si su aplicación no espera sufrir expulsiones.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: según los requisitos de memoria de la aplicación y la capacidad de memoria del clúster de ElastiCache, debe establecer el umbral en el porcentaje que refleje el nivel crítico de uso de memoria del clúster. Puede utilizar los datos históricos de uso de memoria como referencia para determinar el umbral de uso de memoria aceptable.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

EngineCPUUtilization

Dimensiones: CacheClusterId

Descripción de la alarma: esta alarma ayuda a supervisar el uso de la CPU de un subproceso del motor Redis dentro de la instancia de ElastiCache. Los motivos más comunes por los que la CPU tiene un motor elevado son los comandos de ejecución prolongada que consumen mucha CPU, el elevado número de solicitudes, el aumento del número de nuevas solicitudes de conexión de clientes en un periodo corto y el elevado número de expulsiones cuando la memoria caché no tiene suficiente memoria para almacenar datos nuevos. Debería considerar el Escalado de clústeres de ElastiCache for Redis mediante la adición de más nodos o el escalado vertical del tipo de instancia.

Finalidad: esta alarma se utiliza para detectar un uso elevado de la CPU del subproceso del motor de Redis. Resulta útil si desea supervisar el uso de la CPU del propio motor de base de datos.

Estadística: Average

Umbral recomendado: 90,0

Justificación del umbral: establezca el umbral en un porcentaje que refleje el nivel crítico de uso de la CPU del motor para su aplicación. Puede comparar su clúster mediante su aplicación y la carga de trabajo esperada para correlacionar EngineCPUUtilization con el rendimiento como referencia y, a continuación, establecer el umbral en consecuencia. En la mayoría de los casos, puede establecer el umbral en alrededor del 90 % de la CPU disponible.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

ReplicationLag

Dimensiones: CacheClusterId

Descripción de la alarma: esta alarma ayuda a supervisar el estado de la replicación del clúster de ElastiCache. Un retraso de replicación alto significa que el nodo principal o la réplica no pueden mantener el ritmo de la replicación. Si la actividad de escritura es demasiado alta, considere escalar horizontalmente el clúster con la adición de más nodos principales, o, bien, escalar verticalmente el clúster con un tipo de nodo de mayor tamaño. Consulte Escalado de clústeres de ElastiCache for Redis para obtener más información. Si sus réplicas de lectura están sobrecargadas por la cantidad de solicitudes de lectura, considere agregar más réplicas de lectura.

Finalidad: esta alarma se utiliza para detectar un retraso entre las actualizaciones de datos en el nodo principal y su sincronización con el nodo de réplica. Ayuda a garantizar la coherencia de datos de un nodo de clúster de réplica de lectura.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral de acuerdo con los requisitos de su aplicación y el posible impacto del retraso en la replicación. Debe tener en cuenta las velocidades de escritura esperadas de la aplicación y las condiciones de la red para determinar el retraso de replicación aceptable.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon EC2 (AWS/ElasticGPUs)

GPUConnectivityCheckFailed

Dimensiones: InstanceId, EGPUId

Descripción de la alarma: esta alarma ayuda a detectar fallos de conexión entre la instancia y el acelerador de Elastic Graphics. Elastic Graphics utiliza la red de la instancia para enviar comandos de OpenGL a una tarjeta gráfica conectada de forma remota. Además, se suele utilizar tecnología de acceso remoto para obtener acceso al escritorio que ejecuta una aplicación de OpenGL con un acelerador de Elastic Graphics. Es importante distinguir entre un problema de rendimiento relacionado con la presentación de OpenGL o con la tecnología de acceso remoto del escritorio. Para obtener más información sobre el problema, consulte Investigación de problemas de rendimiento de las aplicaciones.

Finalidad: esta alarma se utiliza para detectar problemas de conectividad desde la instancia al acelerador de Elastic Graphics.

Estadística: Maximum

Umbral recomendado: 0,0

Justificación del umbral: el valor del umbral de 1 indica que falló la conectividad.

Período: 300

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: GREATER_THAN_THRESHOLD

GPUHealthCheckFailed

Dimensiones: InstanceId, EGPUId

Descripción de la alarma: esta alarma le ayuda a saber cuándo el estado del acelerador Elastic Graphics es incorrecto. Si el acelerador no está en buen estado, consulte los pasos para la solución de problemas en Resolver problemas de estado incorrecto.

Finalidad: esta alarma se utiliza para detectar si el acelerador de Elastic Graphics está en mal estado.

Estadística: Maximum

Umbral recomendado: 0,0

Justificación del umbral: el valor de umbral de 1 indica que falló una comprobación de estado.

Período: 300

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon ECS

CPUReservation

Dimensiones: ClusterName

Descripción de la alarma: esta alarma le ayuda a detectar una reserva de CPU elevada en el clúster ECS. Una reserva de CPU elevada puede indicar que el clúster se está quedando sin CPU registradas para la tarea. Para solucionar problemas, puede agregar más capacidad, escalar el clúster o configurar el escalado automático.

Finalidad: la alarma se utiliza para detectar si el número total de unidades de CPU reservadas para las tareas del clúster está por alcanzar el total de unidades de CPU registradas para el clúster. Esto le ayuda a saber cuándo escalar verticalmente el clúster. Alcanzar el total de unidades de CPU para el clúster puede provocar que se agote la CPU para las tareas. Si tiene activado el escalado gestionado de los proveedores de capacidad de EC2 o asoció Fargate a los proveedores de capacidad, no se recomienda esta alarma.

Estadística: Average

Umbral recomendado: 90,0

Justificación del umbral: establezca el umbral de reserva de CPU en 90 %. Como alternativa, puede elegir un valor inferior en función de las características del clúster.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

CPUUtilization

Dimensiones: ClusterName, ServiceName

Descripción de la alarma: esta alarma le ayuda a detectar un uso elevado de la CPU del servicio ECS. Si no hay una implementación de ECS en curso, una utilización máxima de la CPU podría indicar un cuello de botella en los recursos o problemas de rendimiento de las aplicaciones. Para solucionar los problemas, puede aumentar el límite de la CPU.

Finalidad: esta alarma se utiliza para detectar un uso elevado de la CPU para el servicio de ECS. Un uso elevado y constante de la CPU puede indicar un cuello de botella en los recursos o problemas de rendimiento de las aplicaciones.

Estadística: Average

Umbral recomendado: 90,0

Justificación del umbral: las métricas del servicio para la utilización de la CPU pueden superar el 100 % de utilización. Sin embargo, recomendamos que supervise la métrica para comprobar si hay un uso elevado de la CPU para evitar que afecte a otros servicios. Establezca el umbral entre el 90 y el 95 %. Recomendamos que actualice las definiciones de las tareas para reflejar el uso real y evitar futuros problemas con otros servicios.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

MemoryReservation

Dimensiones: ClusterName

Descripción de la alarma: esta alarma ayuda a detectar una reserva de memoria elevada en el clúster de ECS. Una reserva de memoria elevada puede indicar un cuello de botella de recursos para el clúster. Para solucionar el problema, analice el rendimiento de la tarea de servicio para ver si se puede optimizar el uso de la memoria de la tarea. Además, puede registrar más memoria o configurar el escalado automático.

Finalidad: la alarma se utiliza para detectar si el total de unidades de memoria reservadas para las tareas del clúster está cerca de alcanzar el total de unidades de memoria registradas para el clúster. Esto puede ayudarle a saber cuándo escalar verticalmente el clúster. Alcanzar el total de unidades de memoria para el clúster puede provocar que el clúster no pueda iniciar nuevas tareas. Si activó el escalado gestionado por los proveedores de capacidad de EC2 o asoció Fargate a los proveedores de capacidad, no se recomienda utilizar esta alarma.

Estadística: Average

Umbral recomendado: 90,0

Justificación del umbral: establezca el umbral de reserva de memoria en 90 %. Puede ajustarlo a un valor inferior en función de las características del clúster.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

HTTPCode_Target_5XX_Count

Dimensiones: ClusterName, ServiceName

Descripción de la alarma: esta alarma ayuda a detectar un recuento elevado de errores del lado del servidor en el servicio de ECS. Esto puede indicar que hay errores que hacen que el servidor no pueda atender las solicitudes. Para solucionar el problema, consulte los registros de la aplicación.

Finalidad: esta alarma se utiliza para detectar un número elevado de errores del lado del servidor en el servicio de ECS.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: calcule un valor de alrededor del 5 % del tráfico promedio y utilice este valor como punto de partida para el umbral. Puede encontrar el tráfico promedio con la métrica RequestCount. También puede analizar los datos históricos para determinar la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia. Los errores 5XX que se producen con frecuencia deben ser objeto de alarma. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede ser demasiado sensible.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

TargetResponseTime

Dimensiones: ClusterName, ServiceName

Descripción de la alarma: esta alarma ayuda a detectar un tiempo de respuesta del destino elevado para las solicitudes de servicio de ECS. Esto puede indicar que hay problemas que hacen que el servicio no pueda atender las solicitudes a tiempo. Para solucionar el problema, compruebe la métrica CPUUtilization para ver si el servicio se está quedando sin CPU o compruebe el uso de la CPU de otros servicios posteriores de los que depende el servicio.

Finalidad: esta alarma se utiliza para detectar un tiempo de respuesta del destino elevado para las solicitudes de servicio de ECS.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida del caso de uso. Revise la criticidad y los requisitos del tiempo de respuesta del destino del servicio y analice el comportamiento histórico de esta métrica para determinar los niveles de umbral razonables.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon ECS con Información de contenedores

EphemeralStorageUtilized

Dimensiones: ClusterName, ServiceName

Descripción de la alarma: esta alarma ayuda a detectar el alto nivel de almacenamiento efímero utilizado en el clúster de Fargate. Si el almacenamiento efímero es constantemente alto, puede comprobar el uso del almacenamiento efímero y aumentarlo.

Finalidad: esta alarma se utiliza para detectar un uso elevado de almacenamiento efímero en el clúster de Fargate. El uso constante de un alto nivel de almacenamiento efímero puede indicar que el disco está lleno y provocar una falla en el contenedor.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral en aproximadamente el 90 % del tamaño del almacenamiento efímero. Puede ajustar este valor en función del uso aceptable del almacenamiento efímero del clúster de Fargate. Para algunos sistemas, puede ser normal utilizar un alto volumen constante de almacenamiento efímero, mientras que para otros puede provocar una falla en el contenedor.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

RunningTaskCount

Dimensiones: ClusterName, ServiceName

Descripción de la alarma: esta alarma ayuda a detectar un número bajo de tareas en ejecución del servicio ECS. Si el recuento de tareas en ejecución es demasiado bajo, puede indicar que la aplicación no puede gestionar la carga de servicio y esto podría provocar problemas de rendimiento. Si no hay ninguna tarea en ejecución, es posible que el servicio Amazon ECS no esté disponible o que haya problemas de implementación.

Finalidad: esta alarma se utiliza para detectar si el número de tareas en ejecución es demasiado bajo. Un número bajo y constante de tareas en ejecución puede indicar problemas de rendimiento o implementación del servicio ECS.

Estadística: Average

Umbral recomendado: 0,0

Justificación del umbral: puede ajustar el umbral en función del recuento mínimo de tareas en ejecución del servicio ECS. Si el recuento de tareas en ejecución es 0, el servicio Amazon ECS no estará disponible.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: LESS_THAN_OR_EQUAL_TO_THRESHOLD

instance_filesystem_utilization

Dimensiones: InstanceId, ContainerInstanceId, ClusterName

Descripción de la alarma: esta alarma ayuda a detectar un uso elevado del sistema de archivos en el clúster de ECS. Si el uso del sistema de archivos es constantemente alto, verifique el uso del disco.

Finalidad: esta alarma se utiliza para detectar un uso elevado del sistema de archivos en el clúster de Amazon ECS. Un uso elevado y constante del sistema de archivos puede indicar un cuello de botella en los recursos o problemas de rendimiento de las aplicaciones y puede impedir la ejecución de nuevas tareas.

Estadística: Average

Umbral recomendado: 90,0

Justificación del umbral: puede establecer el umbral de utilización del sistema de archivos entre el 90 y el 95 %. Puede ajustar este valor en función del nivel de capacidad aceptable del sistema de archivos del clúster de Amazon ECS. Para algunos sistemas, una utilización elevada y constante del sistema de archivos puede ser normal y no indicar ningún problema, mientras que para otros puede ser motivo de preocupación y provocar problemas de rendimiento e impedir la ejecución de nuevas tareas.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon EFS

PercentIOLimit

Dimensiones: FileSystemId

Descripción de la alarma: esta alarma ayuda a garantizar que la carga de trabajo se mantenga dentro del límite de E/S disponible para el sistema de archivos. Si la métrica alcanza su límite de E/S con frecuencia, considere la posibilidad de trasladar la aplicación a un sistema de archivos que utilice el rendimiento máximo de E/S como modo. Para solucionar problemas, compruebe los clientes que están conectados al sistema de archivos y las aplicaciones de los clientes que limitan el sistema de archivos.

Finalidad: esta alarma se utiliza para detectar qué tan cerca está un sistema de archivos para llegar al límite de E/S del modo de rendimiento de uso general. Un porcentaje de E/S elevado y constante puede ser un indicador de que el sistema de archivos no puede escalarse lo suficiente con respecto a las solicitudes de E/S y el sistema de archivos puede ser un cuello de botella de recursos para las aplicaciones que utilizan el sistema de archivos.

Estadística: Average

Umbral recomendado: 100,0

Justificación del umbral: cuando el sistema de archivos alcanza su límite de E/S, es posible que responda más lento a las solicitudes de lectura y escritura. Por lo tanto, se recomienda supervisar la métrica para evitar que afecte a las aplicaciones que utilizan el sistema de archivos. El umbral se puede establecer en torno al 100 %. Sin embargo, este valor se puede ajustar a un valor inferior en función de las características del sistema de archivos.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

BurstCreditBalance

Dimensiones: FileSystemId

Descripción de la alarma: esta alarma ayuda a garantizar que haya saldo de créditos de ráfaga disponible para el uso del sistema de archivos. Cuando no haya créditos de ráfaga disponibles, el acceso de las aplicaciones al sistema de archivos se verá limitado debido al bajo rendimiento. Si la métrica cae a 0 de forma constante, considere la posibilidad de cambiar del modo de rendimiento al modo de rendimiento elástico o aprovisionado.

Finalidad: esta alarma se utiliza para detectar un saldo de crédito de ráfaga bajo del sistema de archivos. Un saldo de créditos de ráfaga bajo y constante puede ser un indicador de la ralentización del rendimiento y del aumento de la latencia de E/S.

Estadística: Average

Umbral recomendado: 0,0

Justificación del umbral: cuando el sistema de archivos se queda sin créditos de ráfaga e incluso si la tasa de rendimiento de referencia es inferior, EFS proporciona un rendimiento medido de 1 MiBps a todos los sistemas de archivos. Sin embargo, se recomienda supervisar la métrica para comprobar si el saldo de créditos por ráfaga es bajo para evitar que el sistema de archivos actúe como un cuello de botella para los recursos de las aplicaciones. El umbral se puede establecer en torno a 0 bytes.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: LESS_THAN_OR_EQUAL_TO_THRESHOLD

Amazon EKS con Información de contenedores

node_cpu_utilization

Dimensiones: ClusterName

Descripción de la alarma: esta alarma ayuda a detectar un uso elevado de la CPU en los nodos de trabajo del clúster de EKS. Si la utilización es elevada de forma constante, podría indicar la necesidad de reemplazar los nodos de trabajo por instancias que tengan mayor CPU o la necesidad de escalar horizontalmente el sistema.

Finalidad: esta alarma ayuda a supervisar el uso de la CPU de los nodos de trabajo del clúster de EKS para que el rendimiento del sistema no se degrade.

Estadística: Maximum

Umbral recomendado: 80,0

Justificación del umbral: se recomienda establecer el umbral en un valor inferior o igual al 80 % para disponer del tiempo suficiente para depurar el problema antes de que el sistema empiece a verse afectado.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

node_filesystem_utilization

Dimensiones: ClusterName

Descripción de la alarma: esta alarma ayuda a detectar un uso elevado del sistema de archivos en los nodos de trabajo del clúster de EKS. Si la utilización es elevada de forma constante, es posible que necesite actualizar los nodos de trabajo para que tengan un mayor volumen de disco o que necesite escalarlos horizontalmente.

Finalidad: esta alarma ayuda a supervisar la utilización del sistema de archivos de los nodos de trabajo del clúster de EKS. Si la utilización alcanza el 100 %, se pueden producir fallos en la aplicación, cuellos de botella de E/S del disco, la expulsión del pod o que el nodo deje de responder por completo.

Estadística: Maximum

Umbral recomendado: depende de la situación

Justificación del umbral: si hay suficiente presión en el disco (lo que significa que el disco se está llenando), los nodos se marcan como en mal estado y los pods se expulsan del nodo. Los pods de un nodo con presión de disco se expulsan cuando el sistema de archivos disponible es inferior a los umbrales de expulsión establecidos en kubelet. Establezca el umbral de alarma para tener tiempo suficiente para reaccionar antes de que el nodo sea expulsado del clúster.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

node_memory_utilization

Dimensiones: ClusterName

Descripción de la alarma: esta alarma ayuda a detectar un uso elevado de la memoria en los nodos de trabajo del clúster de EKS. Si la utilización es elevada de forma constante, podría indicar la necesidad de aumentar el número de réplicas de los pods u optimizar la aplicación.

Finalidad: esta alarma ayuda a supervisar el uso de la memoria de los nodos de trabajo del clúster de EKS para que el rendimiento del sistema no se degrade.

Estadística: Maximum

Umbral recomendado: 80,0

Justificación del umbral: se recomienda establecer el umbral en un valor inferior o igual al 80 % para disponer de tiempo suficiente para depurar el problema antes de que el sistema empiece a verse afectado.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

pod_cpu_utilization_over_pod_limit

Dimensiones: ClusterName, Namespace, Service

Descripción de la alarma: esta alarma ayuda a detectar un uso elevado de la CPU en los pods del clúster de EKS. Si la utilización es siempre alta, podría indicar la necesidad de aumentar el límite de la CPU del pod afectado.

Finalidad: esta alarma ayuda a supervisar el uso de la CPU de los pods que pertenecen a un servicio de Kubernetes en el clúster de EKS, de modo que se puede identificar con rapidez si el pod de un servicio consume más CPU de lo esperado.

Estadística: Maximum

Umbral recomendado: 80,0

Justificación del umbral: se recomienda establecer el umbral en un valor inferior o igual al 80 % para disponer de tiempo suficiente para depurar el problema antes de que el sistema empiece a verse afectado.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

pod_memory_utilization_over_pod_limit

Dimensiones: ClusterName, Namespace, Service

Descripción de la alarma: esta alarma ayuda a detectar un uso elevado de la memoria en los pods del clúster de EKS. Si la utilización es siempre alta, podría indicar la necesidad de aumentar el límite de memoria del pod afectado.

Finalidad: esta alarma ayuda a supervisar el uso de la memoria de los pods del clúster de EKS para que el rendimiento del sistema no se degrade.

Estadística: Maximum

Umbral recomendado: 80,0

Justificación del umbral: se recomienda establecer el umbral en un valor inferior o igual al 80 % para disponer de tiempo suficiente para depurar el problema antes de que el sistema empiece a verse afectado.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon Kinesis Data Streams

GetRecords.IteratorAgeMilliseconds

Dimensiones: StreamName

Descripción de la alarma: esta alarma puede detectar si la antigüedad máxima del iterador es demasiado alta. Para aplicaciones de procesamiento de datos en tiempo real, configure la retención de datos de acuerdo con la tolerancia al retraso. Esto proceso suele tomar solo algunos minutos. En el caso de las aplicaciones que procesan datos históricos, utilice esta métrica para supervisar la velocidad de recuperación. Una solución rápida para detener la pérdida de datos consiste en incrementar el período de retención mientras se soluciona el problema. También, puede aumentar el número de trabajadores que procesan los registros en su aplicación para consumidores. Las causas más comunes del incremento gradual en la antigüedad del iterador son la insuficiencia de recursos físicos o una lógica de procesamiento de registros que no se escaló con un aumento en el rendimiento del flujo. Consulte este enlace para obtener más detalles.

Intención: esta alarma se utiliza para detectar si los datos de su flujo van a caducar porque se conservaron durante demasiado tiempo o porque el procesamiento de los registros es demasiado lento. Esta alarma ayuda a evitar la pérdida de datos tras alcanzar el 100 % del tiempo de retención del flujo.

Estadística: Maximum

Umbral recomendado: depende de la situación

Justificación del umbral: el valor de umbral recomendado para esta alarma depende en gran medida del período de retención del flujo y de la tolerancia al retraso en el procesamiento de los registros. Revise sus requisitos y analice las tendencias históricas y, a continuación, establezca el umbral en la cantidad de milisegundos que representa un retraso de procesamiento crítico. Si la antigüedad de un iterador supera el 50 % del periodo de retención (con un valor predeterminado de 24 horas, pero configurable hasta 365 días), existe el riesgo de pérdida de datos debido al vencimiento del registro. Puede supervisar la métrica para asegurarse de que ninguna de sus particiones nunca se acerque a este límite.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

GetRecords.Success

Dimensiones: StreamName

Descripción de la alarma: esta métrica aumenta cada vez que los consumidores leen de forma correcta los datos del flujo. GetRecords no devuelve ningún dato cuando genera una excepción. La excepción más común es ProvisionedThroughputExceededException, debido a que la tasa de solicitudes del flujo es demasiado alta o a que el rendimiento disponible ya está ocupado para el segundo en cuestión. Reduzca la frecuencia o el tamaño de las solicitudes. Para obtener más información, consulte Límites en la Guía para desarrolladores de Amazon Kinesis Data Streams, y Reintentos de error y retroceso exponencial en AWS.

Finalidad: esta alarma puede detectar si los consumidores tienen problemas para recuperar los registros del flujo. Al configurar una alarma en esta métrica, puede detectar de forma proactiva cualquier problema relacionado con el consumo de datos, como el aumento de las tasas de error o la disminución del número de recuperaciones exitosas. Esto le permite tomar medidas oportunas para resolver posibles problemas y mantener una canalización de procesamiento de datos sin inconvenientes.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: en función de la importancia de recuperar los registros del flujo, establezca el umbral en basándose en la tolerancia de la aplicación a los registros fallidos. El umbral debe ser el porcentaje correspondiente de operaciones exitosas. Puede utilizar los datos métricos históricos de GetRecords como referencia para determinar la tasa de errores aceptable. También debe tener en cuenta los reintentos al establecer el umbral, ya que los registros fallidos se pueden volver a intentar. Esto ayuda a evitar que los picos transitorios generen alertas innecesarias.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: LESS_THAN_THRESHOLD

PutRecord.Success

Dimensiones: StreamName

Descripción de la alarma: esta alarma detecta cuando el número de operaciones de PutRecord fallidas supera el umbral. Investigue los registros del productor de datos para encontrar las causas principales de las fallas. La razón más común es un rendimiento aprovisionado insuficiente en la partición que provocó el ProvisionedThroughputExceededException. Esto se debe a que la tasa de solicitudes para el flujo es demasiado alta o a que el rendimiento que se intentó incorporar en la partición es demasiado alto. Reduzca la frecuencia o el tamaño de las solicitudes. Para obtener más información, consulte Límites y Reintentos de error y retroceso exponencial en AWS.

Finalidad: esta alarma puede detectar fallas en la incorporación de registros en el flujo. Le ayuda a identificar problemas al escribir datos en el flujo. Al configurar una alarma en esta métrica, puede detectar de forma proactiva cualquier problema que puedan tener los productores a la hora de publicar datos en el flujo, como el aumento de las tasas de error o la disminución del número de registros que se publican con éxito. Esto le permite tomar medidas oportunas para abordar posibles problemas y mantener un proceso fiable de ingesta de datos.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: en función de la importancia del procesamiento y la ingesta de datos para su servicio, establezca el umbral en función de la tolerancia de su aplicación a los registros fallidos. El umbral debe ser el porcentaje correspondiente de operaciones exitosas. Puede utilizar los datos métricos históricos de PutRecord como referencia para determinar la tasa de fallos aceptable. También debe tener en cuenta los reintentos al establecer el umbral, ya que los registros fallidos se pueden volver a intentar.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: LESS_THAN_THRESHOLD

PutRecords.FailedRecords

Dimensiones: StreamName

Descripción de la alarma: esta alarma detecta cuando el número de PutRecords fallidos supera el umbral. Kinesis Data Streams intenta procesar todos los registros de cada solicitud de PutRecords, pero un único error en el registro no detiene el procesamiento de los registros posteriores. El motivo principal de estos errores es que se supera el rendimiento de un flujo o una partición individual. Las causas más comunes son los picos de tráfico y las latencias de la red, que hacen que los registros lleguen al flujo de manera desigual. Debe detectar los registros procesados de forma incorrecta y reintentarlos en una llamada posterior. Consulte Handling Failures When Using PutRecords para obtener más información.

Finalidad: esta alarma puede detectar errores constantes cuando se utiliza la operación por lotes para colocar registros en el flujo. Al configurar una alarma en esta métrica, puede detectar de forma proactiva un aumento en el número de registros fallidos, lo que le permitirá tomar medidas oportunas para abordar los problemas subyacentes y garantizar un proceso de ingesta de datos fiable y fluido.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: defina el umbral en el número de registros fallidos que refleje la tolerancia de la aplicación frente a los registros fallidos. Puede utilizar los datos históricos como referencia para determinar el valor de errores aceptable. También debe tener en cuenta los reintentos al establecer el umbral, ya que los registros fallidos se pueden volver a intentar en llamadas posteriores a PutRecords.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

ReadProvisionedThroughputExceeded

Dimensiones: StreamName

Descripción de la alarma: la alarma hace un seguimiento de la cantidad de registros que provocan una limitación de la capacidad de rendimiento de lectura. Si observa una limitación constante, debería considerar la posibilidad de agregar más particiones al flujo para aumentar el rendimiento de lectura aprovisionado. Si hay más de una aplicación para consumidores que se ejecuta en el flujo y estas comparten el límite GetRecords, recomendamos que registre las nuevas aplicaciones para consumidores mediante Enhanced Fan-Out. Si al agregar más particiones no se reduce el número de limitaciones, es posible que se trate de una partición “activa” de la que se está leyendo más que desde otras particiones. Habilite la supervisión mejorada, busque la partición “activa” y divídala.

Finalidad: esta alarma puede detectar si los consumidores se ven limitados al superar el rendimiento de lectura aprovisionado (determinado por el número de particiones de las que dispone). En ese caso, no podrá leer desde el flujo y este puede empezar a hacer copias de seguridad.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: por lo general, las solicitudes limitadas se pueden volver a intentar y, por lo tanto, establecer el umbral en cero hace que la alarma sea demasiado sensible. Sin embargo, una limitación constante puede afectar a la lectura desde el flujo y debería activar la alarma. Establezca el umbral en un porcentaje en función de las solicitudes limitadas de la aplicación y de las configuraciones de reintento.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

SubscribeToShardEvent.MillisBehindLatest

Dimensiones: StreamName, ConsumerName

Descripción de la alarma: esta alarma detecta cuando el retraso en el procesamiento de los registros en la aplicación sobrepasa el umbral. Los problemas transitorios, como los fallos en el funcionamiento de la API en una aplicación posterior, pueden provocar un aumento repentino en la métrica. Si estos fallos se producen de forma constante, debería investigar. Una causa común es que el consumidor no procesa los registros con la suficiente rapidez debido a la insuficiencia de los recursos físicos o de la lógica de procesamiento de registros, que no se escala con el aumento del rendimiento del flujo. El bloqueo de las llamadas en una ruta crítica suele ser la causa de la ralentización en el procesamiento de registros. Puede aumentar el paralelismo si incrementa el número de particiones. También, debe confirmar que los nodos de procesamiento subyacentes tengan recursos físicos suficientes durante los picos de demanda.

Finalidad: esta alarma puede detectar un retraso en la suscripción al evento de una partición del flujo. Esto indica un retraso en el procesamiento y puede ayudar a identificar posibles problemas con el rendimiento de la aplicación para consumidores o con el estado general del flujo. Cuando el retraso en el procesamiento es significativo, debe investigar y abordar cualquier cuello de botella o ineficiencia en las aplicaciones del consumidor para garantizar el procesamiento de los datos en tiempo real y minimizar la acumulación de datos.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida del retraso que pueda tolerar su aplicación. Revise los requisitos de su solicitud y analice las tendencias históricas y, a continuación, seleccione el umbral correspondiente. Cuando la llamada SubscribeToShard se realiza de forma correcta, el consumidor recibirá eventos de SubscribeToShardEvent a través de la conexión persistente durante un máximo de 5 minutos, tras lo cual tendrá que volver a llamar a SubscribeToShard para renovar la suscripción si quiere continuar con la recepción de registros.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

WriteProvisionedThroughputExceeded

Dimensiones: StreamName

Descripción de la alarma: esta alarma detecta cuando el número de registros que dan lugar a una limitación de la capacidad de rendimiento de escritura alcanza el umbral. Cuando los productores superan el rendimiento de escritura aprovisionado (determinado por el número de particiones que posee), se verán limitados y no podrán incluir los registros en el flujo. Para evitar una limitación constante, debería considerar la posibilidad de agregar particiones al flujo. Esto aumenta el rendimiento de escritura aprovisionado y evita futuras limitaciones. También debe tener en cuenta la elección de la clave de partición al incorporar los registros. Se prefiere la clave de partición aleatoria porque distribuye los registros de manera uniforme entre las particiones del flujo, siempre que sea posible.

Finalidad: esta alarma puede detectar si sus productores son rechazados a la hora de escribir registros debido a la limitación del flujo o la partición. Si el flujo está en modo aprovisionado, configurar esta alarma le ayudará a tomar medidas de forma proactiva cuando el flujo de datos alcance sus límites, lo que le permitirá optimizar la capacidad aprovisionada o tomar las medidas de escalado adecuadas para evitar la pérdida de datos y mantener un procesamiento de datos fluido.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: por lo general, las solicitudes limitadas se pueden volver a intentar, por lo que, si se establece el umbral en cero, la alarma será demasiado sensible. Sin embargo, una limitación constante puede afectar a la escritura en el flujo, por lo que debe configurar el umbral de alarma para detectar este problema. Establezca el umbral en un porcentaje en función de las solicitudes limitadas de la aplicación y de las configuraciones de reintento.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Lambda

ClaimedAccountConcurrency

Dimensiones: None

Descripción de la alarma: esta alarma ayuda a supervisar si la simultaneidad de la función de Lambda se acerca al límite de simultaneidad a nivel de la región de su cuenta. Una función comienza a limitarse si alcanza el límite de simultaneidad. Puede realizar las siguientes acciones para evitar la limitación.

  1. Solicitar un aumento de simultaneidad en esta región.

  2. Identifique y reduzca cualquier simultaneidad reservada o aprovisionada que no se utilice.

  3. Identificar los problemas de funcionamiento en las funciones para mejorar la velocidad de procesamiento y, por lo tanto, mejorar el rendimiento.

  4. Aumentar el tamaño del lote de las funciones, de modo que cada invocación de la función procese más mensajes.

Finalidad: esta alarma puede detectar de forma proactiva si la simultaneidad de su función de Lambda se acerca a la cuota de simultaneidad de la cuenta a nivel regional, para que pueda actuar en consecuencia. Una función se limita si ClaimedAccountConcurrency alcanza la cuota de simultaneidad de la cuenta a nivel de la región. Si utiliza la simultaneidad reservada (RC) o la simultaneidad aprovisionada (PC), esta alarma le ofrece más visibilidad del uso de la simultaneidad que una alarma activada en ConcurrentExecutions.

Estadística: Maximum

Umbral recomendado: depende de la situación

Justificación del umbral: debe calcular el valor de alrededor del 90 % de la cuota de simultaneidad configurada para la cuenta en la región y utilizar el resultado como valor para el umbral. De forma predeterminada, la cuenta tiene una cuota de simultaneidad de 1000 en todas las funciones en una región. Sin embargo, debe comprobar la cuota de su cuenta desde el panel de control de Service Quotas.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_THRESHOLD

Errores

Dimensiones: FunctionName

Descripción de la alarma: esta alarma detecta un alto número de errores. Los errores incluyen las excepciones lanzadas por el código y las excepciones lanzadas por el tiempo de ejecución de Lambda. Puede consultar los registros relacionados con la función para diagnosticar el problema.

Finalidad: la alarma ayuda a detectar un alto número de errores en las invocaciones de funciones.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral en un número mayor a cero. El valor exacto puede depender de la tolerancia a los errores de la aplicación. Es fundamental comprender la importancia de las invocaciones que maneja la función. Para algunas aplicaciones, cualquier error puede ser inaceptable, mientras que otras aplicaciones permiten un cierto margen de error.

Período: 60

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: GREATER_THAN_THRESHOLD

Limitaciones

Dimensiones: FunctionName

Descripción de la alarma: esta alarma detecta un número elevado de solicitudes de invocación limitadas. La limitación ocurre cuando no hay ninguna simultaneidad disponible para escalar verticalmente. Existen varios enfoques para resolver este problema. 1) Solicitar un aumento de simultaneidad de AWS Support en esta región. 2) Identificar los problemas de rendimiento en la función para mejorar la velocidad de procesamiento y, por lo tanto, mejorar el rendimiento. 3) Aumentar el tamaño del lote de la función, de modo que cada invocación de la función procese más mensajes.

Finalidad: la alarma ayuda a detectar un número elevado de solicitudes de invocación limitadas para una función de Lambda. Es importante saber si las solicitudes se rechazan con frecuencia debido a la limitación y si necesita mejorar el rendimiento de la función de Lambda o aumentar la capacidad de simultaneidad para evitar una limitación constante.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral en un número mayor a cero. El valor exacto del umbral puede depender de la tolerancia de la aplicación. Establezca el umbral de acuerdo con los requisitos de uso y escalado de la función.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Duration (Duración)

Dimensiones: FunctionName

Descripción de la alarma: esta alarma detecta tiempos de duración prolongados para procesar un evento mediante una función de Lambda. Las duraciones prolongadas pueden deberse a cambios en el código de la función, que hacen que la función tarde más en ejecutarse, o a que las dependencias de la función demoren más.

Intención: esta alarma puede detectar una duración prolongada de ejecución de una función de Lambda. Una duración prolongada del tiempo de ejecución indica que la invocación de una función tarda más tiempo y, también, puede afectar a la capacidad de simultaneidad de la invocación si Lambda gestiona un número mayor de eventos. Es fundamental saber si la función de Lambda tarda con frecuencia más tiempo de ejecución de lo esperado.

Estadística: p90

Umbral recomendado: depende de la situación

Justificación del umbral: el umbral de la duración depende de la aplicación y de las cargas de trabajo, así como de los requisitos de rendimiento. Para los requisitos de alto rendimiento, establezca el umbral en un tiempo más corto para comprobar si la función cumple con las expectativas. También, puede analizar los datos históricos de las métricas de duración para comprobar si el tiempo empleado coincide con las expectativas de rendimiento de la función y, a continuación, establecer el umbral en un tiempo superior al promedio histórico. Asegúrese de establecer el umbral por debajo del tiempo de espera de la función configurada.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

ConcurrentExecutions

Dimensiones: FunctionName

Descripción de la alarma: esta alarma ayuda a supervisar si la simultaneidad de la función se acerca al límite de simultaneidad a nivel de la región de su cuenta. Una función comienza a limitarse si alcanza el límite de simultaneidad. Puede realizar las siguientes acciones para evitar la limitación.

  1. Solicitar un aumento de simultaneidad en esta región.

  2. Identificar los problemas de funcionamiento en las funciones para mejorar la velocidad de procesamiento y, por lo tanto, mejorar el rendimiento.

  3. Aumentar el tamaño del lote de las funciones, de modo que cada invocación de la función procese más mensajes.

Para obtener una mejor visibilidad de la simultaneidad reservada y del uso de la simultaneidad aprovisionada, configura una alarma en la nueva métrica de ClaimedAccountConcurrency.

Finalidad: esta alarma puede detectar de forma proactiva si la simultaneidad de la función se acerca a la cuota de simultaneidad de la cuenta a nivel regional, para que pueda actuar en consecuencia. Una función se limita si alcanza la cuota de simultaneidad de la cuenta a nivel de la región.

Estadística: Maximum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral en alrededor del 90 % de la cuota de simultaneidad establecida para la cuenta en la región. De forma predeterminada, la cuenta tiene una cuota de simultaneidad de 1000 en todas las funciones en una región. Sin embargo, puede comprobar la cuota de tu cuenta, ya que se puede aumentar si se pone en contacto con el servicio de asistencia de AWS.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_THRESHOLD

Lambda Insights

Recomendamos configurar alarmas de las prácticas recomendadas para las siguientes métricas de Lambda Insights.

memory_utilization

Dimensiones: function_name

Descripción de la alarma: esta alarma se utiliza para detectar si la utilización de la memoria de una función de lambda se acerca al límite configurado. Para solucionar problemas, puede intentar 1) Optimizar su código. 2) Calcular de forma correcta su asignación de memoria al estimar con precisión los requisitos de memoria. Puede consultar Lambda Power Tuning para más información. 3) Utilizar la agrupación de conexiones. Consulte Using Amazon RDS Proxy with Lambda para ver la agrupación de conexiones para la base de datos de RDS. 4) También, puede considerar diseñar sus funciones para evitar almacenar grandes cantidades de datos en la memoria entre las invocaciones.

Finalidad: esta alarma sirve para detectar si la utilización de memoria para la función de Lambda se acerca al límite configurado.

Estadística: Average

Umbral recomendado: 90,0

Justificación del umbral: establezca el umbral en el 90 % para recibir una alerta cuando la utilización de la memoria supere el 90 % de la memoria asignada. Puede ajustarlo a un valor inferior si le preocupa la carga de trabajo relacionada para el uso de la memoria. También puede comprobar los datos históricos de esta métrica y establecer el umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon VPC (AWS/NATGateway)

ErrorPortAllocation

Dimensiones: NatGatewayId

Descripción de la alarma: esta alarma ayuda a detectar cuándo la puerta de enlace NAT no puede asignar puertos a nuevas conexiones. Para resolver este problema, consulte Resolve port allocation errors on NAT Gateway.

Finalidad: esta alarma se utiliza para detectar si la puerta de enlace NAT no pudo asignar un puerto de origen.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: si el valor de ErrorPortAllocation es superior a cero, significa que hay demasiadas conexiones simultáneas a un único destino popular abiertas a través de la puerta de enlace NAT.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

PacketsDropCount

Dimensiones: NatGatewayId

Descripción de la alarma: esta alarma ayuda a detectar cuándo la puerta de enlace NAT descarta paquetes. Esto puede deberse a un problema con la puerta de enlace NAT, así que consulte el panel de estado del servicio de AWS para ver el estado de la puerta de enlace NAT de AWS en su región. Esto puede ayudarlo a correlacionar el problema de red relacionado con el tráfico mediante la puerta de enlace NAT.

Finalidad: esta alarma se utiliza para detectar si la puerta de enlace NAT descarta paquetes.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: debe calcular el valor del 0,01 por ciento del tráfico total en la puerta de enlace NAT y utilizar ese resultado como valor del umbral. Utilice los datos históricos del tráfico en la puerta de enlace NAT para determinar el umbral.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Enlace privado de AWS (AWS/PrivateLinkEndpoints)

PacketsDropped

Dimensiones: VPC Id, VPC Endpoint Id, Endpoint Type, Subnet Id, Service Name

Descripción de la alarma: esta alarma ayuda a detectar si el punto de conexión o el servicio del punto de conexión no funcionan de forma correcta, ya que supervisa la cantidad de paquetes descartados por el punto de conexión. Tenga en cuenta que se descartan los paquetes con un tamaño superior a 8500 bytes que llegan al punto de conexión de VPC. Para solucionar problemas, consulte ¿Cómo soluciono los problemas de conectividad entre un punto de conexión de Amazon VPC de interfaz y un servicio de punto de conexión?.

Finalidad: esta alarma se utiliza para detectar si el punto de conexión o el servicio del punto de conexión no están en buen estado.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral según el caso de uso. Si quiere saber si el punto de conexión o el servicio del punto de conexión están en mal estado, debe establecer un umbral bajo para poder solucionar el problema antes de que se produzca una pérdida importante de datos. Puede utilizar los datos históricos para comprender la tolerancia ante el descarte de paquetes y establecer el umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Enlace privado de AWS (AWS/PrivateLinkServices)

RstPacketsSent

Dimensiones: Service Id, Load Balancer Arn, Az

Descripción de la alarma: esta alarma ayuda a detectar los destinos de un servicio de punto de conexión en mal estado en función de la cantidad de paquetes de restablecimiento que se envían a los puntos finales. Al depurar los errores de conexión con un consumidor de su servicio, puede validar si el servicio está restableciendo las conexiones con la métrica RstPacketsSent o si hay algún otro error en la ruta de la red.

Finalidad: esta alarma se utiliza para detectar si los destinos de un servicio de punto de conexión están en mal estado.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: el umbral depende del caso de uso. Si su caso de uso puede tolerar que los destinos no estén en buen estado, puede establecer el umbral en un nivel alto. Si el caso de uso no tolera los destinos en mal estado, puede establecer el umbral en un nivel muy bajo.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon RDS

CPUUtilization

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar un uso elevado y constante de la CPU. La utilización de la CPU mide el tiempo de inactividad. Considere la posibilidad de utilizar Supervisión mejorada o Información del rendimiento para revisar qué tiempo de espera consume la mayor parte del tiempo de la CPU (guest, irq, wait, nice, etc.) en MariaDB, MySQL, Oracle y PostgreSQL. A continuación, evalúe qué consultas consumen la mayor cantidad de CPU. Si no puede ajustar la carga de trabajo, considere la posibilidad de cambiar a una clase de instancia de base de datos más grande.

Finalidad: esta alarma se utiliza para detectar un uso elevado y constante de la CPU con el fin de evitar tiempos de respuesta y tiempos de espera muy elevados. Si desea comprobar la microrráfaga de uso de la CPU, puede configurar un tiempo de evaluación de la alarma más bajo.

Estadística: Average

Umbral recomendado: 90,0

Justificación del umbral: es posible que los picos aleatorios en el consumo de CPU no obstaculicen el rendimiento de la base de datos, pero un nivel prolongado de CPU puede dificultar las próximas solicitudes de la base de datos. Según la carga de trabajo general de la base de datos, un nivel elevado de CPU en la instancia de RDS/Aurora puede reducir el rendimiento general.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

DatabaseConnections

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma detecta un número elevado de conexiones. Revise las conexiones existentes y cancele las que estén en estado de “reposo” o que estén cerradas incorrectamente. Considere la posibilidad de utilizar la agrupación de conexiones para limitar el número de conexiones nuevas. También puede aumentar el tamaño de la instancia de base de datos para usar una clase con más memoria y, por lo tanto, un valor predeterminado más alto para “max_connections” o aumentar el valor “max_connections” en RDS y Aurora MySQL y PostgreSQL para la clase actual si puede soportar la carga de trabajo.

Finalidad: esta alarma se utiliza para evitar el rechazo de conexiones cuando se alcanza el número máximo de conexiones de base de datos. No se recomienda esta alarma si cambia con frecuencia la clase de instancia de base de datos, ya que al hacerlo se modifican la memoria y el número máximo predeterminado de conexiones.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: el número de conexiones permitidas depende del tamaño de la clase de instancia de base de datos y de los parámetros específicos del motor de base de datos relacionados con los procesos o las conexiones. Debe calcular un valor entre el 90 y el 95 % del número máximo de conexiones de la base de datos y utilizar ese resultado como valor del umbral.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

EBSByteBalance%

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar un bajo porcentaje de los créditos de rendimiento restantes. Para solucionar problemas, consulte problemas de latencia en RDS.

Finalidad: esta alarma se utiliza para detectar un bajo porcentaje de créditos de rendimiento que quedan en el bucket de ráfaga. Un porcentaje de balance de bytes bajo puede provocar problemas de cuello de botella en el rendimiento. Esta alarma no se recomienda para las instancias de Aurora PostgreSQL.

Estadística: Average

Umbral recomendado: 10,0

Justificación del umbral: un saldo de créditos de rendimiento inferior al 10 % se considera deficiente y se debe establecer el umbral en consecuencia. También puede establecer un umbral inferior si la aplicación puede tolerar un rendimiento inferior para la carga de trabajo.

Período: 60

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: LESS_THAN_THRESHOLD

EBSIOBalance%

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar el bajo porcentaje de créditos de IOPS restantes. Para obtener ayuda con la solución de problemas de latencia, consulte problemas de latencia en RDS.

Finalidad: esta alarma se utiliza para detectar un bajo porcentaje de créditos de E/S que quedan en el bucket de ráfaga. Un porcentaje de saldo de IOPS bajo puede provocar problemas de cuello de botella de IOPS. Esta alarma no se recomienda para las instancias de Aurora.

Estadística: Average

Umbral recomendado: 10,0

Justificación del umbral: un saldo de créditos de IOPS inferior al 10 % se considera deficiente y puede establecer el umbral en consecuencia. También puede establecer un umbral más bajo si la aplicación puede tolerar un menor número de IOPS para la carga de trabajo.

Período: 60

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: LESS_THAN_THRESHOLD

FreeableMemory

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar la poca memoria que se puede liberar, lo que puede indicar que hay un pico en las conexiones de la base de datos o que la instancia está sometida a una gran presión de memoria. Compruebe la presión de memoria supervisando las métricas de CloudWatch para SwapUsage además de FreeableMemory. Si el consumo de memoria de instancia es con frecuencia demasiado alto, significa que debe verificar la carga de trabajo o actualizar la clase de instancia. Para una instancia de base de datos de lectura de Aurora, considere añadir instancias de base de datos de lectura al clúster. Para obtener información acerca de cómo solucionar problemas de Aurora, consulte problemas de memoria que se puede liberar.

Finalidad: esta alarma se utiliza para evitar que se agote la memoria, lo que puede provocar el rechazo de las conexiones.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: según la carga de trabajo y la clase de instancia, pueden ser adecuados diferentes valores para el umbral. Lo ideal es que la memoria disponible no sea inferior al 25 % de la memoria total durante períodos prolongados. Para Aurora puede establecer un umbral cercano al 5 %, ya que la métrica que se aproxima a un valor de 0 significa que la instancia de base de datos ha escalado verticalmente todo lo que puede. Puede analizar el comportamiento histórico de esta métrica para determinar los niveles de umbral razonables.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: LESS_THAN_THRESHOLD

FreeLocalStorage

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar el bajo nivel de almacenamiento local libre. La edición Aurora compatible con PostgreSQL utiliza el almacenamiento local para almacenar los registros de errores y los archivos temporales. Aurora MySQL utiliza el almacenamiento local para almacenar registros de errores, registros generales, registros de consultas lentas, registros de auditoría y tablas temporales que no son de InnoDB. Estos volúmenes de almacenamiento local están respaldados por Amazon EBS Store y pueden ampliarse utilizando una clase de instancia de base de datos mayor. Para solucionar problemas, compruebe Aurora compatible con PostgreSQL y compatible con MySQL.

Finalidad: esta alarma se utiliza para detectar qué tan cerca está la instancia de base de datos Aurora de alcanzar el límite de almacenamiento local si no se utiliza Aurora sin servidor v2 o una versión superior. El almacenamiento local puede alcanzar su capacidad máxima si se almacenan datos no persistentes, como archivos de registro y tablas temporales, en el almacenamiento local. Esta alarma puede evitar un error de falta de espacio que se produce cuando la instancia de base de datos se queda sin almacenamiento local.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: debe calcular entre el 10 y el 20 % de la cantidad de almacenamiento disponible en función de la velocidad y la tendencia del volumen de uso y, a continuación, utilizar ese resultado como valor límite para tomar medidas proactivas antes de que el volumen alcance su límite.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: LESS_THAN_THRESHOLD

FreeStorageSpace

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma comprueba si hay poco espacio de almacenamiento disponible. Considere la posibilidad de ampliar el almacenamiento de la base de datos si se acerca con frecuencia a los límites de capacidad de almacenamiento. Incluya búfer para asumir incrementos imprevistos de la demanda de las aplicaciones. Como alternativa, considere habilitar el escalado automático del almacenamiento de RDS. Además, considere la posibilidad de liberar más espacio eliminando los datos y registros no utilizados u obsoletos. Para obtener más información, consulte el documento sobre el agotamiento de almacenamiento de RDS y el documento sobre problemas de almacenamiento de PostgreSQL.

Finalidad: esta alarma ayuda a evitar problemas de almacenamiento lleno. Esto puede evitar el tiempo de inactividad que ocurre cuando la instancia de la base de datos se queda sin almacenamiento. No recomendamos usar esta alarma si tiene activado el escalado automático de almacenamiento o si cambia con frecuencia la capacidad de almacenamiento de la instancia de base de datos.

Estadística: Minimum

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral dependerá del espacio de almacenamiento actualmente asignado. Por lo general, debe calcular el valor del 10 por ciento del espacio de almacenamiento asignado y utilizar ese resultado como valor del umbral.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: LESS_THAN_THRESHOLD

MaximumUsedTransactionIDs

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a evitar que los ID de transacción se distorsionen en PostgreSQL. Consulte los pasos de solución de problemas de este blog para investigar y resolver el problema. También puede consultar este blog para familiarizarse aún más con los conceptos de aspiración automática, los problemas más comunes y las prácticas recomendadas.

Finalidad: esta alarma se utiliza para evitar que los ID de transacción se distorsionen en PostgreSQL.

Estadística: Average

Umbral recomendado: 1,0E9

Justificación del umbral: si se establece este umbral en mil millones, tendrá tiempo para investigar el problema. El valor predeterminado de autovacuum_freeze_max_age es de 200 millones. Si la edad de la transacción más antigua es de mil millones, la aspiración automática tendrá problemas para mantener este umbral por debajo del objetivo de 200 millones de ID de transacción.

Período: 60

Puntos de datos para la alarma: 1

Períodos de evaluación: 1

Operador de comparación: GREATER_THAN_THRESHOLD

ReadLatency

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar la alta latencia de lectura. Si la latencia de almacenamiento es alta, se debe a que la carga de trabajo supera los límites de los recursos. Puede revisar el uso de E/S en relación con la configuración de la instancia y del almacenamiento asignado. Consulte la sección de solución de problemas de latencia de los volúmenes de Amazon EBS causada por un cuello de botella de IOPS. Para Aurora, puede cambiar a una clase de instancia que tenga una configuración de almacenamiento optimizado para E/S. Consulte Planificación de E/S en Aurora para obtener orientación.

Finalidad: esta alarma se utiliza para detectar una latencia de lectura alta. Los discos de las bases de datos suelen tener una latencia de lectura/escritura baja, pero pueden tener problemas que provoquen operaciones de alta latencia.

Estadística: p90

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida del caso de uso. Es probable que las latencias de lectura superiores a 20 milisegundos sean motivo de investigación. También puede establecer un umbral más alto si la aplicación puede tener una latencia mayor para las operaciones de lectura. Revise la criticidad y los requisitos de latencia de lectura y analice el comportamiento histórico de esta métrica para determinar los niveles de umbral razonables.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

ReplicaLag

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a comprender la cantidad de segundos que una réplica está atrasada respecto de la instancia principal. Una réplica de lectura de PostgreSQL registra un retraso de replicación de hasta cinco minutos si no se están produciendo transacciones de usuario en la instancia de base de datos de origen. Cuando la métrica ReplicaLag llegue a 0, la réplica estará funcionando al mismo ritmo que la instancia de base de datos principal. Si la métrica ReplicaLag devuelve -1, la replicación actualmente no está activa. Para obtener orientación relacionada con PostgreSQL en RDS, consulte las prácticas recomendadas de replicación y, para solucionar problemas de ReplicaLag y errores relacionados, consulte solución de problemas de ReplicaLag.

Finalidad: esta alarma puede detectar el retraso en la réplica, lo que refleja la pérdida de datos que podría producirse en caso de que hubiera un error en la instancia principal. Si la réplica se queda muy por detrás de la instancia principal y esta falla, la réplica no tendrá datos que estaban en la instancia principal.

Estadística: Maximum

Umbral recomendado: 60,0

Justificación del umbral: normalmente, el retraso aceptable depende de la aplicación. Se recomienda no más de 60 segundos.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: GREATER_THAN_THRESHOLD

WriteLatency

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar la alta latencia de escritura. Si la latencia de almacenamiento es alta, se debe a que la carga de trabajo supera los límites de los recursos. Puede revisar el uso de E/S en relación con la configuración de la instancia y del almacenamiento asignado. Consulte la sección de solución de problemas de latencia de los volúmenes de Amazon EBS causada por un cuello de botella de IOPS. Para Aurora, puede cambiar a una clase de instancia que tenga una configuración de almacenamiento optimizado para E/S. Consulte Planificación de E/S en Aurora para obtener orientación.

Finalidad: esta alarma se utiliza para detectar una latencia de lectura alta. Si bien los discos de las bases de datos suelen tener una latencia de lectura/escritura baja, pueden experimentar problemas que provoquen operaciones de alta latencia. Supervisar esto garantizará que la latencia del disco sea tan baja como se esperaba.

Estadística: p90

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida del caso de uso. Es probable que las latencias de escritura superiores a 20 milisegundos sean motivo de investigación. También puede establecer un umbral más alto si la aplicación puede tener una latencia mayor para las operaciones de escritura. Revise la criticidad y los requisitos de latencia de escritura y analice el comportamiento histórico de esta métrica para determinar los niveles de umbral razonables.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

DBLoad

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar una carga de base de datos alta. Si el número de procesos supera el número de vCPU, los procesos comienzan a ponerse en cola. Cuando aumentan las colas, el rendimiento se ve afectado. Si la carga de base de datos suele estar por encima del máximo de la CPU virtual y el estado de espera principal es CPU, la CPU del sistema está sobrecargada. En este caso, puede supervisar CPUUtilization, DBLoadCPU y tareas en la cola en Información del rendimiento/Supervisión mejorada. Quizá desee limitar las conexiones con la instancia, ajustar las consultas SQL con una carga de CPU alta o pensar en la posibilidad de usar una clase de instancia de mayor tamaño. Si hay instancias altas y uniformes en cualquier estado de espera, eso indica que es posible que haya problemas de contención de recursos o cuellos de botella que hay que resolver.

Finalidad: esta alarma se utiliza para detectar una carga elevada de base de datos. Una carga elevada de la base de datos puede provocar problemas de rendimiento en la instancia de base de datos. Esta alarma no se aplica a las instancias de base de datos sin servidor.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: El valor máximo de la CPU virtual se determina por el número de núcleos de vCPU (CPU virtual) de la instancia de base de datos. En función de la vCPU máxima, pueden ser adecuados diferentes valores para el umbral. Lo ideal es que la carga de la base de datos no supere la línea de vCPU.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

AuroraVolumeBytesLeftTotal

Dimensiones: DBClusterIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar el bajo volumen total restante. Cuando el volumen total restante alcanza el límite de tamaño, el clúster informa un error de falta de espacio. El almacenamiento Aurora escala automáticamente con los datos del volumen del clúster y se expande hasta 128 TiB o 64 TiB, según la versión del motor de base de datos. Considere la posibilidad de reducir almacenamiento eliminando las tablas y bases de datos que ya no necesite. Para obtener más información, consulte escalado del almacenamiento.

Finalidad: esta alarma se utiliza para detectar qué tan cerca está el clúster de Aurora del límite de tamaño del volumen. Esta alarma puede evitar un error de falta de espacio que se produce cuando el clúster se queda sin espacio. Esta alarma se recomienda solo para Aurora MySQL.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: debe calcular entre el 10 y el 20 % del límite de tamaño real en función de la velocidad y la tendencia del aumento del volumen de uso y, a continuación, utilizar ese resultado como valor del umbral para tomar medidas proactivas antes de que el volumen alcance su límite.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: LESS_THAN_THRESHOLD

AuroraBinlogReplicaLag

Dimensiones: DBClusterIdentifier, Rol=ESCRITURA

Descripción de la alarma: esta alarma ayuda a supervisar el estado de error de la replicación de la instancia de escritura de Aurora. Para obtener más información, consulte la reproducción de clústeres de base de datos de Aurora MySQL entre distintas regiones de AWS. Para solucionar problemas, consulte Problemas de replicación de Aurora MySQL.

Finalidad: esta alarma se utiliza para detectar si la instancia de escritura se encuentra en un estado de error y no puede replicar el origen. Esta alarma se recomienda solo para Aurora MySQL.

Estadística: Average

Umbral recomendado: -1,0

Justificación del umbral: se recomienda utilizar -1 como valor del umbral, ya que Aurora MySQL publica este valor si la réplica presenta un estado de error.

Período: 60

Puntos de datos para la alarma: 2

Períodos de evaluación: 2

Operador de comparación: LESS_THAN_OR_EQUAL_TO_THRESHOLD

BlockedTransactions

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar un número elevado de transacciones bloqueadas en una instancia de base de datos Aurora. Las transacciones bloqueadas pueden terminar en una reversión o en una confirmación. La alta simultaneidad, las transacciones inactivas o las transacciones de larga duración pueden provocar el bloqueo de las transacciones. Para solucionar problemas, consulte la documentación de Aurora MySQL.

Finalidad: esta alarma se utiliza para detectar un número elevado de transacciones bloqueadas en una instancia de base de datos de Aurora a fin de evitar la reversión de las transacciones y el deterioro del rendimiento.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: debe calcular el 5 % de todas las transacciones de la instancia utilizando la métrica ActiveTransactions y utilizar ese resultado como valor del umbral. También puede revisar la criticidad y los requisitos de las transacciones bloqueadas y analizar el comportamiento histórico de esta métrica para determinar los niveles de umbral razonables.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

BufferCacheHitRatio

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar una tasa de aciertos de caché baja y constante del clúster Aurora. Si la tasa de aciertos es baja, eso indica que las consultas de esta instancia de base de datos van al disco con frecuencia. Para solucionar problemas, investigue la carga de trabajo para ver qué consultas están causando este comportamiento y consulte el documento recomendaciones sobre RAM de instancias de base de datos.

Finalidad: esta alarma se utiliza para detectar una tasa de aciertos de caché baja y constante a fin de evitar una disminución sostenida del rendimiento en la instancia de Aurora.

Estadística: Average

Umbral recomendado: 80,0

Justificación del umbral: puede establecer el umbral para la tasa de aciertos de la caché del búfer en un 80 %. Sin embargo, puede ajustar este valor en función del nivel de rendimiento y las características de la carga de trabajo aceptables.

Período: 60

Puntos de datos para la alarma: 10

Períodos de evaluación: 10

Operador de comparación: LESS_THAN_THRESHOLD

EngineUptime

Dimensiones: DBClusterIdentifier, Rol=ESCRITURA

Descripción de la alarma: esta alarma ayuda a supervisar el bajo tiempo de inactividad de la instancia de base de datos de escritura. La instancia de base de datos de escritura puede dejar de funcionar debido a un reinicio, mantenimiento, actualización o conmutación por error. Cuando el tiempo de actividad alcanza 0 debido a una conmutación por error en el clúster y el clúster tiene una o más réplicas de Aurora, entonces la réplica asciende a la instancia de escritura primaria durante un evento de error. Para aumentar la disponibilidad del clúster de base de datos, considere crear al menos una o varias réplicas de Aurora en dos o más zonas de disponibilidad diferentes. Para obtener más información, consulte factores que influyen en el tiempo de inactividad de Aurora.

Finalidad: esta alarma se utiliza para detectar si la instancia de base de datos de escritura de Aurora está inactiva. Esto puede evitar un fallo prolongado en la instancia de escritura que se produzca debido a un bloqueo o una conmutación por error.

Estadística: Average

Umbral recomendado: 0,0

Justificación del umbral: un evento de error provoca una interrupción breve durante la cual las operaciones de lectura y escritura generan errores con una excepción. Sin embargo, el servicio se suele restaurar en menos de 60 segundos y, en muchos casos, en menos de 30 segundos.

Período: 60

Puntos de datos para la alarma: 2

Períodos de evaluación: 2

Operador de comparación: LESS_THAN_OR_EQUAL_TO_THRESHOLD

RollbackSegmentHistoryListLength

Dimensiones: DBInstanceIdentifier

Descripción de la alarma: esta alarma ayuda a supervisar una longitud constante del historial de segmentos de reversión alta de una instancia de Aurora. Una gran longitud de la lista del historial de InnoDB indica que hay un gran número de versiones de filas antiguas, y las consultas y los cierres de bases de datos se han ralentizado. Para obtener más información y solucionar problemas, consulte la documentación sobre el aumento significativo de la longitud de la lista del historial de InnoDB.

Finalidad: esta alarma se utiliza para detectar una longitud constante del historial de segmentos de reversión elevada. Esto puede ayudarle a evitar un deterioro sostenido del rendimiento y un uso elevado de la CPU en la instancia de Aurora. Esta alarma solo está disponible para Amazon MySQL.

Estadística: Average

Umbral recomendado: 1000000,0

Justificación del umbral: si establece este umbral en 1 millón, tendrá tiempo para investigar el problema. Sin embargo, puede ajustar este valor en función del nivel de rendimiento y las características de la carga de trabajo aceptables.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

StorageNetworkThroughput

Dimensiones: DBClusterIdentifier, Rol=ESCRITURA

Descripción de la alarma: esta alarma ayuda a supervisar el alto rendimiento de la red de almacenamiento. Si el rendimiento de la red de almacenamiento supera el ancho de banda total de la red de la instancia EC2, se puede producir una latencia de lectura y escritura elevada, lo que puede reducir el rendimiento. Puede comprobar el tipo de instancia EC2 desde la consola de AWS. Para solucionar problemas, compruebe cualquier cambio en las latencias de escritura/lectura y evalúe si también ha activado una alarma en esta métrica. Si ese es el caso, evalúe el patrón de la carga de trabajo durante las horas en que se activó la alarma. Esto puede ayudar a identificar si puede optimizar la carga de trabajo para reducir la cantidad total de tráfico de red. Si esto no es posible, puede que tenga que considerar la posibilidad de escalar la instancia.

Finalidad: esta alarma se utiliza para detectar un alto rendimiento de la red de almacenamiento. La detección de un alto rendimiento puede evitar la caída de paquetes de red y el deterioro del rendimiento.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: debe calcular entre el 80 y el 90 % del ancho de banda total de la red del tipo de instancia EC2 y, a continuación, utilizar ese resultado como valor del umbral para tomar medidas de forma proactiva antes de que los paquetes de red se vean afectados. También puede revisar la criticidad y los requisitos del rendimiento de la red de almacenamiento y analizar el comportamiento histórico de esta métrica para determinar los niveles de umbral razonables.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon Route 53 Public Data Plane

HealthCheckStatus

Dimensiones: HealthCheckId

Descripción de la alarma: esta alarma ayuda a detectar puntos de conexión en mal estado según los comprobadores de estado. Para entender el motivo de un fallo que provoca el mal estado, utilice la pestaña Comprobadores de estado de la consola de Comprobación de estado de Route 53 para ver el estado de cada región, así como el último error de la comprobación de estado. La pestaña de estado también muestra el motivo por el que se informa que el punto de conexión está en mal estado. Consulte los pasos para la solución de problemas.

Finalidad: esta alarma utiliza los comprobadores de estado de Route 53 para detectar puntos de conexión en mal estado.

Estadística: Average

Umbral recomendado: 1,0

Justificación del umbral: el estado del punto de conexión se informa como 1 cuando está en buen estado. Cualquier valor menor a 1 se considera en mal estado.

Período: 60

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: LESS_THAN_THRESHOLD

Amazon S3

4XXErrors

Dimensiones: BucketName, FilterId

Descripción de la alarma: esta alarma nos ayuda a informar del número total de códigos de estado de error 4XX que se crean en respuesta a las solicitudes de los clientes. Por ejemplo, los códigos de error 403 pueden indicar una política de IAM incorrecta y los códigos de error 404 pueden indicar un mal comportamiento de la aplicación cliente. La habilitación del registro de acceso al servidor S3 de forma temporal, podría ayudarlo a identificar el origen del problema mediante los campos de estado HTTP y de código de error. Para obtener más información sobre el código de error, consulte Error Responses.

Finalidad: esta alarma se utiliza para crear una referencia para las tasas típicas de errores 4XX, de forma que pueda detectar cualquier anomalía que pudiera indicar un problema de configuración.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: el umbral recomendado es detectar si más del 5 % del total de las solicitudes reciben errores 4XX. Los errores 4XX que se producen con frecuencia deberían disparar las alarmas. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede resultar demasiado sensible. También puede ajustar el umbral para adaptarlo a la carga de las solicitudes, teniendo en cuenta un nivel aceptable de errores 4XX. También puede analizar los datos históricos para encontrar la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

5xxErrors

Dimensiones: BucketName, FilterId

Descripción de la alarma: esta alarma ayuda a detectar una gran cantidad de errores por parte del servidor. Estos errores indican que un cliente realizó una solicitud que el servidor no pudo completar. Esto puede ayudarlo a correlacionar el problema al que se enfrenta su aplicación debido a S3. Para obtener más información que lo ayude a gestionar o reducir los errores de manera eficiente, consulte Optimización de los patrones de diseño de rendimiento. Los errores también pueden deberse a un problema con S3. Compruebe el panel de estado del servicio de AWS para conocer el estado de Amazon S3 en su región.

Finalidad: esta alarma puede ayudar a detectar si la aplicación tiene problemas debido a errores 5XX.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: se recomienda establecer el umbral para detectar si más del 5 % del total de las solicitudes reciben errores 5XX. Sin embargo, puede ajustar el umbral para adaptarlo al tráfico de las solicitudes y a las tasas de error aceptables. También puede analizar los datos históricos para ver cuál es la tasa de error aceptable para la carga de trabajo de la aplicación y ajustar el umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

OperationsFailedReplication

Dimensiones: SourceBucket, DestinationBucket, RuleId

Descripción de la alarma: esta alarma ayuda a comprender un error de replicación. Esta métrica rastrea el estado de los nuevos objetos replicados mediante CRR de S3 o SRR de S3, y también rastrea los objetos existentes replicados mediante la replicación por lotes de S3. Consulte Solución de problemas de replicación para obtener más información.

Finalidad: esta alarma se utiliza para detectar si falló una operación de replicación.

Estadística: Maximum

Umbral recomendado: 0,0

Justificación del umbral: esta métrica emite un valor de 0 si las operaciones se realizan de forma correcta y no emite ningún valor si no se realizaron operaciones de replicación para el minuto. Cuando la métrica emite un valor superior a 0, significa que la operación de replicación no se realizó de forma correcta.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

S3ObjectLambda

4xxErrors

Dimensiones: AccessPointName, DataSourceARN

Descripción de la alarma: esta alarma nos ayuda a informar del número total de códigos de estado de errores 4XX que se crean en respuesta a las solicitudes de los clientes. La habilitación del registro de acceso al servidor S3 de forma temporal, podría ayudarlo a identificar el origen del problema mediante los campos de estado HTTP y de código de error.

Finalidad: esta alarma se utiliza para crear una referencia para las tasas típicas de errores 4XX, de forma que pueda detectar cualquier anomalía que pudiera indicar un problema de configuración.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: se recomienda establecer el umbral para detectar si más del 5 % del total de las solicitudes reciben errores 4XX. Los errores 4XX que se producen con frecuencia deberían disparar las alarmas. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede resultar demasiado sensible. También puede ajustar el umbral para adaptarlo a la carga de las solicitudes, teniendo en cuenta un nivel aceptable de errores 4XX. También puede analizar los datos históricos para encontrar la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

5xxErrors

Dimensiones: AccessPointName, DataSourceARN

Descripción de la alarma :esta alarma ayuda a detectar un gran número de errores del lado del servidor. Estos errores indican que un cliente realizó una solicitud que el servidor no pudo completar. Estos errores pueden deberse a un problema con S3. Compruebe el panel de estado del servicio de AWS para conocer el estado de Amazon S3 en su región. Esto puede ayudarlo a correlacionar el problema al que se enfrenta su aplicación debido a S3. Para obtener información que lo ayude a gestionar o reducir estos errores de forma eficiente, consulte Optimización de los patrones de diseño de rendimiento.

Finalidad: esta alarma puede ayudar a detectar si la aplicación tiene problemas debido a errores 5XX.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral:recomendamos establecer el umbral para detectar si más del 5 % del total de las solicitudes reciben errores 5XX. Sin embargo, puede ajustar el umbral para adaptarlo al tráfico de las solicitudes y a las tasas de error aceptables. También puede analizar los datos históricos para ver cuál es la tasa de error aceptable para la carga de trabajo de la aplicación y ajustar el umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

LambdaResponse4xx

Dimensiones: AccessPointName, DataSourceARN

Descripción de la alarma: esta alarma ayuda a detectar y diagnosticar errores (del tipo 500) en las llamadas a S3 Object Lambda. Estos errores pueden deberse a errores o problemas en la configuración en la función de Lambda encargada de responder a sus solicitudes. Investigar los flujos de registro de CloudWatch de la función de Lambda asociada al punto de acceso de Object Lambda puede ayudarle a determinar el origen del problema en función de la respuesta de S3 Object Lambda.

Finalidad: esta alarma se utiliza para detectar errores 4XX del cliente en las llamadas a WriteGetObjectResponse.

Estadística: Average

Umbral recomendado: 0,05

Justificación del umbral: se recomienda establecer el umbral para detectar si más del 5 % del total de las solicitudes reciben errores 4XX. Los errores 4XX que se producen con frecuencia deberían disparar las alarmas. Sin embargo, si se establece un valor muy bajo para el umbral, la alarma puede resultar demasiado sensible. También puede ajustar el umbral para adaptarlo a la carga de las solicitudes, teniendo en cuenta un nivel aceptable de errores 4XX. También puede analizar los datos históricos para encontrar la tasa de error aceptable para la carga de trabajo de la aplicación y, a continuación, ajustar el umbral en consecuencia.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon SNS

NumberOfMessagesPublished

Dimensiones: TopicName

Descripción de la alarma: esta alarma puede detectar cuando el número de mensajes SNS publicados es demasiado bajo. Para solucionar problemas, compruebe por qué los publicadores envían menos tráfico.

Finalidad: esta alarma ayuda a supervisar y detectar de forma proactiva descensos significativos en la publicación de notificaciones. Esto le ayuda a identificar posibles problemas con su aplicación o sus procesos empresariales, de modo que pueda tomar las medidas adecuadas para mantener el flujo de notificaciones esperado. Debe crear esta alarma si espera que su sistema tenga un tráfico mínimo que atender.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: el número de mensajes publicados debe coincidir con el número esperado de mensajes publicados para su aplicación. También puede analizar los datos históricos, las tendencias y el tráfico para encontrar el umbral correcto.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: LESS_THAN_THRESHOLD

NumberOfNotificationsDelivered

Dimensiones: TopicName

Descripción de la alarma: esta alarma puede detectar cuando el número de mensajes SNS entregados es demasiado bajo. Esto puede deberse a la cancelación accidental de la suscripción de un punto de conexión o a un evento de SNS que provoque un retraso en los mensajes.

Finalidad: esta alarma ayuda a detectar una caída en el volumen de mensajes enviados. Debe crear esta alarma si espera que su sistema tenga un tráfico mínimo que atender.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: el número de mensajes entregados debe coincidir con el número esperado de mensajes producidos y el número de consumidores. También puede analizar los datos históricos, las tendencias y el tráfico para encontrar el umbral correcto.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: LESS_THAN_THRESHOLD

NumberOfNotificationsFailed

Dimensiones: TopicName

Descripción de la alarma: esta alarma puede detectar cuando el número de mensajes SNS fallidos es demasiado alto. Para solucionar problemas con las notificaciones fallidas, habilite el registro en los Registros de CloudWatch. Revisar los registros puede ayudarle a determinar qué suscriptores fallan, así como los códigos de estado que devuelven.

Finalidad: esta alarma ayuda a detectar de forma proactiva los problemas relacionados con la entrega de las notificaciones y a tomar las medidas adecuadas para solucionarlos.

Estadística: Sum

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida del impacto de las notificaciones fallidas. Revise los acuerdos de nivel de servicio (SLA) proporcionados a sus usuarios finales, la tolerancia a los errores, la importancia de las notificaciones y analice los datos históricos y, a continuación, seleccione el umbral correspondiente. El número de notificaciones fallidas debe ser 0 para los temas que solo tienen suscripciones a SQS, Lambda o Firehose.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidAttributes

Dimensiones: TopicName

Descripción de la alarma: esta alarma ayuda a supervisar y resolver posibles problemas con el publicador o los suscriptores. Compruebe si un publicador publica mensajes con atributos no válidos o si se aplica un filtro inadecuado a un suscriptor. También puede analizar los Registros de CloudWatch para ayudar a encontrar la causa raíz del problema.

Finalidad: la alarma se utiliza para detectar si los mensajes publicados no son válidos o si se han aplicado filtros inadecuados a un suscriptor.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: los atributos no válidos casi siempre son un error del publicador. Se recomienda establecer el umbral en 0, ya que en un sistema en buen estado no deberían esperarse atributos no válidos.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidMessageBody

Dimensiones: TopicName

Descripción de la alarma: esta alarma ayuda a supervisar y resolver posibles problemas con el publicador o los suscriptores. Compruebe si un editor publica mensajes con cuerpos de mensaje no válidos o si se aplica un filtro inadecuado a un suscriptor. También puede analizar los Registros de CloudWatch para ayudar a encontrar la causa raíz del problema.

Finalidad: la alarma se utiliza para detectar si los mensajes publicados no son válidos o si se han aplicado filtros inadecuados a un suscriptor.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: los cuerpos de los mensajes no válidos casi siempre son un error del publicador. Recomendamos establecer el umbral en 0, ya que los cuerpos de los mensajes deberían ser válidos en un sistema en buen estado.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

NumberOfNotificationsRedrivenToDlq

Dimensiones: TopicName

Descripción de la alarma: esta alarma ayuda a supervisar la cantidad de mensajes que se mueven a una cola de mensajes fallidos.

Finalidad: la alarma se utiliza para detectar mensajes que pasaron a una cola de mensajes fallidos. Recomendamos que cree esta alarma cuando SNS esté acoplado a SQS, Lambda o Firehose.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: en un sistema en buen estado de cualquier tipo de suscriptor, los mensajes no deben moverse a la cola de mensajes fallidos. Recomendamos que reciba una notificación en caso de que algún mensaje llegue a la cola, de modo que pueda identificar y abordar la causa raíz y, si es posible, redireccionar los mensajes en la cola de mensajes fallidos para evitar la pérdida de datos.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

NumberOfNotificationsFailedToRedriveToDlq

Dimensiones: TopicName

Descripción de la alarma: esta alarma ayuda a supervisar los mensajes que no se pudieron mover a una cola de mensajes fallidos. Compruebe si existe una cola de mensajes fallidos y si está configurada como corresponde. Compruebe también que SNS tenga los permisos para acceder a la cola de mensajes fallidos. Consulte la documentación sobre cola de mensajes fallidos para obtener más información.

Finalidad: la alarma se utiliza para detectar los mensajes que no se pudieron mover a una cola de mensajes fallidos.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: casi siempre se trata de un error si los mensajes no se pueden mover a la cola de mensajes fallidos. El umbral recomendado es 0, lo que significa que todos los mensajes que no se procesen de forma correcta deben ser capaces de llegar a la cola de mensajes fallidos, una vez configurada.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

SMSMonthToDateSpentUSD

Dimensiones: TopicName

Descripción de la alarma: la alarma ayuda a controlar si tiene una cuota suficiente en su cuenta para que SNS pueda entregar los mensajes. Si alcanza su cuota, SNS no podrá entregar los mensajes SMS. Para obtener más información acerca de la configuración de su cuota de gasto mensual de SMS o acerca de cómo solicitar un aumento de la cuota de gasto con AWS, consulte Configuración de las preferencias de mensajería SMS.

Finalidad: esta alarma se utiliza para detectar si tiene una cuota suficiente en su cuenta para que los mensajes SMS se entreguen de forma correcta.

Estadística: Maximum

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral de acuerdo con la cuota (límite de gasto de la cuenta) para la cuenta. Elija un umbral que informe con suficiente antelación de que está alcanzando el límite de cuota para que tenga tiempo de solicitar un aumento.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

SMSSuccessRate

Dimensiones: TopicName

Descripción de la alarma: esta alarma ayuda a supervisar la tasa de entregas fallidas de mensajes SMS. Puede configurar los Registros de CloudWatch para entender la naturaleza del error y tomar medidas en función de ello.

Finalidad: esta alarma se utiliza para detectar errores en la entrega de mensajes SMS.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: establezca el umbral de la alarma de acuerdo con su tolerancia ante la entrega fallida de mensajes SMS.

Período: 60

Puntos de datos para la alarma: 5

Períodos de evaluación: 5

Operador de comparación: GREATER_THAN_THRESHOLD

Amazon SQS

ApproximateAgeOfOldestMessage

Dimensiones: QueueName

Descripción de la alarma: esta alarma comprueba la antigüedad del mensaje más antiguo en la cola. Puede utilizar esta alarma para supervisar si sus consumidores procesan los mensajes SQS a la velocidad deseada. Considere aumentar el número o el rendimiento de los consumidores para reducir la antigüedad de los mensajes. Esta métrica se puede utilizar en combinación con ApproximateNumberOfMessagesVisible para determinar el tamaño de la cola de espera y la rapidez con la que se procesan los mensajes. Para evitar que los mensajes se eliminen antes de procesarlos, considere la posibilidad de configurar la cola de mensajes fallidos para dejar de lado los posibles mensajes de tipo píldora venenosa (mensajes que se reciben, pero no se pueden procesar).

Finalidad: esta alarma se utiliza para detectar si el mensaje más viejo en la cola de QueueName es demasiado antiguo. La antigüedad elevada puede indicar que los mensajes no se procesan con la suficiente rapidez o que hay algunos mensajes de tipo píldora venenosa que se quedan atascados en la cola y no se pueden procesar.

Estadística: Maximum

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida del tiempo esperado de procesamiento de los mensajes. Puede utilizar los datos históricos para calcular el tiempo promedio de procesamiento de los mensajes y, a continuación, establecer el umbral en un 50 % más que el tiempo máximo de procesamiento de mensajes de SQS esperado por los usuarios de la cola.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesNotVisible

Dimensiones: QueueName

Descripción de la alarma: esta alarma ayuda a detectar un gran número de mensajes en tránsito con respecto a QueueName. Para solucionar problemas, consulte ¿Cómo puedo evitar que se acumulen mensajes en mi cola de Amazon SQS?.

Finalidad: esta alarma se utiliza para detectar un número elevado de mensajes en tránsito en la cola. Si los consumidores no eliminan los mensajes dentro del período de tiempo de espera de visibilidad, cuando se sondee la cola, los mensajes volverán a aparecer en esta. En el caso de las colas FIFO, puede haber un máximo de 20 000 mensajes en tránsito. Si alcanza esta cuota, SQS no devolverá ningún mensaje de error. Una cola FIFO examina los primeros 20 000 mensajes para determinar los grupos de mensajes disponibles. Esto significa que, si tiene una acumulación de mensajes en un solo grupo de mensajes, no podrá consumir los mensajes de otros grupos de mensajes que se hayan enviado más tarde a la cola hasta que no consuman de forma correcta los mensajes acumulados.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: el valor del umbral recomendado para esta alarma depende en gran medida del número esperado de mensajes en tránsito. Puede utilizar los datos históricos para calcular el número máximo esperado de mensajes en tránsito y establecer el umbral en un 50 % por encima de este valor. Si los usuarios de la cola procesan, pero no eliminan los mensajes de la cola, este número aumentará de forma repentina.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesVisible

Dimensiones: QueueName

Descripción de la alarma: esta alarma detecta si la cola de mensajes pendientes es mayor de lo esperada, lo que indica que los consumidores son demasiado lentos o que no hay suficientes consumidores. Considere la posibilidad de aumentar el número de consumidores o acelerar el número de consumidores si esta alarma pasa a estar en estado de ALARMA.

Finalidad: esta alarma se utiliza para detectar si el número de mensajes de la cola activa es demasiado alto y si los consumidores tardan en procesar los mensajes o si no hay suficientes consumidores para procesarlos.

Estadística: Average

Umbral recomendado: depende de la situación

Justificación del umbral: un número alto e imprevisto de mensajes visibles indica que un consumidor no procesa los mensajes al ritmo esperado. Debe tener en cuenta los datos históricos al establecer este umbral.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

NumberOfMessagesSent

Dimensiones: QueueName

Descripción de la alarma: esta alarma ayuda a detectar si un productor no envía ningún mensaje con respecto a QueueName. Para solucionar problemas, compruebe el motivo por el que el productor no envía los mensajes.

Finalidad: esta alarma se utiliza para detectar cuándo un productor deja de enviar mensajes.

Estadística: Sum

Umbral recomendado: 0,0

Justificación del umbral: si el número de mensajes enviados es 0, significa el productor no envía mensajes. Si esta cola tiene un TPS bajo, aumente el número de EvaluationPeriods en consecuencia.

Período: 60

Puntos de datos para la alarma: 15

Períodos de evaluación: 15

Operador de comparación: LESS_THAN_OR_EQUAL_TO_THRESHOLD

AWS VPN

TunnelState

Dimensiones: VpnId

Descripción de la alarma: esta alarma ayuda a comprender si el estado de uno o más túneles está INACTIVO. Para solucionar problemas, consulte How do I troubleshoot VPN tunnel connectivity to an Amazon VPC?.

Finalidad: esta alarma se utiliza para detectar si al menos un túnel está como INACTIVO para esta VPN, de modo que pueda solucionar los problemas de la VPN afectada. Esta alarma siempre estará en estado de ALARMA en las redes que solo tengan un túnel configurado.

Estadística: Minimum

Umbral recomendado: 1,0

Justificación del umbral: un valor inferior a 1 indica que al menos un túnel está en estado INACTIVO.

Período: 300

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: LESS_THAN_THRESHOLD

TunnelState

Dimensiones: TunnelIpAddress

Descripción de la alarma: esta alarma ayuda a entender si el estado de este túnel está INACTIVO. Para solucionar problemas, consulte How do I troubleshoot VPN tunnel connectivity to an Amazon VPC?.

Finalidad: esta alarma se utiliza para detectar si el túnel está en estado INACTIVO, de modo que pueda solucionar los problemas de la VPN afectada. Esta alarma siempre estará en estado de ALARMA en las redes que solo tengan un túnel configurado.

Estadística: Minimum

Umbral recomendado: 1,0

Justificación del umbral: un valor inferior a 1 indica que el túnel está en estado INACTIVO.

Período: 300

Puntos de datos para la alarma: 3

Períodos de evaluación: 3

Operador de comparación: LESS_THAN_THRESHOLD