Ко всем новостям

Как мы доработали postgres_exporter для мониторинга событий в БД

25.09.2024

ривет, Хабр! Меня зовут Станислав Епишин, я DBA в дивизионе поддержки решений в тестовых средах в СберТехе. Эту статью я написал вместе с Дмитрием Корневым, тимлидом и DBA. У Сбера есть целевая СУБД, которую разработали в СберТехе на основе open source версии PostgreSQL, — Platform V Pangolin. Наша команда перешла на Pangolin в числе первых, когда у продукта еще не было инструментов для мониторинга БД. Забегая вперед, позже появились такие решения — графическая консоль Platform V Kintsugi, расширение для сбора статистики — Performance Insights и система мониторинга IT‑инфраструктуры Platform V Monitor. А поначалу мы решили мониторить базы данных связкой Grafana, Prometheus и postgres_exporter. Но, во‑первых, столкнулись, с тем, что нам не хватает гибкости в использовании queries.yaml в postgres exporter. А, во‑вторых, так мы не могли регистрировать события с таймаутом меньше 15 секунд. Поэтому мы тогда сделали свой инструмент для мониторинга — pangolin_exporter

Надеюсь, что эта статья будет полезна тем, кто мониторит инфраструктуру с помощью postgres_exporter и хочет кастомизировать всё под свои нужды. Покажу детали и код решения.

Наши условия таковы: на сопровождении примерно 1200 баз данных, структура динамическая — их количество меняется, создаются новые, удаляются неактуальные. Нам требовалось реализовать динамическое распространение postgres_exporter (это инструмент PostgreSQL для сбора метрик с экземпляров кластера СУБД в формате, доступном Prometheus) по серверам, желательно с периодом 24 часа. Пробуем использовать Jenkins и сценарии Ansible для автоматизации развёртывания postgres_exporter. Итак, здесь всё хорошо: сценарии написаны, решение реализовано.Далее нам надо было получать актуальные для нас метрики, в том числе специфические для Platform V Pangolin. Мы хотели наблюдать статистику активности и выполнения запросов и функций, ввода-вывода, WAL, доступности и актуальности снимков performance_insights и pg_profile и так далее. А также нам хотелось получать метрики по Pangolin Manager и Pangolin Pooler — это улучшенные и переработанные версии Patroni и Pgbouncer. Но, как я уже упоминал в начале, мы столкнулись с тем, что в postgres_exporter не можем гибко настроить получение метрик под себя.Тогда мы решили взять исходный код инструмента и сделать форк на его основе. Создавая решение, мы черпали много информации из книги «Мониторинг PostgreSQL» Алексея Лесовского (спасибо Алексею за дельные и полезные идеи!).

Начинаем делать свой экспортёр

Создаём pangolin_exporter из исходников последней версии postgres_exporter-0.15.0 с GitHub. Для проекта мы использовали Microsoft VS Code, настройка под Go не вызвала каких‑то трудностей. Задаём переменные окружения для сборки и запуска экспортёра. Определяем переменную GOOS. При желании можно собрать версию под Windows, присвоив значение Windows. В нашем случае мы присваиваем значение Linux.

"GOOS": "linux"

Определяем переменную DATA_SOURCE_NAME, содержащую строку подключения к БД, с которой будем собирать метрики. В учебных целях для этого примера определяем учётные данные в открытом виде. Меняем <user>:<pass>@<hostname> на актуальные данные.

"DATA_SOURCE_NAME": "postgresql://<user>:<pass>@<hostname>:5432/postgres?sslmode=disable"

Для этого добавляем пару файлов в проект:

/<project_path>/cmd/postgres_exporter/.vscode/launch.json

/<project_path>/cmd/postgres_exporter/.vscode/settings.json

settings.json

{ "go.toolsEnvVars": { "GOOS": "linux" } }

launch.json

{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Launch Package", "type": "go", "request": "launch", "mode": "auto", "program": "${fileDirname}", "env": { "DATA_SOURCE_NAME": "postgresql://<user>:<pass>@<hostname>:5432/postgres?sslmode=disable" } } ] }

Собираем бинарник из исходников:

cd /<project_path>/cmd/postgres_exporter go build -o /<project_path>/cmd/postgres_exporter/build .

Запускаем в Microsoft VS Code, для этого нужно открыть main.go и нажать F5, при необходимости пошагово отлаживаем код, расставляя breakpoints.

Далее добавляем необходимые нам метрики и редактируем существующие. Для редактирования в пакете collector находим нужную метрику. Файлы пакета находятся в каталоге /<project_path>/collector.

Рассмотрим пример добавления метрики для определения версии Pangolin. Планируем SQL-запрос для получения данных:

select product_version from product_version();

Версия Pangolin будет выводиться в label, метрика будет равна 1, если SQL-запрос выполнен. Добавляем новый файл в пакет collector, путь /<project_path>/collector.

package collector import ( "context" "database/sql" "github.com/go-kit/log" "github.com/prometheus/client_golang/prometheus" ) const InfoPangolinSubsystem = "" func init() { registerCollector(InfoPangolinSubsystem, defaultEnabled, NewPGInfoPangolinCollector) } type PGInfoPangolinCollector struct { log log.Logger } func NewPGInfoPangolinCollector(config collectorConfig) (Collector, error) { return &PGInfoPangolinCollector{log: config.logger}, nil } var ( InfoPangolinVersion = prometheus.NewDesc( prometheus.BuildFQName(namespace_pangolin, InfoPangolinSubsystem, "version"), "Pangolin version.", []string{"product_version"}, prometheus.Labels{}, ) pgInfoPangolinQuery = `select product_version from product_version();` ) func (c PGInfoPangolinCollector) Update(ctx context.Context, instance *instance, ch chan<- prometheus.Metric) error { db := instance.getDB() rows, err := db.QueryContext(ctx, pgInfoPangolinQuery) if err != nil { return err } defer rows.Close() for rows.Next() { var product_version sql.NullString if err := rows.Scan(&product_version); err != nil { return err } product_versionLabel := "unknown" upMetric := 0.0 if product_version.Valid { product_versionLabel = product_version.String upMetric = 1 } else { upMetric = 0 } ch <- prometheus.MustNewConstMetric( InfoPangolinVersion, prometheus.CounterValue, upMetric, product_versionLabel, ) } if err := rows.Err(); err != nil { return err } return nil }

Запускаем экспортёр, при настройках порта по умолчанию вбиваем в веб-браузер http://localhost:9187/metrics и видим нашу новую метрику:

# HELP pangolin_version Pangolin version

# TYPE pangolin_version counter

pangolin_version{product_version="Platform V Pangolin 5.5.0"} 1

Набредаем на баг в Postgres Exporter и другие грабли

Делая своё решение, попутно нашли баг в исходном коде postgres_exporter. Нам нужно было определить рост ожиданий в зависимости от нагрузки, чтобы понять, насколько АС подвержена риску на ПРОМе. Целиком можно было закрыть риск, проведя нагрузочное тестирование и посмотрев на события ожидания от LockManager, — это фоновый процесс в Pangolin, отвечающий за блокировки структур данных. Вариант решения заключался в использовании оригинальной метрики pg_stat_activity_max_tx_duration из Postgres_exporter.

pg_stat_activity_max_tx_duration — максимальная продолжительность выполнения активной транзакции в секундах.

Однако после изучения SQL‑запроса этой метрики (см. ниже), выяснилось, что для pg_stat_activity_max_tx_duration возраст транзакций рассчитывается некорректно. Возраст существующих на конкретный момент транзакций должен определяться следующим образом: текущее время минус время начала транзакции. А на деле вместо текущего времени подставляется время запуска текущей транзакции, now (), то есть в нашем случае это время начала другой транзакции, и поэтому получается некорректное значение.

now() → timestamp with time zone. Current date and time (start of current transaction);clock_timestamp() → timestamp with time zone. Current date and time (changes during statement execution)

Некорректные значения скрывались агрегатной функцией max.

MAX(EXTRACT(EPOCH FROM now() - xact_start))::float AS max_tx_duration

Для мониторинга необходимо использовать clock_timestamp(), которая всегда показывает текущую отметку времени. Запрос, использующийся в оригинальной версии postgres_exporter для max_tx_duration:

SELECT pg_database.datname, tmp.state, tmp2.usename, tmp2.application_name, COALESCE(count,0) as count, COALESCE(max_tx_duration,0) as max_tx_duration FROM ( VALUES ('active'), ('idle'), ('idle in transaction'), ('idle in transaction (aborted)'), ('fastpath function call'), ('disabled') ) AS tmp(state) CROSS JOIN pg_database LEFT JOIN ( SELECT datname, state, usename, application_name, count(*) AS count, MAX(EXTRACT(EPOCH FROM now() - xact_start))::float AS max_tx_duration FROM pg_stat_activity GROUP BY datname,state,usename,application_name) AS tmp2 ON tmp.state = tmp2.state AND pg_database.datname = tmp2.datname;

Что с этим делать? Мы решили выводить все ожидания из pg_stat_activityс группировкой по wait_event. Нам был интересен кумулятивный рост ожиданий в зависимости от нагрузки. В целом ожидали получить график, где будет виден и ряд ожиданий, и их рост в зависимости от времени работы.

select wait_event, SUM(EXTRACT (EPOCH FROM clock_timestamp () - xact_start)::float) AS sum_xact_age, from pg_stat_activity where state not in ('idle') and wait_event is not null group by wait_event

Внедрили этот запрос в наш форк. Новую метрику назвали pangolin_activity_max_seconds_xact_age. Вывели её в Grafana. Нас интересовали таймауты от 5 мс и выше.

29f22b26779b3830ce44e047034f7dac.png

Здесь проявился главный недостаток связки Grafana+Prometheus и других подобных связок, например Grafana+VictoriaMetrics (их мы тоже использовали). В Prometheus есть параметр scrape_interval (интервал сбора метрик). Минимальное значение, которое у нас получилось настроить, — 15 секунд. Если интересующее нас событие длится от нескольких миллисекунд до 15 секунд, то Prometheus с некоторой вероятностью не фиксирует его. Это недостатки мониторинга подобными связками. С ними не получится видеть объективную картину по wait_event.

Что решили с этим? В тот момент в команде Pangolin только появился собственный графический инструмент Platform V Kintsugi. Начали использовать его для получения картины по wait_event

Kintsugi — инструмент для оперативного анализа и диагностики СУБД и сопутствующей инфраструктуры. Он дополняет систему мониторинга, становясь рядом, чтобы пользователи понимали, когда их СУБД тормозит и почему это происходит. 

Kintsugi позволил нам фиксировать 100% событий, которые нам нужны, но только в разрезе сессий.

72454ef323ce9c3c9c1d1a4f71645c2e.png

На тот момент задачу с регистрацией нужных нам таймаутов он не решал. Можно было попробовать использовать pg_profile и pg_wait_sampling.

pg_profile — расширение Postgres, собирает статистику и создаёт снимки по собранной статистике, отдалённо напоминает AWR‑отчеты в ORACLE.pg_wait_sampling — расширение Postgres для периодического сбора статистики по событиям ожидания.

Но в Pangolin нельзя просто так добавить сторонние расширения, сначала они проходят тщательный аудит безопасности. В итоге мы по косвенным признакам сделали вывод об отсутствии интересующих нас событий ожиданий с превышением 100 мс и закрыли этот риск в ПРОМе.

Да, ещё к этому моменту у Platform V, цифровой платформы СберТеха, появилась система мониторинга IT‑инфраструктуры Platform V Monitor. Этот продукт мониторит в том числе и Pangolin, но, честно говоря, мы пока не успели протестировать его для наших задач. А в ближайшее время будем пробовать новую функциональность Platform V Kintsugi — за время подготовки статьи там появилась опция создания собственных метрик, теперь сможем создавать различные особые метрики и наблюдать за ними. 

Вместо заключения

Наше решение можно взять здесь и использовать. Будет здорово, если инструмент окажется вам полезным.

Если вы пользуетесь Platform V Pangolin или Platform V Kintsugi, то знайте, что у команды есть канал и чат, где можно задавать вопросы про настройку и не только. 

Надеюсь, что читать вам было так же интересно, как и нам искать и перебирать решения для сбора метрик :) Будем рады, если наш опыт пригодится тем, кто задумывается о кастомизации postgres_exporter. Если появились вопросы о деталях решения, которые мы могли упустить, или есть желание поделиться своим опытом, приходите в комментарии.