Transformations

Not everything that arrives at GridNMS should be treated exactly as-is. A chatty informational trap might deserve a lower severity, a known cosmetic warning shouldn’t page anyone, and a firehose of debug-level logging doesn’t need to be stored forever just because it exists. Transformations is where you shape that — two independent rule engines, reached from one page, that act before their data settles into its final place:

• Event Rules reshape an incoming event — tag it, change its severity, suppress it, or close it — before it lands on Events & Alerts.
• Log Rules cut ingest volume — drop or divert matching log records — before they’re ever written to storage, so noisy sources don’t cost you search performance or retained storage.

Where to find it

Open Configure → Logs and Events and select the Transformations tab. Two sub-tabs switch between the two engines: Event Rules and Log Rules. Both lists are evaluated top to bottom — the first matching rule wins, and later rules are skipped for that item.

Event Rules

Every inbound event — from a device check, an SNMP trap, or a log detection — passes through Event Rules before it’s written to the feed.

Match conditions

• Message Filter — a regular expression tested against the event’s full message text.
• Tag Filter — a regular expression tested against the event’s current tag (set by the source, or by an earlier rule in the list).
• Match Condition — Either fires the rule if the message or the tag matches; Both requires both to match, for narrower targeting. Leaving a filter blank means it always matches.

Actions

Action	What it does
Set Tag	Attach a tag string to the event, for filtering and for later rules to key on.
Set Severity	Override the event’s severity — for example, promote a warning to critical, or downgrade a chatty trap to Info.
Suppress	Drop the event entirely. It’s never stored or shown anywhere.
Close	Store the event but mark it closed immediately.

Click New Rule to open the editor, or click an existing rule to edit it. The status badge toggles a rule Active/Inactive without deleting it — handy for disabling something during a maintenance window.

Caution

Suppress is powerful. Match it as narrowly as you can — a specific message or device — so you don’t accidentally hide events that turn out to matter.

Common examples

The editor offers a set of ready-made examples you can start from and adjust: suppressing routine “configuration saved” syslog spam, tagging link-down events for easier filtering, escalating UPS low-battery traps to critical, and auto-closing anything already tagged test.

Log Rules

Log Rules act earlier in the pipeline than Event Rules — on the raw ingested log record, before it’s written to storage at all. Each rule matches on a sourcetype (assigned by a parser) and an optional message filter regex over the raw line, then takes an action.

Actions

Action	What it does
Drop	Discard the matching record before it’s ever written to storage.
Route internal	Keep the record, but divert it to the hidden internal index instead of your searchable logs.

Sampling and dry run

• Sample 1-in-N — instead of acting on every match, keep a deterministic slice and apply the action to the rest. For example, N = 100 keeps 1 record in every 100 (a load balancer’s health-check hits, say) and drops the other 99. N = 1 (the default) acts on every match.
• Dry run — a dry-run rule is evaluated and counted, but never actually drops or routes anything. New rules default to dry run, so you can see a rule’s blast radius from its counters before arming it for real.

Live counters

The list shows a running Matched / Acted count per rule (with a kept count alongside it when sampling is in play), refreshed automatically — so what a rule is discarding is never invisible, even though the discarded records themselves never reach storage.

Common examples

Starter examples cover dropping DEBUG-level syslog chatter, sampling load-balancer health-check spam down to 1-in-100, and routing sudo/audit lines to the internal index instead of the tenant log search.

Where to go next

• Assign the sourcetypes Log Rules match against in Parsers.
• Pull structured fields out of what makes it through in Field Extraction.
• Write rules that watch what’s left in Detections.
• See how retention and the cold tier fit in on Log Storage.
• Triage the events Event Rules shape on Events & Alerts.