Docs
GitLabnistor.io
Menu
GitLabnistor.io

Rules and schedules

See which rules run what and when, read a rule's health, run an action by hand, and request a new rule.

Goal: know what Nistor runs, when, and how well it goes, and get a new rule added.

A rule says: when this happens (an event or a cron schedule), if these conditions hold, run this action on these nodes. Rules and scheduling explains rules in full.

Prerequisites#

  • You can sign in. The Scheduler page comes with the scheduling module, listed as Scheduling & Orchestration on the Plugins page.
  • To approve rule requests you need the rules:approve permission, and Nistor needs a connection to the Git repository where the rules live (see GitLab).

Browse the rules#

  1. In the sidebar, open Operations → Scheduler. The page opens on the Scheduling Rules tab.
  2. Narrow the list with the FILTERS panel: EXECUTOR TYPE, STATUS, PRIORITY, DATE, NODE COUNT, ACTIONS (7D), and Show externally managed (Sifflet) under EXTERNAL RULES. Search rules... searches by name.
  3. Read a rule's card from left to right: its name, status and priority, then APPLIES_TO (the nodes), WHEN (the cron schedule and time zone, or the events), IF (conditions), ON (the nodes the action targets, often the same as APPLIES_TO), DO (the action type and its settings) and STATS (nodes, actions in the last 7 days, version). JSON shows the rule's definition and History its versions.

The Scheduling Rules tab with its filters and the first rule cards

The other tabs cover the rest of scheduling: Graphs & Analytics, Refresh Conflicts, Recovery, Scheduler Status, Maintenance (maintenance windows), Business Calendars, System Monitoring and Explorer.

Read a rule's health#

  1. Choose a rule's name. Its page opens on Overview.
  2. The first line sums the rule up, for example: Daily at 07:20 (UTC), runs dummy_run on … → 1 node.
  3. The figures show the runs in the last 30 days, the SUCCESS RATE, the AVG DURATION and the COST. TOP FAILURE and TOP FAILING NODES show what fails most often.
  4. DEFINITION shows APPLIES TO, WHEN, CONDITIONS and THEN.
  5. The other tabs are Nodes impacted, Run timeline, Incidents, Permissions and Activity. Open worst incident jumps to the rule's worst open incident.

The page of the rule Mart refresh - daily store: 30 runs, 97% success, one failure

On the quickstart stack, open Mart refresh - daily store: 30 runs in 30 days, 97% success, one failure (Query exceeded the configured slot reservation and was evicted.), and one incident.

Run an action by hand#

  1. Open the node's page and choose the Execute tab.
  2. Pick the action, for example Dummy action (test), which simulates an outcome so that you can test rule triggers, incidents, retries and chains.
  3. Choose Run. Nistor locks the node and runs the action as the scheduler would, and the status updates on the page.

The Execute tab of mart_store_daily, with the dummy action and the Dataform run

On the quickstart stack, the Dummy action (test) card of mart_store_daily already shows COMPLETED from the seeded run. Choose Run: a moment later the card still reads COMPLETED, and its time changes to now. If the page reports that it could not connect to the scheduler service, check that the scheduler role is running (on the quickstart, docker compose ps lists it).

Ask for a new rule#

The web shell does not create live rules directly: rules are kept as files in a Git repository, and a person approves each change.

  1. On the Scheduler page, choose + Create Rule. The Create Scheduling Rule helper opens.
  2. Rule Setup: pick a template under Start from a template (Blank, Dataform Workflow, Data Quality Check, MicroStrategy Refresh, BigQuery Copy, BigQuery Export to GCS, Webhook Trigger), then fill in Name, Priority (1 is the highest, 100 the lowest), Status, Description and Tags. Choose Next.
  3. When: a cron schedule, or the events that trigger the rule, plus the execution conditions. This step also selects the nodes the rule listens to: Node Type, Node ID Patterns, Tags and Exclude Node IDs.
  4. What: the action and its target nodes.
  5. Preview (Preview fires): pick one of the matched nodes, and the helper replays its recent events against your draft to show when the rule would have fired. When the trigger matches no node, it says No nodes match this trigger.
  6. Review: check each section (choose one to go back and edit it), then choose Submit for review.

Step 1 of the rule helper, with its templates

Your request is listed under Rule requests → My requests. A reviewer finds it in the Review queue, then approves it, rejects it or sends it back, and an approval opens a merge request with the rule file. For a request in plain words instead of a full rule, choose Rule requests → Request a rule → Quick request.

Teams that keep their rules as code can skip the web shell and use nistor rules validate and nistor rules sync (see Rules as code).

Next#

Edit this page on GitLab

↑ ↓ to moveEnter to openEsc to close