dodjdnh opened a new issue, #1590: URL: https://github.com/apache/dubbo-admin/issues/1590
## 背景与问题 Dubbo Admin 已提供 Application、Service 和 Instance Metric 页面。dubbo-go 也已导出基础的 provider 和 consumer RPC 指标，但共享 Dashboard 中的一些假设，使这些页面无法可靠地同时适用于 Java 和 Go 应用。 尤其是，Admin 会将选中的实例转换为推测的 `IP:QoSPort`，但 Prometheus 抓取目标并不等同于应用实例自身的身份。仅作为 consumer 的 RPC 服务也可能无法出现在服务和方法下拉框中。这些问题应通过适配 Admin 查询与现有指标身份来解决，而不是另建一套 Dashboard 或新增 SDK 指标。 ## 当前状态 以下描述的是本功能实现前的 upstream 基线： | 范围 | 当前行为 | | --- | --- | | Application / Service / Instance Metric 页面 | 已存在，本功能并非从零引入这些页面 | | Admin Instance Metric 变量 | 使用 `IP:QoSPort`；未设置 QoS 端口时使用 `22222` | | Instance Dashboard 查询 | 按 Prometheus `instance` 过滤 RPC 序列，将产品实例身份与抓取地址绑定 | | Java / Go 指标身份 | 已检查的 Java RPC 序列可能没有原生 `ip`，Go RPC 序列可能携带 `ip`；两者都需要合适的实例查询路径 | | 服务和方法变量发现 | 仅使用 provider 请求序列，可能遗漏 consumer-only 接口和方法 | | Processing 查询 | 使用的名称缺少实际导出指标的 `_total` 后缀 | | Application Histogram 查询 | 将查询限制在示例方法 `getItem` | | Go exporter 接入 | 需要应用配置和匹配的 Prometheus 抓取目标；仓库附带的 QoS ServiceMonitor 不会自动发现 Go exporter | ## 预期行为 - 使用现有 Admin Metric 页面和共享 Grafana Dashboard 查看 Java 和 Go 已有的 RPC 指标。 - 从 provider 或 consumer 请求指标发现接口和方法，覆盖 consumer-only 应用。 - 按应用名和实例原生裸 IP 选择实例，不假定 QoS 或 exporter 端口。选中实例 A 必须排除实例 B，反之亦然。 - 同时支持携带原生 IP 标签的 RPC 序列，以及需要通过应用元数据关联 IP 的序列。 - 查询应用实际导出的 processing 指标名。如果应用导出了现有 provider histogram 指标族，其应用级查询不应被限制在某个测试样例方法。 - 说明如何启用和抓取 Go exporter，并区分数据缺失、可选指标族缺失与“整个运行时不受支持”。 ## 范围 ### 包含 - 在共享 Metric Dashboard 中兼容 Java / Go 已有 RPC 指标的 Admin 侧改动。 - Provider / consumer 服务和方法变量发现。 - 使用裸 IP 的 Instance Metric 参数及对应 Dashboard 查询行为。 - 修正 processing 指标名和应用 Histogram 中硬编码的方法过滤条件。 - 后端测试、Dashboard / 配置检查，以及抓取、兼容性和验收文档。 - 将真实 Java / Go 查询检查和 Admin Metric 页面人工验证作为验收证据。 ### 不包含 - 修改 dubbo-java 或 dubbo-go SDK、exporter 实现或指标生产逻辑。 - 新增 Go RPC Histogram、错误分类，或统一跨语言耗时单位和错误语义。 - 保证 Go 具有全部 Java 指标族，例如 JVM 或 Java 线程池指标。 - 新增能力状态面板或重新设计现有 Dashboard 布局。 - 自动部署 Go 应用、配置服务发现或 Prometheus 抓取。 - 日志可观测性、Trace → Log、Trace → Metric、Collector 转换或 Jaeger 数据源修改。 ## 验收标准 以下验收项均为 PASS；运行时验证、浏览器验收及 Java 回归由提交者人工验收通过，未使用浏览器自动化。 - [x] 可以通过现有 Admin Application 和 Service Metric 页面查看应用导出的 provider 和/或 consumer 请求指标；consumer-only 应用的接口和方法可被选择。 - [x] 无论是否显式设置 QoS 端口，Instance Metric URL 均携带 `var-application=<application>` 和 `var-instance=<bare IP>`，不根据 Admin 实例推测抓取端口。 - [x] 同一应用具有两个实例时，直接 IP 查询路径仅返回所选实例的 RPC 序列；同时验证选 A 排除 B、选 B 排除 A。 - [x] 对于没有 `ip` 的 RPC 序列，application-info 元数据路径能将所选 IP 关联到正确的抓取目标，并保持相同的双实例隔离。 - [x] 如果两条查询路径选中同一条序列，不重复计数。 - [x] Application、Instance 和 Service 的 processing 面板使用实际导出的 provider / consumer `_processing_total` 指标名。 - [x] 存在 provider histogram bucket 时，Application Histogram 查询覆盖所选应用的方法，而非仅限 `getItem`；这不要求 Go 新增 Histogram 指标族。 - [x] Go 配置和抓取文档明确说明 Metrics 总开关、exporter 端点，以及 ServiceMonitor 的选择器和端口要求。 - [x] 相关 Go 测试及 Dashboard / YAML 检查通过。运行时与人工浏览器检查分别报告，并验证现有 Java Metric 页面没有退化。 - [x] 可以基于 upstream 独立评审和测试本工作，不依赖未合并的 Instance Trace、Log 或 Trace → Metric 改动。 ## 背景与设计说明 实例身份契约是所选应用加上其原生裸 IP。Prometheus `instance` 仍作为内部抓取和关联标签，而不是 Admin 面向用户的实例身份。 实现可使用两条查询路径：直接匹配 `ip`；或者通过 `dubbo_application_info_total`，按 `(application_name, instance)` 进行元数据关联。使用哪条路径取决于实际导出的标签，而不是后端中的 Java / Go 条件分支。PromQL `or` 合并两条路径时，不会重复返回标签集合完全相同的序列。 之前记录的运行时检查使用 Java 3.2.16、Go 3.3.2 和 Grafana 12.1.0。这些历史记录不自动替代当前分支验收，也不能证明所有 SDK 版本。当前独立分支的运行时验证、Go 服务发现 → Admin → Grafana 浏览器验收及 Java 回归已由提交者另行人工验收通过。 本工作解决 OSPP dubbo-go Metric 目标中的 Admin 兼容部分。增强 Go SDK 指标能力和配置生产采集链路仍属于独立工作。 Related to #1524。本 Issue 仅跟踪 Admin 侧 Java / Go Metric 展示兼容，不关闭完整的 OSPP 可观测性总议题。 -- 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]
