Обзор системы мониторинга СУБД Lumen и встроенного ИИ-ассистента

Зачем нужен новый инструмент мониторинга СУБД

Имея за плечами около 15 лет практики в сфере администрирования баз данных и работая старшим инженером по СУБД, я успел протестировать множество специализированных платформ. В моем персональном рейтинге долгое время лидировал комплекс Spotlight for SQL Enterprise от Quest Software. Он предлагал наглядную визуализацию и глубину аналитики, необходимую DBA в ежедневной эксплуатации.

Однако после ухода Quest Software с российского рынка многие команды столкнулись с необходимостью поиска полноценной замены. Анализ существующих альтернатив показал, что готовых решений аналогичного класса практически нет. Это побудило меня применить накопленный практический опыт и разработать собственную платформу мониторинга — Lumen.

Архитектура платформы и технологический стек

В основу Lumen заложен безагентный подход, схожий с концепцией Spotlight. Центральным звеном системы выступает Diagnostic Server, который разворачивается на хосте под управлением Windows. Он отвечает за установку соединений с целевыми серверами баз данных и сбор метрик. На сами целевые узлы устанавливать дополнительное ПО не требуется — достаточно настроить соответствующие права доступа на уровне СУБД и операционной системы.

Если взглянуть на структуру исходного кода проекта в Git-репозитории, основная распределение языков выглядит следующим образом: ключевой бэкенд и логика сбора написаны на C# (78%), пользовательский интерфейс и веб-компоненты задействуют TypeScript (13%), а специализированные скрипты сбора метрик выполнены на T-SQL (5%).

Поддерживаемые целевые системы и метрики

На сегодняшний день Lumen умеет контролировать состояние MS SQL Server, PostgreSQL, операционной системы Windows, а также мониторить состояние самого сервиса сбора. Собираемый набоp данных полностью перекрывает повседневные задачи администратора баз данных:

• Мониторинг активных сессий и блокировок;
• Анализ использования оперативной памяти и дисковой подсистемы;
• Контроль резервного копирования, статуса High Availability (HA) и репликации.

В ближайших планах развития платформы запланировано расширение поддержки на среды Linux и СУБД MySQL.

Механика сбора данных и структура хранения

За непосредственное получение показаний отвечает служба Lumen Diagnostic Server (LDS). Внутри нее функционирует 137 специализированных сборщиков, а базовый комплект содержит 100 готовых правил алертинга. Частота опроса гибко варьируется в зависимости от критичности метрики:

• Данные по сессиям и блокировкам снимаются каждые 30 секунд;
• Инвентаризация списка баз данных и файлов осуществляется раз в час.

Все метрики, снимаемые с SQL Server, PostgreSQL и целевых хостов Windows, агрегируются в единой точке. Diagnostic Server делает срез показателей и фиксирует его в двух внутренних специализированных базах данных.

Функция Playback: исторический реплицированный анализ

Одной из главных проблем при разборе сбоев является ситуация, когда инцидент уже завершился, и на текущий момент показатели сервера вернулись в норму. Для детального проведения postmortem-анализа в Lumen реализован модуль Playback.

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

Система оповещений и настройка правил

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

Дашборды и углубленная детализация (Drilldowns)

Структура интерфейса привычна экспертам, работавшим со Spotlight. В левой части консоли находится дерево подсоединенных хостов. При выборе конкретного узла открывается главный экран (Home Drilldown) с ключевыми индикаторами здоровья системы. Для глубокого анализа предусмотрен набор специализированных экранов детализации:

• Memory Drilldown: анализ распределения памяти и кэшей;
• Waits Drilldown: разбор типов ожиданий СУБД;
• Database Drilldown: показатели на уровне отдельных баз данных;
• Workload Drilldown: динамика общей нагрузки;
• TempDB Check & Usage: мониторинг использования системной базы TempDB и поиск причин ее разрастания;
• SQL Activity Sessions: рабочий стол для исследования активных сессий, включая просмотр тяжелых планов запросов (Plan View) и детальный ввод-вывод по файлам данных (Disk I/O by File).

Экспресс-анализ нагрузки (Workload Analysis)

Для быстрого выявления источников проблем в системе предусмотрен инструмент экспресс-анализа нагрузки. On-demand срезы позволяют за пару кликов получить наглядные отчеты за последний час:

• Топ процессов и запросов, активно утилизирующих ресурсы процессорного времени (CPU);
• Рейтинг самых продолжительных по времени выполнения SQL-запросов.

Внедрение ИИ-оператора на базе локальной LLM

Интересной фичей проекта стала интеграция интеллектуального ИИ-агента непосредственно в контур мониторинга. Идея заключалась в создании автономного ассистента, круглосуточно отслеживающего состояние серверов и самостоятельно проводящего первичную диагностику.

Архитектура ИИ-оператора строится на двух ключевых ролях:

• Хранитель (Watcher): индивидуальный агент, закрепляемый за каждым подключением. Он использует локальную модель Llama 3.1, оснащен механизмом RAG и набором диагностических инструментов. При фиксировании аномалии Хранитель передает сигнал управляющему компоненту;
• Супервизор (Supervisor): оркестратор, выполняющий первичную аналитику. Он запрашивает у Хранителя дополнительные метрики, анализирует контекст, после чего формирует емкое заключение и отправляет его оператору в чат.

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

Тестирование Qwen3.8-Flash-Next 125B на потребительском железе

Параллельно с разработкой инструментария мониторинга я провел эксперимент по запуску открытой модели Qwen3.8-Flash-Next (125B), созданной на базе архитектурных решений будущего поколения Qwen4. Данная нейросеть демонстрирует высокие показатели в написании кода, агентных сценариях и задачах управления интерфейсом, конкурируя с проприетарными флагманскими решениями.

Нам удалось развернуть полный чекпоинт Qwen/Qwen3.8-Flash-Next на одной локальной видеокарте NVIDIA GeForce RTX 4090. Пиковое потребление видеопамяти составило всего 5,95 ГБ VRAM без применения 4-битного квантования или дистилляции. Модель запускалась в оригинальном формате bf16 и полноценно генерировала токены, показав отличную применимость для задач локального анализа и автоматизации.

Источник: habr.com