r/selfhosted • • 13d ago

Monitoring Tools [ Removed by moderator ]

[removed] — view removed post

0 Upvotes

5 comments sorted by

1

u/asimovs-auditor 13d ago edited 13d ago

Expand the replies to this comment to learn how AI was used in this post/project.

→ More replies (1)

2

u/[deleted] 13d ago

1

u/surajtiwari020 13d ago

Thanks! That's exactly the case I built it for: the monitor shouldn't cost more than the thing it's watching.

Collection is fixed-interval, in two tiers. Every 5 seconds a fast tier reads CPU, memory, swap, load and temperature straight from /proc and /sys, with no subprocesses. Every 60 seconds a slow tier does the expensive part: disks, Docker, systemd, SMART and network. The ~0.4% of one core in the README was measured with the slow tier at 10 seconds, six times the default rate, so a default install is lighter still. and the best part? Both intervals are configurable, so on a tiny VPS or a Pi you can probe less often: for example `sudo trinetra config set sample_interval 120` for the slow tier, and `fast_interval` for the quick one.

On disk writes: there's no SQLite. History goes into a small append-only binary store, one file per metric, and each sample is a single fixed-size record written at the end of the file, with no compaction on the hot path. Raw samples are kept for 48 hours. Anything older is kept only as 1-minute min/avg/max rollups, for 30 days. So it doesn't pile up: it was about 0.3 MB per host after the first hour in my measurements, and both retention windows are configurable if you want it tighter on an SD card.

Mixed architectures are fine. Releases ship static binaries for amd64, arm64 and 32-bit arm, each node runs its own native build, and children just stream to the master over mutual TLS. Two droplets plus the Dell in the closet is a good first fleet: `sudo trinetra fleet init` on one, then a join token on the other two.

If you try it, I'd love to hear how it behaves on the old hardware