Как мы доработали 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, содержащую строку подключения к БД, с которой будем собирать метрики. В учебных целях для этого примера определяем учётные данные в открытом виде. Меняем <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 мс и выше.

Здесь проявился главный недостаток связки 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. Если появились вопросы о деталях решения, которые мы могли упустить, или есть желание поделиться своим опытом, приходите в комментарии.