Por qué la carga de CPU no debería (normalmente) ser una alerta crítica.

Una pregunta que a menudo se plantea en el monitoreo es cómo definir los niveles de alerta y las escaladas, y qué nivel establecer varias alertas en estado crítico, Error o Advertencia.

Asumiendo que tiene errores y alertas críticas configuradas para notificar a los equipos por localizador/teléfono, y alertas críticas con un tiempo de escalado más corto, aquí hay algunas pautas simples:

Las alertas críticas deben ser para eventos que tengan un efecto de impacto inmediato en el cliente. Por ejemplo, una IP virtual de producción en un equilibrador de carga monitorizado se cae, ya que no tiene servicios disponibles para enrutar el tráfico. El sitio está caído, así que llama a todos.

Las alertas de error deben ser para eventos que requieren atención inmediata y que, si no se resuelven, aumentan la probabilidad de que ocurra un evento que afecte a la producción. Para continuar con el ejemplo del equilibrador de carga, se debe activar un error si la IP virtual solo tiene un servidor backend en funcionamiento para enrutar el tráfico; ahora no hay redundancia, por lo que un error puede desconectar el sitio.

Las advertencias, que normalmente recomendamos que se envíen solo por correo electrónico, son para todos los demás tipos de eventos. La pérdida de un único servidor de backend de una IP Virtual cuando hay otros 20 servidores funcionando no garantiza que se despierte a nadie en la noche.

Al decidir a qué nivel asignar alertas, tenga en cuenta la función principal del dispositivo. Por ejemplo, en el caso de una matriz de almacenamiento de NetApp, la función del dispositivo es servir solicitudes de E / S de lectura y escritura. Por lo tanto, lo principal para monitorear NetApps debe ser la disponibilidad y el rendimiento (latencia) de estas solicitudes de lectura y escritura. Si un volumen está atendiendo solicitudes con alta latencia, como 70 ms por solicitud de escritura, debería tratarse de una alerta de nivel de error (en algunas empresas, puede ser apropiado configurarla como una alerta de nivel crítico, pero, por lo general, una alerta de rendimiento crítico solo debería activarse si el rendimiento de la aplicación final se degrada de forma inaceptable.) Sin embargo, si la carga de CPU en NetApp es del 99% durante un período, a pesar de que suene alarmante, sugiero que se trate solo como una alerta de nivel de advertencia. Si la latencia no se ve afectada, ¿por qué despertar a la gente por la noche? Envíe una alerta por correo electrónico para que se pueda investigar el problema, pero si la función del dispositivo no se ve afectada, no reaccione de más. (Si lo desea, puede definir las escaladas de sus alertas para que tales condiciones den lugar a páginas si no se corrigen o no se reconocen durante más de 5 horas, por ejemplo.)

La sobrecarga de alerta es un peligro mayor para la mayoría de los centros de datos de lo que la mayoría de la gente cree. El pensamiento es a menudo “si una alerta es buena, más debe ser mejor.”En su lugar, concéntrese en identificar las funciones principales de los dispositivos: configure alertas de nivel de error en esas funciones y use advertencias para informarle sobre las condiciones que podrían perjudicar esas funciones o para ayudar a solucionar problemas. (Si la latencia en NetApp es alta y la carga de la CPU también está en alerta, esto obviamente ayuda a diagnosticar el problema, en lugar de buscar una actividad de volumen inusual.)

Reserve alertas críticas para el rendimiento y la disponibilidad del sistema en su conjunto.

Con la supervisión alojada en LogicMonitor, las definiciones de alerta para todos los dispositivos de centros de datos tienen sus umbrales de alerta predefinidos de la manera anterior, una de las formas en que ayudamos a proporcionar una supervisión significativa en minutos.