alarm-rules
Condition monitoring - rules, their binding, validation, backtest and alarms.
Get a page of alarm rules
Returns one page of the alarm rules the caller may read, each with the number of alarms it has standing (HET-2211). Sortable by `name`, `cronExpression` and `enabled` - any other field is answered with 400 - and by the name by default; equal values keep the order of the rules' ids, so paging never shows a rule twice. Optionally narrowed to the rules whose name contains a text.
Create an alarm rule
Stores a new rule and projects its schedule onto a scheduler job in the same transaction. Responds 400 when the condition does not compile or does not yield a truth value - a rule with an invalid condition cannot come into existence. Objects that carry none of the referenced properties do not prevent saving; they are excluded from the binding, which the validation endpoint reports.
Check a rule without storing it
Checks a rule definition and reports what it would watch: the hit set of the selector, the objects that drop out with their reason, and warnings about configurations that are legal but unlikely to be meant. Nothing is stored, and the rule does not need an id - this is what the editor asks before saving.
Try a rule against a historical stretch
Replays a rule over a historical period and returns the alarms that would have come into existence, including the effect of the debouncing. The rule does not have to be stored. Deliberately an aid for choosing thresholds and delays and NOT a historical record - the evaluation uses the properties that are valid today, so it is not suitable as evidence towards third parties. Responds 400 when the rule cannot be evaluated, the period cannot be resolved, or the backtest would cost more than allowed - computation (ticks of the schedule times bound objects, weighted with the data points per window) or data points to read. That last refusal carries `backtestLimit` with the longest period within the bound (HET-2222).
Get an alarm rule
Returns the rule with the given id, or 404 if it does not exist.
Update an alarm rule
Replaces the rule and writes its scheduler job forward in the same transaction. The change takes effect from the next run; open alarms stay and are not re-evaluated retroactively. A changed condition discards the debouncing progress, changed delays do not.
Delete an alarm rule
Deletes the rule and its scheduler job, and ends the alarms it has standing - nothing else could, since only a run of the rule ends an alarm. The alarms themselves stay and remain editable: an alarm outlives its rule and then only loses the reference to it.
Enable or disable an alarm rule
Switches a rule on or off without sending its whole definition. A disabled rule raises no new alarms, and disabling one ends the alarms it has standing, the self-alarm included. Enabling it again revives none of them: a condition that is still met raises a new alarm on the next run, with its raise delay starting over.
What a stored rule currently watches
Resolves the binding of a stored rule as of now: the objects it evaluates, the ones that drop out with their reason, and the warnings. The binding is determined per tick and not frozen when the rule is saved, so this answer can change without the rule changing - an object that gets a referenced property joins from the next run on.
Alarms of one rule
Returns the alarms this rule raised, cleared ones included - they are the history the filter is about. Each alarm carries the snapshot of the rule as it was when it was raised, so the answer stays readable after the rule was edited.