sort

Sorts search results as specified by the sort criteria.

Synopsis

... | sort [<N>] ((+ | -) field)+

Where:

Usage Notes

Typically, the <field> list contains event fields available in the Logger schema or user-defined fields created using the rex operator prior in the query. However, fields might also be defined by other operators such as the eval operator.

Sorting is based on the data type of the specified field.

When multiple fields are specified for a sort operation, the first field is used to sort the data. If there are multiple same values after the first sort, the second field is used to sort within the same values, followed by third field, and so on. For example, in the example below, first the matching events are sorted by “cat” (device event category). If multiple events have the same “cat”, those events are further sorted by “eventId”.

When multiple fields are specified, you can specify a different sort order for each field. For example, | sort + deviceEventCategory - eventId.

If multiple fields are specified, separate the field names with a white space or a comma.

Sorting is case-sensitive. Therefore, “Error:105” will precede “error:105” in the sorted list (when sorted in ascending order).

When a sort operator is included in a query, only the top 10,000 matches are displayed. This is a known limitation and will be addressed in a future Logger release.

When this operator is included in a query, the search results cannot be previewed. That is, the query must finish running before search results are displayed.

Peer

Sort parameter N is not propagated to all peers. Nonetheless, sort limits peer results at 10 000, by default.

If the user still needs more data from peers, tune the property server.pipeline.sort.bash.count to the desire value in all Loggers.

Concept Link IconSee Also