Open Source Observability: Choose the Stack, Then Decide Who Runs It

What an open source observability stack is made of

There is no single open source observability platform. A stack is a set of projects, each covering one signal, held together by shared labels and a collection layer. Open-source observability usually means logs, metrics and traces, with distributed tracing as the newest layer for many teams. Grafana Labs calls Loki, Grafana, Tempo and Mimir the LGTM stack, and Prometheus, Thanos, OpenSearch and Jaeger fit the same pattern. The useful decisions are which project covers each layer, what that choice makes you operate, and where it usually goes wrong.

Versions as of 4 November 2026: Prometheus 3.15.1, Grafana 13.3, OpenSearch 3.9.0. Sources are listed at the end of this page and the licence rows are the projects' own statements.

Metrics storage: when one Prometheus is enough, and when it is not

Prometheus stores samples on local disk. Its documentation says plainly that local storage is not clustered or replicated, so it should be run like a single-node database. Retention defaults to 15 days unless you set a time or size flag, and when both are set, whichever triggers first applies.

Sizing is arithmetic, and it is worth doing before the incident. The documentation gives the formula: retention time in seconds, times ingested samples per second, times bytes per sample, and it puts the average at 1 to 2 bytes per sample. It also advises setting the size limit to 80 to 85 percent of the disk, to leave room for compaction.

• One server is enough — When the series count and retention fit one machine, and losing a few weeks of history to a disk failure is acceptable.
• Thanos — When you run a Prometheus per cluster and want one query view with data kept in object storage.
• Mimir or Cortex — When write volume is high enough that you want it centralised, with multi-tenancy. Mimir 3.x offers an ingest storage architecture that uses Kafka, besides the classic ingesters.
• A cloud managed service — When you want storage and query off your on-call and accept billing by what you ingest. The Prometheus side, the scraping and rules, stays yours.

OpenTelemetry in the middle: what it replaces and what it does not

OpenTelemetry does not replace Prometheus or Grafana. The Collector receives, processes and exports telemetry to open source or commercial backends, so it is the layer that lets you change a backend without re-instrumenting every service.

The details decide how smooth that is. Prometheus accepts OTLP metrics over HTTP, but the receiver is off by default and has to be switched on with a flag. Delta temporality is still experimental in Prometheus, behind a feature flag, and the project describes delta ingestion as at a very early stage. Resource attributes arrive as a target_info series unless you promote the ones you need to labels, and every promoted attribute is a new dimension of cardinality.

The Collector's own status is mixed, and the project asks you to read the stability level on each component. That is a reason to pin Collector versions, test pipelines in a staging environment and treat an upgrade as a change with a rollback, not a package update.

Cardinality sets the bill, whichever tool you choose

Open source does not remove the cost of cardinality. It moves it from an invoice to your memory, disk and on-call hours. Prometheus's own guidance is to keep the cardinality of a metric below 10, to look for alternatives above 100, and to start with no labels if unsure. Its worked example shows why: 10,000 nodes produce about 100,000 filesystem series, which is fine, while a per-user label across 10,000 users pushes the total into double-digit millions.

The same pattern shows up in logs, where a label or index field with unbounded values multiplies streams or shards, and in traces, where sampling is the lever. So the first design artefact is a label policy: which labels are allowed, who may add one, and where the limit is enforced.

Watching RabbitMQ, Kafka and PostgreSQL in the same stack

Most observability pages stop at application traces. Most production incidents on a messaging or data platform are visible earlier in the platform's own metrics. This is the part AceMQ adds, because messaging and data platforms are what AceMQ supports.

• RabbitMQ — The rabbitmq_prometheus plugin ships with RabbitMQ and is switched on with rabbitmq-plugins enable. It serves metrics on port 15692. Aggregated metrics keep the output size constant as queues and connections grow, while per-object metrics produce one series per object and metric, so a broker with many queues can generate very large scrapes. Choosing between them is a cardinality decision.
• Kafka — Kafka exposes metrics through JMX. The ones that predict trouble include UnderReplicatedPartitions and UnderMinIsrPartitionCount, which should be 0, and ActiveControllerCount, where only one broker in the cluster should report 1.
• PostgreSQL — Replication lag, replication slot retention and WAL volume growth belong beside the application dashboards, because an unattended slot fills a disk and a lagging replica turns a failover into data loss.

Licences and ownership: read them before you standardise

The projects in the stack do not share a licence. Grafana, Loki and Tempo moved from Apache 2.0 to AGPL v3 in 2021, and Mimir is AGPL v3 too. Prometheus, Alertmanager, Thanos and Cortex are Apache 2.0, and so is OpenSearch. Elasticsearch's repository carries a triple licence, AGPL v3, the Server Side Public License and the Elastic License 2.0, after Elastic announced in August 2024 that it would add AGPL as an option.

What those licences mean for your deployment is a question for your counsel, and AceMQ gives no licensing advice. What we can do is the engineering side: list what you run, in which version, under which licence, so the conversation starts from facts. AceMQ is an independent provider: it is not a reseller and sells no Grafana Labs or Elastic subscription.

Who carries the pager for the monitoring stack

The stack that tells you production is down needs its own cover. The question is how much of it you want to hold.

• Tier 1: reactive support — Your team runs Prometheus, Grafana or OpenSearch. AceMQ engineers answer within 15 minutes, around the clock, when it is down, stuck in WAL replay or no longer alerting.
• Tier 2: proactive monitoring — Tier 1 plus monitoring of the platforms themselves, so trouble is noticed before your customers notice it.
• Tier 3: managed on your infrastructure — AceMQ operates the stack inside your cloud account, cluster or data centre.
• Tier 4: managed on AceMQ's infrastructure — AceMQ hosts and operates it. Managed tiers are quoted per engagement and offered for every technology on this page.

Who this is not for, and what we do not promise

• Happy on a commercial platform — If Datadog, New Relic or Splunk meets your needs and your budget, stay. AceMQ supports those platforms too, and the review says so.
• No time to run anything — An open source stack trades licence fees for engineering time and a learning curve. If you want a hosted product with a contract and no pager, a vendor service fits better, and the managed tiers are the middle path.
• A cost figure in advance — Cost depends on volume, retention and who operates it. We do not quote savings before reading your data.
• A monitoring operations centre — We do not offer a 24/7 operations centre watching your applications. The cover is for the stack and the platforms it watches.
• Application instrumentation — Your developers add the spans, metrics and log fields. We design the conventions and review them with you.

Sources, all checked on 4 November 2026: prometheus.io release cycle, storage, instrumentation and OpenTelemetry guide pages; cncf.io project list; opentelemetry.io Collector documentation; jaegertracing.io; grafana.com Mimir documentation and the 2021 AGPL relicensing post; the projects' GitHub licences; opensearch.org releases; Elastic's August 2024 licensing post; rabbitmq.com Prometheus documentation; kafka.apache.org monitoring documentation.