You can still do it, but the "old school" way of doing it is much less flexible.
For this kind of setup, prometheus and grafana are not complicated (close to 0 configuration), and docker mostly works out of the box on linux hosts, barring nftables shenanigans. You end up with something that "just works", is pretty, and does not require fiddling.
Technically I do find this overkill for "home network monitoring", but at least it does not require k8s so I won’t complain.
One would think that should be a hell of a low bar. It’s like having to choose a car and going “Trabant will do, at least it does not require a crew of seamen”.
As someone who has set up a number of "simple" visualizing systems using the exact toolpath you mention (cron, shell scripts, rrdtool), I can say with some authority that getting them right was never simple.
And the load of dozens to hundreds of data points in rrd is shockingly large. Our infrastructure utilization dropped by 30% when I switched from a Graphite/collectd setup to gathering MORE data more frequently with telegraf and influxdb.
rrd and cacti are considerably more complicated and far less useful than prometheus and grafana.
I generally agree with the rest of your point, but the new-fangled infrastructure tools do have some merit and I look forward to seeing where we go with them.
Don't be fooled by the rain of downvotes that some comments are getting: the HN crowd is incredibly biased towards hyped stuff and CV-driven development.
I worked in FAANGS where simplicity really mattered over hype.
Prometheus as a monitoring tool is definitely a lot more complex and does not 'just work' straight out of the box. You need to configure Prometheus to know where to scrape using service discovery, set up different agents on your hosts to export metrics, build graphs in Grafana using PromQL to look for specific labels, and create alerts Alert Manager for every alert you want to receive.
You don't even need cacti or rrd if it's just taking a value and putting it in a file. However these newer tools are much more flexible that cacti and RRD. I find using Grafana miles better than dealing with RRDs, beter granularity and more options for querying data/overlaying results from different metrics on the fly etc.
A lot of people are now building huge container based SaaS software in their $Day_job, so in their free-time they use those technologies because they are more familiar, or they want the practice.
I ran K3s for a few weeks on ODroid hosts at home to get more k8s experience.
I would use Telegraf (a better/distributed collector far more efficient than cacti, even if you have to learn the OIDs for the snmp devices you want to monitor, because not everything is snmp anyway), InfluxDB (a timeseries database better than rrd, is not the only alternative, but at least it works for me), and yes, Grafana.
The cron gives you low granularity (and for some things, it may matter to measure things that changes in less than a minute), and flexibility (both in what you can measure and how you can arrange and correlate the different pieces of information).
Well, FWIW, I’m running a simple smokeping Docker container.
Just works, sits neatly alongside a few extra services (managed via compose) in a little ARM dev board and has kept on ticking for around five years without any hassles using exactly those bits you mentioned.
The new things are shinier, I think, and on the other hand a lot of the old, simpler tools have become less relevant.
As an aside, I recall a younger self annoyed at the inability to get data out of RRDTool into a nice SVG chart. These days I just want the data in whatever format the best tool spits out...
See my other comment in this thread. I've found InfluxDB a lot easier to setup and use (just apt-get install) and comes with push support, dashboards web ui, etc.
I'd say it is easier and more powerful than rrd and cacti (used them like 10 years ago!)
They called to stay popular because they kinda suck. The setup you described works on one host and produces static graphs.
With Prometheus and Grafana you can monitor an entire data center and add visualizations for metrics as you need them with no change to the monitored hosts.
TLDR: the old software stack could be made to do this, modern monitoring stacks do it out of the box.
I think they meant to give an example to indicate the flexibility of the platform. You know nobody is claiming people regularly run data centers at home — why are you asking?
This is totally portable. Compose on Kubernetes provides a new type in your cluster: Stack. It's backed by a regular API server and controller like any other Kubernetes resources.
Apple rebranded "Mac OS X" to "OS X" and later rebranded that to "macOS". It's not like they're different lines of operating systems; it was a rename of the whole line, so my impression is it's fine to use the term "macOS" to refer to any of the versions since 2001, or it's also fine to use the name that was given at release when referring to a specific version. In other words, probably best to not worry about any particular phrasing, and not try to put exact technical meaning on any of these terms. :-)
For example, Wikipedia[1] has a page called "OS X Yosemite" which describes it as "A version of the macOS operating system", and the Wikipedia article on macOS[2] says it was first released in 2001.
Because it's a bother to keep in mind when they introduced the new name? Or release names? It's hard to imagine that someone would actually be talking about certain number of releases this way.
Now you need "complicated" things: prometheus, grafana, docker, etc.
I am a bit puzzled. Is it because sysadmin tutorials from 2000's are not showing up anymore in Google ? Why these tools failed to stay popular ?