Zum Hauptinhalt springen

Where the open alarms sit in the tree

GET 

/alarming/open-alarm-locations

Returns every open alarm with the node it was measured on and that node's ancestors. The explorer builds its per-node indicator from this: the state of a node is the highest criticality and the number of open alarms in its subtree (RG-2), aggregated by the client. It deliberately takes no node list. Asking per node needed one id per node the client had loaded, and that request grew with the tree: at a few hundred nodes the query string passed the reverse proxy's header limit and the answer was 414 - which, with an empty list as the client's starting point, looked exactly like "nothing is alarming" (HET-1541 review). Carrying the ancestors instead makes the request constant in size, and constant across expanding the tree, so opening a branch needs no request at all. The number of open alarms is small by definition; a platform where it is not has a different problem than this endpoint. A node without an open alarm does not appear - absence is what makes a node quiet. Self-alarms of a rule are left out: they carry no node.

Responses

OK