Skip to content

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 to guance 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.

Further Reading

Feedback

Is this page helpful? ×