Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
emamihe wants to merge 1 commit into
base: master
Choose a base branch
from
Open

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

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion app/vtselect/traces/query/query.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -229,7 +229,12 @@ func getTraceIDList(ctx context.Context, cp *tracecommon.CommonParams, param *Tr
}
if len(param.Attributes) > 0 {
for k, v := range param.Attributes {
qStr += fmt.Sprintf(`AND %q:=%q `, k, v)
Copy link
Member

@jiekun jiekun Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@manideep-qlub manideep-qlub Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jiekun - Thank you for the tag.

We'd prefer the ~ prefix approach (as implemented by @emamihe ) for few reasons like "explicit intent", "it avoids false matches", "its predictable" as well

if strings.HasPrefix(v, "~") {
// ~ prefix forces regex (e.g. tags={"key":"~value.*"})
qStr += fmt.Sprintf(`AND %q:re(%s) `, k, strconv.Quote(v[1:]))
} else {
qStr += fmt.Sprintf(`AND %q:=%q `, k, v)
}
}
}
if param.DurationMin > 0 {
Expand Down
3 changes: 2 additions & 1 deletion docs/victoriatraces/querying/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,7 @@ The `/select/jaeger/api/traces` HTTP endpoint provides the following params:

Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot Mar 5, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Fix with Cubic

- `service`: the service name.
- `operation`: the span name (also known as the operation name in Jaeger).
- `tags`: the attributes (also known as tags) filter, example: `{"key":"value"}`
- `tags`: the attributes (also known as tags) filter, example: `{"key":"value"}`. Prefix a value with `~` to use regex matching, e.g. `{"key":"~value.*"}`
- `start`: the start timestamp in unix microseconds.
- `end`: the end timestamp in unix microseconds.
- `minDuration`: the minimum duration of the span, with units `ns`, `us`, `ms`, `s`, `m`, or `h`.
Expand Down Expand Up @@ -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"