От хаоса к порядку: автоматизация мониторинга СУБД в гибридных средах

Всем привет! Недавно закончился PGConf, где большая часть докладов была посвящена новым фичам PostgreSQL Pro, и лишь немногие касались ванильной версии. Попробую разнообразить повестку и рассказать что мы делаем с уклоном на мониторинг PG .

В Прометей Лаб я влился с октября 2024 года и начал развивать сервис администрирования баз данных. Сегодня я хочу поделиться нашим подходом к мониторингу, который экономит время и нервы.

Если вы DBA, то вы наверняка сталкивались с задачей мониторинга десятков инстансов баз данных — PostgreSQL, MSSQL, MariaDB, Oracle или что-то из NoSQL — на разных ОС, от bare metal до PaaS. Настройка мониторинга в таких условиях может занять недели, а ошибки в алертинге приводят к простоям.

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

Я тоже через это проходил, поэтому в Прометей Лаб мы сфокусировались на переносимом, масштабируемом, k8s ready решении, на типовых компонентах которое можно оперативно развернуть и с минимальной болью занести в разрешенный техстек. В последней демо, при наличии тех учеток в бд, весь процесс подключения нового клиента к мониторингу с нуля занимает 40 минут и поддерживает кастомизацию под любые нужды.

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

Требования к решению

Вот вводные, которые определили наш подход:

• Разнообразие ОС у клиентов: Linux, Windows, иногда экзотические дистрибутивы.

• Гибридная инфраструктура: VM, bare metal, PaaS (Sber Cloud, Yandex Cloud).

• Масштаб: 30-50 инстансов баз данных на клиента.

• Разные СУБД: PostgreSQL, MariaDB, MSSQL, ClickHouse, Oracle.

• Минимальные усилия на настройку: Решение должно быть легко тиражируемым между клиентами.

• Кастомизация: Возможность добавлять свои метрики и специфические пороги.

• Cloud Ready: возможность упаковать все в хельмы и ставить в k8s 

Эти требования исключали использование ОС-специфичных инструментов и требовали легковесного, переносимого решения. Мы выбрали контейнеризацию через Docker, так как она решает следующие задачи:

• Автоматизация: GitLab CI + Docker Compose максимально упрощает конфигурирование и развертывание.

• Независимость от ОС: Не у всех есть k8s, а контейнеры все так же продолжают одинаково работать на Centos, Ubuntu, ALT linux etc.

• Простота тиражирования: Один набор конфигураций подходит для всех клиентов.

• Достаточная производительность: Для наших объемов (до 50 инстансов) текущей архитектуры более чем достаточно.

Наш стек мониторинга

• Victoria metrics stack:  для хранения и сбора метрик    

• Grafana: Визуализация метрик через дашборды.

• Экспортеры: Специализированные агенты для сбора метрик из PostgreSQL, MSSQL, MariaDB, Oracle и ClickHouse.

• Docker Compose: Единая точка развертывания всех компонентов.

• Alertmanager: Маршрутизация алертов в Telegram по каналам для критичных и некритичных событий. 

Мы выбрали Victoria metrics  по причине более оптимального потребления ресурсов и разделения его функциональности ( prometheus при рестарте мог запускаться по 5-10 минут ), в случае с викторией в 99.9% случаев хватает перезапуска vmagent c ДТ в секунды.

Структура конфигураций

Для повышения удобства и «читабельности» выносим все таргеты в отдельные группы и типы  

vmetrics/vmagent/targets ├── blackbox │   └── blackbox_dc_gw.yml ├── clickhouse │   └── sc-bi.yml ├── etcd │   └── etcd_ya_dc1.yml ├── mariadb │   └── mariadb.yml ├── mssql │   └── mssql_db.yml ├── node │   ├── clickhouse_sc-bi.yml │   ├── etcd_os_scrape.yml │   ├── haproxy_ya_dc1.yml │   ├── localhost.yml │   ├── mssql_os.yml │   ├── partoni_pg_common.yml │   ├── pg-common.yml │   └── psql-sc-bi.yml └── pgsql     └── pgsql_db.yml

и, там где это возможно, вычитываем конфигурацию директориями ( для критичных узлов приходиться создавать отдельный job со своим набором сертификатов ) 

scrape_configs:   #--------------------------------------------------------------#   # job: node no ssl   # node_exporter ( nodeexporter OS stats )   # labels: [cls, ins, ip, instance]   #--------------------------------------------------------------#   - job_name: node     scrape_interval: 10s     metrics_path: /metrics     file_sd_configs:       -  files: [ ./targets/node/*.yml ]   #--------------------------------------------------------------#   # job: etcd   # labels: [cls, ins, ip, instance]   # path: targets/etcd/<etcd_instance>.yml   #--------------------------------------------------------------#   - job_name: etcd     metrics_path: /metrics     file_sd_configs:       -  files: [ /etc/vmagent/targets/etcd/pg_common.yml ]     scheme: https     tls_config:       ca_file:   /etc/tls/pg_common/ca.crt       cert_file: /etc/tls/pg_common/server.crt       key_file:  /etc/tls/pg_common/server.key

Чтобы сохранить переносимость, кастомизацию алертов делаем через record rule и модификацию запросов

Чуть подробнее: 

      - alert: PostgreSQL_SlowQueries         expr: >-           pg_stat_activity_max_tx_duration {state!="idle in transaction"} > 300           unless pg:ins:pg_stat_activity_max_tx_duration_custom {}

unless pg:ins:pg_stat_activity_max_tx_duration_custom {}

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

Не то чтобы было очень удобно, но такой WA решает основную задачу — переносимость между клиентами ( весь кастом в отдельной папке и если ее убрать, то это не влияет на работоспособность  )

vmetrics/vmagent/ ├── alert_rules │   ├── blackbox_exporter_rules.yml │   ├── clickhouse_rules.yml │   ├── etcd_rules.yml │   ├── mssql_exporter_rules.yml │   ├── mysql_rules.yml │   ├── node_exporter_rules.yml │   ├── oracle_exporter_rules.yml │   ├── postgresql_rules.yml │   └── windows_os_rules.yml ├── custom_rules │   ├── node_alert_custom.yml │   ├── node_record_custom.yml │   ├── pgsql_alert_custom_rules.yml │   └── pgsql_record_custom.yml ├── record_rules │   ├── agent.yml │   ├── etcd.yml │   ├── mssql.yml │   ├── node.yml │   └── pgsql.yml

Делаем отдельные каналы для критов и warning, с делением на топики по типу СУБД

• при желании можно сделать любое деление, из очевидного — добавить в лейблы Код ИС и маршутизирововать алерты в целевой канал, актуально для зрелых проектов 

как видно на примере, мы делим алерты по направлениям (экспертизе команды) на разные направления

По самим алертам, сейчас накопился такой набор : 

Если тема будет интересна, то обязуюсь более подробно об этом рассказать в следующей статье (все ключевые направления уже закрыты: дедлоки, долгие транзакции, автовакуум, bloat, репликация,  коннекты, роллбеки, чекпойты, деддаплы)

Касаемо графиков.. чтобы не осталять совсем без информации, то исходники графиков PG можно глянуть тут https://demo.pigsty.io/ 

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

примеры дашбордов 

MS SQL Backup

PG: overview

Из ньюансов, т.к кластер обычно состоит больше чем из одного узла, то, для построения комплексных дашбордов, добавляем лейбл с именем кластера ( обычно это имя хоста без 01\02\03 ) 

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

  - labels: { cls: 'pg-common', ins: 'p01-pgdb01', ip: '10.2.20.10', type: 'postgres' }       targets:        - 10.2.20.10:9100

тут может закрасться мысль, что поддерживать в консистентном состоянии все порты экспортеров из докера, лейблы для node exporter\pg\haproxy\etcd\pgbouncer это … сложно ) и вы будете правы, поэтому лучше сразу сделать инвентарь с шаблонами по которым все заполняется автоматом.

Экспортеры

1)  PG pg_exporter:latest

используем наработки проекта https://github.com/Vonng/pg_exporter, только добавили вывод отладочной информации   

Плюсы: из коробки очень гибкая возможность настройки:

• в рамках одного экспортера можно делать кастомные запросы под разные версии PG

• настраивается TTL для кеширования запросов, чтобы контролировать overhead 

• настраивается timeout  

• все запросы описываются в понятном формате и их легко добавлять

2) MS SQL burningalchemist/sql_exporter:latest 

Выглядит многообещающим и суперуниверсальным, есть все шансы что кастомные запросы переведем на него

• Возможность кастомизации и добавления своих запросов.

• Поддерживает все нужные типы баз данных

из существенных минусов:

• нет поддержки TTL, как WA — запускать с нужной периодичностью тяжелые запросы и писать результаты в таблицу.

3) Mariadb prom/mysqld-exporter:latest

• покрывает 99% потребностей по части алертинга, но решение от pmm информативнее, все еще параллельно используем pmm при траблшутинге 

4) Oracle  iamseth/oracledb_exporter:latest 

• Есть необходимый набор базовых метрик

• Есть возможность подключить кастомные запросы 

дальше, докручиваем CD  которая запускает мини автоматизацию,  создает конфиги для экспортеров +  добавляет нужные лейблы, порты для таргетов

из ключевого, есть деление docker-compose файлов

• docker-compose.yml ( ядро мониторинга )

  • image: victoriametrics/victoria-metrics:latest

  • image: victoriametrics/vmagent:latest

  • image: victoriametrics/vmalert:latest

  • image: grafana/grafana

  • image: prom/alertmanager:latest

  • image: grafana/loki:latest 

• mssql.docker-compose.yml

• pgsql.docker-compose.yml

• oracle.docker-compose.yml

• maria.docker-compose.yml

• etc 

Ближайшие планы 

• Реализация долгосрочного хранения [Источники] → VM1 (сырые данные, 10s, 10d)] → [VM2 (downsampling, 1m, 60d)]

• Перестать мучать дежурных, доделать интеграцию alertmanager и Jira, с последующей  синхронизацией с учетными системами заказчика

• Сделать мониторинг на мониторинг или перенести все в k8s

• Добавить стадию CI и доработать CD 

  • Проверки синтаксиса конфигов перед применением изменений

  • Определять какой файл изменился и перезапускать\перечитывать конфиги только нужных компонентов

Заключение

С таким подходом подключение к мониторингу баз заказчика занимает минут 40-60, единообразно работает и поддерживает большинство СУБД, в качестве бонуса — видно кто и почему вносил изменения (например добавили метрику по итогам postmortem) да и все наработки легко переносить между клиентами.

Так же есть большой задел для кастомизации и переиспользования на разных проектах  

ps: Однозначно еще есть что улучшить..  

pps: готов поделиться текущим состоянием и исходниками по запросу в ЛС (abushmelev@prometey-lab.ru) при условии конструктивной обратной связи 🙂