Как мы доработали postgres_exporter для мониторинга событий в БД
Привет, Хабр! Меня зовут Станислав Епишин, я 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, содержащую строку подключения к БД, с которой будем собирать метрики. В учебных целях для этого примера определяем учётные данные в открытом виде. Меняем
"DATA_SOURCE_NAME": "postgresql://:@:5432/postgres?sslmode=disable" Для этого добавляем пару файлов в проект:
/
/cmd/postgres_exporter/.vscode/launch.json /
/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://:@:5432/postgres?sslmode=disable"
}
}
]
} Собираем бинарник из исходников:
cd //cmd/postgres_exporter
go build -o //cmd/postgres_exporter/build . Запускаем в Microsoft VS Code, для этого нужно открыть main.go и нажать F5, при необходимости пошагово отлаживаем код, расставляя breakpoints.
Далее добавляем необходимые нам метрики и редактируем существующие. Для редактирования в пакете collector находим нужную метрику. Файлы пакета находятся в каталоге /
Рассмотрим пример добавления метрики для определения версии Pangolin. Планируем SQL-запрос для получения данных:
select product_version from product_version();Версия Pangolin будет выводиться в label, метрика будет равна 1, если SQL-запрос выполнен. Добавляем новый файл в пакет 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 мс и выше.
Здесь проявился главный недостаток связки Grafana+Prometheus и других подобных связок, например Grafana+VictoriaMetrics (их мы тоже использовали). В Prometheus есть параметр scrape_interval (интервал сбора метрик). Минимальное значение, которое у нас получилось настроить, — 15 секунд. Если интересующее нас событие длится от нескольких миллисекунд до 15 секунд, то Prometheus с некоторой вероятностью не фиксирует его. Это недостатки мониторинга подобными связками. С ними не получится видеть объективную картину по wait_event.
Что решили с этим? В тот момент в команде Pangolin только появился собственный графический инструмент Platform V Kintsugi. Начали использовать его для получения картины по wait_event.
Kintsugi — инструмент для оперативного анализа и диагностики СУБД и сопутствующей инфраструктуры. Он дополняет систему мониторинга, становясь рядом, чтобы пользователи понимали, когда их СУБД тормозит и почему это происходит.
Kintsugi позволил нам фиксировать 100% событий, которые нам нужны, но только в разрезе сессий.
На тот момент задачу с регистрацией нужных нам таймаутов он не решал. Можно было попробовать использовать 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. Если появились вопросы о деталях решения, которые мы могли упустить, или есть желание поделиться своим опытом, приходите в комментарии.
