В этом году мы обновили сервис облачного мониторинга и представили клиентам более удобное и понятное решение для отслеживания статуса их ИТ-инфраструктуры. Сервис вырос из нашей системы мониторинга дата-центра, где мы отслеживаем сотни тысяч метрик в работе оборудования. Какие-то из них очевидные, а какие-то вызывают у клиентов реакцию: “А что, так можно было?!”
В статье покажу, как наш мониторинг устроен изнутри, почему выбрали для него именно эти инструменты и как планируем развивать в сторону самообслуживания.
Что делает мониторинг вообще и клиентский мониторинг в частности
В понятие мониторинга многие вкладывают свой смысл, но в целом есть 2 основных направления:
Диагностика системы. Собираем, храним, обрабатываем и визуализируем всевозможные метрики с объектов мониторинга. Затем с помощью инструментов анализа делаем выводы и принимаем управленческие решения.
Реагирование на проблемы. Определяем состояния системы, которые требуют быстрых ответных действий, формулируем их критерии и разрабатываем процедуры реагирования. В системе мониторинга настраиваем автоматические проверки статусов и уведомления ответственным. Можно сказать, что это классический мониторинг, который описывается как процесс управления событиями (Event Management) в библиотеке ITIL.
Разумеется, четкую границу между двумя вариантами провести нельзя. Есть универсальные системы мониторинга, которые могут все. В контексте облачного сервиса для клиентов мы чаще говорим про классический событийный мониторинг. Пользователям облака важно следить за производительностью, доступностью и безопасностью системы и вовремя замечать, например, что какие-то настройки не оптимальны, а вот тут ресурсы начинают подходить к концу.
Для разных облачных сервисов DataLine мы отслеживаем разные показатели, но за ними всегда стоит общий процесс, который лег в основу облачного мониторинга как сервиса. Что делает сервис в общем случае:
формирует алерты в консоли мониторинга;
создает инциденты в Service Desk;
шлет оповещения по email, SMS, Telegram или голосом по телефону — для звонка уже подключается дежурный;
хранит исторические значения метрик в виде данных временного ряда и графиков;
визуализирует текущие статусы объектов мониторинга на дашбордах;
генерирует отчеты.
Когда клиент дата-центра подключает мониторинг, он выбирает ключевые метрики и способ получения информации. Можно попросить себе персональную консоль со всеми графиками и наблюдать за статусами самому, а можно настроить оповещения конкретным сотрудникам в удобном канале. На какие-то события нужно реагировать сразу: их удобно получать на своем смартфоне в виде SMS, звонков, сообщений в мессенджере. Какие-то показатели важно просто фиксировать и анализировать в динамике: их собирают на дашборды и в регулярные отчеты по почте. Все настраивается гибко. Поэтому главный вопрос на старте — какие метрики и как подключить, чтобы не пропустить важного и не перегрузить мониторинг лишней информацией.
За чем мы следим в дата-центре и облаке
В основе наших облачных сервисов — работа целой сети дата-центров. От работоспособности инженерной и ИТ-инфраструктуры зависит уровень предоставления наших услуг, или SLA. Поэтому мы ставим на мониторинг действительно много объектов, вот основные группы.
Электроснабжение:
Вводы на ГРЩ.
Трансформаторы.
ДГУ.
ИБП.
PDU.
АВР.
(Подробнее об этом писали здесь: Мониторинг инженерной инфраструктуры в дата-центре. Часть 2. Система энергоснабжения.)
Холодоснабжение:
Датчики температуры в коридорах машинных залов.
Датчики протечек.
Датчики давления жидкости в охлаждающем контуре.
(Подробнее тут: Мониторинг инженерной инфраструктуры в дата-центре. Часть 3. Система холодоснабжения.)
Видеонаблюдение:
Камеры.
Видеосерверы.
Аппаратное обеспечение оборудования:
Статус блоков питания.
Статус вентиляторов.
Датчики температуры.
Сетевое оборудование:
Статусы интерфейсов.
Загрузка системных ресурсов.
(Подробнее: Мониторинг инженерной инфраструктуры в дата-центре. Часть 4. Сетевая инфраструктура: физическое оборудование.)
Системы хранения данных:
Статусы контроллеров и SAN-портов.
Исправность дисков.
IOPS, Latency, Throughput.
Виртуальная инфраструктура:
Статусы хостов виртуализации (hardware и утилизация ресурсов).
Свободное место на дата-сторах.
ОС (Linux, Windows, AIX):
Доступность.
Утилизация системных ресурсов (CPU, RAM, Swap, Load Average).
Свободное место на дисках.
Базы данных (MS SQL, Oracle, MySQL):
Доступность экземпляров БД и листнеров.
Заполнение tablespace.
Блокировки.
Счетчики Perfmon MS SQL.
Приложения и сервисы:
Доступность соответствующих процессов.
Доступность сетевых портов и корректность ответа.
В общей сложности, у нас сейчас заведено в мониторинг 12 000 хостов и 182 000 проверок на них.
Покажу подробнее, как и куда мы собираем эти данные.
Из чего состоит мониторинг
Общая схема. Система мониторинга дотягивается до всех объектов, снимает с них данные, сохраняет в одном месте, обрабатывает и визуализирует информацию для нас и для клиента. Упрощенно поток данных выглядит так:
За каждый этап сбора данных отвечает свой элемент:
Nagios Core получает значения метрик и выполняет проверки мониторинга (о них чуть ниже). Почему именно Nagios, ответ простой: так исторически сложилось. Во-первых, мы не хотели привязываться к проприетарным системам мониторинга, в том числе SCADA-системам. Во-вторых, нас устраивает его функциональность и нет серьезных аргументов миграции на другой продукт. В-третьих, за 10 лет эксплуатации решения мы создали для него множество скриптов, плагинов и кастомизаций. Zabbix, Prometheus и Victoria Metrics мы тоже используем в компании, но не как основное решение для мониторинга инженерной и ИТ-инфраструктуры.
InfluxDB используется как историческое хранилище. Значения метрик сохраняем в базу с помощью Nagflux.
Grafana используется для отображения графиков на дашбордах. Для совместной работы с Nagflux применяем плагин Histou.
Thruk используем в качестве web-интерфейса для консоли мониторинга.
Кластерная архитектура. Чтобы обеспечить отказоустойчивость и высокую доступность системы, мы используем инструменты кластеризации Pacemaker и DRBD. Каждый кластер состоит из двух нод. Они разнесены физически по разным залам в дата-центре. Упрощенно схема выглядит вот так:
А вот что происходит в динамике. В нормальном повседневном режиме на каждой ноде работает свой инстанс Nagios Core. При этом непрерывно происходит репликация файловых систем между нодами. В случае отказа одной из нод кластерные ресурсы переезжают на исправную ноду, и оба инстанса Nagios продолжают работать на этой ноде. После восстановления отказавшей ноды кластерные ресурсы соответствующего инстанса Nagios возвращаются обратно.
Консоль Thruk тоже подняли в двух экземплярах на разных площадках. Каждый экземпляр Thruk подключается ко всем инстансам Nagios. В случае отказа одного из экземпляров дежурные инженеры просто переключаются на вторую консоль.
Каждый инстанс Nagios покрывает свой скоуп объектов мониторинга. Конфигурации в Nagios хранятся в текстовых файлах, и реляционные БД для этого не используются. Каждый экземпляр Nagios хранит только свою конфигурацию, так что единой точки отказа нет. Сейчас у нас 26 инстансов, и мы не сталкивались с какими-то существенными проблемами в производительности.
Сбор информации на местах и проверки мониторинга. Информацию на мониторинг нужно собрать с аппаратных объектов и из программного обеспечения. Для этого используем разные софтверные и IoT-инструменты:
Датчики температуры/влажности/протечки подключаем с помощью контроллеров — все производства Vutlan.
С инженерного оборудования собираем данные по протоколам Modbus и SNMP. Для мониторинга по Modbus используем преобразователи Moxa Mgate.
Для сбора информации из ИТ-систем используются вендорские API.
В качестве агентов мониторинга применяем стандартные NRPE-агенты для Linux и NSClient++ для Windows.
Полученные данные от оборудования и систем затем необходимо сверить с нормальными референсными значениями. Для типовых проверок используем плагины Nagios, а для специфических задач написали свои скрипты и плагины на Shell, Powershell, Perl, Python, C и Go. Значительная часть плагинов помимо выполнения проверок сохраняют значения метрик. Периодичность опроса для большинства проверок составляет 1 минуту.
Как дежурные инженеры обрабатывает алерты
Итак, мы подключили к системе датчики и API систем и настроили проверки раз в минуту. Результаты этих проверок могут быть нескольких типов:
OK и UP — все хорошо, действий не требуется, просто сохраняем значение метрики.
WARNING — какие-то параметры оборудования или системы подходят к критическому значению.
CRITICAL — аварийная ситуация, что-то сломалось или возникла ошибка на оборудовании.
HOST DOWN — хост недоступен.
UNKNOWN — что-то непонятное, как правило, ошибка во время выполнения проверки, нужно выяснять.
Если результат проверки требует реагирования, то в системе мониторинга создается алерт. Инженеры дежурной смены видят его в консоли Thruk. Для них создан специальный фильтр, который выводит только необработанные алерты. По каждому новому алерту инженеру нужно создать инцидент в системе Service Desk, этот процесс нужно было максимально ускорить и упростить.
По регламенту на каждое событие дежурный инженер обязан отреагировать определенным образом:
На WARNING нужно отреагировать в течение 30 минут. Для этого события создается инцидент с приоритетом 4. Сотрудники подразделения, на которое он был эскалирован, должны разрешить его в течение одного рабочего дня.
На CRITICAL или HOST DOWN нужно отреагировать за 5 минут, а также оповестить ответственного за объект мониторинга голосом по телефону. Для этого события создается инцидент с приоритетом 2, он должен быть разрешен в течение 2-х часов независимо от времени суток.
Для UNKNOWN время реакции 5 минут. Создается инцидент с приоритетом 3, который нужно решить в течение 4 часов.
В консоли Thruk вывели максимум полезного, чтобы наши дежурные могли отреагировать с минимальным количеством кликов.
Чтобы автоматизировать создание инцидента в Service Desk и заполнение формы заявки, мы создали специальное контекстное меню:
После создания инцидента и оповещения инженер действует по инструкции, просмотреть ее можно из консоли:
А еще по наведению на “солнышко” можно быстро посмотреть график изменения метрики:
Как решаем проблемы с ложноположительными алертами
В любом мониторинге могут возникнуть ложные срабатывания. Например, если произошли кратковременные сбои в сети или пороги срабатывания настроены некорректно, какие-то алерты могут поступать в консоль к инженерам повторно. Такие проблемы называют флапами. Если алертов немного, то ничего страшного. Если же суточный поток доходит до 3000—5000 алертов и при этом число проверок каждый год растет чуть ли не вдвое, важно максимально снизить уровень шума от возникающих флапов.
Для этого мы ввели пару дополнительных инструментов:
Практически для всех проверок снизили излишнюю чувствительность мониторинга с помощью алертов типа HARD. Такие алерты появляются в консоли только после того, как проблемный статус фиксируется от 3 до 6 раз подряд, в зависимости от метрики. Количество раз проверяется автоматически с помощью параметра конфигурации max_check_attempts.
Когда этого стало недостаточно, помог специально написанный обработчик flap_killer. Если вкратце, этот инструмент обучается на действиях наших сотрудников. Он предотвращает повторное появление алерта по объекту мониторинга в том случае, если совсем недавно по нему уже было выполнено подтверждение (Acknowledgement) или открыт инцидент.
Flap_killer анализирует жизненный цикл алерта и собирает статистику обработки событий дежурными. Если алерт появляется в консоли, не обрабатывается дежурным, а потом “исчезает сам”, то обработчик помечает соответствующий ему сервис как шумящий. Для этого используется специальная кастомная переменная _NOISE_LEVEL. Если алерт по шумящему сервису возникает потворно, обработчик сначала переводит его в Downtime на 3 минуты и скрывает из консоли. Если же через 3 минуты алерт по-прежнему активен, то он выводится на консоль. Когда алерт обработан, значение переменной меняется на исходное: _NOISE_LEVEL = 0.
Цифру в 3 минуты вывели статистически:
При этом flap_killer не выполняет обработку, если состояние метрики меняется на более критическое. В этом случае алерт сразу появляется в консоли, и наши дежурные ничего не пропускают.
Обработчик разгрузил дежурных и снизил долю человеческого фактора. По статистике, нам удалось отфильтровать до 70% подобных кратковременных алертов.
Как генерируем отчеты
Для создания отчетов какое-то специальное ПО мы не используем. Берем поток событий из логов, делаем выборку по изменению статусов проверок и сохраняем в БД MySQL с помощью NDOUtils.
В историческом хранилище на InfluxDB история изменений метрик хранится 555 дней. На основе этих данных строятся отчеты. У нас есть шаблоны и наработки скриптов на Perl и Python, которые агрегируют исторические данные, формируют html-страницы или Excel-файлы и выполняют рассылку по cron заинтересованным адресатам.
Например, вот отчет о просадках на городских линиях электроэнергии:
Отчет по обработке алертов:
Как планируем развивать monitoring API
Сейчас постановка клиентских хостов на мониторинг происходит по заявкам. С одной стороны, в таком случае клиентский мониторинг прорабатывается более тщательно, без лишних затрат ресурсов как в системе мониторинга, так и на самих объектах. Выбираются самые необходимые метрики и проверки. С другой стороны, это не быстро и не автоматизировано.
Пока мы не можем похвастаться развесистым API а-ля Amazon CloudWatch. Но ведем работу над интеграцией мониторинга в личный кабинет клиента. Вот какие есть “кирпичики”, из которых будет складываться наш API.
Thruk REST API. Thruk является своеобразным зонтиком и отображает статусы объектов со всех инстансов Nagios. С помощью Thruk REST API можно получать списки хостов, сервисов с атрибутами и статусами, применять различные фильтры. Результирующий список можно получить в нескольких форматах: json, csv, Excel и text table (human readable).
Также есть возможность менять runtime-значения атрибутов и выполнять различные действия в виде External Commands. Например, переводить объект мониторинга в Downtime. Для безопасности и разделения доступов используется basic-авторизация api keys или secret key. Можно задействовать HTTP-методы: GET, POST, PUT, PATCH и DELETE.
Несколько примеров использования у нас.
Вывод сервисов и их статусов в формате csv для хостов, в имени которых содержится dtln:
%> curl -g 'http://user:password@localhost/thruk/r/csv/services?host_name[regex]=dtln&columns=description,stateПеревод сервиса <svc> на хосте <host> в Downtime на 1 час:
%> curl -d "start_time=now" -d "end_time=+60m" -d "comment_data='downtime comment'" http://0:3000/thruk/r/services/<host>/<svc>/cmd/schedule_svc_downtimePyNag и RESTlos. PyNag позволяет автоматизировать изменения непосредственно в конфигурационных файлах Nagios. RESTlos — интерфейс REST API к PyNag. Мы переписали его под Python3.
Вот пример добавления новых хостов:
%> cat /tmp/hosts
[
{
"alias": "testhost2",
"use": "generic-host",
"host_name": "testhost2",
"max_check_attempts": 3,
"address": "127.0.0.3"
},
{
"alias": "testhost1",
"use": "generic-host",
"host_name": "testhost1",
"max_check_attempts": 3,
"address": "127.0.0.2"
},
{
"alias": "testhost3",
"use": "generic-host",
"host_name": "testhost3",
"max_check_attempts": 3,
"address": "127.0.0.4"
}
]
%> curl X POST -d @/tmp/hosts -H "content-type: application/json" 'http://admin:password@localhost:8090/host'
{"results":[{"200":"successfully stored host object: testhost2"},{"200":"successfully stored host object: testhost1"},{"200":"successfully stored host object: testhost3"}],"summary":{"failed":0,"succeeded":3,"total":3}}Проверка конфигурации:
curl -X POST -H "content-type:
application/json" 'http://admin:password@localhost:8090/control?verify'
{"output":{"Total Errors":"0","Total Warnings":"3","Warning":["Host 'testhost1' has no default contacts or contactgroups defined!","Host 'testhost2' has no default contacts or contactgroups defined!","Host 'testhost3' has no default contacts or contactgroups defined!"]},"returncode":0}Для актуализации изменений выполняем reload соответствующего инстанса Nagios:
curl -X POST -H "content-type:
application/json" 'http://admin:password@localhost:8090/control?reload'
{"result":"successfully sent command to command file"}Что пригодится клиенту
В мониторинг заведены не только наши системы, но и системы клиентов. Сейчас их доля в мониторинге примерно 20%. Часто данные клиентского мониторинга используют наши администраторы при обслуживании физических и виртуальных серверов клиентов. Но услугу мониторинга для клиентов можно подключить и отдельно от администрирования. Например, вот что подключают наши клиенты сейчас:
Типовые проверки доступности и утилизации системных ресурсов.
Интеграция с клиентскими системами мониторинга или Service Desk. Клиент принимает данные в свою систему мониторинга и может анализировать все события в своей гибридной инфраструктуре. Мы уже настраивали такую синхронизацию с Zabbix и HP Service Manager.
Один из клиентов заказал мониторинг работоспособности web-страницы входа пользователя и возможность авторизации. Для этого мы использовали Selenium. Робот переходил на страницу входа, вводил login/password и проверял успешность входа. Если вход неуспешен, то создавался алерт.
Есть еще несколько интересных кейсов клиентского мониторинга, но о них расскажем в следующий раз.
