counterweight
361683681e
A wedged explorer produced 83 Signal messages in six hours. Nothing about that
was a monitoring success: the checks were right, the cadence was wrong.
monerod-box is a Monero node in the middle of a multi-week initial sync on a
rotating disk. A 5-minute poll tells you nothing a daily one does not, and when
something breaks it turns one fault into a message every five minutes until
somebody silences the phone - which is the failure mode that makes people stop
reading alerts entirely.
So both Monero probes move to OnCalendar:
monerod *-*-* 05:00:00 RandomizedDelaySec=900
xmrblocks *-*-* 05:30:00 RandomizedDelaySec=900
systemd units (infra/401 per-host timer) *-*-* 05:15:00
30 minutes apart on purpose: both read the same LMDB, and the explorer's check
renders a full page out of it - a cold one measured 68 seconds. Running them
together would have each paying the other's cache misses.
OnCalendar rather than OnUnitActiveSec: an interval timer re-bases on every
restart, so "daily" silently becomes "a day after whenever it last came up".
── The window and the cadence are ONE decision ─────────────────────────────
The Gatus heartbeat moves with them, to 26h. Not 24h: the window must EXCEED
the push interval, or a check reporting exactly on schedule races its own
deadline and alerts on jitter alone. With a 900s randomized delay the true
worst case is ~24h15m, so 26h leaves real headroom.
The same logic drops the pulled public-site checks to a 24h interval - and
their failure-threshold from 3 to 1 with it. Three failures at 5m is 15 minutes
of tolerance; three at 24h would be THREE DAYS before anyone heard. A daily
check has no room for a blip, so it alerts on the first.
── Scoping ────────────────────────────────────────────────────────────────
infra/401's timer is ONE PER HOST and iterates every unit in
monitored_services, so slowing it slows all of them. That is safe here only
because monerod-box runs nothing but Monero units; the knobs are therefore in
its host_vars rather than the role, and both 401 and 403 now take a per-host
(resp. per-probe) override with the old 11m as the default. Every other host
is untouched.
Host liveness and disk are deliberately NOT slowed. They answer "is the box
alive", which is still wanted within minutes.
The role-level OnCalendar defaults are prefixed (monero_healthcheck_on_calendar,
xmrblocks_healthcheck_on_calendar) because the generic `healthcheck` role owns
the unprefixed name, and an unprefixed default here would shadow it for any
play that includes both.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
52 lines
2.4 KiB
YAML
52 lines
2.4 KiB
YAML
# monerod-box: the Monero node.
|
|
#
|
|
# These ports are read twice: by the role that deploys the service here, and by
|
|
# the Caddy play that runs on the EDGE host and publishes the restricted RPC.
|
|
# A role default is invisible to that second play, which is why they live in
|
|
# host_vars - the edge play reads them as
|
|
# hostvars['monerod_box_local'].<name>, and the role picks them up
|
|
# automatically because host_vars outranks role defaults.
|
|
monero_p2p_port: 18080
|
|
monero_restricted_rpc_port: 18089
|
|
|
|
# The explorer's HTTP port, read by the Caddy play on the edge host.
|
|
xmrblocks_port: 8081
|
|
|
|
# The 500 GB disk added to this VM in Proxmox as scsi1. Named here rather than
|
|
# left to the role default so that "which disk holds the blockchain" is a
|
|
# property of the machine, recorded next to the machine. The role only ever
|
|
# uses it to create the filesystem; the mount itself goes by UUID.
|
|
monero_data_device: /dev/sdb
|
|
|
|
# Systemd services deployed on this host, monitored every 5 minutes.
|
|
#
|
|
# The fact lives with the machine rather than in a central map, for the same
|
|
# reason the cross-host ports do: "what runs here" is a property of the host,
|
|
# and a central list is one more thing to forget to update when a service moves.
|
|
#
|
|
# Only units WE deploy belong here. Distro units (ssh, cron) have their own
|
|
# supervision and would be noise.
|
|
monitored_services:
|
|
- monerod
|
|
- xmrblocks
|
|
|
|
# ...but on THIS host, once a day rather than every five minutes.
|
|
#
|
|
# Both units are a Monero node in the middle of a multi-week initial sync on a
|
|
# rotating disk. There is nothing a 5-minute poll reports that a daily one does
|
|
# not, and every failing poll was another Signal message - 83 of them in six
|
|
# hours while the explorer was wedged.
|
|
#
|
|
# This is safe to scope to the host because monerod-box runs ONLY Monero units.
|
|
# Do not copy it to a box with a mixed workload: the timer is one per host and
|
|
# iterates every unit in monitored_services, so slowing it slows all of them.
|
|
#
|
|
# 26h, not 24h: the window must EXCEED the push interval, or a check reporting
|
|
# exactly on schedule races its own deadline and alerts on jitter alone. The
|
|
# 900s randomized delay puts the real worst case at ~24h15m.
|
|
#
|
|
# Host liveness and disk are deliberately NOT slowed - they answer "is the box
|
|
# alive", which is still wanted within minutes. See infra/400.
|
|
service_health_on_calendar: "*-*-* 05:15:00"
|
|
service_health_randomized_delay: "900"
|
|
service_health_heartbeat: "26h"
|