зачем администраторы настраивают визуальное отображение графиков с метриками мониторинга

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

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

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

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

В понятие мониторинга многие вкладывают свой смысл, но в целом есть 2 основных направления:

Диагностика системы. Собираем, храним, обрабатываем и визуализируем всевозможные метрики с объектов мониторинга. Затем с помощью инструментов анализа делаем выводы и принимаем управленческие решения.

Реагирование на проблемы. Определяем состояния системы, которые требуют быстрых ответных действий, формулируем их критерии и разрабатываем процедуры реагирования. В системе мониторинга настраиваем автоматические проверки статусов и уведомления ответственным. Можно сказать, что это классический мониторинг, который описывается как процесс управления событиями (Event Management) в библиотеке ITIL.

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

Для разных облачных сервисов DataLine мы отслеживаем разные показатели, но за ними всегда стоит общий процесс, который лег в основу облачного мониторинга как сервиса. Что делает сервис в общем случае:

формирует алерты в консоли мониторинга;

создает инциденты в Service Desk;

шлет оповещения по email, SMS, Telegram или голосом по телефону — для звонка уже подключается дежурный;

хранит исторические значения метрик в виде данных временного ряда и графиков;

визуализирует текущие статусы объектов мониторинга на дашбордах;

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

За чем мы следим в дата-центре и облаке

В основе наших облачных сервисов — работа целой сети дата-центров. От работоспособности инженерной и ИТ-инфраструктуры зависит уровень предоставления наших услуг, или SLA. Поэтому мы ставим на мониторинг действительно много объектов, вот основные группы.

Электроснабжение:

Холодоснабжение:

Датчики температуры в коридорах машинных залов.

Датчики давления жидкости в охлаждающем контуре.

Видеонаблюдение:

Аппаратное обеспечение оборудования:

Статус блоков питания.

Сетевое оборудование:

Загрузка системных ресурсов.

Системы хранения данных:

Статусы контроллеров и SAN-портов.

IOPS, Latency, Throughput.

Виртуальная инфраструктура:

Статусы хостов виртуализации (hardware и утилизация ресурсов).

Свободное место на дата-сторах.

ОС (Linux, Windows, AIX):

Утилизация системных ресурсов (CPU, RAM, Swap, Load Average).

Свободное место на дисках.

Базы данных (MS SQL, Oracle, MySQL):

Доступность экземпляров БД и листнеров.

Счетчики 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:

Перевод сервиса на хосте в Downtime на 1 час:

PyNag и RESTlos. PyNag позволяет автоматизировать изменения непосредственно в конфигурационных файлах Nagios. RESTlos — интерфейс REST API к PyNag. Мы переписали его под Python3.

Вот пример добавления новых хостов:

Для актуализации изменений выполняем reload соответствующего инстанса Nagios:

Что пригодится клиенту

В мониторинг заведены не только наши системы, но и системы клиентов. Сейчас их доля в мониторинге примерно 20%. Часто данные клиентского мониторинга используют наши администраторы при обслуживании физических и виртуальных серверов клиентов. Но услугу мониторинга для клиентов можно подключить и отдельно от администрирования. Например, вот что подключают наши клиенты сейчас:

Типовые проверки доступности и утилизации системных ресурсов.

Интеграция с клиентскими системами мониторинга или Service Desk. Клиент принимает данные в свою систему мониторинга и может анализировать все события в своей гибридной инфраструктуре. Мы уже настраивали такую синхронизацию с Zabbix и HP Service Manager.

Один из клиентов заказал мониторинг работоспособности web-страницы входа пользователя и возможность авторизации. Для этого мы использовали Selenium. Робот переходил на страницу входа, вводил login/password и проверял успешность входа. Если вход неуспешен, то создавался алерт.

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

Источник

Основы мониторинга и сбора метрик

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

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

Что такое метрики, мониторинг и система оповещений?

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

Что такое метрики и зачем их собирать?

Метрики – это неформатированные данные об использовании ресурсов или поведении, которые можно отслеживать и собирать в системах. Это могут быть отчеты об использовании, предоставляемые операционной системой, или данные более высокого уровня, привязанные к конкретным функциям или компонентам (например, количество запросов в секунду, членство в пуле веб-серверов и т.п.). Некоторые метрики представлены в отношении к общей мощности, а другие представлены рейтингами загруженности компонента.

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

Для сбора других метрик – особенно это касается ваших собственных приложений – вам может потребоваться добавить код или интерфейсы.

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

Что такое мониторинг?

Метрики представляют данные о вашей системе, а мониторинг – это процесс сбора, агрегирования и анализа этих данных для улучшения понимания характеристик и поведения компонентов системы. Данные из разных точек среды собираются системой мониторинга, которая отвечает за хранение, агрегацию, визуализацию данных и автоматические реагирует на изменения, когда значения соответствует заданным условиям.

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

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

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

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

Что такое система оповещений?

Система оповещений является компонентом системы мониторинга, который выполняет действия на основе изменений метрических значений. Определения системы оповещений состоят из двух компонентов: условия (или порога), основанного на метриках, и действия, которое нужно выполнить, когда значения выходят за пределы приемлемых условий.

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

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

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

Какие данные нужно отслеживать?

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

Метрики хоста

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

Эти метрики определяют факторы, которые могут повлиять на работоспособность одного компьютера.

Метрики приложения

Следующая категория метрик, которую вы должны отслеживать, – это метрики приложения. Это показатели зависят от ресурсов уровня хоста (таких как сервисы или приложения). Типы метрик, на которые следует обратить внимание, зависят от того, что предоставляет сервис, с какими зависимостями и другими компонентами он взаимодействует. Метрики на этом уровне говорят о работоспособности, производительности или нагрузке приложения:

Эти показатели помогают определить, насколько правильно и эффективно работает приложение.

Метрики сети и подключений

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

Мониторинг сети поможет улучшить доступность и оперативность ваших внутренних и внешних сервисов.

Метрики пула серверов

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

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

Метрики внешних зависимостей

Также вы можете добавить в свою систему метрики, которые относятся к внешним зависимостям. Часто сервисы предоставляют статусные страницы или API для обнаружения сбоев в обслуживании, но отслеживание их в системой мониторинга может помочь вам выявить проблемы с провайдерами, которые могут повлиять на операции вашего приложения. На этом уровне можно отслеживать следующие данные:

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

Факторы, влияющие на мониторинг

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

Ниже перечислены факторы, которые могут повлиять на список отслеживаемых метрик:

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

Важные качества метрик, мониторинга и системы оповещений

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

Независимость от большинства других инфраструктур

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

Надежность

Другим основным требованием является надежность. Поскольку система мониторинга отвечает за сбор, хранение и предоставление доступа к важной информации, вы должны быть уверены, что она будет работать правильно и ежедневно. Потерянные метрики, сбои в обслуживании и ненадежная система оповещений могут сразу оказать негативное воздействие на эффективное управление инфраструктурой. Это относится не только к надежности основного программного обеспечения, но и к надежности конфигурации.

Простые и удобные отчеты

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

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

Эффективная стратегия поддержки истории

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

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

Взаимодействие с другими ресурсами

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

Простота добавления новой метрики или инфраструктуры

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

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

Гибкая и производительная система оповещений

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

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

Источник