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

magento.stackexchange https://magento.stackexchange.com/questions/7648

  •  16-10-2019
  •  | 
  •  

Question

Avant-propos: Nous voulons étendre la surveillance de l'un de nos boutiques en ligne comme le fournisseur avait des problèmes avec la configuration PHP et des parties de la boutique en ligne en direct tombé en panne (back-end et la caisse ne fonctionne pas). Je ne veux pas discuter de passer à un autre fournisseur ici.

Comme nous réfléchissons maintenant sur les possibilités de suivre la boutique en ligne lui-même et la disponibilité de certaines pièces (comme « ? Le travail de la caisse »), la question est:

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

Quelques idées:

  • Vérifiez-vous automatiquement, si la caisse travaille toujours sur un site Web en direct?
  • Que peut-être de bons paramètres pour surveiller pour détecter l'échec? Last Order <1 jour, dernière connexion utilisateur, ...
  • Utilisation de tâches cron: Vérification par exemple pour la dernière date / heure de la commande et si elle est trop longtemps, envoyez un e-mail et / ou vérifier manuellement si la caisse fonctionne toujours
  • Utilisation de logiciels / outils tels que Nagios, Uptime Robot, ...
  • L'envoi d'avertissement E-Mails à Admins, ...

Dans l'attente de vos réponses:)

Était-ce utile?

La solution

Il y a quelques choses que vous pourriez faire automatisés.

  1. Si certaines parties de l'arrêt de travail boutique tests unitaires sont un moyen agréable de détecter si certaines fonctionnalités sont encore travailler.
  2. Pour tester frontend J'utilise phpQuery sur un serveur distant pour rechercher périodiquement pour certains éléments DOM sur certaines pages clés comme « sont là encore des produits sur la liste des catégories », « est là un pied de page * sur la page d'accueil », etc
  3. Mise en place d'une simple tâche cron qui pings votre hôte pour voir si elle est encore disponible
    4. .
  4. Utilisez le natif pour Magento flux RSS pour vérifier si les commandes arrivantes encore sur les magasins achalandés sans ordre pendant une heure un vendredi soir est un bon indicateur qu'il ya quelque chose de mal:)
  5. Surveillez votre fournisseur de services de paiement. Aux Pays-Bas, nous utilisons pour les paiements de manutention iDeal. Ce site s affiche son temps de disponibilité, votre PSP pourrait fournir un service similaire

* s'il n'y a pas de bas de page sur une page qui pourrait pointer vers une erreur de PHP arrêt rendu.

Ce sont quelques solutions que nous utilisons. Ils ont besoin d'un peu de temps d'installation et sont libres de courir.

Grande question par ailleurs, je suis vraiment heureux de toutes les réponses!

Autres conseils

Je concordera sur réponse fantastique de Sander ce qui suit, que vous avez mis en place suppose et d'utiliser un service de surveillance comme Pingdom *:

  • Surveillez le contenu de la page; généralement la balise </html> de fermeture. Je l'ai vu tant de scripts before_body_end échouent avec 3e parties (exceptions non rattrapées, etc.) qui sont invisibles pour les utilisateurs finaux, mais retour 500 état - très mauvais pour le référencement / Google / Webmaster Tools
  • Configurer Webmaster Tools pour vous avertir lorsque des erreurs augmentent au-dessus d'un certain seuil
  • Configurer des alertes pour SSL invalidée sur la page
  • Configurer des alertes pour des erreurs javascript sur la page
  • Utiliser des groupes de messagerie / Cci pour paiement des e-mails échoué, les rapports d'erreur.
  • Get très serré avec votre peuple de centre d'appels et assurez-vous qu'ils savent comment les problèmes de capture d'écran; -. Ils sont généralement les premiers à remarquer quand les choses vont mal
  • Un site lent est aussi mauvais que d'un site vers le bas. Assurez-vous que vos alertes sont sensibles à quand votre site prend plus de temps à charge que d'habitude.
  • Abonnez-vous à Diffusions pour tous vos clés 3ème partie / services hébergés. hôtes ont généralement plus grands déclencheurs Twitter quand il y a des problèmes. Vous pouvez configurer Twitter Email / texte lorsque certains comptes postaux.

Devops:

  • Mise en place Nagios pour la surveillance des systèmes critiques et l'envoi d'alertes
  • Mettre en place un syslog ou Splunk (gratuit jusqu'à un certain nombre de requêtes / jour) aux journaux et total des alertes d'émission en fonction des données du journal
  • Configurer un script, contrôle de routine de votre équipement de réseau. Je l'ai vu (sur plus d'une fois) NPI revenir en arrière et baisse de 1 Go à 10 Mo pour nous unbeknownst.

Pour les grandes équipes:

  • Configurer un serveur CI (Travis, Jenkins / Hudson, Capistrano) pour vous avertir des tests ayant échoué potentiels après commits.
  • Mise en place de pre-commit crochets dans votre contrôle de code source pour appliquer les normes de code ou de vérifier les problèmes flagrants comme un code cassé
  • Comme Sander a dit, mis en place quelque chose à surveiller les flux RSS pour les commandes et le volume par heure de la journée - un avantage ici est que c'est uncached et généralement si vous définissez assez bas seuil de notification d'un problème potentiel se déclenche ce immédiatement
  • Utilisez Sélénium. BEAUCOUP. Des tests scriptés qui traversent le processus de commande toutes les heures ou deux.
  • Mettre en place des rappels de calendrier et alertes spécifiques pour l'expiration SSL

Vous allez générer beaucoup de données et positifs potentiellement faux; ne pas devenir insensible aux alertes.

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

Si vous n'avez des problèmes avec votre hébergeur, et non le paiement, vous pouvez penser à la création d'un produit, ce qui est caché, écrire un sélénium test mis dans le panier ajouter un coupon pour le rendre gratuit et ensuite passer la caisse.

Il y a déjà quelques bonnes réponses ici, en fonction de votre configuration. J'utilise NewRelic pour surveiller les statistiques du serveur et de transactions, ainsi que la mise en place des opérations clés pour chaque étape du processus de commande. De cette façon, je peux regarder un seul écran sur mon téléphone et déterminer si nous obtenons encore la quantité appropriée de personnes vérification par l'ensemble du processus, et si elles obtiennent des temps de réponse appropriés. Si je vois un tas de débit sur tout jusqu'à la dernière étape, je sais que PayPal est probablement cassé comme personne est capable de traiter leurs cartes. Je reçois aussi des alertes s'il y a beaucoup d'erreurs, les temps de réponse sont éteints, etc .. Vous n'êtes pas strictement besoin NewRelic de le faire, mais il est très simple et rapide à mettre en place et je n'avais pas le temps de construire mon propre tableau de bord / app / système d'alerte.

MageMonitoring - https://github.com/magento-hackathon/Hackathon_MageMonitoring Outil open source qui serveur de la piste et la santé Magento, envoyer des emails avec des exceptions et les journaux système, etc.

  • Munin sur le côté du fournisseur pour obtenir des valeurs historiques pour tous les serveurs (LB, App, DB, Redis, etc.) et tous les services (mémoire, charge, etc io.)
  • Nagios / Nagios sur le fournisseur ou le côté local pour la charge de la surveillance en direct près sur tous les serveurs
  • Pingdom temps de réponse Collect pour urls "importants" comme page d'accueil, caisse, etc.
  • Pingdom pour la surveillance de l'utilisateur réel, vous obtenez une valeur similaire à Apdex et voir le développement historique
  • Pingdom pour vérifier urls et leur contenu correct
  • rapports avec les dernières commandes de X en mode de recharge automatique. Avec elle, je peux voir des pauses possibles
  • Les tests automatisés avec Sélénium sur un système de scène identique. Je ne suis pas un ami de mon automatique checkouts système en direct. Vous obtiendrez plus tard des problèmes avec votre comptabilité:)
  • Zapier et Twilio pour Email2SMS. Les erreurs critiques sont envoyées par SMS à un téléphone
  • freeboard.io et dweet.io pour afficher tout sur un beau tableau de bord.
Licencié sous: CC-BY-SA avec attribution
Non affilié à magento.stackexchange
scroll top