База знаний
Войти

Структура Подсистемы

Обзор

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

На рисунке 1 ниже показаны все структурные элементы Подсистемы, а ниже приведены подробные пояснения об их назначении, использовании и значении.

Рисунок 1 — Структура Подсистемы

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

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

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

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

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

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

Преобразование данных полезно в следующих ситуациях:

  • при объединении двух полей в одно, например, "Имя" и "Фамилия" в "Полное имя";
  • при преобразовании типа данных, например, текстовых в формате CSV в другой тип (например, извлечь дату или число из строки);
  • при фильтрации, объединении или выполнении других операций, подобных SQL, которые могут не поддерживаться базовым источником данных или языком запросов.

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

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

Основные элементы

В Подсистеме определяются следующие основные структурные единицы:

  • Плагин приложения – расширение Подсистемы, которое позволяет пользователям предоставлять дополнительные функции для улучшения работы, включая набор плагинов для панелей и источников данных, а также пользовательские страницы;
  • Панель мониторинга – набор из одной или нескольких панелей, организованных и расположенных в один или несколько рядов, которые обеспечивают наглядное представление связанной информации;
  • Источник данных – файл, база данных или служба, предоставляющая данные; Подсистема поддерживает несколько источников данных по умолчанию и может быть расширена для поддержки дополнительных источников данных с помощью плагинов;
  • Экземпляр – любые данные, которые служат подробным примером одного из наблюдений, агрегированных в метрику; содержит наблюдаемое значение вместе с необязательной временной меткой и произвольными метками, которые обычно используются для ссылки на трассировку;
  • Исследование – позволяет пользователю сосредоточиться на построении запроса, в том числе уточнить запрос, чтобы вернуть ожидаемые метрики перед созданием панели мониторинга;
  • Экспорт или импорт панелей мониторинга – включает возможность экспортировать панели мониторинга в файл JSON, которые могут быть импортированы другими пользователями;
  • Экспортер – преобразует данные, поступающие из источника данных, в формат, который может обработать Prometheus;
  • График – широко используемая визуализация, которая отображает данные в виде точек, линий или полос;
  • Mixir – набор панелей мониторинга Подсистемы, а также правил и оповещений Prometheus, написанных на Jsonnet и упакованных вместе в пакет;
  • Панель – базовый элемент в Подсистеме, состоящий из запроса и визуализации; может перемещаться и изменять размер в пределах панели мониторинга;
  • Плагин панели – расширяет Подсистему дополнительными возможностями визуализации;
  • Запрос – используется для запроса данных из источника данных; структура и формат запроса зависят от конкретного источника данных;
  • Временные ряды – серия измерений, упорядоченных по времени; временные ряды хранятся в источниках данных и возвращаются в качестве результата запроса;
  • Трассировка – наблюдаемый путь выполнения запроса через распределенную систему;
  • Преобразование – обработка результатов запроса перед его передачей для визуализации;
  • Визуализация – графическое представление результатов запроса.

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

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

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

Объединение набора измерений называется агрегацией. Существует несколько способов агрегации данных временных рядов. Вот некоторые из них:

  • Среднее значение возвращает сумму всех значений, разделенную на общее количество значений;
  • Min и Max возвращают наименьшее и наибольшее значения в коллекции;
  • Sum возвращает сумму всех значений в коллекции;
  • Count возвращает количество значений в коллекции.

Обычно для визуализации одних и тех же данных временных рядов разными способами используются разные способы агрегации.

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

База данных временных рядов (TSDB) – это база данных, специально разработанная для хранения данных временных рядов. Хотя для хранения измерений можно использовать любую обычную базу данных, TSDB обладает некоторыми полезными оптимизациями.

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

Ниже приведены некоторые из TSDB, поддерживаемых Подсистемой:

  • Graphite;
  • InfluxDB;
  • Prometheus.

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

Вот несколько примеров коллекторов:

  • collectd;
  • statsd;
  • Prometheus exporters;
  • Telegraf.

Коллектор либо отправляет (push) данные в базу данных, либо позволяет базе данных получать (pull) данные из него. Оба метода имеют свои достоинства и недостатки:

  • для push проще реплицировать данные в несколько мест назначения, но TSDB не имеет контроля над тем, какой объем данных отправляется;
  • для pull обеспечивается лучший контроль над объемом обрабатываемых данных и их достоверностью, но брандмауэры, VPN или балансировщики нагрузки могут затруднять доступ к агентам.

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

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

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

В общем случае выполняется один запрос для измерения с одним или несколькими дополнительными свойствами в качестве параметров.

Чтобы идентифицировать уникальные серии в наборе временных рядов, Подсистема сохраняет измерения в метках.

Каждый временной ряд в Подсистеме по желанию может иметь метки. Метки – это набор пар "ключ-значение" для идентификации измерений. Примерами меток могут быть {location=ru} или {country=us,state=ma,city=boston}. В наборе временных рядов сочетание имени и меток идентифицирует каждый ряд.

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

TSDB обычно изначально поддерживают многомерность. Prometheus также хранит измерения в метках. В TSDB, таких как Graphite или OpenTSDB, вместо этого используется термин "тег".

В табличных базах данных, таких как SQL, эти параметры обычно являются параметрами запроса "GROUP BY".

В базах данных SQL или SQL-подобных, которые возвращают табличные результаты, дополнительные параметры обычно представлены в виде столбцов в таблице результатов запроса.

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

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

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

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

Существует несколько источников данных, поддерживающих построение гистограмм с течением времени, например Elasticsearch (с помощью агрегации сегментов гистограммы) или Prometheus (с типом метрики гистограммы и параметром Формат в виде тепловой карты). Но в целом можно использовать любой источник данных, если он соответствует требованию, согласно которому он либо возвращает ряды с именами, представляющими границы сегментов, либо возвращает ряды, отсортированные по границам в порядке возрастания.

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

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

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