Всем привет! Недавно закончился 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) при условии конструктивной обратной связи :-)
