Data Retrieval¶

Obsy Copilot can help users write query statements and also convert natural language into Explorer filter conditions. These two capabilities have different goals: the DQL / PromQL Assistant delivers readable and reusable query statements, while Explorer natural language search is used to filter data on the current page.

DQL / PromQL Assistant¶

The DQL / PromQL Assistant is used to generate, explain, repair, and review query statements, and can also rewrite convertible DQL into platform PromQL. When generating new DQL, Obsy Copilot checks the data sources and fields in the current workspace, confirms semantics and units with field definitions, and validates results through syntax checks and actual queries.

This capability does not return DQL by default just because the user asks to "view recent logs." It only enters the query-language workflow when the user explicitly asks to write, explain, repair, review, or convert DQL / PromQL.

It is suitable for handling the following query tasks:

• You are not familiar with DQL or PromQL syntax and need to generate a query based on a goal.
• An existing query fails, the result definition is unclear, or risks need to be reviewed.
• You want to understand the filtering, aggregation, grouping, and time window of an existing query.
• You need to convert metric DQL into platform PromQL.
• You want a query based on real fields in the current workspace rather than a generic example.

Writing or Checking Queries¶

Describe the query goal directly in Obsy Copilot and provide as much of the following information as possible:

• Data domain: metrics, logs, events, traces, RUM, or other data types;
• Data objects: known measurements, sources, services, or fields;
• Time range: for example, the last 30 minutes or the past 7 days;
• Statistical measure: total, rate, average, percentile, TopN, or grouping dimensions;
• Output type: DQL, platform PromQL, or standard Prometheus queries.

Example:

Please generate a DQL for the current workspace: count the number of error logs for each service in the last 30 minutes, and return the top 10 services in descending order of count.

If you need to repair or explain a query, paste the original statement directly and describe the expected result. When the data domain, time range, or statistical measure is ambiguous, Obsy Copilot will ask for additional information first rather than guessing the data source and fields.

Query Results and Validation¶

When generating new DQL, Obsy Copilot first confirms the query goal, data source, and fields, then performs a syntax check on the final statement, runs an actual query within the specified time range, and verifies the fields, grouping, and statistical measure of the results. When delivering, it briefly explains the data source, filter conditions, aggregation, and time range; if fields or the data source cannot be confirmed, it will state the limitation or ask you to choose.

Field definitions can help you understand aliases, units, and business meaning, but they do not prove that data is actually reported. Passing the syntax check also does not mean the results are correct or complete: cases such as a query returning no data, access failures, and truncated results need to be checked separately, and technical failures should not be treated as "no data."

When only explaining query or field meaning, it is not necessary to actually execute the query; repairing an existing expression can be limited to a syntax check and should not be treated as having verified business results. When generating PromQL, the platform-supported measurement:field metric convention is used by default. This workflow does not actually execute PromQL, so run it on the target query page to confirm the data results.

Explorer Natural Language Search¶

Explorer natural language search converts a user's description into query conditions that the current Explorer can recognize, and executes them on the page together with the existing query and time range. It is suitable for users who are not familiar with Explorer syntax but already know which objects, statuses, or value ranges they want to filter.

This capability currently applies to Explorers with natural language search enabled, including logs, traces, RUM, custom objects, Resource Catalog, events, Synthetic Monitoring, security, cloud billing, backup logs, Agent monitoring, and LLM.

Setting Filter Conditions¶

In Explorers that support this capability, describe the filter target in natural language. For example:

Find data whose service is checkout, with an abnormal status and a duration greater than 2 seconds, and only look at the last 3 hours.

You can express conditions such as equals, not equals, contains, wildcard, regex, numeric comparison, range, field existence, and combinations such as AND, OR, and NOT. The actual operations available depend on the current field type.

By default, Obsy Copilot retains the existing conditions in the query box and appends new conditions after them. If you want to replace the existing conditions, explicitly use expressions such as "requery," "clear the original conditions," "only query," or "replace with."

Condition Conversion Rules¶

Obsy Copilot generates query conditions based on the field list provided by the current Explorer:

• Content that clearly corresponds to the current fields or field aliases is converted into structured filter conditions;
• Keywords whose fields cannot be confirmed are retained as plain text searches and are not forcibly mapped to similar fields;
• Business values such as service names, resource names, IDs, URLs, paths, and error text are preserved as much as possible;
• Time expressions explicitly provided by the user are handed to the Explorer time widget for processing.

The generated results are used to filter the current Explorer and do not create DQL or modify data. If a field does not appear in the fields available on the current page, it will not be used as a structured condition even if other Explorers have a field with the same name.