promscale VS charts

Now that Promscale has been deprecated, what are the other ideal means of self-hosted long term Prometheus storage?

Oh wow, I browsed the project just a few weeks ago, didn't see it then. I see the deprecation is recent (https://github.com/timescale/promscale/issues/1836)

They say:

> if you want to have a seamless experience between metrics and traces, then current experience of stitching together Prometheus & Jaeger is not great.

But I wonder if using Promscale https://github.com/timescale/promscale would make Prometheus & Jaeger not such a big problem as SigNoz imply.

Promscale readme:

> Promscale is a unified metric and trace observability backend for Prometheus, Jaeger and OpenTelemetry built on PostgreSQL and TimescaleDB.

Either way, SigNoz seems interesting indeed. And am glad to see that SigNoz supports OpenTelemetry.

Hi! So the team is over 100 at this point, but engineering effort is spread across multiple products at this point.

The core timescaledb repo [0] has 10-15 primary engineers (although we are aggressively hiring for database internal engineers), with a few others working on DB hyperfunctions and our function pipelining [1] in a separate extension [2]. I think generally the set of folks who contribute to low-level database internals in C is just smaller than other type of projects.

We also have our promscale product [3], which is our observability backend powered by SQL & TimescaleDB.

And then there is Timescale Cloud, which is obviously a large engineering effort (most of which does not happen in public repos).

And we are hiring. Fully remote & global.

https://www.timescale.com/careers

[0] https://github.com/timescale/timescaledb

[1] https://www.timescale.com/blog/function-pipelines-building-f...

[2] https://github.com/timescale/timescaledb-toolkit

[3] https://github.com/timescale/promscale ; https://github.com/timescale/tobs

Promscale is a connector for Prometheus, one of the leading open-source monitoring solutions. Promscale is developed by Timescale, a time series database with full compatibility to Postgres. Since logs are time series events, Timescale developed Promscale to ingest events from Prometheus and make them available in SQL. You can install Promscale in numerous ways.

In case it helps, Promscale (from Timescale) offers long-term storage for Prometheus data and supports both PromQL and SQL queries. Here's the project page: https://www.timescale.com/promscale/ and the repo is here https://github.com/timescale/promscale It also support OpenTelemetry tracing if that's of interest.

At first, let's give the definition of `time series`. This is a series of (timestamp, value) pairs ordered by timestamp. The `value` may contain arbitrary data - a floating-point value, a text, a json, a data structure with many columns, etc. Each time series is uniquely identified by its name plus an optional set of {label="value"} labels. For example, temperature{city="London",country="UK"} or log_stream{host="foobar",datacenter="abc",app="nginx"}.

ClickHouse is perfectly optimized for storing and querying of such time series, including metrics. That's true that ClickHouse isn't optimized for handling millions of tiny inserts per second. It prefers infrequent batches with big number of rows per each batch. But this isn't the real problem in practice, because:

1) ClickHouse provides Buffer table engine for frequent inserts.

2) It is easy to create a special proxy app or library for data buffering before sending it to ClickHouse.

TimescaleDB provides Promscale [1] - a service, which allows using TimescaleDB as a storage backend for Prometheus. Unfortunately, it doesn't show outstanding performance comparing to Prometheus itself and to other remote storage solutions for Prometheus. Promscale requires more disk space, disk IO, CPU and RAM according to production tests [2], [3].

[1] https://github.com/timescale/promscale

[2] https://abiosgaming.com/press/high-cardinality-aggregations/

[3] https://valyala.medium.com/promscale-vs-victoriametrics-reso...

Full disclosure: I'm CTO at VictoriaMetrics - competing solution for TimescaleDB. VictoriaMetrics is built on top of architecture ideas from ClickHouse.

Promscale + TimescaleDB

Choose Your Application: Head to the Bitnami website (https://bitnami.com/) and browse their extensive catalog of applications. Find the application that suits your needs – whether it's WordPress for a blog, Moodle for an e-learning platform, or a specialized business tool.

Valkey

Bitnami charts: https://github.com/bitnami/charts

K3s installs super fast.

Writing your first yaml or two is scary & seems intimidating at first .

But after that, everything is cut from the same cloth. Its an escape from the long dark age of every sysadmin forever cooking up whatever whimsy sort of served them at the time, escape from each service having very different management practices around it.

And there's no other community anywhere like Kubernetes. Unbelievably many very good quality very smart helm charts out there, such as https://github.com/bitnami/charts just ready to go. Really sweet home-ops setups like https://github.com/onedr0p/home-ops that show that once you have a platform under foot, adding more services is really easy, showing an amazing range of home-ops things you might be interested in.

> Last thing I need is Kubernetes at home

Last thing we need is incredibly shitty attitude. Fuck around and find out is the hacker spirit. Its actually not hard if you try, and actually having a base platform where things follow common patterns & practices & you can reuse existing skills & services is kind of great. Everything is amazing but the snivelling shitty whining without even making the tiniest little case will surely continue. Low signal people will remain low signal, best avoid.

helm chart link: https://github.com/bitnami/charts/tree/main/bitnami/schema-registry

When you are ready to migrate your release and use Cyclops modules, click the Migrate to Cyclops Module, which will open a pop-up where you can input the Helm chart reference. In this case, it would be the Bitnami git repo and its PostgreSQL chart on the main branch.

There are two major ways to deploy Postgres to Kubernetes. First is using Helm charts like bitnami/postgresql or Serge’s postgresql-single, which has benefits compared to bitnami chart. The second way to run Postgres is to use the Kubernetes operator. There are a couple of them, here we will talk about Zalando Postgres operator. The helm way is better when in the future you will not plan to use more than one or two Postgres clusters per Kubernetes cluster. If you realize, that you will run more, then the Operator way is for you with all its automation and management advantages. Here is an example of PostgreSQL database manifest for Zalando Postgres Operator pg-prod.yaml. This example was tested for intensive transaction processing with query rates up to 3000-4000 per second and database size up to 350GB (data and indexes). It is enough to start most projects with thousands of active users like medium-volume webshops, news- and community-support websites, medium-sized gaming or gambling, etc. We assume, that we already set up the operator and the S3 bucket with encryption and access control for backups and WAL-log storage.

First of all, let's setup minio in docker container. I use bitnami's minio package. Add minio service to your docker-compose.yaml:

Of course that requires a more complex setup for the database server itself, but thanks to Bitnami's mariadb-galera Docker image and Helm chart, I've managed to get to something rather manageable for our purposes: