Skip to main content

Rule templates and built-in rules

Nightingale ships rule templates for MySQL, Redis, Kubernetes and sixty other components; import them into any business group, and save your own rules as templates.

Where this page ends: the alert rules that ship with Nightingale for MySQL, Redis, Kubernetes and sixty other things are in one of your business groups, pointed at your data sources and attached to a notification rule — and you know how to put your own rules into the same library.

The library that ships with the install​

Integrations → Components (/components) is a grid of logos, one per integration. v9.1.1 ships 86 integrations; 64 of them carry alert rules, 755 rules in total.

Click an integration to open its drawer. Among its tabs, Alert rules is the list of rules that integration brings. Each rule carries a note, tags, and an action annotation with concrete first-response advice for whoever gets paged.

The list is filterable by Category — the categories come from how the rules are packaged, so MySQL has mysql_by_categraf and mysql_by_exporter as separate categories. Pick the one matching how you actually collect the metrics; importing both gives you every rule twice.

Rules from the shipped library are marked System in the Updated by column. That mark also means they cannot be edited or deleted here — only imported.

Import a built-in rule into a business group​

Tick the rules you want, then Import to business group.

FieldWhat to put in it
Business groupWhere the rules land, and therefore which team owns the resulting events
EnabledOff by default. Leave it off, review what came in, then enable
Source typeRead-only, derived from the rules you selected
Data source filterWhich of your instances these rules should run against
Notification ruleAttach one here. The built-in rules carry no notification config of their own
ContentThe rules as JSON. Editable — this is the place to adjust a threshold before it lands

All the rules in one import must share a data source type; a mixed selection is refused before submission.

Submit. Expected result: the rules appear in that business group's rule list, disabled, with your data source filter and notification rule already set.

Unlike the export/import round trip described in Import, export and reuse, this path keeps the effective time window — the built-in rules carry theirs in the file.

The same import, from the rule list​

If you are already looking at a business group's rules, you do not have to go to Components: Alert rules → Import → Import built-in alert rules browses the same library and imports into the group you are in.

One difference worth knowing: this path does not offer the notification rule field, so rules imported this way arrive with nothing attached. Set it afterwards with More → Update alert rules → Notification rule.

What to do after importing​

A built-in rule is a starting point, not a finished configuration. Three things need your attention before you enable them:

  1. Thresholds. They were written against a generic install. disk_used_percent > 85 is reasonable for a database server and noisy for a log collector. Go through them once.
  2. Severity. The library is generous with S1. Decide which of these genuinely justify waking someone — see Labels, annotations and severity.
  3. A notification rule, if you imported from the rule list. Without it the rule fires into silence.

Then enable them a few at a time rather than all at once, so that a wave of noise can be traced to a specific batch.

Turning your own rule into a template​

There is no "save as template" button. The supported path is a deliberate three-step one, and the form itself tells you so:

  1. build and refine the rule in your own business group, where you can test fire it against real data;
  2. select it in the rule list and use More → Export rules JSON;
  3. go to Integrations → Components, open the integration it belongs to (or create one), the Alert rules tab, and click Create. Fill in a category name and paste the JSON.

A template stored this way lives in the database rather than the shipped files, so it shows your name in Updated by instead of System, and you can edit and delete it. From then on it appears in the same list as the built-in ones and imports the same way.

You can also create a new integration from the Create button on the Components page itself — it takes a name, a logo and an enabled flag. There is no package upload; an integration created this way is a container for templates you paste in.

Two notes on the JSON. The rule name is what the import matches on, so give templates names that will not collide with rules people already have. And strip anything environment-specific before pasting — data source ids in particular, since the import form sets those.

Where the library comes from​

The shipped rules are plain JSON files in the Nightingale release, under integrations/<Integration>/alerts/*.json. Each file is an array of rules, and the file name becomes the category you see in the UI.

They are read from disk at startup. The integrations themselves are recorded in the database; the alert rules, dashboards and metric descriptions are held in memory and rebuilt on every start, which is why editing the JSON files and restarting is enough to change what the library offers.

The directory defaults to integrations next to the working directory, and can be moved with BuiltinIntegrationsDir under [Center]. To skip loading the shipped library entirely — an air-gapped install with its own curated set, say — insert a row into the configs table with ckey = disable_integration_init.

Next​

On this page