By the end of my last post, the setup looked pretty solid.
Pi-hole blocking ads. Unbound resolving DNS privately. Tailscale keeping everything accessible without exposing anything publicly.
From the outside, the network looked healthy.
The problem was I had absolutely no idea what was actually going on inside it.
Pi-hole showed me DNS queries. That was it.
Bandwidth? No idea. Traffic patterns? No idea. Which devices were chatting at 2am without telling anyone? Absolutely no idea.
For someone who spends their working day talking about observability, visibility, and “you cannot manage what you cannot measure” — this was a bit embarrassing.
The Obvious Answer
Search for “Raspberry Pi network monitoring” and the internet will confidently point you at two things.
Prometheus. Grafana.
Rich dashboards. Beautiful graphs. The kind of setup that makes your home network feel like it deserves its own on-call rotation.
I genuinely considered both.
Then I did something that saved me a lot of pain.
I checked how much RAM they actually need.
Prometheus, even lightly configured, wants a meaningful chunk of memory to store and process metrics. Grafana adds more on top. Together they are designed for machines that have resources to spare.
The Raspberry Pi Zero 2W has 512 megabytes total. That is not a recommendation. That is the whole machine.
Pi-hole lives there. Unbound lives there. Tailscale lives there. The operating system lives there.
There is no spare capacity sitting around waiting to host a metrics pipeline.
Asking Prometheus and Grafana to run alongside everything else would have been like inviting two large house guests into a studio flat. Technically possible. Practically a disaster for everyone already living there.
So I asked a more honest question.
What Do I Actually Need?
Not “what would look impressive?”
What do I actually need to see?
The answer, when I was honest about it, was pretty simple.
I wanted to know what traffic was flowing through my network right now. I wanted to know how much bandwidth I was using over time. And I wanted to know which devices were actually on my network.
Three questions.
Three lightweight tools. One for each.
darkstat
darkstat watches your network interface passively and builds a picture of what is flowing through it.
It uses almost no resources. It serves a small web interface. It does not try to be anything more than what it is.
sudo apt install darkstat -y
Once running, the web interface lives at http://<your-pi-ip>:667. Nothing to configure. Just open it.
Getting it installed was easy. Getting it to actually run properly was a different story.
darkstat ships with an init script that was written before systemd became the standard. The two do not get along well. The service would start, report that everything was fine, and then quietly do nothing at all.
Port 667 stayed closed. The web interface never appeared. And systemd had no idea anything was wrong because as far as it was concerned, the job was done.
The fix was to stop trusting the init script entirely and write a proper systemd unit file instead. One that ran darkstat in the foreground, so systemd could actually keep track of it.
That one change fixed everything.
This is something I keep learning with older Linux tools. They were written in a different era. They make assumptions that no longer hold. When a service reports success but nothing is actually running, the culprit is usually somewhere in that gap between how the tool was designed and how the system expects it to behave.
vnstat
darkstat tells you what is happening right now.
vnstat tells you what happened over the last hour, day, week, and month.
It is the difference between glancing out the window and checking your weather history. Both are useful. They just answer different questions.
vnstat runs as a tiny background daemon, samples your network interface quietly, and keeps a running record of bandwidth usage over time.
sudo apt install vnstat -y
Once it has been collecting for a few minutes, these two commands become your best friends:
vnstat -i wlan0 -d # daily breakdown
vnstat -i wlan0 -m # monthly totals
The daily and monthly breakdowns became something I checked more than I expected.
There is something grounding about seeing actual numbers. Not estimates. Not assumptions. Just a record of what moved through the network and when.
One small surprise: vnstat automatically tracked both my main Wi-Fi interface and the Tailscale VPN interface separately. I had not asked it to. It just did. That turned out to be more useful than I anticipated, because now I could see VPN traffic independently from everything else.
nmap
The third question was the one I had been quietly avoiding.
Which devices are actually on my network?
I knew the ones I had deliberately connected. But modern homes are messier than that. Smart TVs. Printers that update themselves overnight. Devices from visitors that technically never left. Things that connect to Wi-Fi without making a sound about it.
sudo apt install nmap -y
Running a quick scan answered the question immediately.
sudo nmap -sn 192.168.*.*/24
The first time I did this, I counted more devices than I expected.
I thought I had about eight.
That is not a rounding error. That is a visibility problem.
Some I recognised straight away. Some took a moment. A couple made me walk around the house and think harder than felt entirely comfortable.
That last part is not paranoia. It is just what happens when you go from zero visibility to any visibility at all. You find things you did not know were there.
I set this up to run automatically every hour via cron and write results to a log file.
Now there is a timestamped record of every device that has appeared on my network, every hour of every day. If something new shows up at 3am, I will know about it. Eventually.
What This Actually Cost
After all three tools were running alongside Pi-hole, Unbound, and Tailscale, I checked the memory.
The combined overhead was under 10 megabytes.
To put that in perspective: a single Chrome tab uses more memory than this entire monitoring stack.
The Pi-hole kept running. Unbound kept resolving. Nothing noticed anything had changed.
That last part matters more than it might sound.
The Pi-hole is not optional. Every device in the house depends on it for DNS. If it struggles, the internet stops working for everyone. Everything else on this machine runs at the Pi-hole’s pleasure, not the other way around.
A monitoring stack that threatens the thing it is supposed to monitor is not a monitoring stack. It is a liability.
What Chagned?
Before this: DNS was visible. Everything else was dark.
After this: I could see live traffic. I had bandwidth history going back weeks. I knew every device on my network by IP and MAC address.
And I got there without adding anything that put meaningful load on a machine that was already doing important work.
The right tool for the constraints you actually have, rather than the constraints you wish you had, is not a glamorous engineering lesson. Nobody writes conference talks about it.
But it shows up in every system that actually keeps running.
What Is Next
Three tools. Three data sources. Three separate places to look.
The obvious next step was to pull all of that into one place.
So I built a small dashboard in Flask that brought everything together in a single page.
If you think “a dashboard sounds like a small project”, I admire your confidence.
It was not a small project.
That is next.
Top comments (0)