Triggers can be used to create rules on event sequence, occurrence or delays. Mentioned below are few alert rules you can setup on your monitors:
- Change in aggregated drop % between any two nodes
- Change in transition times between two nodes (aggregated as well as event-level configurations)
- Metric level rules:
- Change in metric value against a static threshold
- Change in metric value against a benchmark (previous timeline)
- If an entity is stuck at a specific state
- Occurrence of an event within an entity
- Occurrence of an event, more than n times (threshold) within an entity
This is for generating alert when E2 is delayed by more than 'X' time interval than E1.
It will generate alerts for each such instance and notify you of the E1 payload for which it happened. This type of trigger is useful for knowing failures in payments, data pipelines or route creation background tasks.
This is for generating alert when Y% of E1 events have their E2 events delayed by 'X' time interval when periodically evaluated every 'T' minutes.
It will generate alerts for an aggregation of events and will notify you with a link of the Doctor Droid portal where you can see all E1 events whose E2 events got delayed or were missing. This takes into account all E1 events that were received between (Current_Time - T - X) and (Current_Time -X) timestamps.
- Filter on attributes in either of the events so that only the events satisfying that filter are being considered for the trigger rule.
- For the aggregated events trigger, you can choose to consider only those cases where secondary event got missed.
Updated about 1 month ago