Monitoring a home lab from a Raspberry Pi: a weekend build

You do not need a rack server to watch a house network. A Raspberry Pi on a shelf, drawing single-digit watts most of the time, will keep an eye on a router, a managed switch, a NAS and a handful of web services without complaint. It only needs two things from you: tools that suit a small machine, and no SD card anywhere near the database.

This is the build as I did it over one weekend, in the order I did it, with the parts I would change next time.

What went on the bench

• A Raspberry Pi 4 with 4 GB of RAM, or a Pi 5 with 4 or 8 GB. A 2 GB board is fine for a single uptime checker, but it gets tight once a web app and a database share it.
• The official power supply for that board: the 5.1 V, 3 A USB-C unit for the Pi 4, the 27 W, 5 A one for the Pi 5. On a 3 A supply the Pi 5 limits its USB ports to 600 mA in total (1.6 A with the 5 A supply), and that is not much headroom for an SSD under steady writes.
• An SSD on USB 3: a small SATA SSD in a USB enclosure, or one of the compact USB SSDs, plugged into one of the blue USB 3 ports.
• A case with a heatsink and fan for the Pi 4, or the official Active Cooler for the Pi 5.
• A PoE HAT, optional, if your switch has PoE ports and you like one cable instead of two.
• A short Ethernet cable. The monitor is wired, because a box that is supposed to tell you the network is down should not depend on Wi-Fi to say so.

Why the SSD? Monitoring writes all day long: round-robin graph files or a time-series database, a SQL database, logs. Those are small, scattered writes every minute, which is the worst job you can give an SD card. Cards are built for cameras writing large files now and then. When they wear out they tend to fail quietly, flipping to read-only or corrupting the filesystem, and you find out when the graphs stop. An SSD has proper wear leveling and an endurance rating a home monitor will never get close to.

On a Pi 5 the tidier route is an NVMe board under the Pi, which keeps the drive off USB altogether. If you are still shopping, this is the short list for that build, picked from spec sheets and published reviews rather than anything I put through its paces; the endurance card is there for anyone who decides to stay on SD anyway.

# Affiliate links: we may earn a commission. As an Amazon Associate I earn from qualifying purchases.

Friday evening: hardware and boot disk

1. Fit the cooler first, before anything is plugged in. On a Pi 5 the Active Cooler's lead goes into the small four-pin fan header on the board.
2. Write Raspberry Pi OS Lite (64-bit) straight to the SSD with Raspberry Pi Imager. In the Imager's settings, set the hostname, a user and your SSH public key, so the first boot needs no keyboard or screen. Take the 64-bit image: most container images you will want are built for arm64.
3. Boot from the SSD with no SD card in the slot. A Pi 5 and any recent Pi 4 will boot from USB as shipped. An early Pi 4 may need a bootloader update first, and the Imager can write a small card that does that for you.
4. If you are going the PoE route, add the Pi to your switch's power budget now, before the first brownout teaches you about it. The PoE budget calculator adds up the cameras, access points and the Pi against what the switch can deliver.

Saturday morning: the base system

Give the Pi a DHCP reservation on the router so its address never moves, then log in and bring it up to date:

sudo apt update && sudo apt full-upgrade -y
vcgencmd get_throttled
timedatectl

get_throttled should answer throttled=0x0. Anything else means the board has seen under-voltage or heat throttling since it booted, and you want to know that before you trust a single graph. The usual culprit is a phone charger standing in for the proper supply.

timedatectl should say the clock is synchronized. Time matters more than people think: every graph and every alert is stamped with it. The Pi 4 has no real-time clock at all, so it starts each boot with a wrong clock until NTP fixes it. The Pi 5 has one, but it needs a small battery on its connector to keep time with the power off.

Saturday afternoon: picking the tools

The trap here is installing everything. A Pi can run all of these, but you then have four dashboards and no idea which one to look at. This is how I sorted them:

I went with Uptime Kuma for everything I can reach over HTTP or ping, and LibreNMS for everything that speaks SNMP. If your lab is a Proxmox host and a pile of containers with a consumer router in front, swap LibreNMS for Prometheus and node_exporter and you lose very little.

Install Docker Engine from Docker's own Debian repository (Raspberry Pi OS is Debian underneath), then start Uptime Kuma. This is the command from the project's own instructions:

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Its web page is on port 3001. Make the admin account straight away, before anyone else on the network finds the setup page.

For LibreNMS, the project publishes a Docker setup with an example compose file that brings up the database and the poller alongside the web front end. I used it largely as shipped and left the optional extras for another weekend. Put its data directories on the SSD and you are done with the heavy lifting.

Saturday evening: SNMP on the router and switch

This part depends entirely on your hardware. OpenWrt has an snmpd package. pfSense and OPNsense both offer an SNMP service. Most managed and "smart managed" switches have SNMP somewhere in their web pages. A lot of consumer ISP routers have none, and for those you watch the WAN from the inside with ping checks and move on.

Where you have a choice, use SNMPv3 with authentication and privacy. If the device only offers v2c, change the community from public to something nobody would guess and restrict it to the Pi's address. The SNMP versions article explains why v2c is only acceptable on a network you trust.

Test from the Pi before you touch the monitoring tool. The first command asks the router for its uptime over v3; the second walks the switch's 64-bit inbound byte counters (ifHCInOctets) over v2c:

sudo apt install snmp
snmpget -v3 -l authPriv -u monitor -a SHA -A 'long-auth-pass' -x AES -X 'long-priv-pass' 192.168.1.1 1.3.6.1.2.1.1.3.0
snmpwalk -v2c -c n0c-r34d 192.168.1.2 1.3.6.1.2.1.31.1.1.1.6

A Timeticks value from the first command and a list of Counter64 values from the second mean the path works. A timeout means the credentials, the device's access list or a firewall in between. Fix that here: debugging SNMP through a web interface is slower.

Then add both devices in LibreNMS from its Add Device page with the same credentials. It discovers the ports, names them and starts graphing on its default five-minute cycle. Five minutes is fine for a house. If you are tempted to go faster, read how to choose a polling interval first; on a Pi the database pays for every extra poll.

Sunday: deciding what to watch

A house is not a data center, so the list is short. These are the checks that earned their place on mine:

• The internet connection, watched from the inside: a ping check to the ISP's first hop and another to a well-known public host. When both fail it is the line; when only the far one fails it is upstream.
• DNS. If you run Pi-hole or AdGuard Home, add a DNS check in Uptime Kuma that resolves a real name through it. When the household says "the internet is broken", it is DNS more often than not.
• WAN traffic on the router. The interface graph in LibreNMS shows when the upload is saturated, say at 21:00 on a Sunday when every phone in the house starts backing up its photos.
• Switch ports with errors. A port that logs errors all day is a bad cable or a bad termination. Re-punch it before you replace anything expensive.
• Web services: Home Assistant, the NAS admin page, the media server. HTTP checks, with certificate expiry warnings turned on if you use TLS at home.
• Backups. Uptime Kuma's push monitor gives you a URL; the backup job calls it as its last line, and if no call arrives in time, you get told.

curl -fsS -m 10 "http://192.168.1.20:3001/api/push/YOUR_PUSH_TOKEN?status=up&msg=OK" > /dev/null

Keep alerts few. I send phone notifications for internet down, DNS down and a missed backup, and nothing else. Everything else waits on a dashboard until I look.

One more check: something has to watch the Pi itself. A monitor that dies quietly looks exactly like a quiet network. A heartbeat to something outside the house covers it, and the field manual's page on running a monitoring server has more on monitoring the monitor.

Power and cooling

Power is the part I look at first; old habit from the trade.

Put the Pi on the same UPS as the router and switch. If the power blips and the monitor reboots while the router stays up, you lose the record of the blip. If the router is not on a UPS, the Pi cannot send alerts during an outage anyway, so protect the network gear first and the Pi with it.

PoE is tidy, but count it. A PoE HAT takes power from the switch over the data cable, and if that switch is on the UPS, so is the Pi. HATs are board-specific: the Pi 5 moved its PoE pins, so a HAT made for the Pi 4 will not fit it. A busy Pi with an SSD plugged in wants PoE+ (802.3at) rather than plain 802.3af, which is one more reason to run the numbers on the switch's budget before you buy.

Heat creeps up in a closet. A Pi slows itself down when the chip gets near 80 °C, and a shelf next to a router in a closed cupboard in July gets there faster than you think. Check now and then:

vcgencmd measure_temp

If it idles in the 60s Celsius, add airflow before summer does it for you. A small fan that never stops is cheaper than chasing gaps in graphs.

Keep an eye on the SSD as well. smartctl from the smartmontools package reads its health, though some USB adapters only pass the data through with -d sat, and a few not at all. If the disk drops off the bus under load, try a different adapter before you blame the drive; some USB-to-SATA bridges misbehave on the Pi.

The checklist I would start from again

• Pi 4 or 5 with at least 4 GB, the official supply, a cooler
• 64-bit OS on a USB SSD, no SD card in the slot
• throttled=0x0 and a synchronized clock before installing anything
• Uptime Kuma for HTTP, ping, DNS and backup heartbeats
• LibreNMS for SNMP gear, or Prometheus if the lab is mostly Linux
• SNMPv3 where the device allows it, v2c with a private community and an access list where it does not
• Three alerts to the phone, everything else on a dashboard
• Pi, router and switch on the same UPS, and something outside the house watching the Pi

That is a weekend. The second weekend goes on reading the graphs and switching off the checks you never look at.