Repository navigation
Conversation
…ata bridge Use the native IP instead of a guessed QoS scrape port. Keep backend and dashboard parameter contracts together with instance documentation. Resolve Metric instances directly through the existing resource manager API, without relying on the instance Trace helper. Add a self-contained Metric test file for bare-IP variables, URLs, and lookup errors. In the combined branch, keep legacy Trace tests focused only on Trace behavior; the standalone Metric PR does not require those Trace tests or helpers.
Query provider and consumer requests_processing_total in the Application, Instance and Service dashboards to match the exported metric names.
…ogram Remove the sample getItem method restriction so the application histogram query covers the selected application rather than one fixture method. Retain the original adjacent line endings to preserve the aggregate diff.
…ance Describe shared identities, optional metric capabilities, Go exporter enablement and Prometheus scraping requirements. Combine compatibility and acceptance guidance while keeping the essential instance identity contract in the instance feature commit. Distinguish runtime query checks from unclaimed discovery and browser end-to-end acceptance.
robocanic
left a comment
robocanic
left a comment
There was a problem hiding this comment.
整体 LGTM，感谢贡献。CI 已全部通过，几点小意见供参考：
- Instance dashboard 过滤不完整：
grafana-dashboardDefinitions.yaml中 Instance metrics 面板里的dubbo_provider_requests_failed_network_total和dubbo_provider_requests_failed_codec_total（约 5932、5945 行，带or vector(0)）只按application_name过滤，没有应用 ip 选择模式，因此展示的是整个应用的数据而不是所选实例。这是历史遗留问题，但 PR 描述称已处理所有 Instance 查询，建议一并修复或在说明中注明。 - 同一 IP 多个实例：元数据路径按
ip关联抓取目标instance，同一主机上端口不同的多个 Java 实例会同时匹配，选中一个 IP 时可能混入其他实例的序列。可以接受，建议在文档中补充一句说明。 - 文档：
docs/observability-metric-compatibility.md中出现的 “D009” 是内部跟踪编号，上游读者无法理解，建议删除。 - 验证方式：PromQL 仅做了结构性检查，没有自动化测试，主要依赖手动运行验证，请确保 Java 与 Go 两条路径都有实际截图或结果记录。
- 发布顺序：
var-instance参数约定已从IP:port变为纯 IP，后端与 Grafana dashboard 需要一起部署，建议在 release notes 中说明。
|
好的
好的 |
Preserve the upstream Instance Trace resource helper while keeping Metric dashboard variables on bare IPs. Adapt the upstream Metric/Trace regression test to the shared bare-IP contract.
Apply native-IP and application-info metadata selection to provider network and codec failure summaries, retaining the zero fallback. Add a regression check that parses provisioned dashboards and inspects all Instance query expressions, including queries that omit the instance variable entirely.
Document same-application shared-IP limits and the coordinated backend/dashboard rollout. Remove the internal tracking identifier and distinguish recorded Java/Go query observations from the new structural regression check and runtime acceptance evidence still needed for the error summaries.
|
e2e验证结果 1.java metadata联表关联查询 |
|
dubbo-go sdk目前无法正确有效分类codec，network错误，我创建apache/dubbo-go#3774 这个issue用于解决这个问题，不影响admin侧的查询逻辑 |
|
cool work |
|
E2E测试 |
|
3.go原生ip查询 |
|
5.java确认实例隔离 |
AlexStocks
left a comment
AlexStocks
left a comment
There was a problem hiding this comment.
结论：可以合入，但这是有意的 Breaking 变更，需要发布说明
变更实质
GetInstanceDashboardVariables 与 GetInstanceTraceDashboardVariables 的 var-instance 从 IP:QoSPort（QoS 端口缺省时用 22222）改为裸 IP，以匹配 Prometheus 的 ip 标签。同时修正了多处指标名拼写（dubbo_*_tota → dubbo_*_total、requests_processing → requests_processing_total），这部分是净收益。
已核对
- Instance Metric 仪表盘的
instance变量查询已改为label_values(dubbo_application_info_total{application_name="$application"}, ip)，与新后端返回值一致。 - 文档中提到的另一条路径（RPC 序列缺
ip时，用dubbo_application_info_total按(application_name, instance)关联）在查询里以A or (B and on(application_name,instance) C)的形式实现，语义正确：or保证两条路径命中同一序列时不重复。 Instance traces仪表盘的instance是custom类型、query为空，且整块 dashboard 的查询没有引用$instance，因此改成裸 IP 不会影响 Jaeger 查询。- 其余 12 处
"name": "instance"属于导入的 Kubernetes / node-exporter 仪表盘，仍然是label_values(up{...}, instance)，本次未被误改，正确。
P3 · 混合版本部署没有运行时保护
docs/observability-metric-compatibility.md 已明确写出「旧后端 + 新仪表盘」或「新后端 + 旧仪表盘」会得到空结果。但代码里没有任何版本标记或降级提示，用户只能看到空面板。考虑到这是 Grafana 侧配置，后端能做的有限；建议至少在发布说明里把它列为升级步骤（先更新 Admin，再 reload provisioned dashboards），并说明 var-instance 是用户可见的 URL 契约变化。
P3 · var-instance 的语义变化影响自定义看板
任何保存了 var-instance=10.42.1.10:22222 的外部链接都会失效。文档已提示，建议同时在 CHANGELOG / release note 中体现，而不仅放在新增的文档里。
明白 |
|
Summary
Adapt Dubbo Admin's existing shared Metric dashboards to consume available dubbo-go RPC metrics while retaining a query path for Java RPC series that do not carry a native IP label. Changes include consumer metrics in service and method discovery, bare-IP instance selection, corrected processing metric names, and removal of the fixture-specific application histogram filter.
This is Admin-side metric compatibility work, not a new SDK exporter, metric collection pipeline, or Trace → Metric feature.
Motivation
The existing Instance Metric flow constructs a guessed
IP:QoSPortand uses it to filter Prometheus scrape instances. This does not reliably identify an application instance when the exporter uses a different port or when Java and Go series expose different labels. Provider-only variable discovery also omits consumer-only RPC interfaces and methods.The shared dashboards should use the selected application's actual metric identities and available labels, rather than assume one SDK or exporter endpoint.
Changes
1. Discover services and methods from both RPC sides
Use provider or consumer request series for the Service dashboard's interface and method variables, updating both variable definitions and query objects:
This makes consumer-only interfaces and methods selectable; it does not invent provider data for a consumer-only application.
2. Isolate Instance Metric by native IP
ip, select the requested IP directly.ip, associate the selected application/IP with its scrape target throughdubbo_application_info_total, then match RPC series on(application_name, instance).ipvalues in its instance variable.Representative request metric query selector:
Prometheus
instanceis an internal association key, not the product instance identity. If both paths select an identical series,orretains it once. The metadata path requires application-info and RPC series to share consistent application and scrape labels.3. Correct existing dashboard queries
dubbo_provider_requests_processing_totalanddubbo_consumer_requests_processing_totalin the Application, Instance, and Service dashboards. These series represent in-flight requests/concurrency; the name suffix does not turn them into request-rate queries.method="getItem"from the Application's existing provider histogram query so it is not restricted to a sample method.4. Add focused tests and deployment guidance
0and22222, existing query-parameter preservation, missing configuration, missing instances, and lookup failures.9090/metrics.Verification
Unit tests, static checks, and locally reproducible upstream CI checks on the current independent commit series are all PASS. Runtime verification, the complete Go browser journey, and Java regression checks were manually completed and passed by the submitter; no browser automation was used. Local checks do not replace the GitHub Actions results after PR submission.
go test ./pkg/console/service ./pkg/console/handler -count=1at each of the five independent commit checkpoints.licenserc.yamlyarn buildgo fmt ./...make testGOOS=linux GOARCH=riscv64 CGO_ENABLED=0 go build ./...$instancecontain the direct-IP / metadata selection pattern; instance variable usesipgit diff --check b9ee1b7 HEADEarlier runtime checks recorded in
docs/observability-metric-compatibility.mdused Java 3.2.16, Go 3.3.2, Grafana 12.1.0, and Prometheus data. They observed a metadata path for two Java instances and direct-IP queries for Go provider/consumer data. These historical records do not automatically replace acceptance for the current independent branch; the runtime and browser PASS results in the table come from the submitter's separately confirmed manual acceptance.No Codecov upload or release workflow was run locally; the coverage file was generated and retained. Frontend build and RISC-V cross-compilation were performed in a disposable Windows copy, and full unit tests were performed in WSL Ubuntu, all against the same HEAD
cdcb6c6without modifying product source.Reproducible backend checks:
Review Focus
ip, especially with multiple instances and consistent relabeling. Review the complete metric label sets rather than assumeIP:QoSPort.Compatibility / Impact
IP:QoSPortto bare IP. Deploy the backend and shared Instance dashboard together; custom dashboards that assume this parameter is a scrape address must adapt to the parameter contract.Affected areas, retaining the category names from the repository PR template:
Installation impact here is limited to deploying the updated dashboard and documenting scrape prerequisites; no automatic collection infrastructure is added.
Scope
Included
Not Included
Related Issue
Fixes #1590
Related to #1524. This PR closes only the dedicated Metric compatibility issue, not the overall OSPP issue or the separate Instance Trace, Log, or Trace → Metric issues.