Мониторинг сайтов и сервисов: как узнать о проблеме до её появления, чтобы защитить бизнес клиента?

Меня зовут Сергей Никитченко, я — технический директор SVK.Digital (Студии Валерия Комягина). Мы создаем цифровые решения для бизнеса и оказываем услуги digital-консалтинга. В этой статье я расскажу о важном этапе работы с клиентом — поддержке работоспособности его сайта и сервиса.

Клиенты ценят надежных партнеров по разработке и развитию сайтов и сервисов. Руководителям компаний важно знать, что цифровой продукт работает как часы. Тогда люди могут сконцентрироваться на главном — развивать бизнес и стремиться к своей мечте.

Мало сделать хороший сайт или сервис — важно гарантировать его стабильную работу и быстро реагировать на аномалии.

Приведу реальный пример.

У нас есть постоянный клиент, связанный с одним из крупнейших предприятий страны. Однажды ночью наша система сообщила, что сайт заказчика упал. Мы узнали о проблеме раньше клиента. Попытались связаться с ним — не получилось. Взяли на себя ответственность и провели анализ проблемы.

Мы нашли причину и восстановили работу ресурса совместно с техподдержкой хостинга сайта. К утру, когда клиент вышел на связь, сайт работал в полном режиме. Если бы мы не отреагировали ночью, то к началу периода основной посещаемости ресурс был бы недоступен.

Хорошо, что мы всегда держим всё под контролем.

Но как?

Если время от времени проверять, работает ли сервис, можно слишком поздно обнаружить проблему. Важно узнать о проблеме ДО того, как сервис упадет.

Есть несколько зон, которые нужно мониторить, чтобы контролировать работоспособность сервиса.

Сервис работает не сам по себе, а на конкретном «железе». Чаще всего работу сервиса обеспечивает не один сервер, а сразу несколько: например, база данных и ее реплики вынесены на отдельные машины. На каждом из этих серверов крутится большое количество программного обеспечения (веб-серверы, СУБД и т.д.).

При нарушении работы любого ПО начнутся проблемы с доступностью сервиса. Хорошо, что существует огромное число инструментов, позволяющих мониторить серверы. Одно из популярных решений — Zabbix, которым пользуемся и мы.

Zabbix — свободная система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования. Для хранения данных используется MySQL, PostgreSQL, SQLite или Oracle Database, веб-интерфейс написан на PHP.

Система Zabbix свободна и бесплатна. А главное, она позволяет мониторить всё, что нам необходимо!

Zabbix дает возможность добавить шаблоны к каждому узлу (серверу).

Шаблоны указывают системе:

После установки Zabbix становятся доступны многочисленные шаблоны для распространенного ПО: Nginx, Mysql, PostgreSQL, а также общие метрики системы.

Разработчик может подключать шаблоны, разработанные сообществом Zabbix Share.

Или написать свой шаблон под конкретный проект.

Например, мы создали такой для мониторинга асинхронного приложения в нашем проекте Festa (онлайн-игры для вечеринок в формате видеоконференции). На каждый узел или группу узлов можно настроить оповещения по событиям. Для оперативности мы настроили отправку всех уведомлений (алёртов) в специальную группу в Telegram.

Иногда клиенты просят дублировать сообщения им на почту — всё это легко настраивается.

Подключая шаблоны к узлу, мы не просто мониторим доступность серверов, мы держим руку на пульсе.

Например, при мониторинге СУБД мы видим количество подключений. Если оно начнет подбираться к максимальному — в нашу группу сразу прилетит алерт, и мы сможем исправить ситуацию еще до того, как сервис «упадет». А с помощью сохраненных данных удобно разбираться с уже прошедшими инцидентами.

Здесь мы советуем не лениться.

Настроить мониторинг всего ПО, которое требуется сервису, и все триггеры настроить адекватно. Иначе может сложится ситуация, когда тревожных сообщений прилетает так много, что их просто начинают игнорировать, считая незначительными. Здесь есть большой риск пропустить критическое сообщение.

Поэтому абсолютно каждый алёрт должен быть изучен.

Даже на самом лучшем «железе» приложение, написанное с ошибками, будет работать плохо. Заказы не будут оформляться, а на экранах пользователи будут видеть ошибку 500 или 502 («сервис недоступен»).Ошибки будут появляться всегда. Главное — как можно быстрее о них узнать и устранить.

Ошибки бэкенда легко получать через стандартные инструменты вашего фреймворка. Наверняка, у него «из коробки» есть такая возможность, как отправка уведомлений об ошибках на почту.

Для отслеживания бэкенд-ошибок мы используем сервис Sentry.io. Он умеет интегрироваться со всеми популярными решениями и удобно группирует события, не забрасывая разработчиков однотипными сообщениями.

Sentry.io очень помогает нам и с ошибками фронтенда, которые обычно хитрее бэкенда.

Серверная часть приложения всегда работает на одном окружении. Ошибки там чаще всего понятные и воспроизводимые. В то время как фронтенд выполняется на бесчисленном множестве устройств с разными браузерами, разными расширениями, настройками, качеством интернета и так далее. Все эти ошибки мы видим и чиним, игнорируя только ошибки с совсем старых устройств (которые мы не поддерживаем) и стороннего ПО (например, расширений браузера — их код мы не можем исправить).

В воспроизведении ошибок, связанных с окружением, нам помогает сервис BrowserStack, на котором мы можем запустить любой браузер на любом устройстве.

Даже настроив все вышеперечисленное, нельзя исключить возможность упущенного фактора. Любой сервис работает не сам по себе, а обычно в интеграции с парой-тройкой сторонних систем.

Поэтому желательно ко всем метрикам «железа» и приложения добавить бизнес-метрики. Это метрики, которые показывают выполнение бизнес-задачи сайта или сервиса.

Например, это может быть процент оплаченных заказов за последний час.

Если процент ниже порогового значения, нужно бить тревогу и отправлять алерт через сервер Zabbix.

В корне ошибки могут лежать проблемы с платежной системой. По какой-то причине она не дает пользователям ввести карту и не отдает ошибку в api. Или же в интерфейсе сайта сломали кнопку оплаты, и она не всегда нажимается :)

Такие моменты важно вовремя ловить и чинить.

К сожалению, проблемы бывают не только из-за ошибок разработчиков, но и при инцидентах у хостера.

Конечно, настроив мониторинг, вы сразу увидите, что серверы недоступны. Но ничего сделать с этим не сможете (кроме создания тикета в техподдержке хостера).

Тут нужно оценить потери от возможного простоя сервиса из-за проблем в дата-центре хостера. Если они будут дороже, чем держать копию инфраструктуры и ее обслуживание, нужно поднять копию сервиса в другом дата-центре другого хостера. Убедившись, что это действительно разные дата-центры.

Кроме обслуживания копии, нужно подготовить план переключения на резервные мощности с учетом полной недоступности основного дата-центра и регулярно проводить «учения» по переключению.

Пользуйтесь инструментами мониторинга и защищайте бизнес клиентов от неприятных неожиданностей.

P.S. Не забывайте, что систему мониторинга тоже нужно мониторить ;)

Автор статьи: Сергей Никитченко, технический директор SVK.Digital (Студии Валерия Комягина).