Alerting
import { Callout } from ‘@astrojs/starlight/components’;
FourEyes’ alert engine taps the same flush-drain fan-out that the live-results stream reads. It evaluates each flushed batch in memory against your active alert rules — it never re-queries the time-series store after a flush.
Rule model
Section titled “Rule model”A rule combines a threshold with N-of-M confirmation:
- A node enters a violating state after
consecutive_roundssustained violating rounds. - A rule fires when at least
node_thresholdof the test’s assigned nodes are violating (0= any single node).
Mandatory hysteresis
Section titled “Mandatory hysteresis”resolve_consecutive_rounds (defaults to mirror the fire window) must clear before
a rule resolves. This means a single good round on a lossy link won’t flap an alert.
Dropped batches are safe: a time gap greater than 3× the test interval resets a
node’s transition streak.
Incidents
Section titled “Incidents”Each firing opens an incident (fired_alerts): one row per incident, opened by
the engine and closed on resolve. Open incidents are reseeded from the store on
restart, so there’s no double-fire.
Simultaneous incidents are grouped into incident groups by shared target / hop / ASN — the event-correlation tap.
Live alert stream
Section titled “Live alert stream”The engine owns its own fan-out for the /v1/events/alerts Server-Sent Events
stream, so the UI updates the moment a rule fires or resolves.