Parsers

Before a log line can be searched, classified, or matched by a detection, GridNMS first has to answer one question: what kind of log is this? A parser is what answers it. It looks at the raw line, recognizes its format, and assigns it a sourcetype — a label the rest of GridNMS (search, field extraction, and the log rule engine) can key off instead of guessing at raw text.

GridNMS ships with parsers for the common formats already, so nothing needs configuring to get started. Reach for a custom parser when you have a format the built-ins don’t recognize — for example, an appliance that writes its own distinctive message style over plain syslog — so it gets a real sourcetype instead of falling into the generic syslog bucket.

Where to find it

Open Configure → Logs and Events and select the Parsers tab. The list shows every parser with:

Column	What it tells you
Enabled	A switch to turn a custom parser on or off. Built-in parsers can’t be disabled.
Name	The parser’s name, tagged System (built-in) or Custom (yours).
Format	The format code it assigns.
Sourcetype	The sourcetype a match is classified as.
Detect	The pattern used to recognize the format.
Visibility	Whether matching logs stay visible in the default Logs view or are marked internal.

Click any row to open it. Built-in parsers open in a read-only view — you can see exactly how they recognize their format, but they can’t be edited or deleted.

Built-in parsers

GridNMS recognizes several formats out of the box, each assigned a fixed sourcetype the moment a line matches:

• JSON — the raw line parses as a JSON object. Its sourcetype comes from a sourcetype key in the payload when the sender includes one.
• CEF — the raw line carries a CEF: or LEEF: marker (Common/Log Event Format, used by many security appliances). Vendor, product, and severity come from the header, and any extension fields are pulled out too.
• HTTP Event Collector — logs received over the HTTP Event Collector listener. Sourcetype comes from the sending client’s own event envelope.
• Collector log — a collector’s own operational log stream, tagged per collector.
• Internal — GridNMS’s own operational and audit records. These are always marked internal (see below).
• Syslog — the terminal fallback for standard RFC3164/RFC5424 syslog and SNMP traps. A line that doesn’t match anything more specific lands here. This is exactly the format a custom parser exists to reclassify.
• Docker / journald — a syslog-family line carrying a journald-exported envelope (shipped by the Log Forwarder’s journald and Docker log modules) is unwrapped automatically: the envelope is dropped, and the container or system service name becomes the sourcetype (for example docker:my-app or linux:sshd) instead of one undifferentiated bucket. A container’s own structured log body is unwrapped one layer further, and its severity is used when present.

Creating a custom parser

Click New Parser to open the editor.

1. Name — a label you’ll recognize, e.g. MyApp appliance.
2. Sourcetype — the sourcetype assigned on a match, e.g. myapp. This is what field extraction rules and the log rule engine will match against.
3. Detect pattern — a regular expression tested against the raw log line. A syslog-fallback line that matches this pattern gets reclassified to your sourcetype.
4. Internal — turn this on to hide matching logs from the default Operational logs view (they’re still searchable under Include system (_internal) or System only (_internal)). Use it for noisy or audit-style lines you don’t want cluttering everyday search.
5. Enabled — whether the parser is active.

Testing before you save

Paste a real raw log line into the Test against a sample log box. GridNMS runs your pattern against it live and shows either a match (and the sourcetype it would be classified as) or No match — so you know it works before it’s live on real traffic.

Editing and disabling a parser

Click a custom parser to change its name, sourcetype, pattern, or visibility. Toggle the Enabled switch in the list to pause one without deleting it, or open it and use Delete to remove it entirely.

Where to go next

• Pull named fields out of the sourcetype you’ve assigned in Field Extraction.
• Drop or route ingested logs by sourcetype before they’re stored in Transformations.
• Search and filter on the results in Logs & Log Search.
• Set up TCP, TLS, or HTTP Event Collector listeners in Receiving Logs & Traps.