The Log Data Model

A firewall, a switch, a Linux server, and a SaaS API all describe the same kind of event — a login, a blocked connection, a DNS lookup — in completely different words. GridNMS normalizes every log it collects onto one standard data model, so a login is a login no matter which vendor wrote it. That’s what lets a single search or detection work across your whole environment instead of one device format at a time.

The model GridNMS uses is OCSF (the Open Cybersecurity Schema Framework) — a public, vendor-neutral standard also used across the security industry. GridNMS doesn’t invent its own private vocabulary for “what is this log about”; it maps onto a schema you can look up independently, and one you may already recognize if you’ve worked with other security or logging tools.

Why this is worth understanding

You don’t have to think about the data model to get value from GridNMS — logs are searchable and detections work the moment they arrive. But once you do:

• You learn the field names once. class_uid, status_id, actor_user_name mean the same thing whether the log came from a firewall, a Linux host, or your own application — you’re not relearning a new vocabulary per vendor.
• One query covers every source. “Show me every failed authentication” is a single search, not one search per device type.
• You can see exactly how well a log source is understood. A log that hasn’t been classified yet is never dropped or hidden — but the model makes it obvious which of your sources are fully mapped and which ones aren’t.

How the model is organized

Every log GridNMS classifies is placed into a category, and within that category, a specific class. The class defines the attributes that describe that kind of event.

Level	What it means	Example
Category	A broad grouping	Identity & Access Management
Class	A specific kind of event within the category	Authentication
Activity	The specific action within the class	Logon, Logoff
Attributes	The fields that describe an event of this class	user, source IP, source host, severity, status

For example, the Authentication class (in the Identity & Access Management category) has Logon and Logoff activities, and carries attributes like the user, source IP, and source host involved — alongside the fields every class carries: severity, activity, and status (the outcome: success, failure, or unknown). HTTP Activity (in Network Activity) adds attributes specific to web traffic — the URL path, user agent, and response code. Categories today include System Activity, Identity & Access Management, Network Activity, Discovery, Application Activity, and Findings.

Not every log arrives already speaking a format GridNMS recognizes. Anything that hasn’t been classified yet lands in Uncategorized (the “Base Event” class) — it’s never dropped, and it’s still fully searchable, it just hasn’t been sorted into a specific class. A large Uncategorized bucket is a signal, not a problem: it tells you which of your log sources could benefit from a custom extraction rule to get properly classified.

The model grows over time as GridNMS adds support for more classes and vendor formats — you don’t need to do anything for that; it’s part of normal product updates.

Note

GridNMS also uses a separate severity scale for events and cases (1 = Critical down to 5 = Info). A log’s own severity_id is a different scale — 0 (Unknown) up to 6 (Fatal), where a higher number is more severe. They describe different things: one is how serious an event GridNMS raised is, the other is how serious the original log line reported itself to be.

Browsing the model: the Data Model Explorer

Open Explore → Data Model Explorer to see the model applied to your own data.

The page lists every class GridNMS knows about, grouped by category, with — for your selected time range — a row count, the number of sources feeding it, and a summary of how many of its attributes have actually been populated. A summary line at the top shows how many classes have data at all, and how many total rows were classified over that range.

Click any class to drill in and see:

• Sources — which sourcetypes are feeding this class.
• Attributes — every attribute the model defines for this class, each with a fill-rate bar showing how much of your traffic actually populated it. An attribute with nothing behind it yet is marked Not observed rather than hidden — the full shape of the class is always visible, whether or not you have data for every part of it.
• A Search this class in Logs button that jumps straight into Log Search pre-filtered to that class.

Tip

The Explorer is useful even on a brand-new tenant with no logs collected yet — it always shows the complete model (every category, class, and attribute), not just what you happen to have data for. It’s a good way to see what GridNMS is capable of classifying before you’ve pointed anything at it.

Connecting to search

The field names shown in the Explorer aren’t just for browsing — they’re exactly what you filter and group on in Log Search and in detections. A class is identified by class_uid, its category by category_uid, the specific action by activity_id, and the outcome by status_id.

You can reach a class two ways in the search bar:

• Type it directly — class=Authentication (by name) or class_uid=3002 (by number) both work.
• Browse for it — click Browse OCSF classes in the search bar to pick a category and class visually, without memorizing names or numbers. Once a class is selected, the search bar’s own suggestions narrow to that class’s attributes, so you can build the rest of the query without leaving the keyboard.

See Log Fields for the full list of standard fields, and Writing Rules for using them in a detection.

Field extraction and aliasing

GridNMS classifies as much as it can automatically as logs arrive. When a source isn’t recognized — or you want to correct how it’s classified — Field Extraction (Configure → Logs and Events → Field Extraction) is where you close the gap, in two ways:

• Assign a classification to a sourcetype. An extraction rule can say “logs of this sourcetype are the Authentication class, activity Logon” — your assignment takes priority over GridNMS’s own built-in classification for that sourcetype.
• Map one of your own fields onto a standard attribute. A Field Alias maps a native field name (say, response_code) onto the model’s attribute for it (http_response.code), so it lands in the standard field instead of the unmapped long tail. Aliases fill a gap — they never override a field GridNMS already recognizes automatically.

Both live on the same Field Extraction page, next to the rule editor and tester.

Where to go next

• Browse your own data against the model in the app: Explore → Data Model Explorer.
• Search and filter on these fields in Logs & Log Search.
• See the full field reference in Log Fields.
• Use these fields to build alerts in Writing Rules.
• Close classification gaps with Field Extraction.
• Device metrics and inventory readings use a separate, comparable vocabulary — see the Telemetry Data Model.