Внешний мониторинг в ИТ: как выбрать подходящий сервис?
Для любой ИТ-компании, владеющей несколькими веб-сервисами, важной задачей является не только обеспечение их стабильной работы, но и максимально быстрое реагирование на возникающие сложности. Особую роль в данном случае играет правильно подобранная система мониторинга. Travel-компании и не только, со штатом системных администраторов и команд разработки, как правило, отдают предпочтение внутреннему мониторингу. При этом у внешнего – масса преимуществ. Эксперты «UFS», ИТ-компании в сегменте travel, которая работает с высоконагруженными сервисами, проанализировали самые популярные системы, представленные на рынке, выбрали подходящую и решили поделиться успешными кейсами.
Задачи для системы внешнего мониторинга «UFS»
В рамках активного внедрения практики DevOps часть процесса мониторинга перешла от системных администраторов к командам разработки. В первую очередь необходимо было автоматизировать проверку доступности системы компании для потребителя – пользователей, а также веб-сервисов и других систем.
Процесс взаимодействия сервисов «UFS» выглядит следующим образом. Все справочные данные от поставщиков контента передаются в веб-сервисы (шлюзы), являющиеся backend-частью системы, обрабатываются там и в установленном формате передаются на сайт для отображения. Таким образом, при возникновении ошибки в результате запроса от сайта система мониторинга должна оперативно проверить три сервиса – сайт, шлюз, поставщика данных и выявить причину.
Проверка должна направляться на большинство страниц сайта: например, на ключевые направления, маршруты, расписание поездов и др. В ходе проверки backend-части проверяется ряд важных запросов для тех же страниц. А для мониторинга жизнеспособности провайдера данных используется проверка его ответа на соответствие заданному формату – если в ответе не поступает один из обязательных тэгов, значит, проблема на его стороне. Необходимо, чтобы при сигнале о падении того или иного монитора моментально определялось место возникновения проблемы.
При этом система внешнего мониторинга не должна была тестировать сервисы, отвечающие за оплату, корректность почтовых рассылок и т. д. Установить факт работоспособности таких сервисов невозможно проверкой http-статуса ответа. В подобных ситуациях проводятся сложные проверки интеграционным автоматизированным тестированием. Например, для выявления корректной работы сервиса почтовых рассылок используется скрипт, покупающий билет и проверяющий адекватность отображения всех писем, которые должны поступить на почту при покупке.
Требования к внешнему мониторингу
-
Частота опрашивания страниц. Чем быстрее неисправность будет выявлена, тем быстрее она будет исправлена, но слишком часто обращаться к страницам тоже нельзя, так как чрезмерная нагрузка повлияет на доступность серверов. Выяснили, что оптимальна – частота 1 раз в 1–2 минуты для каждой страницы.
-
Распознавание статусов ответа. Традиционно, 200-й код ответа страницы означает «успех». В нашем случае это не всегда так. Например, для проверки работоспособности взаимодействия одного из наших сервисов с внешним поставщиком при определенном запросе мы должны получать страницу с 301-м редиректом, и только ее. Таким образом, система мониторинга должны быть гибко настроена к распознаванию кодов ответа страниц – 404-я ошибка так же может быть успешным кейсом в некоторых случаях.
-
Проверка протоколов HTTP/HTTPS, тогда как FTP, POP3, SMTP, IMAP в данный момент не актуальны.
-
Список ключевых слов в ответе от сервера. Команда пришла к выводу, что стратегия проверки исключительно кода ответа от страницы, к сожалению, проигрышная. Во многих случаях сайт передавал 200-е страницы с абсолютно некорректным содержимым, поэтому было принято решение проверять страницы еще и на присутствие ключевых слов. Или, наоборот, на их отсутствие.
-
Оповещения. Это наиболее важный момент любого мониторинга. Вся переписка внутри компании проходит в одном из популярных мессенджеров, поэтому основным каналом связи должен был стать именно он. Кроме того, необходимы СМС-оповещения или автоматические звонки на телефон для самых важных мониторов.
-
Удобная визуализация статистики. Необходимо обеспечить доступ каждой команды к просмотру данных при минимальном количестве людей, имеющих права на администрирование системы мониторинга в целом. Существует два пути решения этого вопроса – бот в мессенджере, отправляющий оповещения и статистику по запросу, и веб-страница, при открытии которой отображается статистика по проекту. Второй вариант оказался более практичным для использования.
Сервисы мониторинга: особенности работы, плюсы, минусы
Мы выбрали пять сервисов, по предварительным данным отвечающих нашим требованиям и поставленным задачам:
• Pingdom.com;
• UptimeRobot.com;
• StatusCake.com;
• NodePing.com;
• Ping-Admin.ru.
1. Pingdom.com
30 дней бесплатной полной версии, далее только подписка. На минимальном тарифе максимум 10 мониторов с интервалом 1 раз в минуту. Проверяет протоколы HTTP(s), все почтовые – SMTP, IMAP, POP3. Умеет проверять работоспособность указанных портов. Оповещения действуют во многих каналах связи – Slack, HipChat, push-уведомления в собственные мобильные приложения. В минимальный тариф входят 50 СМС-сообщений в месяц. Стоимость $12–200 в месяц.
2. UptimeRobot.com
50 мониторов с частотой проверки раз в 5 минут бесплатно. Проверяет HTTP(s) протоколы, доступность портов, ключевые слова на странице. Удобная визуализация статистики – умеет создавать отдельные страницы для отображения доступности выбранных мониторов, доступ к которым можно получить без входа в панель администрирования.
Уведомления могут быть отправлены большим количеством способов – от банальных Slack и Telegram до собственной RSS-ленты со статусами мониторов.
Стоимость – около $120 в год ($10 в месяц) за 150 мониторов с частотой обновления раз в минуту.
3. StatusCake.com
Есть бесплатный тариф с неограниченным (!) количеством мониторов и частотой проверки раз в 5 минут. Проверяет HTTP(s)-протоколы, пинг, доступность указанных портов, SSH. Уведомления может отправлять на почту, в Slack, HipChat, PublicTweet и в другие менее известные каналы связи. Большой минус – цена, от $25 в месяц.
4. NodePing.com
Умеет проверять многочисленные методы HTTP-протоколов, содержимое ответа сервера по ключевым словам, FTP, DNS, стандартные почтовые протоколы, пинг, доступность портов и многое другое.
Представлено три тарифа в зависимости от количества мониторов. Уведомления отправляются по стандартным каналам – почта, Pushover, Slack, есть возможность голосовых звонков. Стоимость $8–50 в месяц.
5. Ping-admin.ru
Наверное, самый известный русскоязычный сервис мониторинга.
Проверяет HTTP-протокол, FTP, работоспособность БД MySQL и PostgreSQL, почтовые протоколы, DNS, пинг и TelNet. Количество мониторов не ограничено. Уведомления рассылает в Telegram, почту, Skype, аську и Jabber. Фиксированных тарифов нет, оплачивается каждая проверка, стоит $0,00015.
Таблица характеристик систем внешнего мониторинга
Как видно из таблицы, для установленных ранее критериев UptimeRobot – это наиболее подходящая система мониторинга. Он умеет распознавать статусы ответа страницы, искать ключевые слова на указанных страницах, интегрирован с используемым в компании мессенджером, есть возможность формировать WebHook и RSS-ленты со статусами мониторов. Кроме того, его стоимость чуть ли не минимальна среди выбранных сервисов.
Настройка уведомлений, интеграция с мессенджером
Одной из основных функций мониторинга должна была быть отправка сообщений о статусах мониторов в мессенджер. Соответственно, для каждого проекта сообщения для удобства должны были передаваться в отдельный чат. UptimeRobot интегрирован с мессенджером, но не может разделять сообщения о падениях по проектам и отправлять их в разные чаты. Решение нашлось.
UptimeRobot отправляет сообщения о текущих статусах мониторов через несколько каналов, в том числе Web-Hooks, инструмент для определения изменения состояния веб-страницы. Соответственно, для связи UptimeRobot`a и мессенджера нужен был сервис, способный обрабатывать созданные Web-Hook сообщения и отправлять их в мессенджер, например IFTTT.
IFTTT (If This Then That) представляет собой сервис обработки триггеров. В нашем случае он проверяет Web-Hook от UptimeRobot`a на наличие новых записей и при их появлении отправляет в мессенджер сообщение по установленному шаблону. В ответе от сервиса мониторинга поступает название монитора, статус Up или Down, время события.
Общий вид чатов мониторинга представляет собой следующее:
Кейсы с внедренным мониторингом
1. Полное падение системы
Андрей Матвеев, UFS:
«Первый инцидент произошел через неделю после установки бесплатной версии UptimeRobot`a, включающей до 50 мониторов, опрашиваемых с интервалом один раз в 5 минут. Для проверки было установлено около 30 ключевых страниц сайта. В субботу утром мониторинг сообщил о падении абсолютно всех добавленных в него страниц. Оказалось, что сайт был недоступен полностью, а вместе с ним и все остальные сервисы компании. Простой составил около 30 минут, так как внезапно изменились параметры DNS-сервера. Внутренний же мониторинг проблем не обнаружил, поскольку находился внутри сети, а оттуда все сервисы исправно работали. Очевидно, что без внешних средств проверки сайта проблема была бы намного глобальнее».
2. Изменение типа вагона и падение главного направления
Александр Виниченко, UFS:
«В мониторинг были добавлены страницы доступных поездов по десяти самым популярным направлениям: Москва – Санкт-Петербург, Москва – Казань и т. д. Обычно при поломках у поставщика данных или на нашей стороне падали все страницы одновременно, так как логика их работы одинаковая. Однако произошел случай, когда перестала отвечать только страница направления Москва – Санкт-Петербург, остальные направления работали в обычном режиме. После анализа ответа провайдера выяснилось, что для поезда со стандартными типами вагонов (плацкарт, купе, СВ) назначены типы вагонов «Сапсана» («Эконом», «Бизнес» и т. д.) Приложение, не получив привычных данных, ломалось и не отдавало корректного списка поездов. Проблему оперативно решили, избежав простоя страницы по самому прибыльному направлению».
Опубликовано 04.04.2019