Які хороші способи моніторингу магазину в прямому ефірі?

Передмова: Ми хочемо розширити моніторинг одного з наших веб-магазинів, оскільки у постачальника виникли проблеми з конфігурацією PHP, а частини живого веб-магазину вийшли з ладу (бекенд і каси не працюють). Я не хочу тут обговорювати питання про переїзд до іншого постачальника.

Оскільки ми зараз думаємо про можливості стежити за самим веб-магазином та наявністю певних деталей (наприклад, "Чи працює каса?"), Питання:

Які інструменти та стратегії ви пропонуєте для моніторингу веб-сайту?

Деякі ідеї:

• Ви автоматично перевіряєте, чи замовлення все ще працює на веб-сайті?
• Які можуть бути хороші параметри для моніторингу для виявлення несправності? Останнє замовлення <1 день тому, останній вхід користувача, ...
• Використання завдань cron: Перевірка, наприклад, дати / часу останнього замовлення, і якщо це занадто давно, надіслати електронний лист та / або перевірити вручну, чи замовлення все ще працює?
• Використання програмного забезпечення / інструментів, таких як Icinga, Uptime Robot, ...
• Надсилання попереджувальних електронних листів адміністраторам, ...

Чекаю ваших відповідей :)

Є кілька речей, які ви могли б зробити автоматизованими.

1. Якщо частини магазину припиняють свою роботу, тести на модулі - це гарний спосіб виявити, чи певні функції все ще працюють.
2. Для тестування фронтену я використовую phpQuery на віддаленому сервері, щоб періодично шукати певні елементи DOM на певних ключових сторінках, наприклад "чи є ще продукти в списку категорій", "чи є колонтитул * на домашній сторінці" тощо.
3. Налаштуйте просту cronjob, яка надсилає ваш хост, щоб побачити, чи він ще доступний
4. Використовуйте рідну Magento за допомогою RSS-каналу, щоб перевірити, чи все ще надходять замовлення. У магазинах із великим трафіком жодне замовлення на годину у вечір п'ятниці - хороший показник того, що щось не так :)
5. Відстежуйте свого постачальника платіжних послуг. У Нідерландах ми використовуємо iDeal для обробки платежів. Цей веб-сайт відображає їх час роботи, ваш PSP може надавати аналогічну послугу

* якщо на сторінці немає колонтитулу, який міг би вказувати на помилку PHP, що зупиняє візуалізацію.

Це кілька рішень, які ми використовуємо. Їм просто потрібен певний час налаштування і вони вільні для запуску.

Велике запитання до речі, я дуже чекаю всіх відповідей!

Я розповім про фантастичну відповідь Сандера на наступне, що передбачає, що ви створили та використовуєте службу моніторингу, як Pingdom *:

• Слідкуйте за вмістом на сторінці; зазвичай закриваючий </html>тег. Я бачив, що стільки before_body_endсценаріїв не вдається зі сторонніми сторонами (невиконані винятки тощо), які невидимі для кінцевих користувачів, але повертають 500 статусів - дуже погано для SEO / Google / Інструментів для веб-майстрів
• Налаштуйте інструменти для веб-майстрів, щоб повідомляти вас, коли помилки зростають понад певний поріг
• Налаштуйте сповіщення про недійсний SSL на сторінці
• Налаштуйте сповіщення про помилки javascript на сторінці
• Використовуйте групи електронної пошти / bcc для невдалої оплати електронних листів, повідомлень про помилки.
• Будьте тісні з людьми свого кол-центру та переконайтеся, що вони знають, як перевірити проблеми з знімком - вони зазвичай першими вказують, коли все йде не так.
• Повільний сайт такий же поганий, як і спадний сайт. Переконайтеся, що ваші сповіщення чутливі до того, коли ваш сайт завантажує більше часу, ніж зазвичай.
• Підпишіться на канали Twitter для всіх своїх ключових третіх сторін / розміщених послуг. Більші хости зазвичай мають тригери Twitter, коли виникають проблеми. Ви можете налаштувати Twitter, щоб він надсилав / надсилав повідомлення електронною поштою, коли певні облікові записи публікують.

Зберігає:

• Налаштуйте Nagios для моніторингу критичних систем та надсилання сповіщень
• Налаштуйте syslog або Splunk (безкоштовно до певного числа запитів / день) для агрегації журналів та видачі сповіщень на основі даних журналу
• Налаштуйте сценарій рутинної перевірки мережевого обладнання. Я бачив (не один раз), що NIC повертаються назад і знижуються з 1 ГБ до 10 Мб невідомо для нас.

Для більших команд:

• Налаштуйте CI-сервер (Travis, Jenkins / Hudson, Capistrano), щоб попередити вас про можливі невдалі тести після вчинення.
• Налаштуйте гачки попереднього введення у своєму джерелі управління, щоб застосувати стандарти коду або перевірити наявність кричущих проблем, таких як зламаний код
• Як сказав Сандер, налаштовуйте щось для моніторингу RSS-каналів для замовлень та обсягу за часом доби - перевага тут у тому, що це кеш-пам'ять, і, як правило, якщо встановити достатньо низький поріг сповіщень, це може негайно усунути цю проблему.
• Використовуйте селен. БАГАТО. Проведіть сценарії тестів, які проходять процедуру оформлення замовлення кожні годину чи дві.
• Налаштуйте нагадування календаря та конкретні сповіщення про закінчення терміну дії SSL

Ви збираєтесь багато даних та потенційно помилкових позитивних результатів; не сприймайте сповіщення.

Я не пов'язаний з Pingdom. Я просто люблю їх (безкоштовний) продукт.

Якщо у вас є лише проблеми з хостером, а не оплата, ви можете подумати про те, як налаштувати товар, який є прихованим, напишіть тест на селен, покладіть його в кошик, додайте купон, щоб зробити його безкоштовним, а потім перейдіть через касу.

Тут вже є кілька чудових відповідей, залежно від налаштувань. Я використовую NewRelic для моніторингу статистики сервера та транзакцій, а також для налаштування ключових транзакцій для кожного кроку процесу оформлення замовлення. Таким чином, я можу переглянути один екран свого телефону і визначити, чи все-таки ми отримуємо відповідну кількість людей, які перевіряють весь процес, і чи отримують вони відповідні часи відповіді. Якщо я бачу купу пропускної здатності на всьому до останнього кроку, я знаю, що PayPal, ймовірно, зламаний, оскільки ніхто не може обробити їхні карти. Я також отримую сповіщення, якщо багато помилок, час відгуку вимкнено і т. Д. Вам не потрібно строго NewRelic для цього, але це дуже просто і швидко налаштувати, і я не встиг побудувати моя власна приладова панель / додаток / система оповіщення.

Мені подобаються NewRelic і PagerDuty за це, вони просто ідеальні і повідомляють вас (електронною поштою, текстовими повідомленнями та дзвінками) за хвилину, якщо ваш веб-сайт або будь-яка частина вашого веб-сайту не працює. Він навіть повідомляє, якщо ваш процесор чи пам'ять перевищує вказаний відсоток використання, роблячи сайт невідповідним.

• Налаштуйте New Relic з усіма сторінками, які потрібно відстежувати, та частотою моніторингу. Приклад: Домашня сторінка, будь-яка сторінка 1 категорії, будь-яка 1 сторінка товару, сторінка кошика, сторінка оформлення замовлення тощо.
• Додайте користувачів (які отримують сповіщення), графіки (день та час, коли ви бажаєте отримувати сповіщення), послуги (сповіщення про нову реліквію) та політику ескалації на сповіщення PagerDuty та типи сповіщень, які ви хочете (електронна пошта, текст, дзвінок)

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

Відмова: Я не пов'язаний ні з одним із перерахованих вище служб.

MageMonitoring - https://github.com/magento-hackathon/Hackathon_MageMonitoring Чудовий безкоштовний інструмент з відкритим кодом, який відстежує здоров'я сервера та Magento, надсилає електронні листи з винятками та системні журнали тощо.

• Munin на стороні постачальника, щоб отримати історичні значення для всіх серверів (LB, App, DB, Redis тощо) та всіх служб (пам'ять, завантаження, io тощо)
• Nagios / Icinga у постачальника або на місцевій стороні для майже навантаженого моніторингу завантаження на всіх серверах
• Pingdom для збору часу відгуку для "важливих" URL-адрес, таких як головна сторінка, замовлення тощо.
• Pingdom для реального моніторингу користувачів, ви отримуєте значення, подібне до APDEX, і бачите історичну розробку
• Pingdom для перевірки URL-адрес та їх правильного вмісту
• Звітування з останніми X замовленнями в режимі автоматичного перезавантаження. З ним я бачу можливі перерви
• Автоматизовані тести із селеном на ідентичній сценічній системі. Я не є другом автоматизованих кас в моїй живій системі. Ви отримаєте проблеми зі своїм бухгалтерським обліком пізніше :)
• Zapier і Twilio для Email2SMS. Критичні помилки надсилаються як SMS на телефон
• freeboard.io та dweet.io для відображення всього на приємній інформаційній панелі.