Domanda

Introduzione: Vogliamo estendere il monitoraggio di uno dei nostri negozi online come il fornitore aveva problemi con la configurazione di PHP e le parti del negozio online dal vivo si è schiantato (back-end e cassa non funziona). Io non voglio discutere di trasferirsi in un altro provider qui.

Come stiamo ora pensando di possibilità per monitorare l'webshop stesso e la disponibilità di alcune parti (come "? È la lavorazione cassa"), la domanda è:

Quali sono gli strumenti e le strategie cosa suggerisce di monitorare un sito web dal vivo?

Alcune idee:

  • si fa a controllare automaticamente, se la cassa sta ancora lavorando su un sito web dal vivo?
  • Che cosa può essere buoni parametri per il monitoraggio per rilevare fallimento? Last Order <1 giorno fa, ultimo accesso utente, ...
  • Utilizzo cron jobs:? Controllo ad esempio per l'ultimo ordine di data / ora e se è troppo tempo fa, inviare una e-mail e / o controllare manualmente se la cassa funziona ancora
  • Utilizzo di software / strumenti come Icinga, Uptime Robot, ...
  • L'invio di avviso e-mail a amministratori, ...

In attesa di vostre risposte:)

È stato utile?

Soluzione

Ci sono un paio di cose che si potevano fare automatizzati.

  1. Se le parti del negozio di arresto di lavoro sono un bel modo di rilevare se alcune funzionalità sono ancora lavorando.
  2. Per test di frontend che uso phpQuery su un server remoto per cercare periodicamente la presenza di alcuni elementi DOM su alcune pagine chiave come 'ci sono ancora i prodotti nella lista categoria', 'c'è un piè di pagina * sulla home page', etc
  3. Imposta un semplice cronjob che i ping vostro ospitanti per vedere se è ancora disponibile
  4. .
  5. Utilizza il nativo Magento fine di feed RSS per verificare se gli ordini sono ancora ritornassi in On negozi ad alto traffico senza un ordine per un'ora il venerdì sera è un buon indicatore che ci sia qualcosa che non va:)
  6. Monitorare il Payment Service Provider. Nei Paesi Bassi si usa l'ideale per la gestione dei pagamenti. Questo sito mostra il loro tempo di attività, la PSP potrebbe fornire un servizio simile

* se non c'è piè di pagina su una pagina che potrebbe puntare a un rendering errore di PHP arresto.

Questi sono un paio di soluzioni che stiamo usando. Hanno solo bisogno di un po 'di tempo di configurazione e sono liberi di correre.

Grande questione tra l'altro, non vedo l'ora di tutte le risposte!

Altri suggerimenti

io a coda di rondine sulla risposta fantastica di Sander la seguente, che presuppone che si sia di impostare e utilizzare un servizio di monitoraggio come Pingdom *:

  • Orologio per i contenuti della pagina; di solito il tag di chiusura </html>. Ho visto tanti script before_body_end falliscono con 3 parti (Le eccezioni non rilevate, etc.) che sono invisibili agli utenti finali, ma restituire 500 stato - molto male per SEO / Google / Strumenti per i Webmaster
  • Imposta fino Webmaster Tools per notificare quando gli errori sono in aumento al di sopra di una certa soglia
  • Imposta avvisi per SSL invalidato nella pagina
  • Imposta avvisi per gli errori JavaScript sulla pagina
  • Utilizzare i gruppi e-mail / BCC per pagamenti email falliti, le segnalazioni di errori.
  • Entra in stretto con il vostro call center persone e assicurarsi che essi sanno come problemi Screen Shot -. Sono di solito il primo a sottolineare quando le cose vanno male
  • Un sito lento è così male come un sito verso il basso. Assicurarsi che gli avvisi sono sensibili da quando il sito sta prendendo più tempo per il carico del solito.
  • Sottoscrivi feed di Twitter per tutti i principali servizi di terze parti / ospitati. padroni di casa più grandi di solito hanno Twitter trigger per quando ci sono problemi. È possibile configurare Twitter per email / testo che quando alcuni conti pubblichi.

Devops:

  • Set up Nagios per il monitoraggio dei sistemi critici e l'invio di avvisi
  • Imposta uno syslog o Splunk (gratis fino a un certo # di query / giorno) per i registri e emettere avvisi aggregati sulla base di dati di log
  • Configura un script, controllo di routine delle apparecchiature di rete. Ho visto (in più di un'occasione) NIC tornare indietro e cadono da 1 GB a 10 MB a nostra insaputa.

Per i team più grandi:

  • configurare un server CI (Travis, Jenkins / Hudson, Capistrano) per avvisare l'utente di eventuali prove di fallimento dopo il commit.
  • Set up pre-commit ganci nel controllo del codice sorgente per far rispettare le norme del codice o per verificare la presenza di problemi palesi come codice rotto
  • Come Sander ha detto, istituito qualcosa di monitorare i feed RSS per gli ordini e il volume per ora del giorno - un vantaggio è che è memorizzata nella cache e in genere se si imposta abbastanza bassa soglia di notifica di un potenziale problema scatterà questo immediatamente
  • Usa Selenio. UN SACCO. Avere test script che corrono attraverso il processo di checkout ogni ora o due.
  • Imposta promemoria del calendario e avvisi specifici per la scadenza SSL

Hai intenzione di generare un sacco di dati e potenzialmente falsi positivi; non diventare immuni agli avvisi.


Non sto affiliato con Pingdom. Adoro il loro prodotto (gratuito).

If you only have problems with your hoster and not the payment, you can think about setting up a product, which is hidden, write a selenium-test put it in the cart add a coupon to make it free and then step through the checkout.

There are already some great answers here, depending on your setup. I use NewRelic to monitor server and transaction stats, as well as setting up key transactions for every step of the checkout process. That way, I can look at a single screen on my phone and determine if we are still getting the appropriate amount of people checking out through the whole process, and if they are getting appropriate response times. If I see a bunch of throughput on everything up to the last step, I know that PayPal is probably broken as nobody is able to process their cards. I also get alerts if there are a lot of errors, response times are off, etc.. You don't strictly need NewRelic to do this, but it is very simple and quick to set up and I didn't have time to build my own dashboard/app/alerting system.

I like NewRelic and PagerDuty for this, they are simply perfect and notifies you (email, text and call) in a minute if your site or any part of your site is down. It even notifies if your CPU or Memory goes beyond the specified percentage of use making site unresponsive.

  • Setup New Relic with all the pages you want to monitor and monitoring frequency. Example: Homepage, any 1 category page, any 1 product page, cart page, checkout page, etc.
  • Add users (who all gets notifications), schedules (day and time you prefer to receive notifications), services (New Relic alerts) and escalation policies on PagerDuty alerts and types of notifications you want (email, text, call)

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

Disclaimer: I am not affiliated with any of the above services.

MageMonitoring - https://github.com/magento-hackathon/Hackathon_MageMonitoring Great free open source tool which track server and Magento health, send emails with exceptions and system logs etc.

  • Munin on provider side to get historical values for all servers (LB, App, DB, Redis, etc) and all services (memory, load, io etc.)
  • Nagios/Icinga on on provider or local side for near live monitoring load on all servers
  • Pingdom to collect response time for "important" urls like front page, checkout etc.
  • Pingdom for real user monitoring, you get a value similar to APDEX and see the historical development
  • Pingdom to check urls and their correct content
  • Reporting with last X orders in auto reload mode. With it I can see possible breaks
  • Automated tests with Selenium on a identical stage system. I am not a friend of automated checkouts on my live system. You will get problems with your accounting later:)
  • Zapier and Twilio for Email2SMS. Critical errors are sent as SMS to a phone
  • freeboard.io and dweet.io to display everything on a nice dashboard.
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a magento.stackexchange
scroll top