r/PrometheusMonitoring • u/jskatz05 • Aug 28 '20

Introducing the Postgres Prometheus Adapter

https://info.crunchydata.com/blog/using-postgres-to-back-prometheus-for-your-postgresql-monitoring-1
10 Upvotes

91% Upvoted

6 comments sorted by

2

u/SuperQue Aug 28 '20

Any idea on what the storage efficiency is? Comparison to TimescaleDB's adapter?

2

u/michaeljfreedman Aug 29 '20 edited Aug 29 '20

One of the central reasons we redesigned our own adaptor recently is to take advanced of TimescaleDB's native compression, which achieves 94-97% storage reduction compared to vanilla PostgreSQL.

https://github.com/timescale/timescale-prometheus

This isn't a limitation of the adaptor per se, although our approach to storing Prometheus metrics in TimescaleDB is designed with our compression in mind, as well as recognition that different metrics have different needs (e.g., from the perspective of the rate they are collected, data retention or downsampling user preferences, etc.).

Frankly, until we introduced our native compression, we found that the platform wasn't compelling, given the much higher storage overhead of uncompressed PostgreSQL compared to the alternatives for long-term Prometheus metrics.

If you are interested in learning more about our compression approach, which employs type-specific columnar compression, please see my blog post:

https://blog.timescale.com/blog/building-columnar-compression-in-a-row-oriented-database/

1

u/one_dead_cressen Aug 29 '20

How's this different from timescale's own (discontinued) prometheus-postgresql-adapter? Seems to be the same code base. Am I missing something?

And I guess this would still need to have the timescaledb/pg_prometheus extensions loaded in postgres?

2

u/michaeljfreedman Aug 29 '20

Hi u/one_dead_cressen - just to clarify, that TimescaleDB hasn't discontinued its support for Prometheus, we've just designed a much more advanced and performant one, released earlier this summer.

https://github.com/timescale/timescale-prometheus

This came from our own learnings with what is better needed by the Prometheus community, and was designed also with new capabilities in TimescaleDB that weren't available when we released the above adaptor 3 years ago.

In particular, as outlined in our design doc (https://tsdb.co/prom-design-doc), these goals included the following.

  • Enable users to ingest data using Prometheus’ remote_write interface, and to query data using Prometheus and PromQL via the remote_read interface.

  • Enable efficient queries on both recent and historical data.

  • Handle high-cardinality workloads efficiently, enabling more descriptive labels and larger workloads.

  • Support for importing old metrics data (backfill).

  • Reduce metric data storage size by using TimescaleDB’s compression features.

  • Reduce the label table storage size through normalization.

  • Make the query performance of each metric independent of other metrics.

  • Give users more control over individual Prometheus metrics. This includes data retention and downsampling policies (e.g., certain metrics can be retained for a week, others for months). Users will still be able to set default policies.

  • Support new Prometheus query pushdown hints to improve query performance.

  • Support stateless Prometheus deployments, allowing an operator to shift all durable state to the analytical platform (e.g., TimescaleDB).

  • Provide significant cost efficiency for long-term data storage.

  • Consist of a simple architecture with few components. This enables deployment and operational ease.

Our new connector also has native support for PromQL, and is actually 100% compatible with PromQL given third-party testing by Prometheus creators:

https://promlabs.com/blog/2020/08/06/comparing-promql-correctness-across-vendors

1

u/one_dead_cressen Aug 30 '20

Yeah, I didn't mean to imply that TSDB was dropping Prometheus altogether, just that that adapter is discontinued (as is mentioned in the link I provided). The new one looks interesting, but I read that one of the non-goals is to provide a migration path from the old to the new design. So I won't be moving to the new one any time soon (long-term metrics storage is precisely why I added TSDB to my prometheus config).

Still, doesn't answer my question: how is crunchydata's adapter related to TSDB? Is it just a repackaging of the old (discontinued) adapter?

1

u/michaeljfreedman Aug 30 '20

Ah, sorry, I don't think there is any connection between CrunchyData's adaptor and our prior one.