Nice list, I'll have to try a few! I've been having fun squeezing things into a Raspberry Pi 4 (4GB) and a thin client acting as a server (16GB), there's something about passively cooled compute that feels "free"...

Possibly of note from my services list:

victoria-metrics : currently at 230 MB ram because I send it all kinds of metrics

victoria-logs : 114 MB ram -- log aggregator

vl-agent : 25 MB ram (log forwarder for above)

ntp : 2 MB ram

librespeed : 16 MB ram (LAN speed testing, useful for wifi / quick ethernet checks)

corentinth/it-tools : 5 MB ram

mqtt mosquitto : 5 MB ram (message broker)

smokeping : 52 MB ram (latency history)

https://github.com/apenwarr/blip : 2 MB (live DNS latency checker)

lighttpd : 2 MB (static web server serving a single homepage)

▲

krautsauer a day ago | parent | next [-]

https://github.com/openspeedtest/Speed-Test would be a speedtest that's static files only. (Though I'm not sure you'll find a lighttpd config. The nginx one is somewhat involved. https://github.com/openspeedtest/Nginx-Configuration/blob/f4... )

▲

rcarmo a day ago | parent | prev [-]

How much telemetry do you have in victoria-metrics? I've stuck to graphite but have been considering moving to it.

▲

InsidiousWombat 18 hours ago | parent | next [-]

Victoria metrics is just storage/aggregation/scraping and a simple UI for graphs (generally you want Grafana in front of it for most power/convenience). It also has vmagent which acts as aggregation/metric relabeling/scraping/format conversion in front of it

Then you'd either:

* push into it directly using prometheus write format * push using other formats supported (there is a bunch so if you already have infra to get metrics you can often just plug it in * set up vmagent to scrape destinations (uses same config format as prometheus)

I use it for a while now both for work (few hundred servers) and for home stuff and it is excellent, small and low on disk storage

(yes that sounds like PR, no, it is not, I'm just very happy user)

▲

NortySpock a day ago | parent | prev [-]

lol last time I crowed about VictoriaMetrics someone accused me of being a bot https://news.ycombinator.com/item?id=48192183

But anyways, a fun test I ran was "load 4.5 million samples of Beijing hourly air quality data (ozone, S02, PM2.5, etc) from May 2013 to May 2017." (using Bento to turn the csv into json to fire at the API, with some batching and 4 http connections to Victoriametrics )

VictoriaMetrics accepts all of this in 54 seconds, network traffic shows between 9 and 14MB per second , and the data is available several seconds later (it's definitely a noticeable delay for me before it shows up in the VictoriaMetrics UI). Server is an old passively cooled thin client with a quad core AMD GX-415GA (circa 2013) and DDR3 ram.

So, 4.5M data points, 11 timeseries. Docker volume says it's under 14MB in size.

In my regular day-to-day telemetry (separate container) the volume is 99MB in size, it has 11,747 timeseries, 18,689 total samples, but I only keep a few days of data retention.

I think VictoriaMetrics is great, and I have found their documentation is extensive and easy to follow.

	▲	anygivnthursday 18 hours ago \| parent \| next [-]
		I also self host VicoriaMetrics and VictoriaLogs, use Vector to forward the logs, and Grafana for visualization, never had any issues with the stack, here and there upgrades are uneventful usually. Stats show about 220 datapoints per second ingestion and 15k active series. VictoriaMetrics uses about 220MB of memory. VictoriaLogs has 3.25 jsonline per second ingestion and uses 180MB. Vector and SNMP exporter are maybe around 20MB when idle, Grafana idle is not that bad, but jumps to like a 800MB or so on use.
	▲	InsidiousWombat 18 hours ago \| parent \| prev [-]
		I definitely glazed the project enough that some of my comments in other places looked like this. It's just very well done, and in the Prometheus ecosystem the best backend currently available. I'll add to the numbers: I run 2 storage demons (once storing with 1m accuracy for 10 years, other with 10s for 2 years) short term one has 43.8GB and stores 69 bil rows long term one has 16.8GB and stores 20.4 bil rows so compression in both cases is getting it to less than a byte per metric entry stored