[FEATURE] Add Jaeger trace plugin

[aviralgarg05]

Description

This pull request adds a new Jaeger plugin to the plugins repository so Perses can query and display traces coming from Jaeger.

The implementation covers both main Jaeger trace workflows:

• fetching a trace directly from a Jaeger trace ID
• searching traces through Jaeger query parameters such as service, operation, span kind, tags, duration filters, and limit

The plugin then converts Jaeger responses into the trace data format expected by Perses trace visualizations, so the result can be used in trace-related panels without requiring any special handling elsewhere.

A few points worth calling out for review:

• trace IDs are validated before requests are sent
• Jaeger trace data is mapped into OTLP-style spans, including parent-child relationships, events/logs, links, span kind, and status information
• plugin schemas, SDK helpers, datasource configuration, query editor support, and tests are included as part of the same change
• only the files required for the Jaeger plugin and workspace registration were touched

This change is intended to address the Jaeger support requested in the linked issue and follow-up discussion.

Closes perses/perses#3409
Context: perses/perses#3993

Screenshots

UI changes are limited to the new datasource and trace query editors for the Jaeger plugin.
No screenshots are attached here.

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.

[jgbernalp]

cc @andreasgerstmayr

[sunng87]

hello @aviralgarg05 , quick question: which version of jaeger API are we using for this plugin? I heard the most adopt jaeger API is actually their internal http API. Grafana is also using that API. And they have a public gRPC API but it's still a WIP for switching Grafana data source to that.

Background: I'm from http://github.com/GreptimeTeam/ and our database has compatibility for jaeger's http API. So if this patch is using that one, we won't need to create our own trace data source.

[aviralgarg05]

hello @aviralgarg05 , quick question: which version of jaeger API are we using for this plugin? I heard the most adopt jaeger API is actually their internal http API. Grafana is also using that API. And they have a public gRPC API but it's still a WIP for switching Grafana data source to that.

Background: I'm from http://github.com/GreptimeTeam/ and our database has compatibility for jaeger's http API. So if this patch is using that one, we won't need to create our own trace data source.

Hi, this plugin is using Jaeger’s HTTP API, not the gRPC API.

Right now it talks to the same HTTP endpoints Jaeger exposes for its UI / datasource integrations, mainly:

• GET /api/traces/{traceId}
• GET /api/traces
• GET /api/services
• GET /api/operations

So if your compatibility layer implements Jaeger’s HTTP API for those endpoints and response shapes, this plugin should work with it without needing a separate datasource.

I have not added any dependency on Jaeger’s public gRPC API in this PR.

[sunng87]

@aviralgarg05 Perfect! All these endpoints are supported by GreptimeDB. Thank you for clarification.

[jgbernalp]

@aviralgarg05 there is a small issue with the cue formatting. The rest LGTM