Обзор системы мониторинга
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: Агентный мониторинг
Принцип работы
- Агент устанавливается на целевой узел (Windows или Linux)
- Система создает периодические задачи для сбора метрик
- Задачи выполняются по расписанию
- Сервер отправляет запрос к агенту через защищенное соединение
- Агент собирает актуальные данные с системы
- Данные передаются обратно в INFRAX и сохраняются
- Детальная информация о системных ресурсах
- Низкая нагрузка на сеть (данные передаются сжато)
- Доступ к внутренним метрикам ОС
- Мониторинг процессов и сервисов
Метод 2: Ping-мониторинг
Принцип работы
- Система создает периодическую задачу проверки доступности узлов
- Задача запускается каждые 1-5 минут (настраивается)
- Сервер отправляет ICMP Echo Request ко всем активным узлам
- Измеряется время отклика (RTT) и потеря пакетов
- Результаты сохраняются для анализа и отображения
Ping-мониторинг идеален для узлов, на которых невозможно установить агент: сетевое оборудование, принтеры, IoT устройства, или когда требуется только проверка доступности.
Метод 3: Проверка SSL сертификатов
Принцип работы
- Система создает задачу проверки SSL сертификатов
- Сервер подключается к узлу по HTTPS
- Извлекается информация о сертификате
- Проверяется срок действия и валидность
- При истечении срока создается тикет в 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
Не включайте автоматическое создание тикетов для всех метрик сразу. Начните с критичных узлов и инцидентов, затем постепенно расширяйте охват по мере адаптации команды.