¿Cuáles son los requisitos para un sistema de control de estado de la aplicación?

Question

¿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 las aplicaciones de usuario individuales, los sitios web y las bases de datos también deben ser monitoreados?

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

Adición: Gracias por la entrada, estaba realmente en busca de supervisión a nivel de aplicación de monitoreo no en la infraestructura, pero es bueno saber acerca tanto

Answer 1

• Si la aplicación se está ejecutando.
• Uso inusual de la CPU/memoria/red.
• Indique las excepciones no controladas.
• 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).
• Quizás rastree el uso de la aplicación e informe estadísticas sobre las funcionalidades más/menos usadas para que sepa dónde son más beneficiosas las optimizaciones.

Answer 2

mínima: asegúrese de que está ejecutando :)

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.

Answer 3

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.

Answer 4

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

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

Answer 5

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

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

1. ¿Se puede iniciar sesión en un script automatizado? ¿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.

Answer 6

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

En mi proyecto hacemos el monitoreo 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.

Answer 7

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

la diferencia es:

• monitoreo de infraestructura sería servidores, además de MS Exchange Server, Apache, IIS, etc.
máquinas de los usuarios serían monitoreo
• aplicación y los programas específicos que utilizan para hacer sus trabajos, y/o servidores más el movimiento de datos/aplicaciones de back-end que se ejecutan para mantener los datos que fluyen

a veces es difícil trazar la línea - una definición simplificada podría ser "si su equipo lo escribió, es una aplicación; si usted lo compró, que es la infraestructura"

Creo que en la práctica es mejor para controlar tanto

Answer 8

Lo que hay que hacer es romper el proceso de negocio de la aplicación y luego tener el software emite eventos en las principales componentes comerciales. Además, deberá crear transacciones sintéticas de extremo a extremo (por ejemplo, emular usuarios finales que hagan clic en un sitio web). Todos esos datos se incorporarían a una herramienta de monitoreo. En el pasado, he hecho JMX para las aplicaciones de las cuales fluyeron al Adaptador JMX de Tivoli Monitoring y luego hice scripts que implementan un "usuario falso" y luego canalizo los resultados en el Adaptador de scripts de Tivoli Monitoring. Tivoli Monitoring toma los datos y luego crea cuadros de rendimiento y estado de la aplicación datos sin procesar.

Answer 9

Una gran pregunta.

Hace algún tiempo, hemos estado buscando una solución de monitoreo de nivel de aplicación para nuestras necesidades sin ningún tipo de 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.

Nos necesaria (principalmente) siguientes características:

• alerta - que queríamos saber sobre incidente lo más rápido posible
• gestión indolora - servicio alojado wouldbe los mejores
• visualizaciones - es bueno para saber qué está pasando y tomar un poco de conocimiento de los datos

Porque no encontramos la solución adecuada en comenzamos a escribir el nuestro. Finalmente, hemos terminado con el servicio up-run 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). Al momment nosotros y otros estamos utilizando para:

• supervise tareas programadas (cron jobs)
• seguimiento de la ejecución de toda lógica de la aplicación
• alerta sobre los errores en las aplicaciones
• también estamos trabajando en ejemplos de supervisión de la infraestructura básica con AlertGrid