Actuator设计文档
一、产品设计
1.1. 需求
- 健康检查
通过Actuator接口可以统一获取到Layotto内部所有组件以及业务应用的健康状态
- 查看运行时元数据
通过Actuator接口可以统一获取到Layotto自己的元数据信息(例如版本,git信息),以及业务应用的元数据信息(例如通过配置中心订阅的配置项列表,例如应用版本信息)
- 支持集成进开源基础设施,包括:
- 可以集成进k8s健康检查
- 可以集成进监控系统,比如Prometheus+Grafana
- 如有需要,注册中心可以基于健康检查结果剔除节点
- 后续可以基于此接口做dashboard项目或者GUI工具,以便排查问题。
- 类似于Spring Boot Actuator的功能,未来有更多的想象空间:Monitoring, Metrics, Auditing, and more.
1.2. 解释
Q: 价值是啥?健康检查接口开出来给谁用?
-
供开发排查问题,直接调接口查询运行时信息,或者做个dashboard页面/GUI工具
-
供监控系统做监控;
-
供基础设施做自动化运维,比如部署系统基于健康检查来判断部署进度,停止或继续分批部署;比如注册中心基于健康检查剔除异常节点;比如k8s基于健康检查kill容器、重新创建容器
Q: 好像返回个状态码就行,没必要返回运行时信息?查出来的运行时详细信息给谁用?
- 后续可以基于此接口做dashboard页面或者GUI工具,以便排查问题;
类似于spring boot社区基于spring boot actuator写了个spring boot admin网页 参考https://segmentfault.com/a/1190000017816452
- 集成监控系统:可以接入Prometheus+Grafana
类似于Spring Boot Actuator接入Prometheus+Grafana 参考Spring-Boot-Metrics监控之Prometheus-Grafana
Q: 做不做管控能力,比如“开关 Layotto 内部特定组件的流量”
A: 不做,开关部分组件会让app处于partial failure状态,有不确定性。 但是后续可以考虑添加debug能力,比如mock、抓包改包等
Q: 健康检查的接口做不做权限管控
A: 先不搞,有反馈需求再加个钩子
二、概要设计
2.1. 总体方案
先开放http接口,因为开源基础设施的健康检查功能基本上都支持http(比如k8s,prometheus),没有支持grpc的。
为了能够复用MOSN的鉴权filter等filter能力,Actuator将作为7层的filter跑在MOSN上。
具体来说,MOSN新增listener,新写个stream_filter,这个filter负责http请求处理、调用Actuator.
Actuator内部抽象出Endpoint概念,新请求到达服务器后,Actuator会委托对应的Endpoint进行处理。Endpoint支持按需扩展、注入进Actuator:
2.2. Http API设计
2.2.1. 路径解释
路径采用restful风格,不同的Endpoint注册进Actuator后,路径是
/actuator/{endpoint_name}/{params}
比如
/actuator/health/liveness
其中health标识Endpoint的名称是health,liveness是传给该Endpoint的参数。
参数支持传多个,形如 /a/b/c/d,具体传几个、参数的语义由每个Endpoint自己定
默认注册的路径有:
/actuator/health/liveness
/actuator/health/readiness
/actuator/info