Всем привет, меня зовут Алексей, я люблю мониторинг и в этом посте расскажу про pgpro-otel-collector.

TLDR: pgpro-otel-collector - opentelemetry-коллектор (агент мониторинга) для сбора метрик и журналов Postgres от PostgresPro.

Начать стоит конечно с OpenTelemetry, но по этой теме написано довольно много всего, поэтому подробно останавливаться не буду, но приведу чуть-чуть ссылок:

Другим важным куском OpenTelemetry является OpenTelemetry Collector. По сути это конструктор — комбинируя различные компоненты можно собрать агента мониторинга который будет собирать то, что вам нужно и отправлять туда, куда вам нужно. Если заглянуть в коробку этого конструктора, можно найти много полезных и интересных компонентов. Нас больше всего интересует PostgreSQL, но к сожалению имеющийся ресивер представляет собой лишь академический интерес - функциональность в нем очень и очень скромная. Поэтому можно написать свой ресивер, затем взять ocb, собрать все необходимое вместе и на выходе получить pgpro-otel-collector.

Так что же умеет pgpro-otel-collector?

Сбор метрик Postgres - это самое главное ради чего задумывался и создавался коллектор. В основе сбора лежит отдельная библиотека и на ней построен ресивер. Библиотека и ресивер являются внутренним продуктом и это позволяет без лишней бюрократии быстро добавлять новую функциональность, вносить изменения в случае ошибок. Ресивер использует классическую схему сбора данных - подключение к Postgres и SQL-запросы к системному каталогу за нужными данными. Другое дело что этих данных очень много и сам черт ногу сломит что там важно и нужно, а что нет.

Сбор метрик операционной системы на основе hostmetrics: утилизация процессора, памяти, сетевых и дисковых устройств, использование файловых системы и т.п. В мониторинге Postgres без этого можно, но сложно.

Сбор журналов Postgres на основе filelog. Postgres поддерживает запись журналов в формате CSV и JSON, коллектор в свою очередь умеет читать журналы в этих форматах. И здесь в коллекторе очень удачно получилось совместить сразу и сбор метрик и сбор журналов.

Несколько служебных процессоров для пакетной обработки данных (метрик и журналов). Процессоры нужны для эффективной передачи собранных данных в системы мониторинга.

Отправка метрик и журналов в OTLP-совместимые хранилища на основе otlphttp. Пока только Elasticsearch, но уже есть и другие кандидаты на перспективу.

Публикация метрик для Prometheus на основе prometheus экспортера. Это самый простой способ публикации метрик для широко известной системы мониторинга.

Таким образом, предположим есть экземпляр Postgres за работой которого хочется наблюдать. Ставим в эту же систему pgpro-otel-collector, указываем подключение к Postgres, и указываем куда отправлять (или публиковать) данные. То есть, один инструмент в зависимости от наших потребностей готов обеспечивать и сбор и метрик и журналов и доставку в систему мониторинга. Остается самое сложное — составить дашборды в Grafana?.

Если вдаться в большие подробности, то в плане метрик коллектор умеет собирать большую часть статистики Postgres с основных системных представлений - статистика клиентской активности, репликация, фоновая запись, чекпоинты, автовакуумы, запись и архивирование WAL, ввод-вывод, таблицы, индексы, запросы... в общем полно всего. Есть и поддержка более специфичных штук — CFS и pg_wait_sampling. Полный список метрик можно посмотреть здесь.

Для установки и запуска понадобится всего 5 команд, а конфигурация по умолчанию включает минимальный сбор общих метрик. Для более полного сбора потребуется включить и настроить соответствующие модули. В прочем это не сложно, да и в пакете идут расширенные примеры конфигурации для самых разных сценариев. После запуска, метрики можно получить запросом на *:8889/metrics (да-да, тот самый дедовский прометеевский способ экспорта включен по умолчанию).

Дальше все зависит от сетапа инфраструктуры мониторинга... Если это Prometheus/Victoriametrics-стек, то данные можно снимать сразу с коллектора. Если что-то что поддерживает получение через OTLP, то коллектор настраивается на отправку в эту систему — метрики и журналы становятся доступны уже имеющимся инструментам, вроде Grafana/Kibana.

Планы на будущее? После публичного релиза хочется порадоваться, сделать выдох и продолжить работу:

  • есть еще несколько представлений и расширений с которых хочется снимать метрики,

  • добавить интеграцию с Shardman и BiHA,

  • добавить сбор метрик на основе пользовательских запросов,

  • добавить в пакеты дашборд для Grafana,

  • и внести некоторое множество накопившихся внутренних улучшений.

Всем спасибо за внимание!

А для тех кто дочитал до конца, немного ретроспективы и лирики...

Всегда был неравнодушен к системам мониторинга... В далеких нулевых все начиналось с виндовой The Dude, было короткое увлечение Cacti. В прочем популярные Nagios и Graphite прошли мимо и не упоминаются в резюме. В 2010 я познакомился с Zabbix, написал кучу самых разных скриптов, они и по сей день живут на гитхабе и напоминают о себе редкими issues. Для Zabbix я написал скрипты для сбора данных с Postgres, да и вообще как-то часто приходилось заниматься Postgres. В 2014 я пришел в DataEgret и Postgres'а стало много и каждый день. Часто приходилось разгребать проблемы и за неимением нормальных инструментов я написал pgcenter. Затем появились Prometheus и Grafana (горячо люблю и использую их в разных задачах).

Примерно в 2017 я загорелся идеей создать мониторинговый SaaS для Postgres, который бы не только показывал графики и картинки, но и был бы более интеллектуальным и предлагал бы продвинутые функции, типа адвайзеров для конфигурации на основе данных мониторинга и рабочей нагрузки. Так появился Weaponry, делал я его около двух лет, но за инженерными навыками нужны были и навыки продажника, которых увы у меня не было. После двух лет вложений сил, денег и личного времени, я свернул проект. Единственное, что осталось с этого проекта это pgSCV - инструмент подобный прометеевским экспортерам, объединявший в себе сбор метрик и журналов Postgres, метрики Pgbouncer и Patroni. Всем был хорош, но был завязан на Prometheus и это был его недостаток. Позже я познакомился с OpenTelemetry и проникся его идеями, особенно мне понравилась вендор-агностичность - отсутствие привязки к конкретным продуктам и вендорам обеспечивают универсальность и широкую применимость в самых разных условиях использования. После того как я познакомился с OpenTelemetry, развивать и продвигать pgSCV я уже не хотел.

После свертывания проекта я начал смотреть по сторонам, в итоге покинув консалтинг и проработав девопсом в паре организацией я пришел в PostgresPro.

Итак, PostgresPro, конец 2023 года, с молчаливого одобрения своего руководителя мы с коллегой начали разработку OpenTelemetry-коллектора. Вдвоем с Сашей (все имена изменены, а совпадения случайны) мы начали работу сначала над библиотекой сбора данных, а затем и над коллектором. Спустя несколько месяцев Саша покинула компанию, а разработку подхватили другие ребята. По большому счету, работа над коллектором шла урывками, в не приоритетном режиме и в относительной тишине - мы особо не трезвонили о нашей работе, а те кто слышал были настроены не всегда оптимистично. В процессе разработки и затем публикации пришлось столкнуться и преодолевать разные бюрократические барьеры - написание документации, взаимодействие с отделом сборки (лучи уважения Виктору, за то что снисходительно смотрел на наши пацанские выходки и помогал с релизами), проведение семинара для техподдержки, взаимодействие с юристами и решение лицензионных вопросов. В общем, в фоновом режиме в конце 2024 удалось преодолеть все бюрократические препоны и сделать внутренний ознакомительный релиз, а спустя два месяца уже публичный. Теперь коллектор доступен для использования всем желающим. Уффф... На мой взгляд получилось великолепно.

Комментарии (3)


  1. Sleuthhound
    03.02.2025 13:53

    Алексей спасибо, что приоткрыли завесу тайны о создании коллектора и выложили его попробовать в деле)

    Возникло несколько вопросов:

    1) Будет ли что-то доступно в опенсорсе или это полностью коммерческая разработка?

    2) Может ли один pgpro-otel-collector мониторить несколько экземпляров пг?

    3) Может ли pgpro-otel-collector мониторить удаленные экземпляры пг?

    4) Может ли pgpro-otel-collector мониторить облачные управляемые пг (managed database), например Yandex Managed Service for PostgreSQL?

    5) Не нашел нигде в документации какие привелегии внутри пг нужны для корректной работы корректора? Хватит ли прав роли pg_monitor? Или нужно дополнитель pg_read_server_files или еще что-то?

    6) Куда можно зарепортить о багах? ;)


    1. lesovsky Автор
      03.02.2025 13:53

      1) в ближайшее время точно нет, в долгосрочной перспективе с высокой вероятностью библиотека и/или ресивер будут открыты

      2) да, может. подробнее об этом можно прочитать в документации по файлу конфигурации

      3) сбор метрик - да, достаточно указать реквизиты подключения. сбор логов - нет, т.к. требуется доступ к каталогу с логами

      4) не могу ответить на вопрос, не пробовал их скрещивать, но если там теже самый вьюхи доступные через SQL, то все должно получиться

      5) этот пробел в документации мы заполним, но да, должно хватить pg_monitor роли и могут потребоваться гранты на execute на pg_ls_dir и pg_stat_file (требуется для сбора осиротевших файлов).

      6) как обычно - bugs@postgrespro.ru


  1. RPG18
    03.02.2025 13:53

    Идея классная. Интересно будут ли переходить с pgSCV на pgpro-otel-collector.