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

Monitorear el número de conexiones a su servidor Web y su base de datos es otra buena cosa para rastrear. Lo más probable es que si uno dispara a través del techo, algo está hambriento de recursos y el sitio está a punto de caer.

También asegúrese de tener una solicitud regular para una URL que sea una prueba razonable de extremo a extremo del sistema. Si su sitio es compatible con la búsqueda, entonces haga que nagios ejecute una búsqueda - que debe asegurarse de que el índice de búsqueda está en buen estado, el servidor Web y la base de datos servidor.

Además, asegúrese de que sus aplicaciones le envíen un correo electrónico cada vez que sus usuarios vean un error o haya una excepción no controlada. De esa manera usted sabe cómo la aplicación está fallando en el campo.

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. Si bien probar cosas como la disponibilidad de la base de datos, el tiempo de actividad del servidor, etc., son importantes, probar los flujos de trabajo a través de su sistema a través de un sistema de prueba de interfaz de usuario remoto cubre todas estas bases. Si sabe que las partes críticas de su sistema están disponibles para el usuario final, entonces sabe que su sistema está bien.

1. Identificar el flujos de trabajo importantes en su sistema. Por ejemplo, si escribiste un sitio de comercio electrónico, podrías identificar un flujo de trabajo de "buscar un producto, poner un producto en el carrito de compras y comprar un producto".
2. Prioriza los flujos de trabajo y crea primero pruebas de mayor prioridad. Siempre puede agregar pruebas adicionales después de comenzar la producción.
3. Compile pruebas de interfaz de usuario utilizando uno de los marcos de prueba de interfaz de usuario disponibles. Hay una serie de pruebas de interfaz de usuario gratuitas y comerciales frameworks que se pueden ejecutar de forma automatizada. Cree primero un conjunto básico de pruebas que aborden los flujos de trabajo críticos.
4. Configure al menos una ubicación remota desde la que ejecutar las pruebas. Desea probar todos los aspectos de su sistema, lo que significa probarlo de forma remota. ¿La conexión a Internet está activada? ¿Se está ejecutando el servidor web? ¿Funciona la conexión al servidor de base de datos? Etc, etc. Si prueba de forma remota, asegúrese de que su sistema esté disponible para el mundo exterior, lo que significa que lo más probable es que funcione de extremo a extremo. También puede ejecutar estas pruebas internamente, pero creo que es fundamental ejecutarlas externamente.
5. Asegúrese de que su solución incluya tanto informes como notificaciones. Si una de sus pruebas críticas de flujo de trabajo falla, desea que alguien lo sepa para solucionar el problema lo antes posible. Si una tarea no crítica falla, tal vez solo desee informes para poder solucionar problemas fuera de banda.

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

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

Esencialmente, necesita una forma de inspeccionar el estado interno de su aplicación, tanto en un momento específico, como en períodos de tiempo (este último es muy importante para detectar problemas antes de que ocurran). Otra forma de verlo es como una glorificada prueba unitaria.

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

1. Añadir un registro.método de tipo monitor (), que registrará la información en el disco. Esto debería admitir, al menos, el registro de números simples y dictos de números (la asociación clave=>valor puede ser increíblemente útil).
2. Tiene un proceso que raspa los registros de monitoreo y los almacena en una base de datos.
3. Tiene un proceso que toma la información de la base de datos, la compara con las reglas y envía alertas. Tenga en cuenta que algunas cosas pueden ser escamosas. Simplemente porque tienes un 404 una vez no significa que la aplicación hacia abajo.
4. Tiene una manera de silenciar 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 procesar que coloque en una configuración en algún lugar), que digan "Si las consultas por segundo se duplican, envíe una alerta de SlashDotted", o " si el 50% de las respuestas son 404, envíe una alerta". También deslumbrará a la administración porque puede cuantificar cualquier comentario sobre si es hacia arriba, hacia abajo, rápido o lento.

Las cosas a monitorear incluyen (otros probablemente mencionaron esto también): estado http, puerto accesible, carga http, carga de base de datos, conexión abierta, latencia de consulta, accesibilidad del servidor (ssh, ping), consultas por segundo, número 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. Es mejor mantenerlos simples, pero debe tener uno que intente tocar las piezas principales de la aplicación (almacenamiento en caché, base de datos, autenticación).

Yo uso Munin y Monit, y he estado muy contento con ambos.

El registro interno está bien y excelente, pero cuando toda su aplicación se cae o su caja/enviro se bloquea, también necesita una verificación externa. http://www.pingdom.com / ha sido muy confiable para mí.

Mi único consejo es que no pasó demasiado tiempo en esto. mi mejor ejemplo es Twitter, cuánta energía pusieron en el sistema siendo capaces de morir a medias en lugar de solo invertir ese tiempo y energía en lanzar más hardware / escalarlo.

Las posibilidades son lo que termina derribándote, tus sistemas de registro y salud habrán fallado de todos modos.

La forma más importante de monitorear cualquier sitio en línea es monitorear externamente. El objetivo debe ser monitorear su sitio de una manera que refleje más de cerca cómo sus usuarios usan el sitio. En el 99% de los casos, tan pronto como sepas que tu 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 usar un monitoreo de rendimiento externo Servicio. Ellos muy desde el extremo muy bajo (mon.itor.us, pingdom) a la gama alta (Webmetrics, Gomez, Keynote). Y como siempre, obtienes lo que pagas. Las cosas que debe buscar al buscar un servicio de monitoreo incluyen:

• El tamaño y la distribución de la red de vigilancia
• Si la solución de monitoreo es capaz de 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 script las transacciones contra su sitio)
• El departamento de soporte, para ayudarlo en el camino y brindarle experiencia sobre cómo monitorear correctamente

¡Buena suerte!

Web monitoring by IP Patrolor SiteSentry have been useful for us. El segundo es un poco como el sitio de confianza, pero un poco más bonito jajaja.

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

Aparte de lo que debe monitorear, que ya ha sido contestado, debe asegurarse, sea cual sea el sistema que use, de que solo recibe 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 simplemente molesto...

Divida los turnos de espera entre el equipo de soporte/desarrollo, para que una persona no tenga que estar de guardia cada noche. Eso desgastará a la gente. El monitoreo es una buena cosa, pero todos necesita tener la oportunidad de tener una vida de vez en cuando. Su teléfono celular zumbando a las 2 AM durante unas noches se volverá muy viejo muy pronto, confía en mí. Y no todos los desarrolladores están acostumbrados al soporte 24/7, por lo que debe encontrar el equilibrio entre el uso de monitoreo y el abuso de monitoreo.

Básicamente, tener distintos niveles de escalada, y si el cielo no está cayendo, definir una " serenidad ahora" ventana en la noche donde los niveles de escalada más pequeños no salen.

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 procedieran a través de un formulario de suscripción en línea.

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

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

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 es un poco anticuado y usted tiene que tener un demonio que se ejecuta en cada servidor que está siendo monitoreado. Zenoss tiene una interfaz de usuario mucho más agradable que incluye gráficos de tendencias del uso de recursos, pero usa SNMP, por lo que debe tener cierta familiaridad con eso para que funcione correctamente, y la documentación no es la mejor - hay cientos de páginas, pero es muy difícil encontrar la información que necesita para empezar.

Mis amigos también han recomendado Cactus y Hyperic, pero no tengo experiencia personal con ellos.

Una última cosa - una de las otras respuestas sugirió ejecutar una herramienta que estresa su sitio. No recomendaría hacer eso en su sitio en vivo a menos que tenga un período de silencio confiable cuando nadie lo está golpeando; incluso entonces podría derribarlo inesperadamente. Mucho mejor tener un servidor de ensayo donde pueda ejecutar pruebas de carga antes de poner los cambios en producción.

Es bueno tal vez tener pruebas de sistema (Selenio) funcionando regularmente.

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

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

No hay cargo por alertas, no importa qué tipo o cuántas, y ofrecen alertas de correo electrónico, correo de voz y SMS -- y si sucede algo importante, una llamada telefónica de una persona en vivo para ayudarlo.

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

Solo agregaría que puede predecir la probabilidad de error de alguna manera en función del historial de errores pasados y haberlos corregido. Con pruebas internas de menor escala si tuviera que graficar la frecuencia y gravedad de los problemas que se han corregido hasta este punto, tendrá una visión general de los nuevos problemas predecibles. Si todo se ha estado ejecutando 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 suena como 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 arreglaron el último error y no hay más. Hasta que lo haya.

Cambiando un poco la línea, algo que realmente creo que es útil y cambió mucho la forma en que monitoreo mis aplicaciones es registrar excepciones de javascript en algún lugar. Hay una implementación muy buena que registra eso directamente desde los navegadores de los usuarios a Google Analytics. Esto es una necesidad para aplicaciones web centradas en Javascript, y puede darle resultados basados directamente en los navegadores de los usuarios lo que puede conducir a errores muy inesperados (iE y navegador móvil son dolor)

Descargo de responsabilidad: Mi mensaje abajo

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

Para el monitoreo de presencia en Internet, sugeriría el servicio en el que estoy trabajando: Sucuri NBIM (Network-based integrity monitor).

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