Skip to content

Search

Text Search

Search generally consists of terms and operators. Wildcard queries are supported:

  • * matches 0 or more arbitrary characters;
  • ? matches 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 to guance AND test)
  • Phrase: "guance test"; (using double quotes converts a group of words into a phrase)

Example:

JSON Search

Prerequisites
  • Workspace created after June 23, 2022;
  • Used in the Log Explorer.

By default, it performs an exact search on the content of message, and message must be in JSON format. Log content in other formats does not support this search method. The search format is: @key:value. For multi-level JSON, use . to connect key names, for example @key1.key2:value, as shown in the figure.

Scenario Example:

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 meta.service = 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 will cause the system to recognize trace and id as two separate keys rather than a whole. To avoid this issue, please use the @\"key1.xxx\":value format for input, for example @\"trace.id\":value, so that the system correctly recognizes the complete key name.

Search History

The system records the conditions for each triggered query. Clicking on it allows direct reuse of the query, and it can be flexibly modified as needed.

Search History Merging

As a general tool within the platform, Explorer is applicable to multiple features. The interoperability of search history between different features has some differences:

  • RUM > Session/View/Resource/Action/Long Task/Error six types of Explorers have interoperable search history;
  • Container Explorer and Kubernetes Explorer have interoperable search history;
  • Resource Catalog Explorer has interoperable search history;
  • Log Explorer and Log Error Incident Explorer have interoperable search history;
  • Trace Explorer, APM Error Incident, and Profiling Explorer have interoperable search history.

Except for the above cases, other Explorers independently save their own search history.

Further Reading