Skip to main content

Logs Search syntax

Logs Search syntax

Overview

In every log view, there is the possibility to filter logs using a search string. We will explore in this article how the user can retrieve relevant information from the logs by filtering and searching using queries.

The query string for the search is formed using elastic query string syntax. This is a brief description of how to use it. For more information, please visit the following link: Elastic query string syntax

Field names

There is a list of columns available for filtering in every log view, which can be found in the "View columns" drop-down. The following articles provide more information on the columns of logs: Automation Process Run Event LogNode Details Event LogNode Features Event Log, Model Event Log, Logs.

In addition to the fields from "View columns," there is a default field message. This field provides the log message to the user.

The query syntax allows you to specify fields that will be searched:

  • where the severity field contains word DEBUG

    severity:DEBUG
    
    
  • where the severety field contains words WARN or ERROR:

    severity:(WARN OR ERROR)
    
    
  • where the thread field contains the exact phrase "SimpleQueueWorker":

    thread:"SimpleQueueWorker"
    
    
  • where the message field contains binding parameter (note how we need to escape the space with a backslash):

    message:binding\ parameter
    
    
  • where any of the fields TASK_UUID, RUN_UUID or SESSION_UUID contains 4163f6e9cb0b or b32b5eb29eb2 (note how we need to escape the * with a backslash):

    \*UUID:(4163f6e9cb0b OR b32b5eb29eb2)
    
    
  • where the field title has any non-null value:

    _exists_:TASK_UUID

Wildcards

You can run wildcard searches on individual terms by using ? to replace a single character, and * to replace zero or more characters:

qu?ck bro*

Regular expressions

Wrapping regular expression patterns in forward slashes ("/") will allow them to be embedded in the query string: 

message:/joh?n(ath[oa]n)/

Ranges

Date, numeric and string fields can be specified with ranges. Inclusive ranges are enclosed in square brackets [min TO max] and exclusive ranges are enclosed in curly brackets {min TO max}.

  • All messages from 2022 year of GMT time zone:

    @timestamp:[2022-01-01 TO 2022-12-31]
    
    
  • All messages from 2022-05-04 in GMT+1 time zone (Curly and square brackets can be combined):

    @timestamp:[2022-05-04T00:00:00.000+01 TO 2022-05-05T00:00:00.000+01}
    
    
  • All messages prior to 2022 year of GMT time zone:

    @timestamp:{* TO 2012-01-01}

The following syntax can be used for ranges with one unbounded side:  

@timestamp:>1651047079242
@timestamp:>=1651047079242 
@timestamp:<1651047079242 
@timestamp:<=1651047079242
Where 1651047079242 is milliseconds passed from 1970 GMT, Wed Apr 27 09:11:19 GMT+1 2022

Boolean operators

All terms are optional by default, as long as one of them matches. A search for foo bar baz will find any document that contains one or more of foo or bar or bazIn addition to the default_operator discussed above, which makes all terms required, there are also boolean operators you can use in the query string itself for greater flexibility. 

Operators that are preferred are + (the term must be present) and - (the term must not be present). All other terms are optional. For example, this query:

quick brown +fox -news

states that:

  • fox must be present
  • news must not be present
  • quick and brown are optional — their presence increases the relevance

Grouping

Multiple terms or clauses can be grouped together with parentheses, to form sub-queries:

(quick OR brown) AND fox

Groups can be used to target a particular field, or to boost the result of a sub-query:

severiy:(ERROR OR WARNIN) message:(full text search)

Reserved characters

In order to use characters which are not operators in your query itself (but which function as operators), you must escape them with a leading backslash. For instance, to search for (1+1)=2, you would need to write your query as (1+1)=2. When using JSON for the request body.

The reserved characters are: + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : /

Failing to escape these special characters correctly could lead to a syntax error which prevents your query from running.

Examples

search string

description
@timestamp:[2022-05-04T15:00:00.000+03 TO 2022-05-04T15:10:00.000+03]

messages between 2022-05-04T15:00:00.000+03 and 2022-05-04T15:10:00.000+03

Use elastic build-in date formats to specify dates. Here are the timestamp in format yyyy-MM-dd'T'HH:mm:ss.SSSZ

@timestamp:{ * TO 2022-04-20 }messages before 2022-04-20
@timestamp:[ 2022-04-20 TO *]messages after 2022-04-20
@timestamp:[ 2022-04-19 TO 2022-04-20 ]messages between 2022-04-19 and 2022-04-20
logger:"eu.ibagroup.easyrpa.cs.queue.SimpleQueue"logger column equals eu.ibagroup.easyrpa.cs.queue.SimpleQueue
logger:/.*Simple.*/logger column contains Simple 
logger:(*SimpleQueue OR *ConsoleTransferListener)logger column ends with SimpleQueue or ConsoleTransferListenercontains 
thread:"DataPurge-1"threads equals DataPurge-1
thread:(+CsTask)threads that has CsTask
thread:(+http-nio-9000)threads that has http-nio-9000
thread:(+CsTask) AND logger:*ApComponentValidatorthread and logger columns filtering
+S4035Message must contain S4035 string. The same as message:+S4035. An S4035 error filtering.
WARNING:Message contains WARNING:
+(WARNING:) +(--illegal-access=warn)Message contains WARNING: and --illegal-access=warn
(TASK_UUID:62ee5144) AND (logger:/*ProcessExecutor/)TASK_UID field contains 62ee5144 and logger ends with ProcessExecutor
*UUID:"de680db1-44ac-40c2-8180-ca84d8ff844d"

TASK_UUID, RUN_UUID or SESSION_UUID has exact de680db1-44ac-40c2-8180-ca84d8ff844d

TASK_UUID:de680db1-44ac-40c2-8180-ca84d8ff844dTASK_UUID has word de680db1-44ac-40c2-8180-ca84d8ff844d