Triggered by investigating a several-hour >10Mbps traffic spike to
linode. HAProxy's own IPAccounting confirmed ~121GB moved over ~19.6h
before it crash-looped, but with 'option httplog' commented out and no
per-backend request logs, there was no way to attribute that traffic
to a specific backend, host, or client.
- linode: enable HAProxy httplog + defaults 'log global' (was
commented out) so every proxied HTTP request is now logged with
timing/status/bytes.
- linode: add a haproxy 'stats' listener on 127.0.0.1:8404 for live
per-backend/per-server connection and byte counters.
- linode: route nginx (Nextcloud's local vhost) access logs to
journald via syslog, since the read-only monitoring account has no
access to /var/log/nginx/*.
- linode: enable vnstat for historical per-interface bandwidth
tracking (5-min granularity) so a reported 'traffic was high for N
hours' can be confirmed/timestamped immediately instead of
reconstructed after the fact from journal timestamps.
- k3s manifests: enable Traefik access logging (JSON) — this is the
ingress layer HAProxy forwards :80 traffic to (git/matrix/immich),
and lacked any per-request visibility.
- hosts/baseline.nix (fleet-wide): add a journald rate limit
(2000 lines / 30s per unit). Found live while investigating that
uptime-kuma on 'kuma' was logging a Prometheus label-validation
error on every monitor beat (~100k lines/hour), which was itself
degrading journalctl responsiveness on that host during the
cross-host traffic scan.
Related but not otherwise addressed here: Nebula relay/handshake
churn on kuma's tunnel and the etcd read-latency warnings seen on
isaiah/zeke around the same incident window — noted for a future
investigation, not fixed by this PR.
Enable the iscsi services on the local hosts
Enable special NixOS style Longhorn workarounds
Enable Longhorn in Kubernetes, as well
Update host names to point at Longhorn
Expose Longhorn UI and secrets
Expose the postgres cluster outside of the Kubernetes cluster
Give myself the option of connecting to postgres from my own machines,
so that I can hopefully leverage the improved performance
Update some file linting issues in Nix
Add necessary gitlab keys so it can be updated properly the next time I
deploy to it
Add DNS entries for postgres
Update the configuraiton of Traefik to expose the appropriate ports
Rather than running helm on the client and passing it to kubectl, just
install Flux and set the Helm repos on the server side
Add resolv.conf to the Kubernetes config so that the hosts can resolve
hostnames in order to pull down the Helm repositories
Add backups to the database configurations
emily
Greg Hellings