

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Defina y configure las alarmas en la sección Detección y respuesta a incidentes
<a name="idr-gs-alarms"></a>

AWS trabaja con usted para definir métricas y alarmas a fin de proporcionar visibilidad del rendimiento de sus aplicaciones y su AWS infraestructura subyacente. Solicitamos que las alarmas cumplan los siguientes criterios al definir y configurar los umbrales:
+ Las alarmas solo entran en el estado de «alarma» cuando se produce un impacto crítico en la carga de trabajo monitoreada (pérdida de ingresos o deterioro de la experiencia del cliente, lo que reduce significativamente el rendimiento) y requiere la atención inmediata del operador.
+ Las alarmas también deben activar las soluciones especificadas para la carga de trabajo al mismo tiempo o antes de contactar con el equipo de gestión de incidentes. Los ingenieros de gestión de incidentes deberían colaborar con las personas encargadas de resolver las incidencias en el proceso de mitigación, no actuar como personal de primera línea y luego acudir a usted.
+ Los umbrales de alarma se deben establecer con un umbral y una duración adecuados, de modo que cada vez que se active una alarma, se lleve a cabo una investigación. Si una alarma oscila entre los estados «Alarma» y «OK», se está produciendo un impacto suficiente como para justificar la respuesta y la atención del operador.

**Tipos de alarmas**:
+ Alarmas que muestran el nivel de impacto en el negocio y transmiten información relevante para una detección sencilla de fallas.
+ Amazon CloudWatch canarios. [Para obtener más información, consulte [Canaries and X-Ray tracing](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) y X-Ray.](https://aws.amazon.com/xray/)
+ Alarmas agregadas (monitoreo de dependencias)

En la siguiente tabla se muestran ejemplos de alarmas, todas ellas con el sistema CloudWatch de monitoreo.


****  

| Nombre de la métrica o umbral de alarma | ARN de alarma o ID de recurso | Si se activa esta alarma | Si está contratado, solicite un caso de soporte premium para estos servicios | 
| --- | --- | --- | --- | 
| Errores de API/ Número de errores >= 10 para 10 puntos de datos | arn:aws:cloudwatch:us-west- 2:000000000000:Alarma: E2 Lambda-Errores MPmim | El equipo de administradores de bases de datos (DBA) ha sido eliminado | Lambda, API Gateway | 
| ServiceUnavailable (Código de estado HTTP 503) Número de errores >=3 para 10 puntos de datos (clientes diferentes) en un período de 5 minutos | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode503 | Boleto reducido al equipo de servicio | Lambda, API Gateway | 
| ThrottlingException (Código de estado HTTP 400) Número de errores >=3 para 10 puntos de datos (clientes diferentes) en un período de 5 minutos | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode400 | Boleto eliminado para el equipo de servicio | EC2, Amazon Aurora | 

Para obtener más información, consulte [Monitorización y observabilidad de la detección y respuesta a incidentes de AWS](observe-idr.md).

Si prefiere utilizar herramientas de automatización para incorporar las alarmas, la interfaz de línea de comandos (CLI) de detección y respuesta a incidentes le ayuda a implementar e incorporar sus alarmas. Para obtener más información, consulte [CLI de detección y respuesta a incidentes de AWS](idr-cli.md).

**Resultados clave:**
+ Definición y configuración de las alarmas en sus cargas de trabajo.
+ Completar los detalles de la alarma en el cuestionario de incorporación.

**Topics**
+ [Cree CloudWatch alarmas](idr-alarms-fit-purpose.md)
+ [Cree CloudWatch alarmas con CloudFormation plantillas](idr-create-alarms-with-cfn.md)
+ [Ejemplos de casos de uso de CloudWatch alarmas](idr-ex-alarm-use-cases.md)

# Cree CloudWatch alarmas que se adapten a las necesidades de su empresa en materia de detección y respuesta a incidentes
<a name="idr-alarms-fit-purpose"></a>

Al crear CloudWatch las alarmas de Amazon, hay varios pasos que puede seguir para asegurarse de que las alarmas se adapten mejor a las necesidades de su empresa.

**nota**  
Para ver ejemplos de CloudWatch alarmas recomendadas Servicios de AWS para incorporar la detección y respuesta a incidentes, consulte las [mejores prácticas en materia de detección y respuesta a incidentes en AWS re:Post](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr).

## Revise las CloudWatch alarmas propuestas
<a name="idr-review-alarms"></a>

Revise las alarmas propuestas para asegurarse de que solo pasen al estado de «alarma» cuando la carga de trabajo monitoreada se vea afectada de manera crítica (pérdida de ingresos o deterioro de la experiencia del cliente, lo que reduce significativamente el rendimiento). Por ejemplo, ¿considera que esta alarma es lo suficientemente importante como para reaccionar inmediatamente si pasa al estado de «alarma»?

A continuación se sugieren métricas que podrían representar un impacto empresarial crítico, por ejemplo, afectar a la experiencia de los usuarios finales con una aplicación:
+ **CloudFront:** Para obtener más información, consulte las [métricas de visualización CloudFront y funciones perimetrales](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html).
+ **Equilibradores de carga de aplicaciones:** se recomienda crear las siguientes alarmas para los balanceadores de carga de aplicaciones, si es posible:
  + HTTPCode\$1ELB\$15xx\$1Count
  + HTTPCode\$1TARGET\$15xx\$1Count

  Las alarmas anteriores le permiten monitorear las respuestas de los objetivos que están detrás del Application Load Balancer o detrás de otros recursos. Esto facilita la identificación del origen de los errores 5XX. Para obtener más información, consulte [CloudWatch las métricas de su Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).
+ **Amazon API Gateway:** si utiliza la WebSocket API en Elastic Beanstalk, considere la posibilidad de utilizar las siguientes métricas:
  + Tasas de error de integración (filtradas a 5XX errores)
  + Latencia de integración
  + Errores de ejecución

  Para obtener más información, consulta [Supervisar la ejecución de la WebSocket API con CloudWatch métricas](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html).
+ **Amazon Route 53:** monitorea la **EndPointUnhealthyENICount**métrica. Esta métrica es el número de interfaces de red elásticas en estado de **recuperación automática**. Este estado indica los intentos del solucionador de recuperar una o más de las interfaces de red de Amazon Virtual Private Cloud asociadas al punto final (especificadas por **EndpointId**). En el proceso de recuperación, el punto final funciona con una capacidad limitada. El punto final no puede procesar las consultas de DNS hasta que se haya recuperado por completo. Para obtener más información, consulte [Supervisión de los puntos finales de Amazon Route 53 Resolver con Amazon CloudWatch](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html).

## Valide las configuraciones de sus alarmas
<a name="idr-validate-alarm-config"></a>

Tras confirmar que las alarmas propuestas se ajustan a las necesidades de su empresa, valide la configuración y el historial de las alarmas:
+ Valide el **umbral** para que la métrica entre en estado de «alarma» en función de la tendencia gráfica de la métrica.
+ Valide el **período** utilizado para sondear los puntos de datos. Los puntos de datos de sondeo a los 60 segundos ayudan a detectar los incidentes de forma temprana.
+ Valide la **DatapointToAlarm**configuración. En la mayoría de los casos, se recomienda establecer este valor en 3 de 3 o 5 de 5. En caso de incidente, la alarma se activa después de 3 minutos si se establece en [métricas de 60 segundos con 3 de 3 DatapointToAlarm] o 5 minutos cuando se establece en [métricas de 60 segundos con 5 de 5 DatapointToAlarm]. Utilice esta combinación para eliminar las alarmas ruidosas.

**nota**  
Las recomendaciones anteriores pueden variar en función del uso que se haga del servicio. Cada AWS servicio funciona de forma diferente dentro de una carga de trabajo. Además, el mismo servicio puede funcionar de manera diferente cuando se usa en varios lugares. Debe asegurarse de entender cómo su carga de trabajo utiliza los recursos que alimentan la alarma, así como los efectos ascendentes y descendentes.

## Valide la forma en que sus alarmas gestionan los datos faltantes
<a name="idr-validate-missing-data"></a>

Algunas fuentes de métricas no envían datos a CloudWatch intervalos regulares. En el caso de estas métricas, se recomienda tratar los datos faltantes como datos que **no se filtran.** Para obtener más información, consulte [Configurar el modo en que CloudWatch las alarmas tratan los datos faltantes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) y [Evitar transiciones prematuras al estado de alarma](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition).

Por ejemplo, si una métrica monitorea una tasa de errores y no hay errores, la métrica no muestra puntos de datos (nulos). Si configura la alarma para tratar los datos faltantes como **ausentes**, un solo punto de datos que infringe la seguridad seguido de dos puntos de datos sin datos (nulos) hace que la métrica pase al estado de «Alarma» (para 3 de cada 3 puntos de datos). Esto se debe a que la configuración de datos faltantes evalúa el último punto de datos conocido en el período de evaluación.

En los casos en que las métricas supervisan una tasa de error, si no se produce una degradación del servicio, se puede suponer que la ausencia de datos es algo positivo. Se recomienda tratar los datos faltantes como datos que **no se infringen**, de modo que los datos faltantes se traten como «correctos» y la métrica no entre en estado de «alarma» en un solo punto de datos.

## Revisa el historial de cada alarma
<a name="idr-review-alarm-history"></a>

Si el historial de una alarma muestra que pasa con frecuencia al estado de «Alarma» y, después, se recupera rápidamente, es posible que la alarma se convierta en un problema para usted. Asegúrese de ajustar la alarma para evitar ruidos o falsas alarmas.

## Valide las métricas de los recursos subyacentes
<a name="idr-validate-underlying-resources"></a>

Asegúrese de que sus métricas tengan en cuenta los recursos subyacentes válidos y utilicen las estadísticas correctas. Si se configura una alarma para revisar los nombres de recursos no válidos, es posible que la alarma no pueda rastrear los datos subyacentes. Esto podría provocar que la alarma entre en el estado de «Alarma».

## Cree alarmas compuestas
<a name="idr-create-composite-alarms"></a>

Si proporciona a las operaciones de detección y respuesta a incidentes un gran número de alarmas para incorporarlas, es posible que se le pida que cree alarmas compuestas. Las alarmas compuestas reducen la cantidad total de alarmas que deben incorporarse.

# Cree CloudWatch alarmas en Incident Detection and Response con plantillas CloudFormation
<a name="idr-create-alarms-with-cfn"></a>

Para acelerar la incorporación a AWS Incident Detection and Response y reducir el esfuerzo necesario para crear alarmas, le AWS proporciona CloudFormation plantillas. Estas plantillas incluyen una configuración de alarma optimizada para los servicios comúnmente integrados, como Application Load Balancer, Network Load Balancer y Amazon. CloudFront

**Cree alarmas con plantillas CloudWatch CloudFormation**

1. Descargue una plantilla mediante los enlaces proporcionados:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IDR/latest/userguide/idr-create-alarms-with-cfn.html)

1. Revise el archivo JSON descargado para asegurarse de que cumple con los procesos de operación y seguridad de su organización.

1. Crea una CloudFormation pila:
**nota**  
Los siguientes pasos utilizan el proceso de creación de CloudFormation pilas estándar. Para ver los pasos detallados, consulta [Crear una pila en la CloudFormation consola](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html).

   1. Abre la AWS CloudFormation consola en [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).

   1. Seleccione **Creación de pila**.

   1. Seleccione **La plantilla está lista** y, a continuación, cargue el archivo de plantilla desde su carpeta local.

      El siguiente es un ejemplo de la pantalla **Crear pila**.  
![\[Ejemplo de creación de un archivo de plantilla de carga de pilas\]](http://docs.aws.amazon.com/es_es/IDR/latest/userguide/images/create-cfn-stack1.png)

   1. Elija **Siguiente**.

   1. Introduzca la siguiente información necesaria:
      + **AlarmNameConfig**y **AlarmDescriptionConfig**: Introduce un nombre y una descripción para la alarma.
      + **ThresholdConfig**: Revise el valor límite para que cumpla con los requisitos de su solicitud.
      + **Distribución IDConfig**: asegúrate de que el identificador de distribución apunte a los recursos correctos de la cuenta en la que vas a crear la CloudFormation pila.

   1. Elija **Siguiente**.

   1. Revisa los valores predeterminados de los **DatapointsToAlarmConfig**campos **PeriodConfig**EvalutionPeriodConfig****, y. Se recomienda utilizar los valores predeterminados para estos campos. Si es necesario, puede realizar ajustes para cumplir con los requisitos de su aplicación.

   1. Si lo desea, introduzca las etiquetas y la información de notificación de SNS según sea necesario. Se recomienda activar la **protección de terminación** para evitar la eliminación accidental de la alarma. Para activar la protección de terminación, selecciona el botón de opción **Activado**, como se muestra en el siguiente ejemplo:  
![\[Cree un ejemplo de protección de terminación con activación por pila\]](http://docs.aws.amazon.com/es_es/IDR/latest/userguide/images/create-cfn-stack2.png)

   1. Elija **Siguiente**.

   1. Revisa la configuración de tu pila y, a continuación, selecciona **Crear pila**.

   1. Tras crear la pila, verás la alarma en la lista de CloudWatch **alarmas** de Amazon, como se muestra en el siguiente ejemplo:  
![\[Ejemplo de lista CloudWatch de alarmas\]](http://docs.aws.amazon.com/es_es/IDR/latest/userguide/images/create-cfn-stack3.png)

1. Una vez que haya creado todas las alarmas en la cuenta y AWS región correctas, notifíquelo a su administrador técnico de cuentas (TAM). El equipo de detección y respuesta a incidentes de AWS revisa el estado de las nuevas alarmas y continúa con la incorporación.

# Ejemplos de casos de uso de CloudWatch alarmas en Incident Detection and Response
<a name="idr-ex-alarm-use-cases"></a>

Los siguientes casos de uso proporcionan ejemplos de cómo puedes usar CloudWatch las alarmas de Amazon en Incident Detection and Response. Estos ejemplos muestran cómo se pueden configurar CloudWatch las alarmas para monitorear las métricas y los umbrales clave en varios AWS servicios, lo que le permite identificar y responder a posibles problemas que podrían afectar a la disponibilidad y el rendimiento de sus aplicaciones y cargas de trabajo.

## Ejemplo de caso de uso A: Application Load Balancer
<a name="use-case-alb"></a>

Puede crear la siguiente CloudWatch alarma que indique un posible impacto en la carga de trabajo. Para ello, debe crear una métrica matemática que emita una alarma cuando las conexiones correctas caigan por debajo de un determinado umbral. Para ver las CloudWatch métricas disponibles, consulte [CloudWatch las métricas de su Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)

**Métrica:** `HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`

**NameSpace: AWS/Aplicación** ELB

**ComparisonOperator(Umbral):** inferior a x (x = umbral del cliente).

**Periodo:** 60 segundos

**DatapointsToAlarm:** 3 de 3

**Tratamiento de datos faltantes:** trate los datos faltantes como una [violación.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)

**Estadística: **Sum

El siguiente diagrama muestra el flujo del caso de uso A:

![\[Ejemplo de caso de uso de Application Load Balancer\]](http://docs.aws.amazon.com/es_es/IDR/latest/userguide/images/UseCaseAALB.png)


## Ejemplo de caso de uso B: Amazon API Gateway
<a name="use-case-apigateway"></a>

Puede crear la siguiente CloudWatch alarma que indique el posible impacto en la carga de trabajo. Para ello, debe crear una métrica compuesta que emita una alarma cuando hay una latencia alta o un número medio alto de errores 4XX en la API Gateway. Para ver las métricas disponibles, consulte [Dimensiones y métricas de Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)

**Métrica:** `compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`

**NameSpace:** AWS/Puerta de enlace API

**ComparisonOperator(Umbral):** superior a (los umbrales de x o y del cliente)

**Período:** 60 segundos

**DatapointsToAlarm:** 1 de cada 1

**Tratamiento de datos faltantes:** trate los datos faltantes como si [no se tratara de una violación.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)

**Estadística:**

El siguiente diagrama muestra el flujo del caso de uso B:

![\[Ejemplo de caso de uso de API Gateway\]](http://docs.aws.amazon.com/es_es/IDR/latest/userguide/images/UseCaseBAPIGW.png)


## Ejemplo de caso de uso C: Amazon Route 53
<a name="use-case-apigateway"></a>

Puede supervisar sus recursos mediante la creación de comprobaciones de estado de Route 53 que se utilizan CloudWatch para recopilar y procesar datos sin procesar para convertirlos en métricas legibles y prácticamente en tiempo real. Puede crear la siguiente CloudWatch alarma que indique el posible impacto en la carga de trabajo. Puede usar las CloudWatch métricas para crear una alarma que se active cuando supere el umbral establecido. Para ver las CloudWatch métricas disponibles, consulte las [CloudWatch métricas de las comprobaciones de estado de Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics)

**Métrica:** `R53-HC-Success`

**NameSpace:** AWS/Ruta 53

**Umbral HealthCheckStatus:** HealthCheckStatus < x para 3 puntos de datos en 3 minutos (es x el umbral del cliente)

**Periodo:** 1 minuto

**DatapointsToAlarm:** 3 de 3

**Tratamiento de datos faltantes:** trate los datos faltantes como una [violación.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)

**Estadística: **Minimum

El siguiente diagrama muestra el flujo del caso de uso C:

![\[Ejemplo de caso de uso para Route 53\]](http://docs.aws.amazon.com/es_es/IDR/latest/userguide/images/UseCaseCR53.png)


## Ejemplo de caso de uso D: Supervise una carga de trabajo con una aplicación personalizada
<a name="use-case-apigateway"></a>

Es fundamental que te tomes el tiempo necesario para definir un chequeo de estado adecuado en este escenario. Si solo compruebas que el puerto de una aplicación esté abierto, significa que no has comprobado que la aplicación esté funcionando. Además, realizar una llamada a la página de inicio de una aplicación no es necesariamente la forma correcta de determinar si la aplicación funciona. Por ejemplo, si una aplicación depende tanto de una base de datos como de Amazon Simple Storage Service (Amazon S3), la comprobación de estado debe validar todos los elementos. Una forma de hacerlo es crear una página web de monitoreo, como **/monitor.** La página web de monitoreo realiza una llamada a la base de datos para asegurarse de que puede conectarse y obtener datos. Además, la página web de monitoreo hace una llamada a Amazon S3. A continuación, diriges la comprobación de estado del balanceador de cargas a la página **/monitor.**

El siguiente diagrama muestra el flujo del caso de uso D:

![\[Ejemplo de caso de uso para monitorear con una aplicación personalizada\]](http://docs.aws.amazon.com/es_es/IDR/latest/userguide/images/CustomAlarm.png)
