IT ManagerИТ в бизнесеИнфраструктура

Внешний мониторинг в ИТ: как выбрать подходящий сервис?

| 04.04.2019

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Внешний мониторинг в ИТ: как выбрать подходящий сервис?

Для любой ИТ-компании, владеющей несколькими веб-сервисами, важной задачей является не только обеспечение их стабильной работы, но и максимально быстрое реагирование на возникающие сложности. Особую роль в данном случае играет правильно подобранная система мониторинга. Travel-компании и не только, со штатом системных администраторов и команд разработки, как правило, отдают предпочтение внутреннему мониторингу. При этом у внешнего – масса преимуществ. Эксперты «UFS», ИТ-компании в сегменте travel, которая работает с высоконагруженными сервисами, проанализировали самые популярные системы, представленные на рынке, выбрали подходящую и решили поделиться успешными кейсами.

Задачи для системы внешнего мониторинга «UFS»

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

Процесс взаимодействия сервисов «UFS» выглядит следующим образом. Все справочные данные от поставщиков контента передаются в веб-сервисы (шлюзы), являющиеся backend-частью системы, обрабатываются там и в установленном формате передаются на сайт для отображения. Таким образом, при возникновении ошибки в результате запроса от сайта система мониторинга должна оперативно проверить три сервиса – сайт, шлюз, поставщика данных и выявить причину.

Проверка должна направляться на большинство страниц сайта: например, на ключевые направления, маршруты, расписание поездов и др. В ходе проверки backend-части проверяется ряд важных запросов для тех же страниц. А для мониторинга жизнеспособности провайдера данных используется проверка его ответа на соответствие заданному формату – если в ответе не поступает один из обязательных тэгов, значит, проблема на его стороне. Необходимо, чтобы при сигнале о падении того или иного монитора моментально определялось место возникновения проблемы.

img

При этом система внешнего мониторинга не должна была тестировать сервисы, отвечающие за оплату, корректность почтовых рассылок и т. д. Установить факт работоспособности таких сервисов невозможно проверкой 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 в месяц.

img

2.         UptimeRobot.com

50 мониторов с частотой проверки раз в 5 минут бесплатно. Проверяет HTTP(s) протоколы, доступность портов, ключевые слова на странице. Удобная визуализация статистики – умеет создавать отдельные страницы для отображения доступности выбранных мониторов, доступ к которым можно получить без входа в панель администрирования.

Уведомления могут быть отправлены большим количеством способов – от банальных Slack и Telegram до собственной RSS-ленты со статусами мониторов.

Стоимость – около $120 в год ($10 в месяц) за 150 мониторов с частотой обновления раз в минуту.

img

3.         StatusCake.com

Есть бесплатный тариф с неограниченным (!) количеством мониторов и частотой проверки раз в 5 минут. Проверяет HTTP(s)-протоколы, пинг, доступность указанных портов, SSH. Уведомления может отправлять на почту, в Slack, HipChat, PublicTweet и в другие менее известные каналы связи. Большой минус – цена, от $25 в месяц.

img

4.         NodePing.com

Умеет проверять многочисленные методы HTTP-протоколов, содержимое ответа сервера по ключевым словам, FTP, DNS, стандартные почтовые протоколы, пинг, доступность портов и многое другое.

Представлено три тарифа в зависимости от количества мониторов. Уведомления отправляются по стандартным каналам – почта, Pushover, Slack, есть возможность голосовых звонков. Стоимость $8–50 в месяц.

img

5.         Ping-admin.ru

Наверное, самый известный русскоязычный сервис мониторинга.

Проверяет HTTP-протокол, FTP, работоспособность БД MySQL и PostgreSQL, почтовые протоколы, DNS, пинг и TelNet. Количество мониторов не ограничено. Уведомления рассылает в Telegram, почту, Skype, аську и Jabber. Фиксированных тарифов нет, оплачивается каждая проверка, стоит $0,00015.

img

Таблица характеристик систем внешнего мониторинга

img

Как видно из таблицы, для установленных ранее критериев UptimeRobot – это наиболее подходящая система мониторинга. Он умеет распознавать статусы ответа страницы, искать ключевые слова на указанных страницах, интегрирован с используемым в компании мессенджером, есть возможность формировать WebHook и RSS-ленты со статусами мониторов. Кроме того, его стоимость чуть ли не минимальна среди выбранных сервисов.

Настройка уведомлений, интеграция с мессенджером

Одной из основных функций мониторинга должна была быть отправка сообщений о статусах мониторов в мессенджер. Соответственно, для каждого проекта сообщения для удобства должны были передаваться в отдельный чат. UptimeRobot интегрирован с мессенджером, но не может разделять сообщения о падениях по проектам и отправлять их в разные чаты. Решение нашлось.

UptimeRobot отправляет сообщения о текущих статусах мониторов через несколько каналов, в том числе Web-Hooks, инструмент для определения изменения состояния веб-страницы. Соответственно, для связи UptimeRobot`a и мессенджера нужен был сервис, способный обрабатывать созданные Web-Hook сообщения и отправлять их в мессенджер, например IFTTT.

IFTTT (If This Then That) представляет собой сервис обработки триггеров. В нашем случае он проверяет Web-Hook от UptimeRobot`a на наличие новых записей и при их появлении отправляет в мессенджер сообщение по установленному шаблону. В ответе от сервиса мониторинга поступает название монитора, статус Up или Down, время события.

img

Общий вид чатов мониторинга представляет собой следующее:

img

img

 

Кейсы с внедренным мониторингом

1. Полное падение системы

Андрей Матвеев, UFS:

«Первый инцидент произошел через неделю после установки бесплатной версии UptimeRobot`a, включающей до 50 мониторов, опрашиваемых с интервалом один раз в 5 минут. Для проверки было установлено около 30 ключевых страниц сайта. В субботу утром мониторинг сообщил о падении абсолютно всех добавленных в него страниц. Оказалось, что сайт был недоступен полностью, а вместе с ним и все остальные сервисы компании. Простой составил около 30 минут, так как внезапно изменились параметры DNS-сервера. Внутренний же мониторинг проблем не обнаружил, поскольку находился внутри сети, а оттуда все сервисы исправно работали. Очевидно, что без внешних средств проверки сайта проблема была бы намного глобальнее».

2. Изменение типа вагона и падение главного направления

Александр Виниченко, UFS:

«В мониторинг были добавлены страницы доступных поездов по десяти самым популярным направлениям: Москва – Санкт-Петербург, Москва – Казань и т. д. Обычно при поломках у поставщика данных или на нашей стороне падали все страницы одновременно, так как логика их работы одинаковая. Однако произошел случай, когда перестала отвечать только страница направления Москва – Санкт-Петербург, остальные направления работали в обычном режиме. После анализа ответа провайдера выяснилось, что для поезда со стандартными типами вагонов (плацкарт, купе, СВ) назначены типы вагонов «Сапсана» («Эконом», «Бизнес» и т. д.) Приложение, не получив привычных данных, ломалось и не отдавало корректного списка поездов. Проблему оперативно решили, избежав простоя страницы по самому прибыльному направлению».

 

Ключевые слова: разработка ПО

Горячие темы: Бизнес в цифре

Журнал IT Manager    [ Подписка на журнал ]

Мероприятия

23.04.2019
BIT-2019

Санкт-Петербург, Конференц-центр отеля "Holiday Inn Московские ворота"

24.04.2019
Meet Up "VR/AR в маркетинге"

Технопарк "Калибр"

25.04.2019
Эрудированные роботы в массовом дистанционном обслуживании

Москва, Swissotel Красные Холмы, панорамный зал «Давос»

25.04.2019 — 26.04.2019
Open Agile Day

Отель Шератон Палас

25.04.2019
Эффективные бизнес-процессы: будущее за цифрой

Санкт-Петербург, конференц-зал отеля «Гайот», ул.Профессора Попова 23 (м.Петроградская)

22.05.2019 — 24.04.2019
Цифровая индустрия промышленной России

Иннополис (Республика Татарстан) , Университетская ул.1