¿Cuáles son buenas maneras de monitorear una tienda en vivo?


41

Prefacio: Queremos extender el monitoreo de una de nuestras tiendas en línea ya que el proveedor tuvo problemas con la configuración de PHP y partes de la tienda virtual en vivo se bloquearon (el backend y el pago no funcionaban). No quiero hablar sobre mudarse a otro proveedor aquí.

Como ahora estamos pensando en las posibilidades de monitorear la tienda en línea y la disponibilidad de ciertas partes (como "¿Funciona el pago?"), La pregunta es:

¿Qué herramientas y estrategias sugiere para monitorear un sitio web en vivo?

Algunas ideas:

  • ¿Comprueba automáticamente si el pago sigue funcionando en un sitio web en vivo?
  • ¿Cuáles pueden ser buenos parámetros para monitorear para detectar fallas? Último pedido <hace 1 día, último inicio de sesión de usuario, ...
  • Uso de trabajos cron: Verificación, por ejemplo, de la fecha / hora del último pedido y, si fue hace mucho tiempo, ¿enviar un correo electrónico y / o verificar manualmente si el pago aún funciona?
  • Utilizando software / herramientas como Icinga, Uptime Robot, ...
  • Enviando correos electrónicos de advertencia a administradores, ...

Mirando hacia adelante a sus respuestas :)


1
Incluso si esto parece un poco "basado en la opinión", estoy realmente ansioso por ver algunas respuestas :).
Marius

Gracias @Marius, sé que es algo subjetivo, pero podría ser interesante compartir de todos modos :)
Anna Völkl

Gran pregunta, ¡me he estado preguntando lo mismo! ¡Gracias!
Wessel

Respuestas:


30

Hay un par de cosas que puedes hacer de forma automatizada.

  1. Si partes del taller dejan de funcionar , las pruebas unitarias son una buena manera de detectar si ciertas funcionalidades siguen funcionando.
  2. Para probar frontend, uso phpQuery en un servidor remoto para buscar periódicamente ciertos elementos DOM en ciertas páginas clave como '¿todavía hay productos en la lista de categorías', 'hay un pie de página * en la página de inicio', etc.
  3. Configure un cronjob simple que haga sonar su host para ver si todavía está disponible
  4. Utilice la fuente RSS de pedidos nativa de Magento para verificar si los pedidos siguen llegando. En las tiendas de alto tráfico, ningún pedido durante una hora los viernes por la noche es un buen indicador de que hay algo mal :)
  5. Controle a su proveedor de servicios de pago. En los Países Bajos utilizamos iDeal para gestionar pagos. Este sitio web muestra su tiempo de actividad, su PSP podría proporcionar un servicio similar

* si no hay un pie de página en una página que pueda apuntar a un error de PHP que detiene la representación.

Estas son un par de soluciones que estamos usando. Solo necesitan un tiempo de configuración y son libres de ejecutarse.

Gran pregunta por cierto, ¡realmente estoy esperando todas las respuestas!


25

Voy a encajar en la fantástica respuesta de Sander, la siguiente, que asume que has configurado y usado un servicio de monitoreo como Pingdom *:

  • Mire el contenido en la página; generalmente la </html>etiqueta de cierre . He visto que muchos before_body_endscripts fallan con terceros (excepciones no detectadas, etc.) que son invisibles para los usuarios finales pero devuelven el estado 500, muy malo para SEO / Google / Herramientas para webmasters
  • Configure las Herramientas para webmasters de Google para que le notifiquen cuando los errores aumentan por encima de cierto umbral
  • Configure alertas para SSL invalidado en la página
  • Configurar alertas para errores de JavaScript en la página
  • Use grupos de correo electrónico / bcc para correos electrónicos con pagos fallidos, informes de errores.
  • Póngase en contacto con las personas de su centro de atención telefónica y asegúrese de que sepan cómo solucionar problemas de captura de pantalla: generalmente son los primeros en señalar cuándo las cosas van mal.
  • Un sitio lento es tan malo como un sitio inactivo. Asegúrese de que sus alertas sean sensibles en cuanto a cuándo su sitio tarda más en cargarse de lo habitual.
  • Suscríbase a las fuentes de Twitter para todos sus servicios clave de terceros / alojados. Los hosts más grandes generalmente tienen desencadenantes de Twitter para cuando hay problemas. Puede configurar Twitter para enviarle un correo electrónico / mensaje de texto cuando se publiquen ciertas cuentas.

Devops:

  • Configure Nagios para monitorear sistemas críticos y enviar alertas
  • Configure un syslog o Splunk (libere hasta cierto número de consultas / día) para agregar registros y emitir alertas basadas en datos de registro
  • Configure una comprobación de rutina de su equipo de red con secuencia de comandos. He visto (en más de una ocasión) que las NIC retroceden y caen de 1GB a 10MB sin que lo sepamos.

Para equipos más grandes:

  • Configure un servidor CI (Travis, Jenkins / Hudson, Capistrano) para advertirle de posibles pruebas fallidas después de las confirmaciones.
  • Configure enganches de precompromiso en su control de origen para hacer cumplir los estándares del código o para verificar problemas evidentes como el código roto
  • Como dijo Sander, configure algo para monitorear las fuentes RSS de pedidos y volumen por hora del día: un beneficio aquí es que no se almacena en caché y, por lo general, si establece el umbral de notificación lo suficientemente bajo, un posible problema lo activará de inmediato
  • Utiliza selenio. MUCHO. Tenga pruebas escritas que se ejecuten a través del proceso de pago cada hora o dos.
  • Configure recordatorios de calendario y alertas específicas para el vencimiento de SSL

Vas a generar MUCHOS datos y potencialmente falsos positivos; no te vuelvas inmune a las alertas.


No estoy afiliado a Pingdom. Me encanta su producto (gratis).


8

Si solo tiene problemas con su proveedor de alojamiento y no con el pago, puede pensar en configurar un producto, que está oculto, escriba una prueba de selenio, colóquelo en el carrito, agregue un cupón para liberarlo y luego realice el pago.


1
bueno, me gusta la idea oculta de producto gratis :-)
Anna Völkl

5

Ya hay algunas respuestas excelentes aquí, dependiendo de su configuración. Utilizo NewRelic para monitorear el servidor y las estadísticas de transacciones, así como para configurar transacciones clave para cada paso del proceso de pago. De esa manera, puedo mirar una sola pantalla en mi teléfono y determinar si todavía estamos recibiendo la cantidad adecuada de personas que realizan la verificación durante todo el proceso y si están obteniendo los tiempos de respuesta adecuados. Si veo un montón de rendimiento en todo hasta el último paso, sé que PayPal probablemente esté roto ya que nadie puede procesar sus tarjetas. También recibo alertas si hay muchos errores, los tiempos de respuesta están desactivados, etc. No es estrictamente necesario que NewRelic haga esto, pero es muy simple y rápido de configurar y no tuve tiempo de construir mi propio tablero de instrumentos / aplicación / sistema de alerta.


1
Estoy de acuerdo con usted acerca de que NewRelic funciona a las mil maravillas. También agregaría que usar un servicio como Pingdom también es una buena opción para monitorear la accesibilidad del servidor.
Eirik

5

Me gusta NewRelic y PagerDuty para esto, son simplemente perfectos y le notifica (correo electrónico, mensaje de texto y llamada) en un minuto si su sitio o alguna parte de su sitio está caído. Incluso notifica si su CPU o memoria va más allá del porcentaje especificado de uso haciendo que el sitio no responda.

  • Configure New Relic con todas las páginas que desea monitorear y la frecuencia de monitoreo. Ejemplo: página de inicio, 1 página de categoría, 1 página de producto, página de carrito, página de pago, etc.
  • Agregue usuarios (que reciben notificaciones), horarios (día y hora que prefiere recibir notificaciones), servicios (alertas New Relic) y políticas de escalado en las alertas de PagerDuty y los tipos de notificaciones que desea (correo electrónico, mensaje de texto, llamada)

https://www.pagerduty.com/docs/guides/new-relic-integration-guide/

Descargo de responsabilidad: no estoy afiliado a ninguno de los servicios anteriores.



3
  • Munin del lado del proveedor para obtener valores históricos para todos los servidores (LB, App, DB, Redis, etc.) y todos los servicios (memoria, carga, io, etc.)
  • Nagios / Icinga en el proveedor o en el lado local para una carga de monitoreo casi en vivo en todos los servidores
  • Pingdom para recopilar el tiempo de respuesta para las URL "importantes" como la página principal, el pago y envío, etc.
  • Pingdom para monitoreo real de usuarios, obtienes un valor similar a APDEX y ves el desarrollo histórico
  • Pingdom para verificar las URL y su contenido correcto
  • Informes con los últimos pedidos X en modo de recarga automática. Con ella puedo ver posibles descansos
  • Pruebas automatizadas con selenio en un sistema de etapas idénticas. No soy amigo de los pagos automáticos en mi sistema en vivo. Tendrás problemas con tu contabilidad más tarde :)
  • Zapier y Twilio para Email2SMS. Los errores críticos se envían como SMS a un teléfono.
  • freeboard.io y dweet.io para mostrar todo en un buen tablero.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.