01.02.2025 16:39
lesovsky 0 942 Источник

Всем привет, меня зовут Алексей, я люблю мониторинг и в этом посте расскажу про 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 удалось преодолеть все бюрократические препоны и сделать внутренний ознакомительный релиз, а спустя два месяца уже публичный. Теперь коллектор доступен для использования всем желающим. Уффф... На мой взгляд получилось великолепно.

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