Hey folks, I’m Alexey. I’m a big fan of observability, and in this post, I want to share something I’ve been working on — the pgpro-otel-collector.
TL;DR: pgpro-otel-collector is an OpenTelemetry collector (aka monitoring agent) tailored for gathering Postgres metrics and logs — brought to you by PostgresPro.
A few words about OpenTelemetry
It makes sense to start with OpenTelemetry, but since there's already plenty of material out there, I won’t go into detail. Just a few links for reference:
One of the key components of OpenTelemetry is the OpenTelemetry Collector. Essentially, it's a modular toolkit — by combining different components, you can build a monitoring agent that collects the data you need and sends it where you want. If you look inside this toolkit, there’s a lot of useful and interesting components.
We’re primarily interested in PostgreSQL, but unfortunately, the existing receiver is mostly academic — the functionality is minimal. So, we wrote our own receiver, added it to builder, and the result is pgpro-otel-collector.
What can pgpro-otel-collector do?
Collect Postgres metrics. This is the main purpose of the collector. The receiver is built on top of a separate internal metrics library. This makes it easier to quickly add new functionality or fix issues without bureaucracy. The receiver uses the classic model: connects to Postgres and queries system catalogs. There’s a lot of data, and figuring out what’s actually useful is not trivial.
Collect OS-level metrics via
hostmetrics. CPU, memory, disk and network usage, filesystem stats, etc. Technically optional for Postgres monitoring, but often necessary.Collect Postgres logs via
filelog. Postgres supports logging in CSV and JSON formats, and the collector can read both. This integrates well with the metrics collection part.Internal processors for batch processing of metrics and logs. Helps prepare and optimize data before sending to the monitoring system.
Export to OTLP-compatible backends via
otlphttp. So far, only Elasticsearch is supported, but other backends are planned.Prometheus exporter for exposing metrics. This is the easiest way to get metrics into a widely used monitoring system.
How to use it
Say you have a Postgres instance you want to monitor. You install pgpro-otel-collector on the same host, configure the Postgres connection, and set up where to send or expose the data. That’s it. One tool handles metrics, logs, and exporting to your monitoring system. The rest is up to you — for example, building Grafana dashboards.
The collector can gather most of the PostgreSQL statistics from standard system views: client activity, replication, background writer, checkpoints, autovacuum, WAL write/archive, I/O, tables, indexes, queries, etc. It also supports more specific features like CFS and pg_wait_sampling. The full list of metrics is available here.
Installation and startup take about five commands. The default config includes minimal general metrics. For more detailed monitoring, enable and configure the relevant modules. It's not difficult, and the package includes extended example configs for various scenarios.
Once it’s running, metrics are available at *:8889/metrics (yes, the classic Prometheus export method is enabled by default).
How you integrate it depends on your monitoring setup. If you’re using the Prometheus/VictoriaMetrics stack, you can scrape data directly. If your stack supports OTLP, configure the collector to send metrics and logs accordingly — tools like Grafana and Kibana will work out of the box.
What’s next
After the public release, the plan is to continue development:
Support for additional system views and extensions
Integration with Shardman and BiHA
Collection of custom query-based metrics
A Grafana dashboard included in the package
Various internal improvements
Retrospective
I’ve always had an interest in monitoring systems. Back in the 2000s, I started with The Dude on Windows, briefly tried Cacti. I skipped Nagios and Graphite. In 2010, I got into Zabbix and wrote a lot of scripts — many still live on GitHub and occasionally get new issues. I wrote Zabbix scripts for Postgres, and ended up working with Postgres a lot.
In 2014, I joined DataEgret and started working with Postgres daily. Often had to troubleshoot production issues without good tools — that’s how pgcenter was born. Then came Prometheus and Grafana, which I still use regularly.
Around 2017, I started building a Postgres monitoring SaaS — not just dashboards, but more intelligent functionality like config advisors based on workload and telemetry. That became Weaponry. I worked on it for about two years, but without sales/marketing skills, the project didn’t take off. I shut it down after investing significant time and money.
The only thing that remained was pgSCV — a tool like a Prometheus exporter for Postgres, Pgbouncer, and Patroni metrics and logs. It worked well but was tightly coupled with Prometheus, which limited flexibility. Later, I discovered OpenTelemetry and appreciated its vendor-neutral approach — it offered more flexibility and broader applicability. After that, I had no desire to continue developing pgSCV.
After leaving consulting, I worked in DevOps roles at a few places, and eventually joined PostgresPro.
At the end of 2023, with silent approval from my manager, a colleague and I started developing the OpenTelemetry Collector. We began with the metrics library, then moved to the collector. A few months in, my colleague left the company, and others picked up the work. Development was sporadic and low-priority — we didn’t advertise it much, and not everyone who heard about it was enthusiastic.
There were some bureaucratic hurdles along the way — writing docs, working with the build team (thanks to Viktor for his help), holding a seminar for support staff, dealing with legal and licensing. Eventually, in late 2024, we made an internal release, and two months later — a public one.
Now the collector is available for anyone to use. In my opinion, it turned out quite well.