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

ℹ️ О системе мониторинга

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

Архитектура мониторинга

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

Основные компоненты

1. Агенты мониторинга

  • Агенты на узлах — устанавливаются на Windows и Linux серверы для сбора детальных метрик
  • Периодический опрос — агенты регулярно отправляют данные на сервер INFRAX
  • Легковесность — минимальное потребление ресурсов на мониторируемых узлах
  • Автообновление — возможность централизованного обновления агентов

2. Централизованный сервис мониторинга

  • Ping-мониторинг — проверка доступности узлов без установки агентов
  • Проверка SSL сертификатов — мониторинг срока действия сертификатов
  • Мониторинг виртуализации — отслеживание состояния платформ виртуализации

3. Хранилище метрик

  • Надежное хранение данных — сохранение временных рядов метрик
  • Автоматическая ротация — периодическое удаление старых данных
  • Оптимизация хранения — два режима: полная история и последние значения
  • Быстрый доступ — оптимизированный поиск исторических данных

4. Система правил и триггеров

  • Гибкие правила мониторинга — настройка порогов и условий срабатывания
  • История триггеров — запись всех срабатываний правил
  • Автоматическое создание тикетов — интеграция с системой Helpdesk
  • Автозакрытие инцидентов — закрытие тикетов при нормализации показателей

5. Система очередей задач

  • Асинхронная обработка — сбор метрик не блокирует основную работу системы
  • Планировщик задач — регулярный запуск задач мониторинга по расписанию
  • Повторные попытки — автоматический retry при временных сбоях
  • Приоритизация — управление порядком выполнения задач

Схема взаимодействия компонентов

┌─────────────────┐         ┌──────────────────┐
│  Узлы с агентами │────────>│  Бэкенд INFRAX   │
└─────────────────┘         │  (Очередь задач) │
                            └────────┬─────────┘
                                    │
                                    ▼
                           ┌─────────────────┐
                           │  PostgreSQL     │
                           │  (метрики)      │
                           └────────┬────────┘
                                    │
                                    ▼
                           ┌─────────────────┐
                           │  Движок правил  │
                           │  мониторинга    │
                           └────────┬────────┘
                                    │
                                    ▼
                           ┌─────────────────┐
                           │  Helpdesk       │
                           │  (создание      │
                           │   тикетов)      │
                           └─────────────────┘

Типы метрик

Система мониторинга INFRAX поддерживает широкий спектр метрик для всестороннего контроля состояния инфраструктуры.

Базовые метрики доступности

Метрика Описание Источник данных
Ping (доступность) Проверка доступности узла и измерение времени отклика (RTT) Централизованный ping с сервера INFRAX
Потеря пакетов Процент потерянных пакетов при ping-проверке Централизованный ping

Системные ресурсы

Метрика Описание Источник данных
CPU (процессор) Загрузка процессора в процентах, загрузка по ядрам Агент (Windows/Linux)
RAM (память) Использование оперативной памяти, свободная/занятая память Агент (Windows/Linux)
Disk (диски) Использование дискового пространства для каждого раздела Агент (Windows/Linux)
Network (сеть) Входящий и исходящий трафик по интерфейсам Агент (Windows/Linux)

SSL сертификаты

Метрика Описание Источник данных
Срок действия Проверка даты истечения SSL сертификата Периодическая задача
Валидность Проверка корректности сертификата Периодическая задача

Субъекты мониторинга

Метрики могут быть привязаны к различным субъектам (компонентам) узла:

Доступные типы субъектов

  • Хранилище: Физический диск, Логический том, Файловая система, RAID массив
  • Сеть: Сетевой интерфейс, Беспроводной интерфейс, VLAN, Порт моста
  • Системные ресурсы: CPU, Память, Swap, Средняя нагрузка, Время работы (uptime)
  • Датчики/питание: Температура, Вентилятор, Блок питания, Батарея, Датчик, ИБП
  • ПО/сервисы: Процесс, Сервис
  • Виртуализация: Виртуальная машина, Контейнер
  • Другое: Прочие метрики

Сбор данных

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

Метод 1: Агентный мониторинг

Принцип работы

  1. Агент устанавливается на целевой узел (Windows или Linux)
  2. Система создает периодические задачи для сбора метрик
  3. Задачи выполняются по расписанию
  4. Сервер отправляет запрос к агенту через защищенное соединение
  5. Агент собирает актуальные данные с системы
  6. Данные передаются обратно в INFRAX и сохраняются
✅ Преимущества агентного мониторинга
  • Детальная информация о системных ресурсах
  • Низкая нагрузка на сеть (данные передаются сжато)
  • Доступ к внутренним метрикам ОС
  • Мониторинг процессов и сервисов

Метод 2: Ping-мониторинг

Принцип работы

  1. Система создает периодическую задачу проверки доступности узлов
  2. Задача запускается каждые 1-5 минут (настраивается)
  3. Сервер отправляет ICMP Echo Request ко всем активным узлам
  4. Измеряется время отклика (RTT) и потеря пакетов
  5. Результаты сохраняются для анализа и отображения
ℹ️ Когда использовать ping-мониторинг

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

Метод 3: Проверка SSL сертификатов

Принцип работы

  1. Система создает задачу проверки SSL сертификатов
  2. Сервер подключается к узлу по HTTPS
  3. Извлекается информация о сертификате
  4. Проверяется срок действия и валидность
  5. При истечении срока создается тикет в Helpdesk

Интервалы сбора данных

Тип метрики Стандартный интервал Настраивается
Ping 1-5 минут Да (в настройках cron-задачи)
CPU, RAM 1-5 минут Да (в настройках cron-задачи)
Диски 5-15 минут Да (в настройках cron-задачи)
Сетевые интерфейсы 1-5 минут Да (в настройках cron-задачи)
SSL сертификаты 1 раз в день Да (в настройках cron-задачи)

Хранение данных

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

Типы хранимых данных

История метрик (history)

  • История ping-данных (RTT, потеря пакетов)
  • История загрузки CPU
  • История использования RAM
  • История использования дисков
  • История сетевого трафика

Последние значения (last state)

  • Хранятся последние 3 значения метрик
  • Используется для быстрого доступа к актуальным данным
  • Оптимизировано для метрик с режимом хранения last_3

История инцидентов

  • История срабатываний правил мониторинга
  • Информация о начале и окончании инцидентов
  • Связь с тикетами Helpdesk

Режимы хранения метрик

Режим Описание Применение
history Полная история значений с временными метками Метрики, для которых важна динамика (CPU, RAM, Ping)
last_3 Хранятся только последние 3 значения в JSONB Метрики, для которых не нужна полная история (версии ПО, статусы)
ℹ️ Выбор режима хранения

Режим history позволяет строить графики временных рядов и анализировать тренды. Режим last_3 экономит место и подходит для метрик, где важно только текущее состояние.

Оптимизация хранения

Автоматическая ротация данных

История метрик автоматически оптимизируется:

  • Данные организованы по временным периодам
  • Старые данные автоматически удаляются
  • Ускорен доступ к недавним данным
  • Упрощена очистка устаревшей информации

Прореживание точек графиков

Для ускорения отображения графиков используется интеллектуальная оптимизация:

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

Ротация данных

Автоматическая очистка

Система автоматически удаляет старые данные мониторинга:

  • Периодическая задача очистки выполняется автоматически
  • Удаляются данные старше заданного срока (настраивается)
  • Типовой срок хранения: 30-90 дней для детальных метрик
  • История инцидентов хранится дольше для анализа
✅ Преимущества архитектуры хранения
  • Быстрый доступ к актуальным данным
  • Эффективное использование дискового пространства
  • Масштабируемость для большого количества узлов
  • Гибкая настройка сроков хранения

Процесс мониторинга

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

Жизненный цикл метрики

1. Сбор данных
   ├─> Агент/Ping запрашивает данные
   └─> Данные отправляются в INFRAX

2. Сохранение в БД
   ├─> Запись в таблицу history или last_state
   └─> Обновление временной метки

3. Проверка правил (Triggers)
   ├─> Сравнение значения с порогами
   ├─> Проверка условий срабатывания
   └─> Подсчет последовательных превышений

4. Срабатывание триггера (если условия выполнены)
   ├─> Создание записи об инциденте
   ├─> Автоматическое создание тикета в Helpdesk
   └─> Отправка уведомлений (Telegram, Email)

5. Нормализация показателей
   ├─> Метрика возвращается в норму
   ├─> Закрытие инцидента
   └─> Автозакрытие тикета (если включено)

6. Ротация данных
   ├─> Периодическое удаление старых партиций
   └─> Освобождение дискового пространства

Настройка и просмотр мониторинга

Настройки мониторинга доступны в карточке узла на вкладке "Мониторинг", где можно настроить параметры для каждого типа метрик (доступность, CPU, RAM, диски) и условия создания тикетов. Настройки поддерживают иерархическое наследование от папок к узлам.

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

Рекомендации по настройке

Выбор метода мониторинга

Тип узла Рекомендуемый метод Обоснование
Windows/Linux серверы Агентный мониторинг Детальные метрики системных ресурсов
Сетевое оборудование Ping мониторинг Проверка доступности без установки ПО
Принтеры, IoT Ping мониторинг Проверка доступности без установки ПО
Веб-сервисы SSL мониторинг + Ping Контроль сертификатов и доступности

Настройка порогов срабатывания

CPU

  • Нормальная загрузка: 70-80% порог, 3-5 превышений подряд
  • Критическая загрузка: 90% порог, 2-3 превышения подряд
  • Учитывайте специфику узла (веб-серверы могут иметь выше порог)

RAM

  • Предупреждение: 80% порог, 3-5 превышений подряд
  • Критическое: 95% порог, 2-3 превышения подряд
  • Для Linux учитывайте использование кеша

Диски

  • Предупреждение: 80-85% заполнения
  • Критическое: 90-95% заполнения
  • Для системных разделов используйте более строгие пороги

Ping

  • Обычные узлы: 3-5 неудачных попыток подряд
  • Критичные сервисы: 2 неудачные попытки подряд
  • Увеличьте количество для узлов с нестабильной сетью

Оптимизация производительности

Для больших инфраструктур

  • Увеличьте интервалы сбора некритичных метрик (диски, SSL)
  • Используйте режим last_3 для статусных метрик
  • Настройте агрессивную ротацию старых данных
  • Распределите задачи сбора метрик по времени

Интеграция с Helpdesk

Автоматизация реагирования

  • Включайте автоматическое создание тикетов для критичных метрик
  • Используйте автозакрытие тикетов при нормализации показателей
  • Настройте приоритеты тикетов в зависимости от типа инцидента
  • Назначайте исполнителей автоматически через правила Helpdesk
⚠️ Избегайте переизбытка тикетов

Не включайте автоматическое создание тикетов для всех метрик сразу. Начните с критичных узлов и инцидентов, затем постепенно расширяйте охват по мере адаптации команды.