Write Search Queries
Syntax
The search syntax is very close to the Lucene syntax. By default all message fields are included in the search if you don’t specify a message field to search in.
Messages that include the term ssh :
ssh
Messages that include the term ssh or login :
ssh login
Messages that include the exact phrase ssh login :
"ssh login"
Messages where the field type includes ssh :
type:ssh
Messages where the field type includes ssh or login :
type:(ssh OR login)
Messages where the field type includes the exact phrase ssh login :
type:"ssh login"
Messages that have the field type :
_exists_:type
Messages that do not have the field type :
NOT _exists_:type
Messages that match regular expression ethernet[0-9]+
:
/ethernet[0-9]+/
By default all terms or phrases are OR connected so all messages that have at least one hit are returned. You can use Boolean operators and groups for control over this:
"ssh login" AND source:example.org
("ssh login" AND (source:example.org OR source:another.example.org)) OR _exists_:always_find_me
You can also use the NOT operator:
"ssh login" AND NOT source:example.org
NOT example.org
Note that AND, OR, and NOT are case sensitive and must be typed in all upper-case.
Wildcards: Use ?
to replace a single character or *
to replace zero or more characters:
source:*.org
source:exam?le.org
source:exam?le.*
Note that leading wildcards are disabled to avoid excessive memory consumption! You can enable them in your Graylog configuration file:
allow_leading_wildcard_searches = true
Also note that message
, full_message
, and
are the only fields that are being analyzed by default. While wildcard searches (using source
*
and ?
) work on all indexed fields, analyzed fields will behave a little bit different. See wildcard and regexp queries for details.
Fuzziness: You can search for similar terms:
ssh logni~
source:exmaple.org~
This example is using the Damerau–Levenshtein distance with a default distance of 2 and will match “ssh login” and “example.org” (intentionally misspelled in the query).
You can change the distance like this:
source:exmaple.org~1
You can also use the fuzziness operator to do a proximity search where the terms in a phrase can have different/fuzzy distances from each other and don’t have to be in the defined order:
"foo bar"~5
Numeric fields support range queries. Ranges in square brackets are inclusive, curly brackets are exclusive and can even be combined:
http_response_code:[500 TO 504]
http_response_code:{400 TO 404}
bytes:{0 TO 64]
http_response_code:[0 TO 64}
You can also do searches with one side unbounded:
http_response_code:>400
http_response_code:<400
http_response_code:>=400
http_response_code:<=400
It is also possible to combine unbounded range operators:
http_response_code:(>=400 AND <500)
It is possible make a range query on the date field. It is important that the selected period of time at the time-picker fits the range you want to search in. If you search in the last 5 minutes, but the searched time is a week in the past the query will not return anything. The dates needs to be UTC and the format needs to be like Graylog displays them.:
timestamp:["2019-07-23 09:53:08.175" TO "2019-07-23 09:53:08.575"]
Graylog has a custom index mapping for the field timestamp to save the date in the format like YYYY-MM-DD HH:MM:SS.sss. If one additional field where Elasticsearch has determined that this is a date and used the default date format, which is YYYY-MM-DD HH:MM:SS.sss. Means that a search in that period would be like:
otherDate:["2019-07-23T09:53:08.175" TO "2019-07-23T09:53:08.575"]
At least with Elasticsearch 6.x, you can include timezone information in that time range. A query would look like:
otherDate:["2020-07-29T12:00:00.000-05:00" TO "2020-07-30T15:13:00.000-05:00"]
This date query can also be dynamic, that you always look back at a specified time:
otherDate:[now-5d TO now-4d]
Escaping
The following characters must be escaped with a backslash:
& | : \ / + - ! ( ) { } [ ] ^ " ~ * ?
Example:
resource:\/posts\/45326
Error Types
When entering your queries be sure to look out for warning and exceptions. If you enter a query Graylog won't understand, an icon with a yellow exclamation mark appears along with a message with the warning or exception. They include:
Parse exception: This exception is thrown when a parsing errors occurs. This appears when you make an error in the syntax of your search query. The error message should contain more information about the position of the syntax error.
Invalid operator: This occurs when the operator is misspelled. For example, AND
is a valid operator but and
is not. In most cases, operators are uppercase.
Unknown field: This warning occurs when you include a field in your search query that does not exist in the involved index sets. This is determined by the relationship between streams and index sets.
Parameter error: This error occurs when you are using an undeclared parameter in your search query. Parameters need to be defined before you can include them in your search.