Ramblings of an aging IT geek
← Ramblings of an aging IT geek
golang

forty lines of go that quietly run my house

A small Go daemon that polls a sensor and exposes it for Prometheus, and why Go keeps winning the "I need a long-running thing on a Pi" job.

Source code on a programming editor

I keep ending up here. Some small thing needs to run forever, poll something, and expose the result, and after briefly considering a shell script or a Python venv I write it in Go and ship a single binary. This week's instance: a daemon on a Raspberry Pi that reads a temperature and humidity sensor every thirty seconds and exposes the readings as a /metrics endpoint for Prometheus to scrape.

The whole thing is about forty lines of actual logic plus the client library. A ticker, a read, two gauges set, an HTTP handler. No process manager wrestling with virtualenvs, no interpreter to keep in step. GOARCH=arm GOARM=6 go build on my laptop, scp the result, drop in a systemd unit, done.

ticker := time.NewTicker(30 * time.Second)
for range ticker.C {
    t, h, err := sensor.Read()
    if err != nil {
        log.Printf("read failed: %v", err)
        continue
    }
    tempGauge.Set(t)
    humidityGauge.Set(h)
}

That's the heart of it. The thing that keeps drawing me back to Go for this category isn't speed, the Pi has cycles to spare. It's that the deployment story is "copy a file". Cross-compilation that actually works, a static binary, and a standard library with a real HTTP server in it. The daemon's been up for a few days now, the graphs are filling in, and I haven't thought about it since I walked away. Which is exactly what you want from something this small. Ship it and forget it.