monitoring A field note by Vikrant Sharma
Someone shipped a monitoring stack in one Go binary
A French dev got sick of Prometheus configs and wrote a monitoring tool that fits in one binary, one YAML file, and one SQLite database.
Someone on Hacker News wrote their own monitoring tool because the existing ones annoyed them. The interesting bit is the constraint: one Go binary, one YAML config, one SQLite database. That is the entire stack. Most monitoring setups are five services minimum. Prometheus for metrics, Grafana for dashboards, Alertmanager for alerts, a time-series database if you are fancy, maybe Loki if you want logs in the same place. Each one has its own config format. Each one needs its own Docker container or systemd unit. The author looked at that and said no. The tool they built scrapes HTTP endpoints, stores metrics in SQLite, and serves a web UI from the same binary. Alerts are in the same YAML file as the scrape targets. No exporters, no separate alert routing config, no query language that requires three Stack Overflow tabs to write a rate calculation. SQLite as a time-series store is the spicy choice here. Time-series databases exist because appending millions of datapoints per second to a relational database usually ends badly. But if you are monitoring twenty services on a single server, SQLite can handle that. The write-ahead log keeps it fast, and you get SQL for queries instead of PromQL. The trade-off is obvious. This does not scale to distributed systems. You cannot federate it across ten data centres. It does not have a thriving plugin ecosystem. But for a small team running a dozen services, that might not matter. The cognitive load of running one binary is lower than the cognitive load of running five. I have spent enough time debugging Prometheus scrape intervals and Grafana datasource timeouts to see the appeal. Sometimes the boring stack is the one that lets you sleep.
Source: One Go binary, one YAML file, one SQLite database: I wrote my monitoring tool
