Dubbo 可观测性方案与目标设计
- [x] I have searched the issues of this repository and believe that this is not a duplicate.
Describe the proposal
简介
Dubbo可观测性包括许多附加功能,帮助您在将应用程序推向生产时监视和管理应用程序。您可以选择使用HTTP端点或JMX来管理和监视应用程序。审计、运行状况和度量收集也可以自动应用于应用程序。
参考SpringBoot3的可观测性
https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.enabling
如何开启Dubbo的可观测性?主要通过引入如下依赖:
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo-spring-boot-actuator</artifactId>
<version>${dubbo.version}</version>
</dependency>
Dubbo可观测性主要管理如下几大纬度分别是:
- 指标埋点
- 链路追踪
- 日志打印
- 健康检查
- 文档案例
指标Metrics
说明
关于指标的设计文档参考:
https://qnac8r4ct8.feishu.cn/docx/doxcncmY1gYiRGX9ccX264W6JJd
指标埋点主要从三大中心,消费者,提供者几个纬度细化。通过引入micrometer进行指标埋点,让系统更透明。用户可以根据实际用户需求进行扩展将指标数据进行转换为需要的格式并输送给第三方系统。
指标埋点任务事项
| 事项 | 说明 | 重要程度 | 产出 | 任务链接 | 状态 |
|---|---|---|---|---|---|
| Grafana Dashboard | Grafana dashboard制作并上传至Grafana官网供用户直接导入 | 重要 | 面板配置 |
点击进入 | 进行中 |
| 线程池监控埋点 | 可监测线程池队列大小,任务被拒绝数量 | 重要 | 指标与面板配置 |
点击进入 | 代码编写中 |
| 消费者请求埋点数据完善调研 | 梳理现有指标与缺失指标项 | 重要 | 文档 | 点击进入 | 完善中 |
| 提供者响应数据埋点完善调研 | 梳理现有指标与缺失指标项 | 重要 | 文档 | 点击进入 | 开发中 |
| 注册中心相关指标数据完善调研 | 梳理现有指标与缺失指标项 | 重要 | 文档 | 点击进入 | |
| 配置中心相关指标数据完善调研 | 梳理现有指标与缺失指标项 | 重要 | 文档 | 点击进入 | |
| 元数据中心相关指标数据完善调研 | 梳理现有指标与缺失指标项 | 重要 | 文档 | 点击进入 | |
| 异常情况的监控埋点 | 对于dubbo调用中出现的比较重要的异常进行埋点,方便监控异常场景的出现可以细化和粗粒度多个角度 | 重要 | 实现+文档+dashboard | 点击进入 | |
| 其他指标项梳理 | 其他需要明确的指标项 | 重要 | 文档 | 点击进入 | |
| 监控平台数据导出 | 完善当前指标数据导出到其他流行的监控平台(非普罗米修斯) | 一般 | 先调研文档 | 点击进入 | |
| 使用案例 | 完善Demo与接入教程 | 重要 | 文档+sample案例 | 点击进入 | |
| 补全micrometer jvm监控信息 | JVM监控中增加应用信息label和完善dashboard内容 | 一般 | 代码和dashboard | 点击进入 | 完成 |
| 监控指标统一为dubbo前缀 | 为所有的埋点指标加上前缀dubbo | 重要 | 代码 | 点击进入 | 完成 |
| 为Dubbo低版本提供埋点依赖 | 额外开发一个兼容的依赖包来为dubbo低版本进行监控埋点 | 重要 | 代码 | 点击进入 | |
| 响应时间直方图 | 对于平均耗时过于不均衡的场景进行分桶统计 | 重要 | 代码 | 点击进入 | |
| 优化拉取延迟 | Dubbo中指标数据经过了线程池定期的转换产生了较大的延迟 | 重要 | 代码 | 点击进入 | |
| Dubbo的版本号埋点 | Dubbo版本埋点并展示在dashboard中 | 重要 | 代码 | 点击进入 |
链路追踪
说明
链路追踪主要用于管理一个请求链路环节的关键节点,通过引入opentracing或者micrometer tracing 门面默认,基于是无链路信息的用户可以灵活配置链路埋点输送到日志,或者第三方链路追踪系统。
| 事项 | 说明 | 重要程度 | 产出 | 任务链接 | 状态 |
|---|---|---|---|---|---|
| 调研门面框架 | opentracing与micrometer进行技术选型 | 重要 | 文档 |
点击进入 | 已完成 |
| 提供者trace数据埋点 | 接收外部来的请求时候获取与产生埋点 | 重要 | 文档+代码 | 点击进入 | |
| 消费者trace数据埋点 | 请求下游时候的请求埋点 | 重要 | 文档+代码 | 点击进入 | |
| 跨线程时候的trace传递 | 请求中存在的跨线程代码的请求埋点 | 重要 | 文档+代码 | 点击进入 | |
| 内置链路追踪页面 | 无第三方链路框架时候可以自行查询的简单页面 | 一般 | 文档+代码 | 点击进入 | |
| 使用案例 | 完善Demo与接入教程 | 重要 | 文档+sample案例 | 点击进入 | |
| 验证micrometer与skywalking | 需验证下micrometer通过otel bridge,怎么和skywalking集成 | 重要 | 点击进入 |
日志打印
这里包含了Dubbo日志打个方式与常见日志解析,方便用户排查问题,无需研究源码进行分析
| 事项 | 说明 | 重要程度 | 产出 | 任务链接 |
|---|---|---|---|---|
| 日志配置文档 | 文档完善即可,包含如何优雅的日志打印比如分层打印框架日志,性能日志等 | 一般 | 文档 | 点击进入 |
| 日志兼容trace | 这个看trace那边怎么做trace那边将数据埋点到MDC中日志中增加配置即可 | 一般 | 文档 | 点击进入 |
| 常见日志解析 | 针对典型日志要做出案例分析 | 一般 | 文档 | 点击进入 |
健康检查
这里涉及到存活健康检查地址URL和可读健康检查URL方便业务系统在物理机中和容器中进行优雅地上下线。
| 事项 | 说明 | 重要程度 | 产出 | 任务链接 |
|---|---|---|---|---|
| 健康检查配置文档 | 目前已经实现了梳理好文档 | 重要 | 文档 | 点击进入 |
| 健康检查兼容SpringBoot的健康检查与可读检查 | 兼容SpringBoot | 重要 | 文档+代码 | 点击进入 |
文档案例 任务链接:点击进入
这里需要梳理出一个完整的可观测性文档,具体内容可以参考SpringBoot3的可观测性,如链接:
https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.enabling
- 可观测性说明文档:产出背景与架构文档
- 入门使用文档: 产出入门接入文档
- 入门示例与解析文档: 产出例子
- 原理解析: 产出原理文档
- 可观测性实战: 故障排查案例分析 收集常见Dubbo异常 产出故障分析分类与文档
其他需求
- 配置简化: 支持dubbo外置配置文件配置和配置中心配置,用户可灵活开关。 点击进入
补充:当然这些想法只是片面的,如果你有更好的想法赶紧贡献吧,感谢。
是不是可以加上protocol,比如trace的protocol是啥,metrics的protocl是啥。
一方面是企业需要把这个能力纳入到自己系统中的时候,可以用protocol来清楚的知道能不能收这个数据。 另一方面,dubbogo、dubbo rust后面接入的时候,肯定也是面向protocol,而不是micrometer这样的library。
OpenTelemetry ?
OpenTelemetry ?
我觉得ot可以作为tracing的protocol,但metrics、log我们仍然需要调研下标准协议。
OpenTelemetry ?
我觉得ot可以作为tracing的protocol,但metrics、log我们仍然需要调研下标准协议。
可以再调研下micrometer tracing springboot3中已经支持 micrometer tracing也支持接入OpenTelemetry 再看看前景
线程池监控埋点
Agree with @robberphex's suggestion, and we need to support protocol extensions in addition to providing a default protocol implementation. The need for observability for some users and enterprises with customization needs to access Dubbo needs to be taken into account at the beginning of the design.
- The Dubbo main repository will identify default protocols, such as OpenTelemetry
- The SDK that Dubbo will use to implement these protocols will need to be determined and selected
- Dubbo will support extensions to the protocols and will complete the implementation of these extensions in dubbo-spi-extensions and provide them to users for selection