Mejores prácticas para las alarmas
Obtenga información sobre las mejores prácticas para alarmas.
Creación de un juego de alarmas para cada métrica
Para cada métrica emitida por recursos, cree alarmas que definan los siguientes comportamientos de recursos:
- En riesgo. Existe el riesgo de que el recurso deje de estar operativo según lo indicado por los valores de las métricas.
- No óptimo El recurso está funcionando a un nivel que no es el óptimo según lo indicado por los valores de la métrica.
- El recurso está activo o caído. El recurso no está accesible o no funciona.
Los ejemplos siguientes utilizan la métrica CpuUtilization emitida por el espacio de nombres de métrica oci_computeagent. Esta métrica controla el uso de la instancia informática y el nivel de actividad de cualquier servicio y aplicación que se ejecute en la instancia. CpuUtilization es una métrica de rendimiento clave para un servicio en la nube de cloud service porque indica el uso de CPU para la instancia informática y se puede utilizar para investigar problemas de rendimiento. Para obtener más información sobre el uso de la CPU, consulte la siguiente URL: https://en.wikipedia.org/wiki/CPU_time.
Ejemplo de En riesgo
Un umbral de riesgo típico para la métrica CpuUtilization es cualquier valor superior a un 80 %. Una instancia informática que infrinja este umbral puede estar en riesgo y dejar de estar operativa. Normalmente, este comportamiento se debe a que el porcentaje de consumo de CPU de una o varias aplicaciones es alto.
En este ejemplo, decide notificar inmediatamente al equipo en el que se ejecutan operaciones y establece la gravedad de la alarma como "Crítica", ya de que es necesario llevar a cabo un arreglo para que las instancias regresen a niveles operativos óptimos. Configura notificaciones de alarma para el equipo responsable mediante PagerDuty y correo electrónico, y solicita una investigación y las reparaciones pertinentes antes de que las instancias vuelvan a estar operativas. Configura las notificaciones para que se repitan cada minuto. Cuando alguien responde a las notificaciones de alarma, detiene temporalmente las notificaciones con la mejor práctica de supresión de la alarma . Cuando las métricas regresan a valores óptimos, elimina la supresión.
Ejemplo de NonOptimal
Un umbral no óptimo típico para la métrica CpuUtilization oscila entre un 60 % y el 80 %. Cuando los valores de la métrica de una instancia informática se encuentran dentro de este rango, la instancia se encuentra por sobre el rango operativo óptimo.
En este ejemplo, decide notificar al individuo o equipo que corresponda que una aplicación o un proceso están consumiendo más CPU de lo habitual. Configura una alarma de umbral para notificar a los contactos pertinentes, definiendo la gravedad de la alarma como "Advertencia", puesto que no se necesitan acciones inmediatas para investigar y reducir la CPU. Activa solo las notificaciones por correo electrónico para el equipo o el desarrollador, y las configura para que se repitan cada 24 horas para no causar molestias.
Ejemplo de "recurso activo o caído"
Un indicador típico de disponibilidad de recursos es una ausencia de cinco minutos de la métrica CpuUtilization. Una instancia informática que infrinja este umbral no es accesible o no funciona. Es posible que el recurso haya dejado de responder o que no esté disponible debido al problema de conectividad.
En este ejemplo, decide notificar inmediatamente al equipo del servicio de operaciones y establece la gravedad de la alarma de ausencia como "Crítica" porque es necesario llevar a cabo una reparación para poner las instancias en línea. Configura notificaciones de alarma para el equipo responsable, tanto por PagerDuty como por correo electrónico, para solicitar una investigación y el traslado de las cargas de trabajo a otro recurso disponible. Configura las notificaciones para que se repitan cada minuto. Cuando alguien responde a las notificaciones de alarma, detiene temporalmente las notificaciones con la mejor práctica de supresión de la alarma. Cuando la métrica CpuUtilization se vuelve a detectar desde el recurso, se elimina la supresión.
A veces, desea recibir una notificación cuando se produce un evento, como el cierre de una instancia de base de datos. En este escenario, defina las notificaciones de repetición en cero minutos para crear una alarma basada en eventos. Para obtener instrucciones, consulte Obtención de notificaciones basadas en eventos para una alarma.
Seleccione el intervalo de alarma correcto para la métrica
Seleccione un intervalo en el que se emite la métrica según la frecuencia. Por ejemplo, una métrica que se emite cada cinco minutos requiere un intervalo o superior de alarma de 5 minutos. La mayoría de las métricas se emiten cada minuto, lo que significa que la mayoría de las métricas soportan cualquier intervalo de alarma. Para determinar la existencia de intervalos de alarma válidos para una métrica específica, consulte la referencia de métrica del servicio pertinente.
Supresión de alarmas durante la investigación
Cuando un miembro de equipo responde a una alarma, suprima las notificaciones durante el esfuerzo de investigar o mitigar el problema. La desactivación temporal de las notificaciones ayuda a evitar distracciones durante la investigación y la mitigación. Retire la supresión en cuanto se resuelva el problema. Para obtener instrucciones, consulte Suprimir una alarma única y Supresión de varias alarmas.
Ajuste rutinario de las alarmas
Revise las alarmas de forma periódica, por ejemplo, semanalmente, para garantizar que la configuración sea óptima. Calibre los detalles de umbral, gravedad y notificación de cada alarma, incluidos el método, la frecuencia y el público objetivo.
La configuración óptima de las alarmas aborda los siguientes factores:
- Importancia del recurso.
- Comportamiento apropiado del recurso. Evalúe el comportamiento de manera individual y en el contexto del ecosistema de servicio. Revise las fluctuaciones de los valores de las métricas en un periodo determinado y, a continuación, ajuste los umbrales según sea necesario.
- Ruido de notificaciones aceptable. Evalúe el método de notificación (por ejemplo, correo electrónico o PagerDuty), los destinatarios adecuados y la frecuencia con la que deben repetirse las notificaciones.
En la siguiente tabla, se muestra un ejemplo de calibración de alarma.
| % de umbral de CPU | Gravedad | Método de notificación | Frecuencia | Público objetivo |
|---|---|---|---|---|
| >80 % | Grave | PagerDuty + Correo electrónico | 1 minuto | Recursos informáticos, operaciones y comunicaciones con el cliente |
| >60 % y <80 % | Advertencia | Correo electrónico | Una vez al día | Recursos informáticos y operaciones |
Para obtener instrucciones, consulte Actualización de una alarma.