Skip to content
raspberry / field notes

Collector installation and verification

Install Grafana Alloy natively from its official Linux installation instructions. Pin the verified package version when releasing. Do not install Docker on the Pi just for monitoring. The Python collector uses the standard library, /proc, /sys, statvfs, and bounded subprocesses.

In the portal checkout, inspect collector/config.alloy, then validate with:

Terminal window
alloy validate collector/config.alloy
python3 collector/collect.py
python3 collector/collect.py --mode slow
python3 collector/collect.py --mode updates

The first command checks Alloy configuration. Collector output is public-safe metrics; missing optional sources are omitted. Confirm real temperature, uptime, memory and filesystem measurements rather than copying example values.

Provision root-readable /etc/raspberry-telemetry/alloy.env from the example using dedicated credentials. Configure probes in the separate private probes.env. The router target is optional; DNS and external HTTPS targets must be explicitly configured. No arbitrary ports are discovered or scraped.

Run sudo sh deploy/install-pi.sh only on the dedicated Pi after reviewing its effects. Verify:

Terminal window
systemctl is-active alloy
systemctl list-timers 'raspberry-*'
systemctl status raspberry-collect@host.service
findmnt /var/lib/alloy
journalctl --disk-usage

The installer places atomic textfiles under /run/raspberry-telemetry, bounds Alloy state with tmpfs and journals through journald settings. It preserves the prior Alloy configuration as a backup. Source parsing is validated separately from actual delivery; inspect Grafana and the public portal before declaring success.

Native Alloy collects broad host metrics privately, including process counts and systemd states. Public Python collection deliberately avoids process commands and unbounded labels. If a driver lacks a sensor, no zero is synthesized.

Enforced resource limits

Section titled “Enforced resource limits”

On the tested Pi kernel, memory cgroups were initially disabled. The deployment backed up /boot/firmware/cmdline.txt, appended cgroup_enable=memory, rebooted and verified /sys/fs/cgroup/system.slice/alloy.service/memory.max reports 268435456. Alloy and all collection timers recovered automatically. Check memory.events for OOM kills; the old /proc/cgroups interface does not establish v2 memory-controller availability.