基于 Micrometer 封装的监控框架实践

2021-11-05 14:50:15 浏览数 (1)

此背景也源于近期一个项目功能需求而来,本文对此进行整理,对 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 原生的注解,通过自定义注解来实现。如下:

代码语言:javascript复制
/**
 * @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 "";
}
复制代码

既然注解提供了,则我们需要处理它,下面是对这个注解的切面实现。

代码语言:javascript复制
@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,如下:

代码语言:javascript复制
@GetMapping("/resp")
@MeterMetrics(key = "app", value = "#testModel.getName()")
public String getResp(TestModel testModel){
    return "SUCCESS";
}
复制代码

这段代码中,#testModel.getName() 是一个 spel 表达式,其目的在于能够将自定义注解的 key-value 能够和方法参数绑定起来。这里对应的切面方法的核心处理大致如下:

代码语言:javascript复制
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 实现透传的实现思路:

代码语言:javascript复制
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,而并非是代理对象。

代码语言:javascript复制
public void a(){
    b();
}
public voidb(){//...}
复制代码

网上对此的解释一抓一大把,这里我们仅给实践:

代码语言:javascript复制
/**
 * 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 数据,如下:

代码语言:javascript复制
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 的封装。下面展示具体的使用效果

代码语言:javascript复制
@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,解决了一系列实际业务场景中可能需要面临的一些问题。

如果本篇文章对你有一点点帮助,请点个赞,感谢!

0 人点赞