Grok Pattern Builder & Debugger

Grok is a layer on top of regex, not a replacement. Every grok pattern compiles down to a regular expression. The differences: 1) Grok gives you 100+ pre-built, tested patterns (%{IP}, %{TIMESTAMP_ISO8601}) so you don't reinvent them. 2) Grok pairs each match with a named output field, so parsing and field mapping happen in one step. 3) Grok patterns are far more readable — %{COMBINEDAPACHELOG} vs. a 400-character regex. Use plain regex for one-off matching in code; use grok when parsing logs into structured data for a SIEM or log platform.

Work left to right: grok fails at the first non-matching element, and everything after it never gets evaluated. This tool's debugger automates that process — it matches your pattern segment by segment, shows exactly where matching stopped (green = matched, red = unmatched), and suggests replacements for the failing element. The most common causes are: timestamp format mismatches, single literal spaces where the log has multiple spaces or tabs, and unescaped special characters like [ ] ( ).

GREEDYDATA matches everything to the end of the line (regex .*). It's perfect as the last element of a pattern to capture "the rest of the message." Avoid using it in the middle of patterns — the regex engine will match to the end of the line, then backtrack character by character to satisfy the rest of your pattern. On non-matching lines this causes catastrophic backtracking that can spike Logstash CPU. Use %{DATA} (non-greedy) between known anchors instead.

Paste or build your grok pattern in this tool, then open the Export panel and choose "Regex (JavaScript)" or "Regex (PCRE)". The tool recursively expands every %{PATTERN:field} reference into its underlying regular expression with named capture groups. This is useful when you need the same parsing logic in application code, grep -P, or a tool that doesn't support grok.

Yes. Open "Custom Patterns" below the pattern input and define them one per line, exactly like a Logstash patterns_dir file: ORDERID ORD-[0-9]{6}. You can then reference %{ORDERID:order_id} in your main pattern. The Logstash and ingest pipeline exports automatically include your custom definitions in the generated config.

For the standard combined format, use the built-in %{COMBINEDAPACHELOG} pattern (works for both Apache and nginx default formats). It extracts clientip, timestamp, verb, request, response, bytes, referrer, and agent fields. This tool includes presets for nginx, Apache, HAProxy, and IIS — click one to load the pattern with a sample log line.

Start with %{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:hostname} %{PROG:program}(?:[%{POSINT:pid:int}])?: %{GREEDYDATA:message} for traditional RFC 3164 syslog. This extracts the timestamp, host, program name, optional PID, and message. For specific applications (sshd, CRON, kernel), parse the message field with a second grok pattern. The Syslog and SSH presets in this tool give you working starting points.

Dissect splits strings by fixed delimiters with no regex involved, making it roughly 4x faster than grok. Use dissect when your log format is rigid (every line has identical structure, like CSV or tab-separated). Use grok when the format varies — optional fields, variable whitespace, or different message types in the same stream. A common production pattern is dissect first for the fixed prefix (timestamp, host), then grok only the variable message part.

Add :int or :float as a third component: %{NUMBER:response_time:float} or %{INT:status_code:int}. Without this, every captured field is a string — which means your log platform can't do range queries, sums, or averages on it. This matters for response times, byte counts, and status codes you'll want to aggregate in dashboards.