Перейти к основному содержимому

Постановка объекта контроля на мониторинг

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

  1. Сбор метрик
  2. Моделирвоание CMDB
  3. Создание конфигурационных единиц (КЕ)
  4. Запуск процесса обогащения
  5. Настройка автоматического обогащения по расписанию
  6. Создание шаблона мониторинга
  7. Настройка Дашбордов

1. Сбор метрик​

В разделе Главная / Настройки / Мониторинг / Задания напишем конфигурацию задания, которое собирает метрики с сервисов Памир.

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

СервисПортОписание
auth:80018001Сервис аутентификации
srm:80028002Сервис CMDB
monitoring:80048004Сервис мониторинга
license:80058005Сервис лицензирования
docker-tool:80068006Сервис для работы с Docker
task-tool:80078007Сервис системных задач
notification:80088008Сервис уведомлений
cadvisor:80808080cAdvisor (мониторинг контейнеров)
docker-state-exporter:80808080экспортер состояния Docker

Конфигурации задания Памир:

job_name: Памир
metrics_path: /metrics
static_configs:
- targets:
  - auth:8001
  - srm:8002
  - monitoring:8004
  - license:8005
  - docker-tool:8006
  - task-tool:8007
  - notification:8008
  - cadvisor:8080
  - docker-state-exporter:8080
relabel_configs:
- source_labels:
  - __address__
  regex: ^(auth|srm|monitoring|license|docker-tool|task-tool|notification):.*$
  target_label: name
  replacement: $1
metric_relabel_configs:
- source_labels:
  - instance
  regex: cadvisor:8080
  target_label: instance
  replacement: Pamir docker server
  action: replace

Конфигурация содержит ряд дополнительных настроек по переименованию метрики. Конфигурация переименовывает метку name на основе __address__:

relabel_configs:
- source_labels: [__address__]
  regex: ^(auth|srm|monitoring|license|docker-tool|task-tool|notification):.*$
  target_label: name
  replacement: $1
подсказка
  • Берет значение address (например, auth:8001).
  • Если оно совпадает с regex (auth|srm|monitoring|...), то создает метку name со значением первой группы ($1).
  • Пример:
    • __address__ = "auth:8001" → name="auth"
    • __address__ = "srm:8002" → name="srm"

2. Моделирование CMDB​

Для представления структуры Памир на странице Главная / Настройки / СРМ / Типы КЕ создадим иерархию типов КЕ.

Конфигурационная единица  
│  
├── Программное обеспечение 
│   │  
│   ├── Ресурсы Памир  
│   │   └── Сервис Памир 
│   │       ├── Мониторинг
│   │       ├── Дополнительные
│   │       ├── Сторонние
│   │       ├── License
│   │       ├── СРМ
│   │       ├── Аутентификация
│   │       ├── Notification
│   │       ├── Docker Tool
│   │       └── Task Tool
│   │  
│   └── Памир

Система организует Типы КЕ в виде древовидной структуры. На верхнем уровне находится общая категория Конфигурационная единица, которая включает в себя подкатегории, связанные с программным обеспечением. В частности, выделяется ветка Ресурсы Памир, где детализируются сервисы платформы. Например, Сервис Памир содержит подтипы, такие как Мониторинг, Аутентификация, Docker Tool и другие — это позволяет систематизировать компоненты системы для последующего управления.

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

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

Обогащение происходит рекурсивно:

  1. Сначала обработка начинается с корневой КЕ (например, основного сервиса "Памир").
  2. Затем система анализирует связанные с ней компоненты и создает для них соответствующие КЕ.
  3. Процесс повторяется для каждой новой единицы, пока все связи не будут обработаны.

Настройку процесса обогащения начнем с ТКЕ Памир.

Настройка ТКЕ Памир​

Для корректной работы механизма обогащения конфигурационных единиц необходимо выполнить настройку типа КЕ "Памир". Рассмотрим основные параметры конфигурации:

Получение данных для обогащения​

Будем использовать следующий подход к сбору данных:

  • Вся конфигурация получается единым запросом на уровне ТКЕ Памир
  • Данные о связанных сервисах передаются через связи типа ассоциация
  • Передаваемая информация содержит все необходимые сведения для заполнения атрибутов сервисов

Настройка атрибутов​

Конфигурация системы хранится в единственном атрибуте:

  • Наименование: Конфигурация
  • Тип: сложный объект (JSON)
  • Способ заполнения: PromQL запрос

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

Правило идентификации​

Особенности реализации:

  • Система мониторинга рассчитана на работу с единственным экземпляром Памир
  • Правило идентификации не требуется и может быть удалено
  • Пустое правило идентификации означает singleton-режим:
    • Можно создать только один экземпляр КЕ
    • Все последующие попытки создания будут приводить к объединению с существующим экземпляром

Правило именования​

Правило именования заменяем на строковый литерал "Памир".

Настройка связей​

Процесс обогащения CMDB в системе Памир построен на рекурсивном разборе конфигурации. Рассмотрим детали настройки связей между типами конфигурационных единиц (ТКЕ).

Процесс обработки конфигурации

  1. Инициализация процесса:
  • Обогащение начинается с запуска процесса на корневой КЕ
  • Система последовательно:
    • Получает конфигурацию из объекта контроля
    • Анализирует и парсит данные конфигурации
    • Заполняет атрибуты текущей КЕ
    • Передает соответствующие части конфигурации по настроенным связям
  1. Рекурсивная обработка:
  • Каждый ТКЕ, получив часть конфигурации:
    • Запускает собственный процесс разбора
    • Повторяет алгоритм для связанных КЕ

Настройка доступных связей Добавляем связь Ассоциация до всех ресурсов Памир:

  1. Связь с "Сервис Памир":
  • Назначение: обеспечение возможности выбора всех сервисов через единый узел в TQL
  • Особенность: не требует дополнительных настроек
  • Конфигурация по этой связи не передается
  1. Связи для конкретных сервисов:
  • Требуют настройки фетчера и парсера

Пример для сервиса Мониторинг Фетчер:

  • Тип: Receive data from attribute
  • Источник данных: атрибут Конфигурация

Парсер:

  • Тип: JQ parser
  • Выражение:
.data.result
  | group_by(.metric.container_label_com_docker_compose_service)
  | map({
  service: .[0].metric.container_label_com_docker_compose_service,
  items: map(del(.value))
  })
  | map(select(.service=="monitoring"))
  • Метод поиска: Первое совпадение
подсказка

Аналогичным образом настраиваются связи для других сервисов системы, с соответствующим изменением параметра service в выражении JQ-парсера.

Настройка ТКЕ Сервис Памир​

1. Получение конфигурации

На данном этапе обработки система получает конфигурацию в формате JSON от предыдущего этапа обогащения. Для работы с конфигурацией:

  • Конфигурация сохраняется в атрибут "Конфигурация"
  • Для получения данных используется фетчер:
    • Тип: Receive data from config
  • Парсинг на этом этапе не требуется → вкладка "Парсер" остается пустой

2. Заполнение атрибутов КЕ

Основные атрибуты конфигурационной единицы (Название, Вендор, Версия и др.) заполняются из локального атрибута "Конфигурация". Процесс настройки:

  1. Настройка фетчера:
  • Тип: Receive data from attribute
  • Источник данных: атрибут Конфигурация
  1. Настройка парсера:
  • Тип парсера: JQ parser
  • Для каждого атрибута создается отдельное JQ-выражение
  • Примеры выражений:
    • Для атрибута "Вендор":
      .items[0].metric.container_label_vendor
    • Для атрибута "Версия":
      .items[0].metric.container_label_version
  • Метод поиска: "Первое совпадение"

3. Особенности обработки

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

Примечание: Для разных атрибутов могут потребоваться различные JQ-выражения в зависимости от структуры исходной конфигурации. Рекомендуется проверять корректность извлечения данных для каждого атрибута отдельно.

3. Создание конфигурационных единиц (КЕ)​

Процесс создания КЕ типа Памир:

  1. Переход в раздел управления:
  • Откройте страницу: Главная → СРМ
  • В верхней панели нажмите кнопку "Поиск"
  1. Настройка поиска:
  • В открывшемся окне поиска:
    1. Через контекстное меню добавьте в TQL-запрос тип КЕ "Памир"
    2. Нажмите кнопку Применить
  • Система отобразит граф СРМ, соответствующий заданным критериям
  1. Создание новой КЕ:
  • В открывшемся окне графа СРМ доступны два способа создания:
    • Способ 1: Нажмите кнопку "Добавить" в верхней панели инструментов
    • Способ 2: Используйте контекстное меню (ПКМ на пустой области графа)
  1. Настройка параметров КЕ:
  • В диалоговом окне создания:
    1. Выберите тип "Памир" из списка доступных ТКЕ
    2. Нажмите "Создать"
  • Особенности:
    • Заполнение атрибутов не требуется (КЕ является singleton)
    • При попытке создать дубликат система:
      • Выведет предупреждение о существовании аналогичной КЕ
      • Предложит варианты разрешения конфликта

Важные примечания​

  1. Особенности singleton-КЕ:
  • Система допускает существование только одного экземпляра КЕ типа "Памир"
  • Все последующие попытки создания будут приводить к слиянию с существующим экземпляром
подсказка

В будущих версиях интерфейс создания КЕ будет упрощен:

  • Добавится прямое создание из меню ТКЕ
  • Уменьшится количество требуемых действий
  • Упростится обработка конфликтов

4. Запуск процесса обогащения​

Для построения структуры СРМ Памир необходимо выполнить следующие действия:

  1. Выбор целевой КЕ:
  • В интерфейсе графа СРМ найдите и выделите КЕ типа "Памир"
  • В правой боковой панели управления нажмите кнопку "Запустить обогащение"
  1. Процесс выполнения:
  • Операция выполняется асинхронно
  • Запрос поступает в очередь задач:
  • Статус выполнения можно отслеживать в системе уведомлений

Система уведомлений​

Пользователь получает автоматические уведомления:

  • При постановке задачи в очередь
  • По завершении процесса обогащения
  • В случае возникновения ошибок

Пример уведомления:

Результаты выполнения​

После успешного завершения процесса:

  • Автоматически строится полная СРМ Памир
  • Все связанные КЕ создаются и заполняются данными
  • Устанавливаются соответствующие связи между элементами

Финальный результат:

Особенности процесса:

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

5. Настройка автоматического обогащения по расписанию​

Для настройки автоматического запуска процесса обогащения:

  1. Переход в раздел настроек:
  • Откройте: Главная → Настройки → СРМ → Планы обогащения
  • Нажмите кнопку "Создать план"
  1. Конфигурация плана:
  • Выборка КЕ:
    • Укажите TQL-запрос для отбора конфигурационных единиц
    • Обогащение будет применяться ко всем КЕ, соответствующим критериям
  • Расписание:
    • Задайте периодичность с помощью CRON-выражений
    • Примеры расписаний: 
      Ежедневно в 02:00 → 0 2 * * *
      Каждый час → 0 * * * *
      По рабочим дням в 09:00 → 0 9 * * 1-5

Особенности работы​

  • Планы выполняются фоновым сервисом
  • Статус выполнения можно отслеживать в журнале заданий
  • При необходимости можно запустить план вручную без ожидания расписания
  • Доступна история выполненных обогащений с результатами

Рекомендации:

  1. Для критически важных КЕ устанавливайте более частое расписание
  2. Избегайте одновременного запуска множества ресурсоемких планов
  3. Для сложных структур рекомендуется ночное время выполнения
CRON-формат использует стандартный синтаксис:
* * * * * 
│ │ │ │ │
│ │ │ │ └─ День недели (0-6)
│ │ │ └─── Месяц (1-12)
│ │ └───── День месяца (1-31)
│ └─────── Час (0-23)
└───────── Минута (0-59)

6. Создание шаблона мониторинга​

Шаблон мониторинга позволяет централизованно настроить:

  • область действия для конфигурационных единиц
  • таргеты для сбора метрик Prometheus
  • индикаторы здоровья сервисов

Определение области действия шаблона мониторинга​

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

Основные группы КЕ для мониторинга:

  1. Экземпляр Памир
    Достаточно просто указать в TQL тип КЕ Памир. Так как это singleton-объект, запрос всегда будет возвращать один и тот же экземпляр.

  2. Все сервисы платформы
    Все сервисы Памир работают в Docker-контейнерах. Чтобы включить их в мониторинг, используем ТКЕ Сервис Памир. Это даст нам полный список контейнерных сервисов.

  3. Специфичные Python-сервисы
    Python-сервисы не выделены в отдельный тип КЕ, поэтому мы применяем фильтрацию:

  • Сначала выбираем все сервисы
  • Затем добавляем фильтр по названиям конкретных Python-сервисов
  • Используем логическое условие ИЛИ для перечисления всех нужных сервисов
  1. Сервисы с лицензионными метриками
    Отдельно выделяем сервисы, для которых нужно отслеживать использование лицензий.

Совет по организации:
После настройки запроса вы можете заметить, что некоторые узлы в TQL имеют одинаковые названия, но разные ID. Для удобства рекомендуем переименовать их в более понятные обозначения, например:

  • "Все сервисы" - для полного списка
  • "Python сервисы" - для Python-приложений

Настройка метрик​

Для Памир используются статические таргеты Prometheus, поэтому:

  • Дополнительная настройка метрик не требуется
  • Сбор данных осуществляется по предустановленным заданиям

Настройка индикаторов здоровья​

Давайте настроим мониторинг работоспособности наших сервисов на примере индикатора загрузки процессора. Возьмем для примера показатель Средняя загрузка ЦП за 30 минут.

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

Пошаговая настройка:

  1. Выбираем область действия:
  • Так как мониторинг загрузки CPU важен для всех сервисов, выбираем в TQL узел "Все сервисы"
  1. Настраиваем связь метрик с КЕ:
  • В поле "Правило формирования ci_hint" указываем шаблон: [[node_5.attributes.name]]
  • Это значит, что система будет сопоставлять метрики с сервисами по их названиям
  1. Настраиваем алертинг:
  • Указываем, что Prometheus должен добавлять в алерты лейбл ci_hint
  • Значение берется из лейбла метрики container_label_com_docker_compose_service

Остальные индикаторы (Состояние лицензии, Состояние сервиса и т.д.) настраиваются аналогичным образом. Когда все необходимые индикаторы будут готовы, просто выделяем их в таблице и нажимаем кнопку "Применить". Система активирует мониторинг по всем заданным параметрам.

примечание

Для важных сервисов можно настроить более строгие пороговые значения, чем для второстепенных.

7. Настройка Дашбордов​

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

  1. Формирование TQL-запроса

    • Откройте раздел Главная / СРМ
    • Перейдите в инструмент поиска
    • Постепенно добавьте в запрос:
      • Основной ТКЕ "Памир" (главный узел системы)
      • Все связанные ТКЕ сервисов
    • Свяжите компоненты соответствующими отношениями
    • Сохраните запрос для дальнейшего использования

  2. Проверка корректности данных

    • Воспользуйтесь функцией Подсчитать КЕ (кнопка в левом нижнем углу)
    • Убедитесь, что на каждом узле отображается ожидаемое количество КЕ
    • Пример корректного отображения:

  3. Предварительный просмотр

    • Примените TQL-запрос
    • Переключитесь на схему "Мониторинг"
    • Проверьте текущие статусы индикаторов здоровья:

Создание и настройка дашборда​

Перейдем к непосредственному созданию панели мониторинга:

  1. Инициализация создания

    • Перейдите в Главная / Дашборды
    • Нажмите кнопку Добавить

  2. Основные параметры

    • Задайте понятное название (например, "Общий мониторинг Памир")
    • Выберите сохраненный TQL-запрос из предыдущего шага
    • Настройте временной диапазон отображения данных
    • Добавьте соответствующие теги для удобства поиска

  3. Сохранение и доступ

    • Нажмите "Сохранить"
    • Для открытия используйте меню в общей таблице дашбордов

Советы по эффективному использованию:

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

Готовый дашборд автоматически обновляется согласно заданному временному диапазону. Для оперативного мониторинга рекомендуется использовать короткие интервалы (например, "Последние 4 часа").