django - source - Mejores prácticas de monitoreo de aplicaciones web

software de monitoreo de red gratis (18)

es bueno tener pruebas del sistema (Selenio) funcionando regularmente.

=> 100% ACK. Utilizamos http://www.alertfox.com para esto. con nuestra cuenta PRO2 ejecutan una prueba de regresión cada 1h, lo que es genial. Incluso puede hacer esto con su cuenta gratuita, pero está limitado a un solo sensor de transacción.

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 importante para nosotros obtener las 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 usando django-logging por lo que tenemos una manera separada de información, errores, problemas críticos, etc.

¿Has pensado en monitorear la funcionalidad también? Una secuencia de comandos (ya sea en un lenguaje de scripts como Perl o Pyton o utilizando alguna herramienta como WebTest ) que se comunica con su aplicación y realiza algunos pasos importantes, como iniciar sesión, hacer una compra, etc., es muy agradable.

Además de lo que debe supervisar, que ya se ha respondido, debe asegurarse de que, sea cual sea el sistema que utilice, solo reciba una 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 algo bueno , pero todos deben tener la oportunidad de tener una vida de vez en cuando. Su teléfono celular zumbando a las 2AM por unas pocas noches se pondrá muy viejo muy pronto, créanme. 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 está cayendo, defina una ventana de " serenidad ahora " por la noche donde los niveles de escalamiento más pequeños no se apagan.

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).

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).
Tener un proceso que raspa los registros de monitoreo y los almacena en una base de datos.
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. El hecho de que obtuviste un 404 una vez no significa que la aplicación.
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).

Cambiar la línea un poco, algo que realmente creo que es útil y ha cambiado mucho la manera en que controlo mis aplicaciones es registrar excepciones de JavaScript en alguna parte. Hay una implementación muy buena que registra eso directamente desde los navegadores de los usuarios a Google Analytics. Esta es una necesidad para las aplicaciones web centradas en Javascript, y puede proporcionarle resultados basados directamente en los navegadores de los usuarios, lo que puede conducir a errores muy inesperados (iE y el navegador móvil son dolorosos)

Descargo de responsabilidad: Mi publicación abajo

http://www.directperformance.com.br/en/javascript-debug-simples-com-google-analytics

El monitoreo web por parte de IP Patrol o SiteSentry ha sido útil. El segundo es un poco como la confianza del sitio, pero un poco más bonita jaja.

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 mí.

Mi único otro consejo es que no pasarí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.

He estado usando Nagios + CruiseControl + Selenium para ejecutar pruebas de alto nivel en aplicaciones web de misión crítica. Me quemó bastante duro por un simple error de jquery que impidió que los usuarios procesaran a través de un formulario de registro en línea.

http://www.agileatwork.com/the-holy-trinity-of-web-2-0-application-monitoring/

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!

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

Editar: Hyperic y Groundwork también se ven interesantes.

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 : monitoree todos los procesos que necesite para asegurarse de que se estén ejecutando y no fijen 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) Business Logic Testing : 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 configurar 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.

Para el monitoreo de la presencia de Internet, sugeriría el servicio en el que estoy trabajando: Sucuri NBIM (monitor de integridad basado en la red).

Hace comprobaciones de disponibilidad e integridad, buscando cambios en su presencia en Internet (sitios, DNS, WHOIS, encabezados, etc.) y pérdida de conectividad. Es gratis y puedes probarlo aquí .

Parafraseando a Richard Levasseur: ah, herramientas de monitoreo, cómo tus imperfecciones me frustran. No parece haber una herramienta perfecta por ahí; Nagios es bastante fácil de configurar, pero la interfaz de usuario está un poco pasada de moda y tienes que tener un daemon ejecutándose en cada servidor que se monitorea. Zenoss tiene una interfaz de usuario mucho más agradable que incluye gráficas de tendencia del uso de recursos, pero usa SNMP, así que debes familiarizarte con eso para que funcione correctamente, y la documentación no es la mejor: hay cientos de páginas pero es muy difícil encuentre solo la información que necesita para comenzar.

Mis amigos también me recomendaron Cacti e Hyperic , pero no tengo experiencia personal con ellos.

Una última cosa: una de las otras respuestas sugiere ejecutar una herramienta que haga hincapié en su sitio. No recomendaría hacer eso en su sitio en vivo a menos que tenga un período de tranquilidad confiable cuando nadie lo está golpeando; incluso entonces podrías bajarlo inesperadamente. Es mucho mejor tener un servidor de etapas donde pueda ejecutar pruebas de carga antes de poner los cambios en producción.

Puedes echar un vistazo a AlertGrid . Esta aplicación web le permite filtrar y enviar alertas a su equipo (en todo el mundo). También tiene una buena capacidad para controlar si algo no sucedió.

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.

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".
Priorice los flujos de trabajo y cree primero pruebas de mayor prioridad. Siempre puede agregar pruebas adicionales después de lanzar a producción.
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.
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.
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.

Solo agregaría que puede predecir la probabilidad de error en función del historial de errores pasados y haberlos solucionado. Con pruebas internas a menor escala si tuviera que graficar la frecuencia y la gravedad de los problemas que se han corregido hasta este punto, tendrá una visión general de los nuevos problemas predecibles. Si todo ha estado funcionando sin errores durante algún tiempo, entonces las dos fuentes de problemas serían los cambios recientes o los problemas de escalabilidad.

De lo anterior, parece que la escalabilidad es su única preocupación, pero solo menciono la prueba de frecuencia de errores pasados porque los equipos en los que he estado invariablemente piensan que han solucionado el último error y no hay más. Hasta que hay

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.

Uno de nuestros clientes usa Techout (www.techout.com) y está muy satisfecho con el servicio.

No hay ningún cargo por alertas, sin importar el tipo o el número, y ofrecen alertas por correo electrónico, correo de voz y SMS, y si sucede algo importante, una llamada telefónica de una persona en vivo para que lo ayude.

Todo se basa en el servicio: no instala el software y tiene un asesor que trabaja con usted para determinar el mejor enfoque para su negocio. Es uno de los servicios de monitoreo de aplicaciones web más convenientes porque se encargan de todo.

Uso Munin y Monit , y he sido muy feliz con los dos.