Free-text searches in LogScale are case-sensitive by default, meaning that searching for ERROR will not match events with the string error.

Searches can be made case-insensitive by adding the option i at the end of a regex, this indicates you want the regex to be case-insensitive:

/windows/i

In this example, all strings with either the word WINDOWS or Windows or wInDoWs will be returned in the results.

You can combine filters using the and and or logical operators.

method="GET" or
method="POST"

This query will find events with GET or POST in the field method.

You can also use the Wildcard character * to specify any text:

method="P*" or
method="D*ETE"

The and operator is applied implicitly if no operator is present:

method="PUT" example.com

This will find events with PUT in the method field, and example.com anywhere in the event.

Find listed some of the possible filters, with examples, that are widely used in LogScale.

example.com and statuscode=200

It reads as follows: find events that contain both text example.com and status code equal to 200

not example.com
and not statuscode=200

It reads as follows: find events that do not contain the text example.com and do not have the status code 200.

url=*

It reads as follows: match any event that has a field named url.

url!=*

It reads as follows: find all events, if any, that do not have a field named url.

Find more details about filters in the Query Filters reference section.

An effective usage of filtering in LogScale is provided by comparing a single field against a certain value, that is, to check if that field's value is greater or less than a defined value — for example:

statuscode > 200

This will return all events having a statuscode value greater than 200 thus filtering only certain server error codes, for instance.

test(field1 < field2)

test(field1 != 2 * field2)

groupBy(userid, function=[
{statuscode = 200 
| count(as=status200)},
{statuscode = 500 
| count(as=status500)}
])
| test(status500 > status200)

test(length(userid) == length(method))

avg(responsesize)

Calculates the average value of the field responsesize and returns just one number as the result, showing the field _avg in the Fields panel:

Figure 88. Aggregate Result, _avg Example

Used to count the number of certain events in the repository. For example, we may want to get the list of the status codes found when users access a web site, as well as the total count of each of them:

count(field=statuscode)

It returns just one number as the result, showing the field _count in the Fields panel:

Figure 89. Aggregate Result, _count Example

Used to group events based on the value of one or more fields.

groupBy(method)

The result is a table with a row for each method and the number of times that method has been observed:

Figure 90. GroupBy Result, Example One

The query above is a shorthand for:

groupBy(field="method")

or for:

groupBy(field="method",
function=count(as="_count"))

Both will produce the exact same result.

Since groupBy() is used very frequently, the parameters function and as have default values, and field is the unnamed parameter for groupBy().

A similar example of the groupBy() function would be:

userid=*
| groupBy(userid, function=count(as="_count"))

The result is a table with a row for each user and the number of times that user has appeared in the events:

Figure 91. GroupBy Result, Example Two

The as parameter can do more, see details at Renaming Output Fields.

Grouping can also be done by multiple fields, as in the following example:

groupBy([url, statuscode])

Used to plot events that have a certain field and produce a chart where the X-axis is time.

For example, events that have a field called responsesize are grouped into series in the time chart, based on its values:

timeChart(responsesize)

The same result can be obtained with the query:

responsesize = *
| timeChart()

Used to compute multiple aggregate functions over the input.

This is equivalent to count() function.

stats(function=count())

In the following example, this function will find the maximum and minimum responsesize:

[min_response := min(responsesize), max_response := max(responsesize)]

See Query Functions for more descriptions and examples on these and other aggregation query functions.

Can modify existing fields or create new ones on-the-fly. For example, we may want to show the responsesize field in kilobytes instead of bytes:

eval(sizeInKb=responsesize / 1000)

Allows you to associate the values of a given set of fields and add a new field that contains the merge between those concatenated values. Consider having events that contain either a list of users and a list of the URLs visited, see this example query:

concat([url, userid], as="combined")

The values of the fields url and userid are concatenated, for example, put together, to show which user navigated which URLs in the newly created combined field:

Figure 92. Concatenating Fields

For a detailed description of the as parameter, see Renaming Output Fields.

Takes an array-prefix and a regex pattern and searches all events for matches to the specified pattern. Any event that does not have an array containing a matching entry is filtered off, for example, dropped from the search results. For example, given a sequence of events containing incidents in an incidents array, find all events or hosts containing the 'Cozy Bear' incident, case insensitive:

array:contains(incidents, pattern="cOzY bEaR", flags="i")

Can replace text in field based on regular expressions, and also support capturing groups. Here is an example of string replacement:

replace("\/products\/(.*)", field=url, replacement="[\"category\"]=$1")

Can select a set of fields from each event, particularly useful if you need to export those fields. For example, look at PUT HTTP method and get a table that selects userid and responsetime fields in the searched time range, to be exported in a CSV file.

method=PUT 
| select([userid, responsetime])

Regular expressions are described in detail in Extracting Data Fields.

See Query Functions for more descriptions and examples on these and other transformation query functions.

One important transformation function is regex(), used to extract new fields by means of a regular expression that can contain one or more capturing groups.

For example, you may want to use the logs to figure out which product pages are the most visited.

regex("/products/.+/.+ HTTP/")

The expression above matches events that contain text like for example /products/books/102 HTTP/ — the Event list will now return URLs containing such texts.

Regular expressions are so common that there is even a literal syntax for writing them:

/\/products\/.+\/.+ HTTP\//i

In the query example above, the information about the product category and product id is encoded in the URL and is not available as a field. That means you cannot do a groupBy(). To solve this, you can run:

regex("/products/(?<category>.+)/(?<productId>.+) HTTP/")

This will extract new fields for each event that matches the regex. This syntax is called Groups and backreferences.

The Event list will now contain two new fields category and productId, which you are now able to group to determine how many product categories there are:

regex("/products/(?<category>.+)/(?<productId>.+) HTTP/")
| groupBy(category)

If you are regularly extracting data from events, it is more efficient to do this during parsing. See Parsing for more information.

join() functions do not support live queries, for the reasons explained in Join Operation and Optimization section.

As a consequence, when you enable the Live mode checkbox for a query using join(), be aware, that the query will not be run truly live but repeatedly instead, aiming to provide the most recent results.

For this purpose, an indicator in the UI will specify the last time the query was run:

Figure 95. Repeating Query Indicator