Every Gopher knows the drill:
An endpoint gets slow. A spike of 500s appears. You open Grafana. You stare at 12 different panels. You cross-reference Prometheus metrics with traces. You guess it might be GC pressure or a connection pool saturation.
What if your API just told you what’s wrong?
I built mAPI-ng
because I was tired of the “Observability Tax”: the hours spent configuring OTel, Prometheus, and Grafana just to get basic answers.
mAPI-ng
doesn’t just show graphs; it interprets them. It correlates RED metrics (Rate, Errors, Duration) with Go runtime signals, instance health, and downstream IO.
When an endpoint fails, it ranks the most likely causes:
Every diagnosis comes with a “Rules this out” line. If the evidence doesn’t fit, it tells you, avoiding the “AI hallucinations” of black-box tools.
I’m a “Code Alchemist” at heart—I like things that work out of the box.
To instrument your app:
No YAML hell. No Prometheus to manage. It uses ClickHouse for high-performance, compact storage.
I believe observability should be a right, not a luxury. The entire stack is MIT licensed and self-hostable with a simple make up.
If you prefer the “easy mode”, there’s a hosted version at mapi-ng.com (with a forever-free tier), but you’ll never be locked in.
If you have Docker installed, you can see it in action with a sample “leaky” API:
git clone https://github.com/arhuman/maping
cd maping
make local
make generate-traffic
Open localhost:8080
and watch the diagnosis engine work.
I’m looking for feedback from fellow Gophers!
Does this approach to “evidence-backed diagnosis” make sense for your workflow? What’s the one thing that always kills your on-call nights?
GitHub: arhuman/maping