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.
🧠 Evidence-backed Diagnosis
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:
- “Memory / GC pressure (High confidence)”
- “Downstream IO bottleneck (Medium confidence)”
- “Goroutine leak detected”
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.
🛠 Zero-Config (Almost)
I’m a “Code Alchemist” at heart—I like things that work out of the box.
To instrument your app:
- Two imports.
- One middleware.
- One environment variable.
No YAML hell. No Prometheus to manage. It uses ClickHouse for high-performance, compact storage.
🏠 Self-hostable & MIT
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.
✨ Try it in 30 seconds
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?
👇 Let’s talk in the comments!
GitHub: arhuman/maping
Top comments (0)