feat(jaeger): add regex support for tag search in /api/traces

[emamihe]

Describe Your Changes

This PR adds regex support for tag values when searching traces via the Jaeger /select/jaeger/api/traces endpoint.

Behavior:

• Tag values prefixed with ~ are treated as regex patterns.
• Tag values without ~ keep exact-match behavior.

Examples:

• tags={"http.status_code":"~^2"} – matches 200, 201, 2xx, etc.
• tags={"order_id":"~abc.*"} – matches values starting with "abc"
• tags={"key":"value"} – exact match (unchanged)

Implementation:

• Regex filters are built as LogsQL field:re("regex") and executed by the VictoriaLogs storage engine.
• The ~ prefix is stripped before passing the value to the regex engine.

Files changed:

• app/vtselect/traces/query/query.go – logic for tag values with ~ prefix
• docs/victoriatraces/querying/README.md – documentation and examples for the ~ prefix

Checklist

The following checks are mandatory:

• My change adheres to VictoriaMetrics contributing guidelines.
• My change adheres to VictoriaMetrics development goals.

---

Summary by cubic

Adds regex support for tag filters in the Jaeger /select/jaeger/api/traces endpoint. Prefix a tag value with ~ to use regex; non-prefixed values remain exact matches.

• New Features
  • Regex values are translated to LogsQL field:re("...") and executed by VictoriaLogs.
  • Examples: tags={"http.status_code":"~^2"}, tags={"order_id":"~abc.*"}, tags={"key":"value"} (exact match).

^{Written for commit daa8672. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="docs/victoriatraces/querying/README.md">

<violation number="1" location="docs/victoriatraces/querying/README.md:219">
P3: The docs now show two different formats for the `tags` query param (space-separated `key=value` vs JSON map). The backend only accepts JSON (`json.Unmarshal` on `tags`), so leaving the space‑separated instructions while adding JSON regex examples is misleading and can result in invalid requests. Please make the `tags` format consistent in the examples/description.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P3: The docs now show two different formats for the tags query param (space-separated key=value vs JSON map). The backend only accepts JSON (json.Unmarshal on tags), so leaving the space‑separated instructions while adding JSON regex examples is misleading and can result in invalid requests. Please make the tags format consistent in the examples/description.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At docs/victoriatraces/querying/README.md, line 219:

<comment>The docs now show two different formats for the `tags` query param (space-separated `key=value` vs JSON map). The backend only accepts JSON (`json.Unmarshal` on `tags`), so leaving the space‑separated instructions while adding JSON regex examples is misleading and can result in invalid requests. Please make the `tags` format consistent in the examples/description.</comment>

<file context>
@@ -216,3 +216,4 @@ Some valid filter examples:
 - Multiple span attribute filters: `error=unset otel.scope.name=redis-manual`
 - Single resource attribute filter: `resource_attr:telemetry.sdk.language=go`
 - Span attribute and resource attribute filters: `span.kind=client resource_attr:os.type=linux`
+- Regex filter: prefix the value with `~` to match by regex, e.g. `{"order_id":"~abc.*"}` or `{"http.status_code":"~^2"}` for values starting with "2"
</file context>

[jiekun]

Hi. It seems the original implementation in Jaeger - Elasticsearch equals to %q:~%q in LogsQL. It covers all the cases, which may make sense because I dont think user will check the LogsQL doc before using Jaeger API, and most likely they won't type a=~b in the tag filter input box.

I would expect the user input to be a=b.* or a=a.*b.*c and we should translate it into "a":~"a.*b.*c" directly.

However, by doing so, since the . means any character. It can lead to false matches. For example, the expression 192.168.0.1 may match 1920168001.

I'd like to ask for your opinion and also @manideep-qlub before further review.