dodjdnh opened a new issue, #3723: URL: https://github.com/apache/dubbo-go/issues/3723
### Issue Body ## Background Dubbo Admin is advancing observability enhancements and aims to unify the viewing and correlation capabilities for Metrics, Traces, and Logs on the application, instance, and service pages. The first phase needs to support querying aggregated Metrics around the time when a Dubbo RPC Span occurred. Related context: - [apache/dubbo-admin#1524 — Observability optimization in Admin](https://github.com/apache/dubbo-admin/issues/1524) - [apache/dubbo-go#3562 — Dubbo Go unified observability planning](https://github.com/apache/dubbo-go/issues/3562) - [apache/dubbo-go#3551 — standardize trace span names and semantic attributes](https://github.com/apache/dubbo-go/pull/3551) To allow Dubbo Admin to consume observability data from Dubbo Java and Dubbo Go using unified rules, Dubbo Go Trace and Metric data need to use consistent field semantics for the same RPC interface. ## Current Problem Dubbo Go RPC Metrics currently use `url.Service()` to generate the `interface` Label: ```go constant.TagInterface: url.Service() ``` However, Server and Client RPC Spans currently use `url.ServiceKey()` to generate `rpc.service`: ```go semconv.RPCService(invoker.GetURL().ServiceKey()) ``` When a service is configured with group/version, the two may produce: ```text Metric interface = org.apache.dubbo.samples.OrderService Trace rpc.service = gray/org.apache.dubbo.samples.OrderService:1.0.0 ``` This prevents Dubbo Admin from directly using the following relationship for Trace → Metric mapping: ```text Trace rpc.service == Metric interface ``` ## Expected Behavior `rpc.service` should represent the pure fully qualified interface name and remain consistent with the RPC Metric `interface` Label: ```text rpc.service = org.apache.dubbo.samples.OrderService interface = org.apache.dubbo.samples.OrderService ``` Even when group/version is configured, `rpc.service` should not become a composite service key. ## Proposed Solution In the Server and Client Trace Filters, change: ```go semconv.RPCService(invoker.GetURL().ServiceKey()) ``` to: ```go semconv.RPCService(invoker.GetURL().Service()) ``` Directly reusing `url.Service()` provides the same value source as the Metric and preserves the existing interface parameter and URL Path fallback behavior. The public `URL.ServiceKey()` should not be modified because service registration, routing, and unique service identification still require the composite service key containing group/version. ## Acceptance Criteria - [ ] The Server / Provider Span uses the pure fully qualified interface name for `rpc.service`. - [ ] The Client / Consumer Span uses the pure fully qualified interface name for `rpc.service`. - [ ] When group/version is configured, `rpc.service` does not contain group/version. - [ ] Trace `rpc.service` and Metric `interface` use the same semantics. - [ ] `rpc.system=apache_dubbo`, `rpc.method`, and SpanKind behavior remain unchanged. - [ ] Add regression tests that can record and assert the attributes of ended Spans. ## Non-goals This Issue only tracks the minimum field alignment currently required by Dubbo Admin and does not require the following work to be completed in the same change: - Span name standardization; - Adding separate `dubbo.group`, `dubbo.version`, or other Span attributes; - Metric → Trace / Exemplar; - Log correlation; - Dubbo Admin or Grafana page changes. ## Relationship to Existing Issues / PRs - `apache/dubbo-go#3562` is the broader observability plan. This Issue is an independent and verifiable implementation item for Dubbo Admin Trace → Metric support within that plan. - `apache/dubbo-go#3551` covers broader Span name and semantic attribute standardization. This Issue only extracts the `rpc.service` field correction currently required by Admin and does not depend on the remaining changes. - `apache/dubbo-admin#1524` is the upper-layer use case for this field mapping. This Issue does not introduce Admin- or Grafana-specific logic into Dubbo Go; it only provides a stable cross-signal field contract. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
