基于 Micrometer 封装的监控框架实践
此背景也源于近期一个项目功能需求而来，本文对此进行整理，对 MicroMeter 实现监控埋点进行说明和扩展。
Micrometer
Micrometer 是一个用于基于 JVM 应用程序的度量工具库。它为最流行的监控系统的检测客户端提供了一个简单的门面（facade，类似于 slf4j）。Micrometer 旨在为项目提供在尽可能小的开销基础上，同时提供最大限度地提高的指标工作的可移植性（主要得力于其门面模式的设计，类似的还有像 opentracing 这类，不过 opentracing 和 slf4j 或者 Micrometer 在设计模式上还存在着本质的差别）。本文不重点关注在 Micrometer 基础知识或者概念介绍上，更多信息可以通过其官方文档获取，详见：Micrometer。
背景
这里先抛出项目背景：我们希望提供一个 sdk 或者 starter，使用尽可能简单的 api 或者注解，就可以完成核心方法的埋点。Micrometer 自己其实已经提供了类似 @Timer 这种类似的注解，但是其本身缺失 tag 唯独统计，而基于 api 方式的使用，虽然支持了 tag 能力，但是对于业务代码的侵入性又非常高，因此基于原生注解和 api 尚且不满足当前项目需求，所以需要对其进行扩展。
针对项目自身特性，我们对扩展 Micrometer 大体诉求如下：
- 注解中支持 tag 能力
- 支持在方法执行过程中增加 tag 维度
这两个诉求看起来很简单，但是这里会有几个必须要面对的问题：
- 注解一般打在类或者方法上，支持 tag 很容易，但是 tag 中的值相对来说就比较固定，如果期望支持动态注入 tag 的 value，则需要支持将参数绑定到 value 上去
- 基于注解的方式基本等于绑定 aop，aop 怎么处理 this 应用问题
- 方法执行过程中增加 tag 一般是绑定 threadlocal 实现，怎么解决跨线程传递问题
下面就展开对 Micrometer 扩展的具体实践介绍。
Micrometer 监控框架扩展实践
针对上述问题，我们先一个个来解决。首先是注解中支持 tag 能力，这个并没有什么技术含量，做法就是抛弃 Micrometer 原生的注解，通过自定义注解来实现。如下：
/**
* @ClassName MeterMetrics
* @Description
*
* @MeterMetrics(name = "xx", type = MeterMetricsEnum.COUNT, tags = {@MeterTag(key = "key", value = "value"),...})
* public void test() {...}
*
* @Author glmapper
* @Date 2021/11/4 16:46
* @Version 1.0
*/
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MeterMetrics {
/**
* describe tags name
* @return
*/
String key() default "";
/**
* describe tags value
* @return
*/
String value() default "";
}
复制代码既然注解提供了，则我们需要处理它，下面是对这个注解的切面实现。
@Pointcut("@annotation(com.glmapper.bridge.boot.anno.MeterMetrics)")
public void meterMetricsCut() {
}
@Around("meterMetricsCut()")
public Object meterMetricsAround(ProceedingJoinPoint joinPoint) throws Throwable {
//... 解析注解上的 tag，然后上报
}
@AfterThrowing(value = "meterMetricsCut()", throwing = "ex")
public void meterMetricsThrowing(JoinPoint joinPoint, Throwable ex) throws Throwable {
//... 解析注解上的 tag，然后上报
}
复制代码至此对于初始模型是具备了，但是实际和使用还差的很远，下面是扩展细节。
支持 spel 表达式，实现 tag 值绑定参数
举个例子，期望将参数中的某个值作为 tag 的 value，如下：
@GetMapping("/resp")
@MeterMetrics(key = "app", value = "#testModel.getName()")
public String getResp(TestModel testModel){
return "SUCCESS";
}
复制代码这段代码中，#testModel.getName() 是一个 spel 表达式，其目的在于能够将自定义注解的 key-value 能够和方法参数绑定起来。这里对应的切面方法的核心处理大致如下：
private final SpelExpressionParser parser = new SpelExpressionParser();
private final DefaultParameterNameDiscoverer pmDiscoverer = new DefaultParameterNameDiscoverer();
/**
* 支持从参数中通过 spel 表达式提取对应的值
*/
public String getSpelContent(String spelKey, JoinPoint pjp) {
Expression expression = parser.parseExpression(spelKey);
EvaluationContext context = new StandardEvaluationContext();
MethodSignature methodSignature = (MethodSignature) pjp.getSignature();
Object[] args = pjp.getArgs();
String[] paramNames = pmDiscoverer.getParameterNames(methodSignature.getMethod());
for(int i = 0 ; i < args.length ; i++) {
context.setVariable(paramNames[i], args[i]);
}
// 注意这里可能会有 npe，具体实现是需要关注一下
return expression.getValue(context).toString();
}
复制代码这里需要有几个注意点，首先是上面的 TestModel 必须提供构造函数（spel 自身机制决定），其次是解析流程不应该对主业务流程产生任何影响，也就是当产生异常时，需要内部吃掉，不扩散。
那么到这里，我们解决了注解支持 tag 和 绑定参数两个能力。下面是实现方法内部增加 tag 的能力。
允许在方法中增加 tag 信息
埋点如果期望收集更丰富的维度信息，仅通过参数或者手动指定是不行的，这里举个简单的例子，你的参数是个 token 串，但是在检验这个 token 时，你期望知道这个 token 解析之后的一些信息，比如用户信息、权限信息等，所以这些仅能够在方法内部才能拿到的数据，当需要将其加入到 tag 中去时，也需要提供适当的渠道。
这里提供一个基于 ThreadLocal 实现透传的实现思路：
public class TokenMetricHolder {
// TAG_CACHE
private static ThreadLocal<MetricTag> TAG_CACHE = new ThreadLocal<>();
public static void metricToken(TokenModel tokenModel, String from) {
try {
MetricTag.MetricTagBuilder builder = MetricTag.builder();
// ... 为 builder 添加属性
MetricTag metricTag = builder.build();
TAG_CACHE.set(metricTag);
} catch (Exception ex) {
// do not block main process
LOGGER.error("error to fill metric tags.", ex);
}
}
// 注意 remove，避免内存泄漏风险
public static MetricTag getAndRemove() {
MetricTag metricTag = TAG_CACHE.get();
TENANT_CACHE.remove();
return metricTag;
}
@Data
@Builder
public static class MetricTag {
// 这里是需要收集的一些 tag 指标项，比如 userName
private String userName;
}
复制代码通过 TokenMetricHolder 内部维持的 TAG_CACHE，在一个请求上下文内，方法内部填充的 tag 信息，我们在 aop 中可以轻松获取，这样就可以丰富指标统计维度。
解决 this 引用问题
aop 中，当方法内部调用另一个方法时(a 方法中调用 b)， 对 b 的 aop 会失效，原因在于当前 b 的对象引用时 this，而并非是代理对象。
public void a(){
b();
}
public voidb(){//...}
复制代码网上对此的解释一抓一大把，这里我们仅给实践：
/**
* com.glmapper.bridge.boot.holder#ProxyHolder
* get current proxy object, if get null, return default value with specified
*
* @param t
* @return
*/
public static <T> T getCurrentProxy(T t) {
if (t == null) {
throw new IllegalArgumentException("t should be current object(this).");
}
try {
return (T) AopContext.currentProxy();
} catch (IllegalStateException ex) {
return t;
}
}
复制代码将上述直接调用 b 方法修改为 ProxyHolder.getCurrentProxy(this).b() 即可。
丰富 MeterMetrics，支持多组 tag
上面 MeterMetrics 仅有 key 和 value，略显单薄，下面我们继续扩展 MeterMetrics 的能力，可以允许其指定 name，指定指标类型，支持 tag 数据，如下：
public @interface MeterMetrics {
MeterMetricsEnum type() default MeterMetricsEnum.TIMER;
MeterTag[] tags() default {};
String name() default "";
}
public @interface MeterTag {
String key() default "";
String value() default "";
boolean spel() default false;
}
复制代码使用展示及总结
关于代码后续会托管到 github 上去，目前还缺少对于 starter 的封装。下面展示具体的使用效果
@MeterMetrics(name = "test",
tags = {@MeterTag(key = "appName", value = "#requestModel.getApp_name()"),
@MeterTag(key = "fixedKey", value = "fixedValue")},
type = MeterMetricsEnum.COUNTER)
public void test(@Validated RequestModel requestModel) {...}
复制代码本文对于基于 Micrometer 埋点扩展提供了一个可行的实现思路，并在实际的业务场景中进行了使用。在原生 api 基础上，通过扩展注解和 api，解决了一系列实际业务场景中可能需要面临的一些问题。
如果本篇文章对你有一点点帮助，请点个赞，感谢！
本文系转载，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
本文系转载，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。