Pregunta Mejores prácticas de monitoreo de aplicaciones web [cerrado]


Estamos terminando nuestra aplicación web y planificando la implementación. Un aspecto muy importante de la implementación en producción es monitorear el estado del sistema. Tener un pequeño equipo de desarrolladores / soporte hace que sea muy crítico para nosotros obtener el notificaciones anticipadas de posibles problemas y resolverlos antes de que tengan un impacto en los usuarios.

Usar Nagios se ve como una buena opción, pero quería obtener más opiniones sobre cuáles son las mejores herramientas / prácticas de monitoreo para aplicaciones web en general y específicamente para la aplicación Django. También recibiría con agrado recomendaciones sobre lo que se debería monitorear aparte de la CPU obvia, la memoria, el espacio en disco, la conectividad con la base de datos.

Nuestra aplicación web está escrita en Django, corremos en Linux (Ubuntu) bajo Apache + Fast CGI con base de datos PostgreSQL.

EDITAR Tenemos un entorno completamente virtualizado bajo Linode.

EDITAR Estamos utilizando django-logging para que tengamos una forma separada de información, errores, problemas críticos, etc.


74
2018-01-30 16:39


origen


Respuestas:


Nagios está bien, es bueno tener pruebas del sistema (Selenio) funcionando regularmente.

Editar: Hyperic y Trabajo preparatorio también parece interesante.

Probablemente exista un sistema de suite de pruebas que también pueda hacer pruebas de presión para usted. No puedo recordar el nombre de la parte superior de mi cabeza, tal vez alguien puede mencionar uno a continuación.

Otras cosas que me gusta hacer:

El mejor lema para la infraestructura es siempre arreglar, detectar, reparar. Levántalo, ve a la raíz y cúrralo / prevenlo si puedes.

Dado que existe un sistema en muchos niveles, debemos probar en muchos niveles:

Editar: Haga que todos los errores o advertencias sean enviados directamente a su administrador de casos por correo electrónico. De esta forma puedes rastrear las ocurrencias en un solo lugar.

1) Conexión : controle su conectividad a Internet desde el servidor y desde el exterior. Registra esto en alguna parte

2) Servidor : supervise todos los procesos que necesite para asegurarse de que se estén ejecutando y no bloqueando el servidor. Use un Servidor HP o algo equivalente con notificación de falla de hardware que pueda hacer desde un nivel de BIOS. Notificar y registrar si lo son.

3) Software : Identifique el software clave que siempre debe ejecutarse. Establezca los niveles de rendimiento si los hay y luego supervise. Nagios debería ser capaz de ayudar con esto. En Windows puede ser un poco más. Cuando se produce una excepción, debe poder ejecutar una secuencia de comandos para reiniciar los procesos automáticamente. El sistema de mis sueños me permite interactuar con los servidores a través de SMS si el servidor lo ve como una excepción que tengo que permitir, o uno que sucederá automáticamente a menos que cancele por SMS. Un día..

4) Potencia remota : Asegúrese de que las capacidades remotas de reinicio de energía estén en su mano. Es posible que desee programar reinicios semanales si alguna vez usa Windows para algo.

5) Pruebas de lógica de negocios: Ejecute regularmente scripts que prueben el flujo de trabajo de su sistema. El selenio probablemente puede lograr algo de esto, pero me gusta registrar los resultados y decir que esto se ejecutó en este momento y que estos archivos tenían errores. Si es posible en cualquier lugar, haga que el sistema se supervise a sí mismo a través de sus secuencias de comandos.

6) Copias de seguridad : Haga una copia de seguridad que pueda establecer y olvidar. Si puede obtener cosas en las máquinas virtuales, sería ideal, ya que puede escalar, mover o implementar cualquier parte de su infraestructura en cualquier lugar. He tenido instancias en las que moví un servidor inactivo a mi computadora portátil, lo dejé correr en vmware mientras solucionaba un problema.


36
2018-01-30 16:55



También es bueno hacer un seguimiento del número de conexiones a su servidor web y su base de datos. Lo más probable es que si uno sale corriendo por el techo, algo está muriendo de hambre por los recursos y el sitio está a punto de caer.

Además, asegúrese de tener una solicitud regular de una URL que sea una prueba razonable de extremo a extremo del sistema. Si su sitio admite la búsqueda, haga que nagios ejecute una búsqueda, lo que debería garantizar que el índice de búsqueda esté en buen estado, el servidor web y el servidor de la base de datos.

Además, asegúrese de que sus aplicaciones le envíen un correo electrónico cada vez que los usuarios vean un error o que haya una excepción no controlada. De esta forma, sabrá cómo falla la aplicación en el campo.


12
2018-02-01 21:17



Si tuviera que elegir un tipo de prueba, sería probar la funcionalidad del usuario final del sistema. Lo importante a considerar es el usuario. Aunque probar cosas como la disponibilidad de la base de datos, el tiempo de actividad del servidor, etc., son todas importantes, la prueba de flujos de trabajo a través de su sistema a través de un sistema de prueba de UI remota cubre todas estas bases. Si sabe que las partes críticas de su sistema están disponibles para el usuario final, entonces sabrá que su sistema está bien.

  1. Identifique los flujos de trabajo importantes en su sistema.  Por ejemplo, si escribió un sitio de comercio electrónico, puede identificar un flujo de trabajo de "búsqueda de un producto, colocar el producto en el carro de la compra y comprar el producto".
  2. Priorice los flujos de trabajo y cree primero pruebas de mayor prioridad.  Siempre puede agregar pruebas adicionales después de lanzar a producción.
  3. Cree pruebas de interfaz de usuario usando uno de los marcos de prueba de interfaz de usuario disponibles. Hay una serie de marcos de prueba de IU gratuitos y comerciales que se pueden ejecutar de forma automatizada. Cree primero un conjunto de pruebas básicas que aborden los flujos de trabajo críticos.
  4. Configure al menos una ubicación remota desde la cual ejecutar pruebas. Desea probar cada aspecto de su sistema, lo que significa probarlo de forma remota. ¿La conexión a Internet está activa? ¿Se está ejecutando el servidor web? ¿Está funcionando la conexión al servidor de la base de datos? Etc, etc. Si realiza la prueba de forma remota, asegúrese de que el sistema esté disponible para el mundo exterior, lo que significa que probablemente funcione de principio a fin. También puede ejecutar estas pruebas internamente, pero creo que es crítico ejecutarlas externamente.
  5. Asegúrese de que su solución incluya informes y notificaciones. Si una de sus pruebas críticas de flujo de trabajo falla, quiere que alguien lo sepa para solucionar el problema lo antes posible. Si una tarea no crítica falla, tal vez solo desee informar para que pueda solucionar los problemas fuera de banda.

Esta prueba del usuario final no debe eliminar el monitoreo del sistema en su centro de datos, pero quiero reiterar que las pruebas del usuario final son el tipo de prueba más importante que puede hacer para una aplicación web.


11
2018-02-04 18:59



Ahhh, monitoreo. Cómo te amo y tus vibraciones a las 3 a. M.

Básicamente, necesita una forma de inspeccionar el estado interno de su aplicación, tanto en un momento específico como a lo largo del tiempo (esto último es muy importante para detectar problemas antes de que ocurran). Otra forma de pensarlo es como una unidad de prueba glorificada.

Tenemos nuestro propio (muy bueno) sistema de monitoreo, por lo que no puedo comentar sobre Nagios u otras aplicaciones. Sin embargo, nuestro caso de uso es similar al tuyo (aplicación cgi en apache).

  1. Agregue un método de tipo logging.monitor (), que registrará la información en el disco. Esto debería permitir, al menos, registrar números simples y números de números (la asociación de clave => valor puede ser increíblemente útil).
  2. Tener un proceso que raspa los registros de monitoreo y los almacena en una base de datos.
  3. Tenga un proceso que tome la información de la base de datos, la verifique contra las reglas y envíe alertas. Tenga en cuenta que algunas cosas pueden ser escamosas. Solo porque tienes un 404 una vez no significa que la aplicación no funciona.
  4. Tenga una manera de silenciar las alertas (muy útil para el mantenimiento o para leer su correo electrónico).

Eso es todo bastante alto nivel. Lo importante es que tenga un historial del estado de la aplicación a lo largo del tiempo. A partir de esto, puede crear reglas (tal vez solo consultas sql sin formato que coloca en una configuración en algún lugar), que dicen "Si las consultas por segundo se duplicaron, envíe una alerta SlashDotted", o "si el 50% de las respuestas son 404, envíe un alerta". También deslumbra la gestión porque puedes cuantificar cualquier comentario sobre si está activo, inactivo, rápido o lento.

Las cosas a monitorear incluyen (otros probablemente también mencionaron esto): estado http, puerto accesible, carga http, carga de la base de datos, conexión abierta, latencia de consulta, accesibilidad del servidor (ssh, ping), consultas por segundo, cantidad de procesos de trabajo, porcentaje de error , Tasa de error.

Las pruebas simples de extremo a extremo también son muy útiles, aunque pueden ser frágiles. Lo mejor es mantenerlos simples, pero debería tener uno que intente tocar las piezas principales de la aplicación (almacenamiento en caché, base de datos, autenticación).


7
2018-01-30 16:39



yo suelo Munin y Monit, y he estado muy feliz con ambos.


5



El registro interno es excelente y excelente, pero cuando toda tu aplicación se cae o tu cofre / entorno se bloquea, también necesitas un control externo. http://www.pingdom.com/ ha sido muy confiable para mi

Mi único otro consejo es que no lo gastaría demasiado tiempo en esto. mi mejor ejemplo es Twitter, cuánta energía pusieron en el sistema al poder morir a medias en lugar de solo invertir ese tiempo y energía en tirar más hardware / escalarlo.

Lo más probable es que lo derribe, sus sistemas de registro y de salud se habrán perdido de todos modos.


4



La forma más importante de monitorear cualquier sitio en línea es monitorear externamente. El objetivo debe ser monitorear su sitio de manera que refleje más de cerca cómo usan el sitio los usuarios. En el 99% de los casos, tan pronto como sepa que su sitio está caído externamente, es relativamente fácil encontrar la causa raíz. Lo más importante es saber lo antes posible que sus clientes no pueden cargar su sitio.

Esto generalmente significa el uso de un servicio de monitoreo de desempeño externo. Desde el extremo inferior (mon.itor.us, pingdom) hasta el extremo superior (Webmetrics, Gomez, Keynote). Y como siempre, obtienes lo que pagas. Las cosas a tener en cuenta al comprar un servicio de monitoreo incluyen:

  • El tamaño y la distribución de la red de monitoreo
  • Si la solución de monitoreo puede o no monitorear su sitio usando un navegador real (de lo contrario, no está probando su sitio como lo haría un usuario real)
  • El lenguaje de scripting (para ejecutar las transacciones en su sitio)
  • El departamento de soporte, para ayudarlo en el camino, y proporcionar experiencia sobre cómo monitorear correctamente

¡Buena suerte!


4



Monitoreo web por Patrulla de IP o SiteSentry han sido útiles para nosotros El segundo es un poco como la confianza del sitio, pero un poco más bonita jaja.


3



¿Has pensado en monitorear la funcionalidad también? Un script (ya sea en un lenguaje de script como Perl o Pyton o usando alguna herramienta como WebTest) que habla con su aplicación y hace algunos pasos importantes como iniciar sesión, hacer una compra, etc. es muy bueno tenerlos.


2



Además de lo que debe monitorearse, que ya ha sido respondido, debe asegurarse de que, sea cual sea el sistema que use, solo obtenga uno notificación de un error que ocurre varias veces, en cada solicitud. O su bandeja de entrada se quedará sin memoria :) Además, es simple y molesto ...

Divida los turnos de espera entre el equipo de soporte / desarrollo, por lo que una persona no tiene que estar de guardia todas las noches. Eso desgastará a la gente. El monitoreo es un Buena cosa, pero todos deben tener la oportunidad de tener una vida de vez en cuando. Su teléfono celular zumbando a las 2 de la madrugada por algunas noches obtendrá muy viejo muy pronto, confía en mí. Y no todos los desarrolladores están acostumbrados a la asistencia las 24 horas del día, los 7 días de la semana, por lo que debe encontrar el equilibrio entre el uso del monitoreo y el abuso de la supervisión.

Básicamente, tienen distintos niveles de escalada, y si el cielo no se está cayendo, defina un "serenidad ahora"ventana por la noche donde los niveles más pequeños de escalamiento no se apagan".


2