If you have Prometheus, Loki, Tempo and Grafana running, you have good observability and we are not going to argue with it. What is missing is of a different nature: a time series tells you latency rose at 14:32. It does not tell you revision 88 was deployed at 14:20.
Prometheus for metrics, Loki for logs, Tempo for traces, Mimir for long retention and Grafana to see it all. It is free, it is an industry standard, and PromQL is a query language people learn once and use for years.
Arbitrary dashboards over your own data have no equivalent in a focused tool. If your team built twenty panels answering questions specific to your business, that is real value and it is not replaced.
And alerting maturity — Alertmanager, silences, grouping, escalation routes — is among the best available at any price point.
The data is also yours and sits in your infrastructure. For some teams that outweighs any feature.
Prometheus alone does not scale horizontally, which is why Mimir and Thanos exist. As soon as you need long retention or cross-cluster federation, you adopt a second system with its own operations.
Cardinality is the permanent enemy. Every label combination is a series, and series live in memory. An exporter that adds a pod-identifier label can multiply series by the pod count and make Prometheus itself die on memory — with `Reason: OOMKilled`, the same failure you are investigating in your services.
Loki and Tempo each add their own storage, retention configuration and learning curve. Nobody operates all four without spending real time on it.
And there is a cost that does not appear on an invoice: the knowledge lives in one or two people on the team. When that person leaves, it leaves with them, and the replacement takes months before they can respond to an incident in the stack itself.
This is the underlying difference and it is technical, not commercial. The Prometheus data model is a time series: a number, with labels, over time. It answers "how much" beautifully.
"Which revision was active" is not a number. It is a discrete fact with a start and an end, an image, a commit and an author. It does not fit in a time series, which is why Prometheus does not have it.
You can force it two ways and both have a cost. The first is Grafana annotations, which you have to feed from the pipeline and which end up as vertical lines on a panel: useful to look at, useless to query.
The second is adding a version label to metrics, and there is the irony: **that multiplies cardinality**, which is precisely the problem that brings Prometheus down. You are paying for the change axis with the stability of the system that measures it.
The practical consequence is familiar to anyone who has been on call: you see the graph rise, and then you open three more tabs to find out what was deployed. That stretch of the incident is covered by none of the four pieces of the stack, and it is the one that stretches MTTR.
Deployment frequency, lead time for changes, change failure rate and time to restore are four measures about deployments, not about load. Prometheus does not know what a deployment is.
They can be built by instrumenting the CI pipeline to emit metrics, and some teams do. The work is real, it goes stale when the pipeline changes, and nobody maintains it past the first quarter.
Moonin computes them from the cluster own revision history: if you know what was deployed and when, and when it was rolled back, all four fall out of that without instrumenting anything or touching the pipeline.
Tempo stores and queries traces, but does not generate them. Traces have to be produced, and today the standard path is OpenTelemetry: adding the SDK to each service, propagating context across calls, and keeping that current in every language you use.
OpenTelemetry is the right decision if you want fine control: you can annotate spans with your own business data, measure internal segments and decide what gets sampled. That is a real capability and eBPF does not provide it.
The cost is that you have to instrument, service by service, coordinating with every team that maintains them. In organisations with many services and several languages that project runs for quarters — and the legacy services nobody wants to touch never get instrumented.
Moonin collects service-to-service traces with eBPF in the node kernel, so they appear without adding libraries or touching code. What you see is real traffic between services; what you do not see is the inside of each one. It is an explicit trade, not a better version.
And it should be said in full: the eBPF agent needs node privileges to read kernel traffic. That is the trade-off for not instrumenting, and it is documented agent by agent.
If what you are missing is dashboards, this is not it. Moonin is not a dashboard engine and Grafana is among the best there is.
If you need visibility inside the code — internal segments, business annotations, per-function profiling — instrument with OpenTelemetry. Kernel traces do not reach there.
If your problem is Prometheus falling over on cardinality, that gets fixed in the cardinality. Cleaning up labels nobody queries lowers the pressure without adding tools, and it is worth trying first.
And if your team already operates the stack comfortably and covers the change axis with annotations they genuinely maintain, there is no problem to solve. Moving costs effort and that effort has to buy something.
Almost nobody should turn Prometheus off, and we are not proposing it. What usually works is leaving each thing where it is good: metrics and dashboards in the stack, and the change axis separately.
In practice that means installing the Moonin chart on one cluster and leaving it in parallel for two or three weeks. Access to the Kubernetes API is read-only and does not interfere with exporters, with the Prometheus operator or with Loki agents.
Then the concrete question is how many of your frequent Grafana investigations end in "and what was deployed". If several do, that is the stretch the stack was not covering.
And Moonin pricing does not depend on series or volume: it bills by cluster size, with one Compute Unit equal to 1 vCPU or 2 GB of RAM, billing the larger dimension. Adding a label to debug something has no consequence on the bill, which is exactly the opposite of what cardinality does in Prometheus.
Of your most frequent Grafana investigations, how many end in "and what was deployed before this". That stretch is what the stack does not cover, and it is the one that stretches time to recovery.
About usPricingSecurity and permissionsPartner programmevs Datadogvs Prometheus & Grafanavs New Relicvs Dynatracevs ELK and ElasticsearchCrashLoopBackOffOOMKilledImagePullBackOffPod stuck in PendingDocumentationDemoSign upContact usArguz, the consultancy
For an axis the Prometheus data model does not have. A time series answers "how much" over time; it does not answer "which revision was active", because a revision is not a measurement. You can force it with Grafana annotations or a version label, but the latter multiplies cardinality, which is exactly what brings Prometheus down.
No. Grafana is a dashboard engine and among the best there is; Moonin is not one. If what you are missing is arbitrary visualisations over your own data, the answer is Grafana, not this.
Not directly, because Prometheus does not know what a deployment is. You can instrument the CI pipeline to emit metrics, and some teams do, but that work goes stale when the pipeline changes. Moonin computes them from the cluster own revision history, without touching the pipeline.
Not for service-to-service traces: those come from eBPF in the node kernel, without instrumenting code. You do need it if you want internal segments per service, spans annotated with your business data, or per-function profiling — eBPF does not provide that and it is an explicit trade. In exchange, the eBPF agent needs node privileges.
No. Moonin installs as a separate Helm chart, its Kubernetes API access is read-only, and it does not touch your exporters, your Prometheus operator or your log agents. Running both for two or three weeks is the recommended way to evaluate.