Skip to content
This is an archived version of the documentation downloaded from LogScale Documentation Archives. Up to date documentation, and documentation for later versions, is available on LogScale Documentation

## `sort()`

The `sort()` query function is used to sort events based on a given field — or fields. Events can be sorted by multiple fields by setting the field parameter to an array of field names (for example, between square-brackets in a comma-separated list). Likewise, the order and type of each field can be specified by setting the `order` and `type` parameters to arrays.

Parameter | Type | Required | Default Value | Description
--- | --- | --- | --- | ---
`field`[a] | array of strings | optional[b] |  | The fields by which to sort events.
`limit` | integer | optional[b] | `200` | The argument given to this parameter determines the limit on the number of events included in the result of the function. The default argument is `default`. The maximum is controlled by the `StateRowLimit` dynamic configuration, which is `StateRowLimit` by default. If the argument is `max` (`limit=max`), then the value of `StateRowLimit` is used.
|  | Controlling Variables
|  | `StateRowLimit` |
`order` | array of strings | optional[b] | `desc` | The order in which to sort.
|  |  | Values
|  |  | `asc` | Sort ascending
|  |  | `desc` | Sort descending
`reverse` (deprecated) | boolean | optional[b] | `false` | Whether to sort in descending order. This parameter is deprecated: use `order` instead. (deprecated in 1.100)
|  |  | Values
|  |  | `false` | Sort ascending
|  |  | `true` | Sort descending
`type` | array of strings | optional[b] | `number` | Set the data type of the fields to influence the sorting order.
|  |  | Values
|  |  | `any` | Any fields.
|  |  | `hex` | Treat the field as a hexadecimal value and sort in numerical order
|  |  | `number` | Treat the field as numerical and sort in numerical order
|  |  | `string` | Treat the field as string values and sort alphabetical
[a] The parameter name `field` can be omitted. [b] Optional parameters use their default value unless explicitly set.

Hide omitted argument names for this function

Show omitted argument names for this function

> Omitted Argument Names

> The argument name for `field` can be omitted; the following forms of this function are equivalent:

> logscale Syntax

>     sort(["value"])

> and:

> logscale Syntax

>     sort(field=["value"])

> These examples show basic structure only.

### `sort()` Function Operation

If the `order` or `type` parameter is a single value, all fields are sorted with the same order or type.

Setting the `type` field tells `sort()` how to compare the individual values, either using lexicographical order (for example, `string`), numerical magnitude (for example, `number`, `hex`). The `hex` argument supports numbers as strings starting with either `0x`, `0X`, or no prefix.

### Warning

Sorting is performed in memory. For optimum performance avoid sorting large numbers of events. Perform filtering first and sort the results, or use aggregation to simplify the event list before sorting. Putting `sort()` last in a query, after an aggregating function, offers the best performance.

### `sort()` Syntax Examples

As an example, suppose you have LogScale ingesting data from a web server and want to get a list of referring domains and sub-domains. That is to say, the URLs without the path and web page from which it came (for example, just `www.example.com` from `http://www.example.com/sales/great-sites.html`). Suppose further that you want a count of each referrer and want to sort them alphabetically in reverse order — because we're fickle like that. Below is an example of how that might be done:

logscale Syntax

    regex(regex="/.*/(?<ref_url>.+?)(/
    | $)", field=referrer)
    | groupBy(ref_url)
    | sort(ref_url, type=string, order=desc, limit=12)

In the first line here, we're using the `regex()` function to extract just the first part of the URL, dropping everything after the domain and first slash. On the second line we're using `groupBy()` to group on each referrer (for example, `ref_url`) and counting them. If we hadn't stripped out the base URL from the first line, we might have multiple entries for each domain. See the `regex()` and `groupBy()` reference pages for more information on those query functions.

In the third line of the query above, notice the parameters for the `sort()` function. First is the new field ref_url we created in the first line, then `type` parameter to specify the values sorted may include characters or numbers. The second is how to order the results: in this case, in descending order. Last is the `limit` parameter to limit the results to the first twelve in the sorted list of results. The table below shows the results.

ref_url | _count
--- | ---
www.zabotkin.ru | 14
www.tangblog.top | 1
www.skidn.com | 1
www.klfd.net | 1
www.iopt.pro | 42
www.google.com.au | 1
www.google.com | 11
www.bing.com | 3

To sort events by ascending or descending value, use the `order` parameter, for example:

logscale Syntax

    groupBy(ref_url)
    | sort(ref_url, type=string, order=asc, limit=12)

The output has been ordered using a string based (for example, alphabetical) sorting method.

The `limit` parameter to `sort()` limits the number of rows returned by the function after the sort has been completed. For example, to sort metrics by the repository name and then output the top entry:

Syntax

    name=livequery-count
    |groupBy([repo])
    |sort(field=_count,type=number,order=desc,limit=1)

The above query works by sorting the grouped counts (in the _count field), explicitly setting the type to `number` and then sorting by high to lowest (descending order).

To sort events by ascending or descending value, use the `order` parameter, for example:

logscale Syntax

    groupBy(ref_url)
    | sort(ref_url, type=string, order=desc, limit=12)

When using multiple fields, supply a corresponding array to `order` parameter as the `field` parameter, for example:

logscale Syntax

    groupBy([ref_url,method])
    | sort([ref_url,method], type=string, order=[desc,asc], limit=12)

### `sort()` Examples

Click + next to an example below to get the full details.

#### Calculate Query Cost for All Users by Repository

Search across multiple repositories to calculate query costs for all users by repository using `sort()` and `groupBy()` functions

##### Query

logscale

    #type=humio #kind=logs class=c.h.j.RunningQueriesLoggerJob message="Highest Cost query"
     | groupBy(repo, initiatingUser, totalLiveCost, totalStaticCost)
     | sort([totalLiveCost, totalStaticCost])

##### Introduction

In this example, the query uses `sort()` and `groupBy()` functions to find query costs. The query filters logs in humio repository that are tagged with `kind` equal to `logs` and then returns the events where the class field has values containing `c.h.j.RunningQueriesLoggerJob`, searching for the specific value `Highest Cost query`.

Example incoming data might look like this:

#type | #kind | class | message | timestamp | dataspace | initiatingUser | totalLiveCost | totalStaticCost | deltaTotalCost | repo
--- | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---
humio | logs | c.h.j.RunningQueriesLoggerJob | Highest Cost query | 2025-03-26T09:30:00Z | production | john.doe | 1500 | 800 | 2300 | security-logs
humio | logs | c.h.j.RunningQueriesLoggerJob | Highest Cost query | 2025-03-26T09:31:00Z | development | jane.smith | 2000 | 1200 | 3200 | app-logs
humio | logs | c.h.j.RunningQueriesLoggerJob | Highest Cost query | 2025-03-26T09:32:00Z | staging | bob.wilson | 1000 | 500 | 1500 | infra-logs
humio | logs | c.h.j.RunningQueriesLoggerJob | Highest Cost query | 2025-03-26T09:33:00Z | production | john.doe | 1800 | 900 | 2700 | security-logs
humio | logs | c.h.j.RunningQueriesLoggerJob | Highest Cost query | 2025-03-26T09:34:00Z | development | jane.smith | 2500 | 1300 | 3800 | app-logs
humio | logs | c.h.j.RunningQueriesLoggerJob | Highest Cost query | 2025-03-26T09:35:00Z | staging | alice.cooper | 1200 | 600 | 1800 | infra-logs

##### Step-by-Step

1. Starting with the source repository events.

2. logscale

       #type=humio #kind=logs class=c.h.j.RunningQueriesLoggerJob message="Highest Cost query"

   Filters for Humio internal logs containing `c.h.j. RunningQueriesLoggerJob` in the class field and where the value in the message field is equal to `Highest Cost query`.

3. logscale

       | groupBy(repo, initiatingUser, totalLiveCost, totalStaticCost)

   Groups the results by the repo field, the initiatingUser field, and by both cost types (the fields totalLiveCost, totalStaticCost), and returns a count in a field named _count.

4. logscale

       | sort([totalLiveCost, totalStaticCost])

   Sorts the results by both the totalLiveCost field and the totalStaticCost field, in descending order by default.

5. Event Result set.

##### Summary and Results

The query is used to search across multiple repositories and output query costs for all users by repository. The query returns the count in a field named _count. Use this query to focus on live and static costs separately.

Sample output from the incoming example data:

repo | initiatingUser | totalLiveCost | totalStaticCost | _count
--- | --- | --- | --- | ---
app-logs | jane.smith | 2000 | 1200 | 1
security-logs | john.doe | 1500 | 800 | 1
infra-logs | bob.wilson | 1000 | 500 | 1

#### Calculate and Sort Ingest Lag Times

Analyze the time difference between event occurrence and ingestion using the `select()` function with `sort()`

##### Query

logscale

    select([#repo, #Vendor, #type, @timestamp, @ingesttimestamp])
    | ingest_lag_in_mins := ((@ingesttimestamp-@timestamp)/1000)/60
    | sort(ingest_lag_in_mins, limit=20000)

##### Introduction

In this example, the `select()` function is used to analyze the time difference between when events occurred and when they were ingested into LogScale, helping identify potential ingestion delays or performance issues.

Example incoming data might look like this:

@timestamp | @ingesttimestamp | #repo | #vendor | #type
--- | --- | --- | --- | ---
2025-11-05T10:00:00.000Z | 2025-11-05T10:01:30.000Z | windows-events | Microsoft | SecurityEvent
2025-11-05T10:00:15.000Z | 2025-11-05T10:02:45.000Z | linux-syslog | Linux | SystemLog
2025-11-05T10:00:30.000Z | 2025-11-05T10:01:15.000Z | network-logs | Cisco | FirewallLog
2025-11-05T10:00:45.000Z | 2025-11-05T10:05:45.000Z | endpoint-logs | CrowdStrike | ProcessCreate
2025-11-05T10:01:00.000Z | 2025-11-05T10:01:45.000Z | cloud-logs | AWS | CloudTrail
2025-11-05T10:01:15.000Z | 2025-11-05T10:04:15.000Z | database-logs | Oracle | AuditLog
2025-11-05T10:01:30.000Z | 2025-11-05T10:02:00.000Z | windows-events | Microsoft | LoginEvent
2025-11-05T10:01:45.000Z | 2025-11-05T10:03:45.000Z | linux-syslog | Linux | AuthLog

##### Step-by-Step

1. Starting with the source repository events.

2. logscale

       select([#repo, #Vendor, #type, @timestamp, @ingesttimestamp])

   Selects the relevant fields for analysis: #repo, #vendor, #type, @timestamp, and @ingesttimestamp.

3. logscale

       | ingest_lag_in_mins := ((@ingesttimestamp-@timestamp)/1000)/60

   Creates a new field named ingest_lag_in_mins that calculates the time difference between @ingesttimestamp and @timestamp in minutes. The calculation first converts the millisecond difference to seconds (divided by 1000) and then to minutes (divided by 60).

4. logscale

       | sort(ingest_lag_in_mins, limit=20000)

   Sorts the results based on the ingest_lag_in_mins field in ascending order. The `limit` parameter is set to `20000` to ensure all relevant events are included in the analysis.

5. Event Result set.

##### Summary and Results

The query is used to calculate and analyze the time difference between when events occur and when they are ingested into LogScale, providing visibility into potential ingestion delays or performance issues.

This query is useful, for example, to troubleshoot correlation rule effectiveness, monitor data pipeline health, ensure real-time analysis capabilities, and identify potential bottlenecks in the data ingestion process.

Sample output from the incoming example data:

#repo | #vendor | #type | @timestamp | @ingesttimestamp | ingest_lag_in_mins
--- | --- | --- | --- | --- | ---
network-logs | Cisco | FirewallLog | 2025-11-05T10:00:30.000Z | 2025-11-05T10:01:15.000Z | 0.75
windows-events | Microsoft | SecurityEvent | 2025-11-05T10:00:00.000Z | 2025-11-05T10:01:30.000Z | 1.5
cloud-logs | AWS | CloudTrail | 2025-11-05T10:01:00.000Z | 2025-11-05T10:01:45.000Z | 0.75
windows-events | Microsoft | LoginEvent | 2025-11-05T10:01:30.000Z | 2025-11-05T10:02:00.000Z | 0.5
linux-syslog | Linux | SystemLog | 2025-11-05T10:00:15.000Z | 2025-11-05T10:02:45.000Z | 2.5
linux-syslog | Linux | AuthLog | 2025-11-05T10:01:45.000Z | 2025-11-05T10:03:45.000Z | 2.0
database-logs | Oracle | AuditLog | 2025-11-05T10:01:15.000Z | 2025-11-05T10:04:15.000Z | 3.0
endpoint-logs | CrowdStrike | ProcessCreate | 2025-11-05T10:00:45.000Z | 2025-11-05T10:05:45.000Z | 5.0

Note that the ingest lag is calculated in minutes for easier analysis. Lower values indicate better ingestion performance.

#### Filter Out Fields With No Value

Filter out fields with no values from search results using the `groupBy` with `sort()`

##### Query

logscale

    method=GET
    groupBy(field=[method, statuscode], function=count(as=method_total))
    sort([method, statuscode], order=asc)
    FieldName!=""

##### Introduction

It is possible to filter out on fields with no values in a given returned search result. In this example, all statuscode fields containing no value is filtered out from the final search result.

Example incoming data might look like this:

method | statuscode | method_total
--- | --- | ---
GET | <no value> | 10
GET | 200 | 32492
GET | 301 | 1
GET | 304 | 113
GET | 403 | 9
GET | 404 | 132

##### Step-by-Step

1. Starting with the source repository events.

2. logscale

       method=GET

   Filters for all events with methods of the type `GET`.

3. logscale

       groupBy(field=[method, statuscode], function=count(as=method_total))

   Groups the returned results into a method field and a statuscode field and makes a count of the events in a new field named method_total.

4. logscale

       sort([method, statuscode], order=asc)

   Sorts the returned results in ascending order.

5. logscale

       FieldName!=""

   Excludes all events where one of the fields do not contain a value.

6. Event Result set.

##### Summary and Results

The query is used to filter out fields not containing any values from the returned search result.

Sample output from the incoming example data:

method | statuscode | method_total
--- | --- | ---
GET | 200 | 32492
GET | 301 | 1
GET | 304 | 113
GET | 403 | 9
GET | 404 | 132

#### Find Least Common Values of a Field

Find the least common values of a field using the `sort()` function with `count()`

##### Query

logscale

    groupby([type,kind], limit=max, function=count())
    | sort(_count, order=asc)

##### Introduction

The `sort()` function can be used to sort values in a field bottom up. This is the opposite of the `top()` function, that can be used to find the most common values of a field in a set of events.

In this example, the `sort()` function is used to find the least common values of a field. Types of parsers used (type field) are grouped with their LogScale logging types (kind field) to find the least common values when searching for events of, for example, kinds `metrics`.

##### Step-by-Step

1. Starting with the source repository events.

2. logscale

       groupby([type,kind], limit=max, function=count())

   Groups the event set by the fields type and kind. For each unique combination of type and kind, it then counts the number of events, and returns the results in a field named _count.

   The parameter `limit` is set to `max` to return all counts, as the purpose of this example is to find the least common values of a field.

3. logscale

       | sort(_count, order=asc)

   Sorts the returned results in ascending order from the least common combinations to the most common combinations of type and kind.

4. Event Result set.

##### Summary and Results

The query is used to find the least common values of a field in a set of events, in this example, identifying the least and most common type/kind combinations in an event set. Identifying rare combinations of type and kind could indicate unusual events or potential security issues. This type of query is useful in various scenarios, particularly for data analysis and understanding patterns in event sets.

#### Enter search term