Как стать автором
Обновить
75.23
DataLine
Экосистема ИТ-сервисов

Как мы наблюдаем за метриками в дата-центре и развиваем наш мониторинг

Время на прочтение 11 мин
Количество просмотров 3.9K

В этом году мы обновили сервис облачного мониторинга и представили клиентам более удобное и понятное решение для отслеживания статуса их ИТ-инфраструктуры. Сервис вырос из нашей системы мониторинга дата-центра, где мы отслеживаем сотни тысяч метрик в работе оборудования. Какие-то из них очевидные, а какие-то вызывают у клиентов реакцию: “А что, так можно было?!”

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

Что делает мониторинг вообще и клиентский мониторинг в частности

В понятие мониторинга многие вкладывают свой смысл, но в целом есть 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_downtime

PyNag и 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 и проверял успешность входа. Если вход неуспешен, то создавался алерт. 

Есть еще несколько интересных кейсов клиентского мониторинга, но о них расскажем в следующий раз.

Теги:
Хабы:
+13
Комментарии 4
Комментарии Комментарии 4

Публикации

Информация

Сайт
dtln.ru
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия