Как упростить управление целым парком из 800+ экземпляров СУБД на базе PostgreSQL? Можно доработать postgres_exporter, чтобы настроить получение метрик под себя. А если ещё проще? Мониторить связкой Grafana, Prometheus и кастомизированным p...
Как упростить управление целым парком из 800+ экземпляров СУБД на базе PostgreSQL? Можно доработать postgres_exporter, чтобы настроить получение метрик под себя. А если ещё проще? Мониторить связкой Grafana, Prometheus и кастомизированным postgres_exporter, а данные получать через ИИ‑отчёт, который будет агрегировать данные Prometheus через прямые PromQL‑запросы.
Но если и этого мало, то можно вообще поручить ИИ‑агенту типовые тикеты вроде очистки места на диске и плановой остановки БД.
Меня зовут Станислав Епишин, я из команды «R4C.Support.Всадники апокалипсиса» в СберТехе. Я уже писал, как мы дорабатывали postgres_exporter → pangolin_exporter, исправляя баг в расчёте длительности транзакций, и как внедряли связку Prometheus + Pipeliner + TaskTracker + GigaChat для автоматического создания тикетов.
В этой статье расскажу про R&D‑исследование для небольшой команды DBA, в котором мы тестировали гипотезу: получится ли собрать автономного агента, который сам будет обрабатывать тикеты: очищать дисковое пространство, выполнять VACUUM/ANALYZE и планировать остановки БД?
Здесь я описал инструкцию по созданию агента (с полным кодом и пояснениями) и развёрнутый реальный пример про автономный VACUUM/ANALYZE с обнаружением аномалий через LLM. Также покажу, как организовать ленту событий для мониторинга работы агента, и детально разберу, где и как в проекте используется LLM.