Rules
Rules define what to watch and when to raise an Alert. Each rule targets one resource group (Directors, Devices, or Targets), picks one rule type, applies to a configurable scope of resources within that group, and runs on the engine's one-minute evaluation tick.
Accessing Rules
Navigate to
Rules List
Columns:
| Column | Description |
|---|---|
| Rule Name | Name assigned at creation |
| Resource Group | Directors / Devices / Targets |
| Rule Type | The chosen rule type (for example, Disk utilization) |
| Applied Resources | Number of resources currently in scope (or All) |
| Severity | Severity levels configured on the rule (one for single-severity rules, up to four for multi-severity rules) |
| Status | Active / Passive — Active rules are evaluated every minute; Passive rules are not |
Controls:
Search rules — free-text search across rule name and rule typeResources filter — All, Directors, Devices, TargetsRule Type filter — populated from the rule types available for the selected resource group- Pagination at the foot of the table
Per-row actions (row menu):
The
Creating a Rule
The wizard runs in four steps. The Next button is disabled until every required field on the current step is valid.
Step 1: Define Rule Scope
| Field | Description |
|---|---|
| Rule name | Required. Up to 255 characters. |
| Description | Optional. Free text. |
| Resource Group | Required. One of Directors, Devices, or Targets. Drives every option in the remaining steps. |
| Scope | Required. See the scope modes below. |
Scope modes (labels follow the chosen resource group — directors, devices, or targets):
| Mode | Behavior |
|---|---|
| The rule applies to every current and future resource in the chosen group. A | |
| The rule applies only to the resources picked from the list. | |
| Device rules only. Pick one or more Directors; the rule applies to every Device connected to those Directors, including Devices added later. |
Step 2: Set Rule Type
Pick one rule type from the cards shown for the selected resource group. The set of available types depends on the resource group — see Rule types for the catalog.
Step 3: Define Rule Behavior
The fields that appear in this step depend on the chosen rule type. The common controls are:
| Control | Description |
|---|---|
| Toggle. Off (default) means the rule is evaluated continuously. On lets the user add one or more windows of weekday + start/end time in a chosen timezone; outside those windows the rule is not evaluated. | |
| Severity | Single-severity rule types fix one level (Critical, High, Medium, or Low). Multi-severity rule types accept up to four severity rows, each with its own threshold. |
| Threshold | The numeric trigger value for threshold-based rule types. For utilization rules the unit is fixed to percent and capped at 100; for data and event volume rules a unit selector accompanies the value. |
| The observation window over which the engine evaluates the rule. Minimum one second. | |
| Resolve condition | Available only on Crash detection and Backpressure. |
Step 4: Review and Create Rule
A read-only summary of every value entered in the preceding steps.
Rule Types
The Rule Type filter in the list and the Step 2 cards in the wizard are populated from the catalog below. The Severity model column shows whether the rule type uses one fixed severity (single) or up to four severity rows with thresholds (multiple). The Threshold column shows the input fields shown in Step 3 — — means the rule type has no threshold value (it fires on a binary condition such as disconnection).
Director rules
| Rule type | Severity model | Threshold | Resolve condition |
|---|---|---|---|
| Director status | single | — | — |
| No data received | single | — | — |
| Total ingest amount | multiple | value + unit (KB / MB / GB / TB / events) | — |
| Disk utilization | multiple | percent (≤ 100) | — |
| Processor utilization | multiple | percent (≤ 100) | — |
| Memory utilization | multiple | percent (≤ 100) | — |
| Queue usage | multiple | percent or size — see Queue usage input mode | — |
| Crash detection | single | — | yes |
Device rules
| Rule type | Severity model | Threshold | Resolve condition |
|---|---|---|---|
| Device status | single | — | — |
| No data received | single | — | — |
| High data volume | multiple | value + unit (KB / MB / GB / TB) | — |
| Low data volume | multiple | value + unit (KB / MB / GB / TB) | — |
| High event volume | multiple | value + unit (events) | — |
| Low event volume | multiple | value + unit (events) | — |
Target rules
| Rule type | Severity model | Threshold | Resolve condition |
|---|---|---|---|
| Target status | single | — | — |
| High data volume | multiple | value + unit (KB / MB / GB / TB) | — |
| Low data volume | multiple | value + unit (KB / MB / GB / TB) | — |
| High event volume | multiple | value + unit (events) | — |
| Low event volume | multiple | value + unit (events) | — |
| Queue usage | multiple | percent or size — see Queue usage input mode | — |
| Backpressure | single | — | yes |
Severity models
A single-severity rule has one severity level — the rule either fires at that level or not at all. Every status rule type and the two rule types with a resolve condition (Crash detection, Backpressure) use this model.
A multi-severity rule accepts up to four severity rows. Each row pairs a severity (Critical, High, Medium, Low) with its own threshold; the wizard validates that the thresholds are ordered consistently — Critical at the highest impact, Low at the lowest. When an evaluation crosses more than one threshold simultaneously, the highest matching severity is used.
Queue usage input mode
Queue usage rules expose an extra control that selects between two threshold interpretations:
| Mode | Threshold meaning |
|---|---|
| Threshold is a percentage of queue capacity, capped at 100 | |
| Threshold is an absolute size — value plus unit (KB / MB / GB / TB) |
Switching mode replaces the threshold input field on the form.
Resolve condition
Crash detection (Directors) and Backpressure (Targets) are the only rule types that expose a resolve condition. The two options are:
Do not resolve the alert — the alert stays Open until an operator resolves it manually.Resolve alert after a time period — the engine auto-resolves the alert once the configured time has passed without the condition recurring.
For threshold rule types (utilization, data volume, event volume, total ingest amount, queue usage) there is no resolve-condition field — the engine auto-resolves these alerts on its own when the triggering condition stops being met.
Rule Detail
Clicking a row opens the rule detail page, organized into three tabs. Editing on the detail tabs is gated by the settings-edit permission, which is distinct from the rule permissions that govern the list actions.
Rule Overview
The Overview tab summarizes the rule. A small set of fields is editable inline:
-
Rule Name -
Description Assigned Resources — the scope; the displayed count includes aSee all link that lists the resources currently matched
The following fields are immutable after creation:
-
Rule Type -
Resource Type
Rule Configuration
Every behavior field from Step 3 of the wizard is editable here — working hours, severity rows and thresholds, time period, queue usage input mode, and resolve condition. Saving changes applies them on the next evaluation tick.
Triggered Alerts
A table of alerts the rule has produced, with pagination at the foot — the tab has no search or filter controls.
| Column | Description |
|---|---|
| Last Updated | Most recent change |
| Severity | Current severity |
| Trigger Condition | Threshold and current value snapshot |
| Resource | Resource that produced the alert |
| Status | Open / Acknowledged / Resolved |
Rule Actions
| Action | Effect |
|---|---|
| Opens the rule detail page. Available from the rules list row menu only. | |
| Creates a draft copy of the rule and opens it in the wizard at Step 1, including for system rules that cannot be edited directly. | |
| Toggles status between Active and Passive. A Passive rule is preserved but is not evaluated. | |
| Removes the rule and stops further evaluation. Existing alerts that the rule produced remain in the alerts list. |
Apart from
System rules
System rules are shipped with the platform. They are marked in the rules list and behave like user-created rules at evaluation time, but they cannot be edited or deleted.