monitoring - who - ¿Cuáles son los requisitos para un sistema de monitoreo de la salud de la aplicación?

world health organization mexico (9)

¿Qué debe hacer, como mínimo, un sistema de control de estado de la aplicación para usted (el desarrollador) y / o su jefe (el gerente de TI) y / o el personal de operaciones (de turno)?

¿Qué más debería hacer por encima de los requisitos mínimos?

¿Es suficiente monitorear las aplicaciones de ''infraestructura'' (ms-exchange, apache, etc.) o también se deben monitorear las aplicaciones de usuario individuales, los sitios web y las bases de datos?

si es este último, ¿qué necesitas saber sobre ellos?

ADDENDUM: gracias por la entrada, realmente estaba buscando monitoreo a nivel de aplicación, no monitoreo de infraestructura, pero es bueno saber sobre ambos

Como mínimo, desea saber que el sistema es saludable. Esto es subjetivo en lo que define que su sistema es saludable. ¿Las computadoras están funcionando, los recursos necesarios existen, los datos fluyen a través del sistema, los datos están produciendo los resultados, etc., etc.

En mi proyecto hacemos un seguimiento de la mayor parte de esto y algo más. Realmente se reduce a lo que es el nivel más alto que puede usar para analizar que todo está funcionando. En nuestro caso, necesitamos saber hasta la salida de datos. Si solo necesita saber hasta dónde están estas máquinas, le ahorrará al tratar de mostrarle a un usuario final sin experiencia lo que está mal.

También hay herramientas "listas para usar" que harán mucho del trabajo duro para usted si solo está mirando demasiado los resultados de los datos. Me gustó especialmente Nagios cuando estaba buscando pero necesitábamos más de lo que podía mostrar fácilmente, así que escribí nuestro propio sistema de monitoreo. Básicamente también buscamos "peculiaridades" en el sistema, picos de memoria / CPU, etc.

Creo que esto es bastante simple: monitoree para que pueda ser advertido lo suficientemente temprano antes de que algo salga mal. Eso significa monitorear las dependencias y la aplicación en sí misma.

Es realmente difícil proporcionar detalles si no va a dar detalles sobre la aplicación que está monitoreando, entonces yo diría que la use como regla general.

Esta es una pregunta tan abierta, pero comenzaría con mediciones físicas.
1. ¿Pueden hacer ping todas las máquinas que creo que alojan este sitio?
2. ¿Están todas las máquinas que deberían servir contenido que sirve algún contenido? (Idealmente esto sería golpeado desde una red externa.
3. ¿Se ejecuta cada servicio esperado en cada máquina?
3a. ¿Han funcionado esos servicios recientemente?
4. ¿Cada máquina tiene espacio en el disco duro? (No olvides el db)
5. ¿Se han hecho copias de seguridad de estas máquinas? ¿Cuando fue la ultima vez?

Una vez que se establece el monitoreo físico de los sistemas, uno puede abordar los específicos de un sistema.

1. ¿Puede un script automatizado iniciar sesión? ¿Cuánto tiempo tomó?
2. ¿Cuántos usuarios hay en vivo? ¿Se han agregado un millón de cuentas falsas?
...
Este tipo de preguntas se vuelven más nebulosas y pueden ser muy específicas del sistema. También generalmente se pueden derivar de forma reactiva cuando se responden a mediciones físicas. El disco duro se llenó, tal vez los registros del servidor web se llenaron porque un grupo de agentes creó demasiados usuarios falsos. Ese tipo de cosas.

Si bien el plan A no necesariamente debe ser reactivo, es la forma en que muchos sitios configuran un sistema de monitoreo.

La respuesta es, depende''. ¿Por qué necesitas monitorear? ¿Qué tan grande es su personal de operaciones? ¿Necesitas reportar? ¿Cuál es el entorno de la aplicación? A quién le importa si la aplicación falla? A quién le importa si ocurre una excepción? ¿Alguno de los errores es recuperable? Podría hacer preguntas como estas durante mucho tiempo.

Mínimo: asegúrese de que esté funcionando :)

Sin embargo, algunas otras cosas serían muy útiles. Por ejemplo, la carga de la CPU, el uso de RAM y (en sistemas multiusuario) qué usuario está ejecutando qué. Además, para las aplicaciones que acceden a la red, una lista de conexiones de red para cada aplicación. Y (si tiene acceso a la (s) computadora (s) cliente (s)) sería genial poder ver el ''título de la ventana'' de la aplicación; tal vez revise cada 2-3 minutos si cambiara y guárdelo. Además, una lista de archivos abiertos por la aplicación podría ser muy útil, pero no es obligatorio.

Si la aplicación se está ejecutando.
Uso inusual de la CPU / memoria / red.
Informe cualquier excepción no controlada.
Estado de varios módulos (si corresponde).
Estado de los componentes externos (bases de datos, servicios web, servidores de archivos, etc.)
Número de tareas de fondo pendientes (si corresponde).
Tal vez haga un seguimiento del uso de la aplicación e informe estadísticas sobre las funcionalidades más / menos utilizadas para que sepa dónde son más beneficiosas las optimizaciones.

gracias a todos por la entrada, realmente estaba buscando monitoreo a nivel de aplicación, no monitoreo de infraestructura, pero es bueno saber sobre ambos

la diferencia es:

la supervisión de la infraestructura sería servidores más MS Exchange Server, Apache, IIS, etc.
la supervisión de la aplicación serían las máquinas de los usuarios y los programas específicos que usan para hacer sus trabajos, y / o servidores más las aplicaciones de transferencia de datos / back-end que ejecutan para mantener el flujo de datos

a veces es difícil trazar la línea: una definición demasiado simplificada podría ser "si tu equipo lo escribió, es una aplicación; si la compraste, es una infraestructura"

Creo que en la práctica es mejor monitorear ambos

Lo que debe hacer es desglosar el proceso comercial de la aplicación y luego hacer que el software emita eventos en los principales componentes comerciales. Además, deberá crear transacciones sintéticas de extremo a extremo (por ejemplo, emular a los usuarios finales haciendo clic en un sitio web). Toda esa información se alimentaría en una herramienta de monitoreo. En el pasado, hice JMX para las aplicaciones que fluían al Adaptador JMX de Tivoli Monitoring y luego hice scripts que implementan un "usuario falso" y luego canalizo los resultados al Adaptador de scripts de Tivoli Monitoring. Tivoli Monitoring toma los datos y luego crea cuadros de rendimiento y salud de la aplicación a partir de esos datos brutos.

Gran pregunta

Hemos estado buscando alguna solución de monitoreo a nivel de aplicación para nuestras necesidades hace algún tiempo sin suerte. La solución de monitoreo popular está principalmente dirigida a monitorear la infraestructura y, en mi opinión, son demasiado complicadas para los requisitos de la mayoría de las pequeñas y medianas empresas.

Requerimos (principalmente) las siguientes características:

alertas: queríamos saber sobre el incidente lo más rápido posible
administración sin problemas: el servicio alojado sería el mejor
visualizaciones: es bueno saber qué está pasando y tomar algo de conocimiento de los datos

Como no encontramos la solución adecuada, comenzamos a escribir la nuestra. Finalmente, hemos terminado con el servicio up-running llamado AlertGrid . (Puede verificarlo gratis, por supuesto).

La idea detrás de esto es proporcionar una manera fácil de manejar escenarios de monitoreo personalizados. La API de integración es muy simple (una función con dos parámetros necesarios). En el momento en que nosotros y otros lo estamos usando para:

monitorear tareas programadas (trabajos cron)
monitorear la ejecución de la lógica de la aplicación
alerta sobre errores en las aplicaciones
también estamos trabajando en ejemplos de monitoreo de infraestructura básica usando AlertGrid