Добрый день, читатели habr! В первой заметке о posgres_exporter, я рассмотрел достаточно частный случай, при работе с новой, на тот момент фитчей, а именно возможностью мониторинга одним экспортером набора экземпляров и/или баз данных. И описал тот "букет" проблем с которыми при этом столкнулся и какие обходные решения применял, что бы это всё заработало.
И вот, 25 ноября, вышел очередной релиз postgres_exporter 0.8.0. В нём были решены проблемы описанные в предыдущей заметке, а также, что особо приятно, добавлен новый функционал. Прошу под кат... Для начала хотелось бы более подробно познакомить Вас с postgre_exporter и написать, своего рода, короткое руководство по быстрому старту. Пройдемся по основным пунктам: postgres_exporter — утилита сбора метрик с экземпляров кластера СУБД PostgreSQL в формате доступном Prometheus, написанная на языке Go, имеет открытый исходный код и распространяется бесплатно.  У postgres_exporter, как таковой, отсутствует конфигурационный файл и все параметры передаются в экспортер либо через переменные окружения, либо через аргументы командной строки. При этом, параметры подключения к СУБД возможно передать только через переменные окружения. Как говорилось выше, переменные окружения можно разделить на две группы. Первые передают строку подключения, вторые — дублируют аргументы командной строки. Начнем с первой группы. Эти переменные начинаются с префикса DATA_SOURCE_: DATA_SOURCE_NAME — используется по-умолчанию. Позволяет записывать строку подключения как в формате ключ=значение, так и в виде URI и может содержать логин и пароль подключения.
Допустимые варианты задания подключения к PostgreSQL: Если нужно подключаться к нескольким экземплярам (не допускается использование пробела после запятой): Во вторую группу входят переменные дублирующие аргументы. Т.е. при запуске у вас есть выбор, задать параметры работы приложения в виде переменных окружения, либо передать в качестве аргументов при запуске. Начинаются с префикса PG_EXPORTER_: Метрики по-умолчанию — это некоторый набор метрик для мониторинга, сбор которых заложен непосредственно в коде. Сбор метрик по-умолчанию, можно отключить задав параметры командной строки --disable-default-metrics и/или --disable-settings-metrics или определив соответствующие переменные окружения.
Замечу, что в текущей версии была решена проблема использования метрик при включенном autoDiscovery, из-за которого, происходило дублирование метрик, что приводило к ошибкам. По-умолчанию в мониторинг передаются метрики из следующих представлений: Из того, на что стоит обратить внимание это pg_stat_replication и pg_stat_activity, так как набор возвращаемых полей зависит от версии PostgreSQL. Для этого, в экспортере производится проверка версии СУБД и выбирается соответствующий запрос. Указывать версию в пользовательских запросах, нельзя. Предполагается, что администратор заранее знает, какой версии, экземпляр будет мониторится. Так же могут возникнуть проблемы, если пытаться собирать метрики одним экспортером с экземпляров различных версий.
С метриками настроек экземпляра (pg_settings) всё несколько проще, они формируются запросом: Таким образом, по-умолчанию, формируется набор метрик только из численных значений. Далее, рассмотрим вывод экспортера и в том числе разберёмся в том, почему захордкоженные метрики имеют своё право на существование. Для примера возьмем две метрики: shared_buffers и wal_sender_timeout. В выводе экспортера, на каждую метрику мы получаем три строки.
Первая строка — представляет подсказку и состоит из имени метрики в postgres_exporter, описания (колонка short_desc представления pg_settings) и если происходило приведение к базовому типу, указывается к какому именно (значение в квадратных скобках).
Во второй строке, указывается тип значения, в терминах Prometheus. И третья строка, метрика с набором меток и присвоенным значением. Возвращаемые значения для shared_buffers. pg_settings_shared_buffers_bytes — имя метрики. Оно, по правилам хорошего тона, составляется из имени таблицы, имени метрики и единицы измерения. Далее идет, короткое описание из таблицы pg_settings. И последнее, указание на то, что значении метрики было приведено к единице измерения байт (Units converted to bytes). Почему на последнее стоит обратить внимание, потому что непосредственно в базе значение выглядит несколько иначе, а именно: Тип метрики у нас GAUGE, это значит она может принимать произвольные значения, в течении времени. В нашем случае количество буферов, при подстройке, может меняется в обе стороны.
О типах метрик и их отличиях, можно подробнее узнать в документации Prometheus. Следующая метрика wal_sender_timeout. Информационные поля собираются по тому же принципу, что описан выше. Только в этом случае значение метрики приводится к секундам, а в базе хранится в миллисекундах. С этой особенностью нужно быть внимательными и учитывать при построении графиков. Значение хранимое в базе данных: Все значения имеющие единицы измерения приводятся к двум типам: метрики объема к байтам; метрики времени к секундам. В дополнение или взамен метрик по-умолчанию, можно использовать собственные. Для этого достаточно задать путь к файлу, с пользовательскими запросами, через аргумент --extend.query-path=query.yaml или через переменную окружения PG_EXPORTER_EXTEND_QUERY_PATH.
В репозитории проекта имеется YAML-файл с примерами: queries.yaml Отмечу, что по сравнению с предыдущей версией, в 0.8.0 добавились новые ключи master и cache_seconds. На примере ниже разберем формат записи и назначение полей. Пример содержимого файла queries.yaml Ключи и значения из примера выше: Пример возвращаемых метрик: Ну и резюмируем, все что мы имеем в последней версии postgres_exporter 0.8.0. В основном, все улучшения касаются работы мониторинга нескольких экземпляров и/или нескольких БД в экземпляре.