Why /proc directly
Standard tools are built for human eyes, not automation. Each one re-scans the same kernel counters, reformats them for a terminal, and truncates whatever didn't fit a readable column. Reading /proc directly means one scan instead of many, trivial parsing instead of format-string archaeology, and the full field - nothing lost in translation to a human-friendly layout.
Reading /proc directly gives you:
- Stability - kernel ABI, not userland format strings
- Speed - no fork/exec, no parsing overhead
- Portability - works in minimal containers, rescue shells, locked-down hosts
- Completeness - access fields that
ps and top hide or misrepresent
- Early warning - stay ahead of the OOM killer by monitoring
/proc/pressure/memory, the same pressure signal systemd-oomd watches when it decides which cgroup to kill
To be fair, /proc drifts too: fields appear and change meaning across kernel versions - PSI itself only landed in 4.20, and some counters mean different things on different filesystems. So every signal microSRE reports is traced to the exact file and field it comes from, in the documentation. No counter is named on faith.
Why logs directly
Log scanning extends the same philosophy: observe applications from the outside, without modifying them. And logging was solved decades ago: applications print to stdout, the runtime stores it on disk, and when things break you read it - with grep once there got to be too much of it. What changed since is volume, and the honest answer to volume was better search, not surgery on the application. Instead we got JSON scaffolding wrapped around every line and an SDK in every repo. Your logs already contain the errors; you just have to alert on them. microSRE reads them where they land and matches lines the way you always have - a pattern, a threshold. No code changes. No SDK to break, no network dependency to fail, no vendor to disappear. Keep them local, archive them, or ship them to centralized storage - the pattern alerts either way.
Every hop between an error and a person ships loss: the reporting SDK drops when the service is down, the collector crashloops, the metrics agent misses a pod that dies between scrapes, the telemetry buffer grows through the outage and dies with the process before reaching the vendor. Different failure, same shape - errors vanish exactly when things are worst. The file on disk was written before the failure - it does not buffer, retry, or need the network at the moment everything is on fire. The disk is not invincible; it fails too. It just fails less often than everything we have stacked on top of it.
It's the observer that can't be blinded by the observed.
No hoarding
Most monitoring agents run a hoard-first pipeline: buffer every metric and every log line "just in case", then forward all of it to a remote store. microSRE does the opposite - it reads the source in place, acts on it, and keeps nothing beyond the current check. What to keep and for how long - logs local, archived, shipped, or sampled away - is your decision, not the agent's. (Traces are a different story: they answer questions metrics and logs structurally cannot, and shipping those is a reasonable choice. It is the ship-everything-by-default culture around metrics and logs we opt out of.)
Notifications get the same treatment. On-call tools keep their own log of every page, acknowledgment, and escalation - a second incident history, stored inside the vendor's system. For a large org that audit trail earns its keep. But the alert already landed in your chat, the discussion happened there, and that history is searchable, backed up, and yours. Replaying last night's pages should not require logging into another tool. Where a formal trail is genuinely needed, it should be an explicit opt-in - like shipping logs or adding dashboards - not a side effect of being paged.
The agent is free and open source (MIT), forever; a hosted fleet view and dead-man escalation are coming - see plans.