Search¶
Text Search¶
Search generally consists of two parts: terms and operators. Wildcard queries are supported:
*
matches 0 or more arbitrary characters;?
matches exactly 1 arbitrary character.
Multiple terms can be combined into complex queries using boolean operators (AND
/OR
/NOT
).
Note
Explorer search uses the query_string() query syntax.
Terms can be single words or phrases. For example:
- Single word:
guance
; - Multiple words:
guance test
; (equivalent toguance AND test
) - Phrase:
"guance test"
; (using double quotes converts a group of words into a phrase)
Examples:
JSON Search¶
Prerequisites
- The workspace was created after
June 23, 2022
; - Used in log explorer.
By default, this performs an exact match on the content of message
, and the message
must be in JSON format. This search method does not support log content in other formats. The search format is: @key:value
. For multi-level JSON, you can use .
to connect key names, for example: @key1.key2:value
, as shown in the image.
Example scenarios:
The message information is as follows:
{
__namespace:tracing,
cluster_name_k8s:k8s-demo,
meta:{
service:ruoyi-mysql-k8s,
name:mysql.query,
resource:select dict_code, dict_sort, dict_label, dict_value, dict_type, css_class, list_class, is_default, status, create_by, create_time, remark
from sys_dict_data
}
}
# Query cluster_name_k8s = k8s-demo
@cluster_name_k8s:k8s-demo // Exact match
@cluster_name_k8s:k?s* // Fuzzy match
# Query service under meta = ruoyi-mysql-k8s
@meta.service:ruoyi-mysql-k8s // Exact match
@meta.service:ruoyi?mysql* // Fuzzy match
Note
When the search content contains .
(e.g., trace.id
), directly using the @key1.key2:value
format may cause the system to interpret trace
and id
as two separate keys instead of one whole. To avoid this issue, please use the @\"key1.xxx\":value
format instead. For example, @\"trace.id\":value
, which allows the system to correctly recognize the complete key name.
Search History¶
The system records the conditions each time a query is triggered. Clicking on them allows direct reuse of the query, with the option to flexibly modify it according to your needs.
Merge Records in Search History
As a universal tool within the platform, explorers are applicable to multiple functions. There are some differences in the interoperability of search histories between different functionalities:
- RUM > Session/View/Resource/Action/Long Task/Error: the search histories of these six explorers are interoperable;
- Container Explorer and Kubernetes Explorer have interoperable search histories;
- Resource Catalog Explorer has interoperable search histories;
- Log Explorer and Log Error Tracking Explorer have interoperable search histories;
- Trace Explorer, APM Error Tracking, and Profiling Explorer have interoperable search histories.
Except for the above cases, all other explorers independently save their respective search histories.