Log Fields

When a log arrives, GridNMS normalizes it into a consistent set of named fields. That’s what lets you search across logs from very different devices in one query, and write detections that match on, say, a source IP no matter which vendor produced the message. This page lists the standard fields and the common names GridNMS recognizes for them.

These fields are also how GridNMS’s log data model is organized — the classification fields below (class_uid, category_uid, and so on) are what group logs into categories and classes. See that page for how the model is structured, and the Data Model Explorer (Explore → Data Model Explorer) to browse it against your own data.

Anything that doesn’t map to a standard field is still kept — see Field Extraction for adding your own.

Always-present fields

Every log carries these, taken straight from the message and how it arrived:

Field	What it is
_time	When the event happened, from the log’s own timestamp
_raw	The original, unmodified message
host	The logging source — the device’s hostname or IP from the log header
source	Where the log came in (for example, the syslog port it arrived on)
sourcetype	The detected log format (for example, a Linux auth log, CEF, LEEF)
sender_ip	The IP that actually sent the packet — useful for forensics when it differs from host
severity_id	The log’s own reported severity: 0 (Unknown) up to 6 (Fatal), where a higher number is more severe
facility	Syslog facility

Note

severity_id is a different scale from event severity (1 = Critical down to 5 = Info). One describes how serious the original log line reported itself to be; the other describes an event GridNMS raised from it.

Classification fields

These are what group a log into the data model’s categories and classes — see that page for what the values mean and how to browse them.

Field	What it is
class_uid	The specific kind of event (for example, Authentication, HTTP Activity)
category_uid	The broader category the class belongs to (for example, Identity & Access Management)
activity_id	The specific action within the class (for example, Logon vs. Logoff)
status_id	The outcome: 0 unknown, 1 success, 2 failure, 99 other

A log that hasn’t been matched to a specific class yet still has all four fields — it’s classified as Uncategorized (class_uid = 0) rather than left unset, so it’s always searchable.

Who, what, and where

These fields describe the actor and the network endpoints involved in a log line. They’re filled in as GridNMS recognizes a format, and you can populate more of them with Field Extraction.

Field	What it is
actor_user_name	The actor — a login name or service account
src_endpoint_ip / src_endpoint_hostname / src_endpoint_port	The source of the event — an address, hostname, and port
dst_endpoint_ip / dst_endpoint_hostname	The destination address and hostname
protocol_name	The network protocol — for example, tcp, ssh, http
action_id	The disposition GridNMS assigned (for example, allowed vs. denied)
device_id	The GridNMS device this log is attributed to, if any
collector_id / site_id	Which collector received the log, and which site it belongs to

Field names GridNMS recognizes automatically

Different vendors call the same thing by different names. GridNMS maps the common variants onto the standard fields above, so you can search the standard name and catch them all. A few examples:

Standard field	Also recognized as
src_endpoint_ip	sourceip, source_ip, src, srcip, client_ip, remote_ip, remote_addr
src_endpoint_port	source_port, sport, spt
dst_endpoint_ip	destination_ip, dest_ip, dst_ip, dst, dstip
actor_user_name	user, username, account, userid, login
protocol_name	protocol, proto, ip_protocol
action_id	action, act, verb
status_id	outcome, result, status

What fills these fields in

• Built-in parsers handle common formats out of the box — Linux authentication (sshd, sudo, login) events, and CEF / LEEF security events, among others.
• A generic key=value fallback pulls structured pairs out of any other format.
• Your own rules, added under Configure → Logs and Events → Field Extraction, handle gear-specific formats — including assigning a classification directly, or aliasing one of your own field names onto a standard attribute. See Field Extraction.

Once a field is populated, you can filter on it in Log Search and group or match on it in a detection.

Where to go next

• See how these fields organize logs into categories and classes in The Log Data Model.
• Search on them in Logs & Log Search.
• Match on them in Writing Rules.
• Add your own with Field Extraction.