Skip to content

Detections

Searching your logs is reactive — you only find a problem when you go looking. Detections make it proactive. A detection is a rule that continuously watches your incoming logs and automatically raises an event the moment a message matches a pattern you care about. Instead of remembering to search for “failed password” every morning, you write the rule once and GridNMS tells you when it happens.

The Detections page The Detections page lists each rule with its on/off switch, severity, match count, and when it last ran.

A detection describes:

  • What to look for in incoming logs (for example, many failed logins from the same address in a short window).
  • How serious a match is — its severity.
  • What to do on a match — always raise an event, and optionally open a Case.

When the rule matches, GridNMS raises an event on the Events & Alerts page, exactly like any other alert. To be told when it fires, turn on Notify on match right on the detection and pick who to alert — see Notifications.

Open Investigate → Detections. The list shows every rule with:

Column What it tells you
Enabled A switch to turn the rule on or off without deleting it.
Detection The rule’s name and description; built-in rules are marked, and any with a recent error are flagged.
Severity How serious a match is.
Auto-case Whether a match also opens a Case.
Matches How many times the rule has matched.
Last run When it last evaluated your logs.

Click any row to open its editor.

GridNMS ships with several built-in detections so you get value on day one, covering common security and operational patterns such as:

  • Authentication failures — repeated failed logins that may indicate a brute-force attempt.
  • Privilege or configuration changes — someone gaining elevated access or altering device configuration.
  • Suspicious or service-related activity reported in your logs.

Built-in rules are marked as such. You can enable or disable them and adjust their settings, but you can’t delete them — they’re always available to switch back on. Start by reviewing these, turning on the ones that fit your environment.

Click New Detection (or click an existing rule) to open the editor.

  1. Title — a name you’ll recognize, e.g. SSH brute force.
  2. Severity — Critical, Major, Minor, Warning, or Info. This becomes the severity of the events the rule raises.
  3. Description — a short note on what the rule detects.
  4. Rule — the pattern itself (covered below). Use Test to check it before saving.
  5. Enabled — whether the rule is active.
  6. Open a Case on match — turn this on to have matches also create a Case, so a meaningful pattern becomes a ready-made investigation rather than just an event.
  7. Notify on match — turn this on to be alerted when the rule fires. Choose Notify me and/or pick one or more notification endpoints (email, Slack, webhook, PagerDuty) from the dropdown. This is how a detection pages people — there’s no separate subscriptions list to maintain.
  8. Auto-clear (for problem detections) — give the rule a recovery condition and the event it raised will close itself when the problem clears, so you don’t have to close it by hand.

Click Save to store the rule. On an existing rule, Run now evaluates it immediately against recent logs so you can confirm it behaves as expected, and shows how many matches it found.

A detection runs in one of two ways:

Mode How it runs Best for
Scheduled (default) The rule re-checks your logs on a timer — you set Run every in seconds. Rules that count activity over a window, like “10 failed logins in 5 minutes.”
Streaming The rule is evaluated as each log arrives, not on a timer. Catching a single, unambiguous bad line the instant it lands.

Turn on the Streaming switch for a rule when you want an immediate reaction. Leave it off and set an interval when the rule needs to look across a window of recent activity.

Before you save, click Test. GridNMS checks that the rule is valid and does a dry run against your current logs, reporting:

  • Whether the rule parsed correctly (you’ll see a clear error if not).
  • The window, threshold, and grouping it compiled to.
  • How many matches it found right now, with a few examples.

If the test shows zero matches when you expected some, widen the window or loosen the pattern; if it shows far too many, tighten it. Iterate here until it’s right, then enable it.

  1. The rule matches one or more incoming log messages.
  2. GridNMS raises an event at the rule’s severity on the Events & Alerts page.
  3. If Open a Case on match is on, the event is also rolled into a Case for investigation.
  4. If Notify on match is on, the event is delivered to you and/or the notification endpoints you chose on the detection.

The Matches count and Last run time on the list update so you can see at a glance which rules are firing and which are quiet.

Sharpening detections with extracted fields

Section titled “Sharpening detections with extracted fields”

Detections are far more precise when your logs have named fields to match on — like a source IP, a username, or an outcome — rather than raw text. That’s what Field Extraction provides: it pulls structured fields out of messy log lines so a detection can say “group by source IP and fire when one address fails 10 times” instead of fuzzy text matching. GridNMS extracts common fields automatically, and you can add your own for gear-specific formats.