Grok Parser
A Grok Parser is a Datadog log processor that reads the body of a log with rules made up of named patterns and extracts items such as the timestamp, level, and duration as attributes. Its syntax is shorter and more readable than pure regular expressions, and the extracted attributes can be used directly for search and aggregation.
Overview
A Grok parser is a processor within a log pipeline that extracts attributes from the plain-text body of a log. Because Datadog parses JSON-formatted logs automatically, what it targets is semi-structured text such as plain-text application logs and web server access logs. A rule is written as a combination of three elements, %{matcher:attribute:filter}, where the matcher expresses "what will come here", the attribute name "where to put it", and the filter "how to shape it". You care about it in situations such as being unable to search on an attribute you thought you had extracted, a value that should be a number being treated as a string, or a timestamp not being picked up; if you know the evaluation order of rules and how types are determined, you can narrow down the cause.
Extraction rules that give regular expressions names to make them readable
A Grok parser is one of the processors that make up a log pipeline, and its role is to pull attributes out of the log body. The official documentation explains that JSON-formatted logs are parsed automatically and that for other formats you add attributes with a Grok parser, and positions its syntax as easier than regular expressions (as of September 2026; Source: Parsing). A rule is written in the form %{MATCHER:EXTRACT:FILTER}. Consider, for example, the single line john connected on 11/08/2017. Applying %{word:user} connected on %{date("MM/dd/yyyy"):date} puts john into user and the date-time converted to a Unix timestamp into date. In effect, the regular expression \b\w+\b is covered by the single word word. How to arrange processors is left to the log pipeline entry.
Matchers - saying by name what will come
The heart of a rule is the matcher. At the spot you want to extract, you declare "a word comes here" or "a number comes here", and send that part to an attribute name. Here are the main ones listed in the official documentation.
| Matcher | What it matches | Notes |
|---|---|---|
word | A single word made up of alphanumerics and _ | Equivalent to the regular expression \b\w+\b |
notSpace | The string up to the next whitespace | Used to capture values that contain symbols |
integer / number | Integer / decimal | Parsed as a numeric type |
data | Any string, including whitespace and line breaks | Equivalent to .*. Used when nothing else fits |
date("pattern") | A date-time in the specified format | Converted to a Unix timestamp |
regex("pattern") | Any regular expression | The escape hatch when a named pattern cannot express it |
The key to telling them apart lies in three: word, notSpace, and data. Because word accepts only alphanumerics and underscores, service names that contain hyphens or symbols are captured with notSpace. Since data swallows whitespace and line breaks alike, if you use it only in places that receive "everything remaining", such as the message body at the end of the line, it will not drag other attributes in. There are also dedicated matchers for IP addresses, hostnames, port numbers, and UUIDs (as of September 2026).
Filters shape the type and form
The third element, the filter, is the component that post-processes the matched string. integer and number convert the value to a numeric type, boolean to a boolean, and nullIf("value") converts the specified value to null. lowercase / uppercase normalize the case, and scale(factor) multiplies a number by a factor. There are also ones such as json, keyvalue, and csv that structure an entire format (as of September 2026; Source: Parsing). What matters in practice is how the type is determined. If you capture a duration with %{notSpace:duration}, it becomes a string, and you cannot compare magnitudes or compute averages. Make it a number with %{integer:duration} or %{number:duration} and then register it as a facet measure, and range search and aggregation become available.
When multiple rules are lined up, which one takes effect
A single Grok parser can contain multiple rules, but only one matches a given log: the first rule to match, from the top down, performs the parsing. Each rule can reference rules defined above it, and rule names must be unique within the same parser, consist only of alphanumerics, _, and ., and start with an alphanumeric (as of September 2026; Source: Parsing). The point that is easy to overlook is that a rule must match the entire log. Because it has to account for the line from start to finish, a rule that describes only the first half will not match. Large gaps of whitespace and line breaks are received with \s+ and \n. When there is a lot in common, you can define components such as user and server first as helper rules and call them from the main rule in the form %{user}. By default the message attribute is parsed, but the Extract from setting lets you target a different attribute such as command.line.
Grok in the search screen is only a subset of Grok at ingestion
Grok can be used not only as a processor at ingestion time but also at query time, as a calculated field in the Log Explorer. However, the matchers available at query time are only five: data / integer / notSpace / number / word. The official documentation states explicitly that filters, too, are limited to two, number and integer (as of September 2026; Source: Parsing). This means that interpreting date-times, expanding JSON, and breaking down key-value pairs can only be done at ingestion. When, in the middle of an investigation, you think "I want to narrow down by this value", the judgment becomes: if it is a simple extraction, the search screen will do; if a conversion of type or form is needed, add a rule to the Grok parser in the pipeline and then wait for the incoming logs. Once you have adopted Log Management, if you write rules in advance for just three things, the timestamp, the level, and the duration, you will not be stuck in the search screen during an incident.