Quels sont les bons moyens de surveiller un magasin en direct?

Préface: Nous souhaitons étendre la surveillance de l’une de nos boutiques en ligne, car le fournisseur avait des problèmes avec la configuration de PHP et certaines parties de la boutique en ligne se sont effondrées (l’arrière-plan et le paiement ne fonctionnent pas). Je ne veux pas discuter de changer de fournisseur ici.

Alors que nous réfléchissons maintenant aux possibilités de surveiller la boutique en ligne elle-même et à la disponibilité de certaines parties (comme "La commande fonctionne-t-elle?"), La question est la suivante:

Quels outils et stratégies proposez-vous pour surveiller un site Web en direct?

Quelques idées:

• Vérifiez-vous automatiquement si le paiement fonctionne toujours sur un site Web actif?
• Quels peuvent être les bons paramètres à surveiller pour détecter une défaillance? Dernière commande <Il y a 1 jour, dernière connexion de l'utilisateur, ...
• Utilisation de tâches cron: Vérifier, par exemple, la date / heure de la dernière commande et s’il s’agit d’une date trop ancienne, envoyer un courrier électronique et / ou vérifier manuellement si la commande fonctionne toujours?
• Utilisation de logiciels / outils comme Icinga, Uptime Robot, ...
• Envoi de courriels d'avertissement aux administrateurs, ...

Dans l'attente de vos réponses :)

Vous pouvez automatiser certaines choses.

1. Si certaines parties de l’atelier cessent de fonctionner, les tests unitaires sont un bon moyen de détecter si certaines fonctionnalités fonctionnent toujours.
2. Pour tester l'interface j'utilise phpQuery sur un serveur distant pour rechercher périodiquement certains éléments DOM sur certaines pages clés, telles que "existe-t-il encore des produits dans la liste des catégories", "existe-t-il un pied de page * sur la page d'accueil", etc.
3. Configurez un cronjob simple qui envoie une requête ping à votre hôte pour voir s'il est toujours disponible.
4. Utilisez le flux RSS des commandes natif de Magento pour vérifier si les commandes arrivent toujours. Dans les magasins à forte fréquentation, aucune commande d'une heure le vendredi soir est un bon indicateur qu'il y a quelque chose qui ne va pas :)
5. Surveillez votre fournisseur de services de paiement. Aux Pays-Bas, nous utilisons iDeal pour le traitement des paiements. Ce site Web affiche leur temps de disponibilité, votre PSP pourrait fournir un service similaire

* s'il n'y a pas de pied de page sur une page qui pourrait indiquer une erreur PHP lors de l'arrêt du rendu.

Ce sont quelques solutions que nous utilisons. Ils ont juste besoin d'un peu de temps d'installation et sont libres de s'exécuter.

Excellente question au fait, j'attends toutes les réponses avec impatience!

Je vais faire écho à la réponse fantastique de Sander, qui suppose que vous avez mis en place et utilisez un service de surveillance tel que Pingdom *:

• Surveillez le contenu de la page. généralement la </html>balise de fermeture . J'ai vu tant de before_body_endscripts échouer avec des tiers (exceptions non appréhendées, etc.) qui sont invisibles pour les utilisateurs finaux mais qui renvoient un statut 500, ce qui est très mauvais pour les outils de référencement et de webmaster.
• Configurez les Outils pour les webmasters pour vous avertir lorsque les erreurs dépassent un certain seuil
• Configurer des alertes pour SSL invalidé sur la page
• Configurer des alertes pour les erreurs javascript sur la page
• Utiliser des groupes de messagerie / Cci pour les courriels avec échec de paiement, les rapports d’erreur.
• Renseignez-vous avec les responsables de votre centre d'appels et assurez-vous qu'ils savent comment résoudre les problèmes de prises de vues - ils sont généralement les premiers à signaler les problèmes.
• Un site lent est aussi mauvais qu'un site en panne. Assurez-vous que vos alertes sont sensibles au moment où le chargement de votre site prend plus de temps que d'habitude.
• Abonnez-vous aux flux Twitter pour tous vos services tiers / hébergés clés. Les grands hôtes ont généralement des déclencheurs Twitter lorsqu'il y a des problèmes. Vous pouvez configurer Twitter pour qu'il vous envoie un e-mail / texte lorsque certains comptes sont postés.

Devops:

• Configurer Nagios pour surveiller les systèmes critiques et envoyer des alertes
• Configurez un journal système ou Splunk (libérez jusqu'à un certain nombre de requêtes / jour) pour agréger les journaux et émettre des alertes en fonction de leurs données.
• Configurez une vérification de routine scriptée de votre équipement réseau. J'ai vu (à plus d'une occasion) des cartes réseau revenir en arrière et passer de 1 Go à 10 Mo à notre insu.

Pour les grandes équipes:

• Configurez un serveur de CI (Travis, Jenkins / Hudson, Capistrano) pour vous avertir de l’échec des tests après les validations.
• Configurez des points d'ancrage de pré-validation dans votre contrôle de code source pour appliquer les normes de code ou vérifier les problèmes flagrants tels que le code défectueux.
• Comme Sander l'a dit, configurez quelque chose pour surveiller les flux RSS des commandes et du volume par heure de la journée. L'avantage ici est qu'elle n'est pas mise en cache. Généralement, si vous définissez un seuil de notification suffisamment bas, un problème potentiel entraînera immédiatement un problème.
• Utilisez le sélénium. BEAUCOUP. Ayez des tests scriptés qui passent par le processus de paiement toutes les heures ou toutes les deux heures.
• Configurer des rappels de calendrier et des alertes spécifiques pour l'expiration de SSL

Vous allez générer beaucoup de données et potentiellement de faux positifs; ne devenez pas immunisé contre les alertes.

Je ne suis pas affilié à Pingdom. J'adore leur produit (gratuit).

Si vous ne rencontrez que des problèmes avec votre hébergeur et non avec le paiement, vous pouvez envisager de créer un produit qui est caché, écrivez un test au sélénium, mettez-le dans le panier, ajoutez un coupon pour le rendre gratuit, puis passez à la caisse.

Il existe déjà d'excellentes réponses ici, en fonction de votre configuration. J'utilise NewRelic pour surveiller les statistiques de serveur et de transaction, ainsi que pour configurer des transactions clés pour chaque étape du processus de paiement. De cette façon, je peux regarder un seul écran sur mon téléphone et déterminer si nous obtenons toujours le nombre approprié de personnes tout au long du processus et si elles obtiennent des temps de réponse appropriés. Si je constate un flux de production important jusqu'à la dernière étape, je sais que PayPal est probablement en panne, car personne ne peut traiter leurs cartes. Je reçois également des alertes s'il y a beaucoup d'erreurs, les temps de réponse sont décalés, etc. Vous n'avez pas strictement besoin de NewRelic pour le faire, mais c'est très simple et rapide à configurer et je n'ai pas eu le temps de le construire mon propre tableau de bord / application / système d'alerte.

J'aime NewRelic et PagerDuty pour cela, ils sont tout simplement parfaits et vous avertit (e-mail, SMS et appel) en une minute si votre site ou une partie de votre site est en panne. Il indique même si votre processeur ou votre mémoire dépasse le pourcentage d'utilisation spécifié, ce qui empêche le site de répondre.

• Configurez New Relic avec toutes les pages que vous souhaitez surveiller et surveillez la fréquence. Exemple: page d'accueil, une page de catégorie, une page de produit, une page de panier, une page de paiement, etc.
• Ajoutez des utilisateurs (qui reçoivent tous des notifications), des horaires (le jour et l'heure que vous préférez recevoir des notifications), des services (alertes New Relic) et des règles d'escalade progressive des alertes PagerDuty et des types de notifications souhaités (email, texte, appel)

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

Déni de responsabilité: Je ne suis affilié à aucun des services ci-dessus.

MageMonitoring - https://github.com/magento-hackathon/Hackathon_MageMonitoring Grand outil open source gratuit permettant de suivre l'état du serveur et de la santé de Magento, d'envoyer des e-mails avec des exceptions et des journaux système, etc.

• Munin du côté du fournisseur pour obtenir les valeurs historiques de tous les serveurs (LB, App, DB, Redis, etc.) et de tous les services (mémoire, charge, io, etc.)
• Nagios / Icinga on côté fournisseur ou local pour une charge de surveillance quasi-directe sur tous les serveurs
• Pingdom pour collecter le temps de réponse pour les URL "importantes" comme la page d'accueil, le paiement, etc.
• Pingdom pour un contrôle réel des utilisateurs, vous obtenez une valeur similaire à APDEX et vous visualisez l’évolution historique.
• Pingdom pour vérifier les URL et leur contenu correct
• Reporting avec les X dernières commandes en mode de rechargement automatique. Avec ça je peux voir les pauses possibles
• Tests automatisés avec Selenium sur un système de scène identique. Je ne suis pas un ami des caisses automatiques sur mon système en direct. Vous aurez des problèmes avec votre comptabilité plus tard :)
• Zapier et Twilio pour Email2SMS. Les erreurs critiques sont envoyées sous forme de SMS à un téléphone
• freeboard.io et dweet.io pour tout afficher sur un joli tableau de bord.