Search¶

The search bar in the Explorer supports tokenized search, phrase search, field filtering, JSON search, and function queries. You can also switch to DQL mode to write complete query statements.

Select a Search Method¶

Combined Search¶

The Log Explorer suggests common combined operators such as AND and OR in the search bar dropdown.

• AND: Both conditions must be met.
• OR: Either condition must be met.
• Combined operators must be in uppercase.
• Lowercase and and or are treated as plain text in the search.

For example:

service:api AND status:error
source:nginx OR source:apache
(service:api OR service:web) AND status:error

Text Search¶

The Explorer text search uses the search() query syntax. The system tokenizes the input and retrieves data that contains all the tokens.

• Chinese characters are tokenized by character.
• English is tokenized by word boundaries such as spaces and punctuation.
• English search is case-insensitive.
• Tokens are not required to appear consecutively.

Token Search¶

After entering text, the system automatically tokenizes it. Data containing all the tokens is returned, even if other content exists between the tokens.

Chinese example:

Input: 我喜欢苹果

Possible matches:
- 我喜欢苹果
- 我很喜欢吃苹果
- 苹果是我喜欢的水果

All results above contain every valid token of the search term, and the tokens are not required to be consecutive.

English example:

Input: connection timeout

Possible matches:
- connection timeout
- Connection retry timeout
- connection request failed due to timeout

All results above contain both "connection" and "timeout", tokens are not required to be consecutive, and the search is case-insensitive.

Phrase Search¶

To search for a complete, continuous phrase, add # before the quoted string. Use English half-width double quotation marks:

• #"我喜欢苹果": matches "我喜欢苹果，也喜欢香蕉", but not "我很喜欢吃苹果".
• #"connection timeout": matches "connection timeout occurred", but not "connection retry timeout".

The Explorer supports the following phrase syntax:

# is the phrase search operator and is not part of the search content. Using quotation marks without # does not enable phrase search. Quotation marks must be paired, and the phrase cannot be empty. Unclosed #"connection timeout, #'connection timeout, and empty phrases #"", #'' are not executed as valid queries.

Phrase search can be combined with field filters and combined operators:

service:api #"connection timeout"
#"connection timeout" OR #"request timeout"
-#"health check"

Here, -#"health check" excludes data containing that continuous phrase, corresponding to the DQL condition not search('#"health check"'). When switching from standard mode to DQL mode, compatibility syntaxes are uniformly converted to the DQL phrase form #"...". Switching back to standard mode does not accumulate backslash escape characters.

JSON Search¶

JSON search is used to query nested fields in the message field of logs. The message must be a valid JSON format. The query format is @field_name:field_value. For nested fields, use . to connect the field names at each level.

Take @meta.service:api as an example:

For example, the message content is as follows:

{
  "__namespace": "tracing",
  "cluster_name_k8s": "k8s-demo",
  "meta": {
    "service": "ruoyi-mysql-k8s",
    "name": "mysql.query"
  }
}

You can use the following conditions to query:

@cluster_name_k8s:k8s-demo       # Exact match
@cluster_name_k8s:k?s*           # Wildcard match
@meta.service:ruoyi-mysql-k8s    # Query nested field
@meta.service:ruoyi?mysql*       # Nested field wildcard match

Here, * matches zero or more characters, and ? matches exactly one character. Wildcards are only used for field filtering, not for plain text search.

Field Name Contains .¶

In JSON search, . represents the nested field hierarchy by default. If a field name itself contains ., you must escape it with a backslash \.

Wrapping the field name in double quotation marks, such as @"user.id":1001, is not supported.

MD5 Function Query¶

If a sensitive data scanning rule applies MD5 processing to sensitive content, the original value is replaced with an irreversible 32-character hexadecimal hash. To locate the masked data using the original value, use the MD5 function query in the Explorer.

The recommended syntax is the function form:

field_name:md5(original_value)

For example, if the original value red in the color field has been converted to an MD5 hash, enter:

color:md5(red)

The system converts this to the following DQL condition:

`color` = md5("red")

The Explorer recognizes md5 and the parentheses as function syntax. For backward compatibility, the older syntax color:md5|red is still supported and produces the same DQL condition. The function argument cannot be empty. MD5 is case-sensitive and space-sensitive; ensure the input exactly matches the original value before encryption.

MD5 is a one-way hash algorithm and cannot reverse the hash to the original content. For more information, see Sensitive Data Scanning.

DQL Query¶

To use functions, expressions, aggregations, or complex filter conditions, click the DQL button on the right side of the search bar to enter DQL Query mode:

Search conditions in standard mode are converted to DQL when switching modes. For example:

The system automatically applies the corresponding data type and data source based on the current Explorer. For example, the following DQL query retrieves logs from the last hour where message contains connection timeout:

L("default")::logs:(message) {search(message, "connection timeout")} [1h]

• L indicates log data.
• "default" indicates the log index.
• logs indicates the data source.
• [1h] indicates the query time range of the last hour.

After entering DQL mode, you must use a complete DQL statement. Different Explorers correspond to different data types. You cannot switch to another data type within the current Explorer.

CIDR Function Query¶

The CIDR function queries data belonging to a specific IP range within a given IP field. It performs a range match, not a string match.

A CIDR range consists of a network address and a prefix length, for example 13.0.0.0/8. The larger the prefix length, the smaller the address range. For IPv4, /32 matches only a single IP address.

Query format:

CIDR(@field_name, IP_CIDR)

For example, to query data in the network.client.ip field belonging to the 13.0.0.0/8 range:

CIDR(@network.client.ip, 13.0.0.0/8)

Matches:
- 13.0.0.1
- 13.100.20.5
- 13.255.255.255

Does not match:
- 12.255.255.255
- 14.0.0.1

To match a single IPv4 address exactly, use /32:

CIDR(@network.client.ip, 13.10.20.30/32)

If the field value is empty, malformed, or not a valid IP address, it will not be matched.

In DQL mode, you can use the lowercase cidr() function and enclose the CIDR range in double quotation marks:

L::nginx:(*) {cidr(client_ip, "13.0.0.0/8")} [1h]

Search History¶

The search and filter history of the Log Explorer is independent of the index selection history. It is accessed via the history icon on the right side of the log index search box.

The current user can view the most recent search and filter conditions in the local browser, with a maximum of 100 entries. Clicking a history condition reuses it in the current Explorer.

Further Reading¶

• Filter
• DQL Functions
• Full-Text Index Stop Words List