带你读《Apache Tomcat的云原生演进》——Web容器可观测最佳实践（2）https://developer.aliyun.com/article/1377522
Metrics的最佳实践是一定要在端侧预聚合指标。我们的指标来源于span的，对应的就是埋点统计方法的耗时。这样一个span的字段有很多，比如span name接口名、耗时以及产生的时间。我们按照15秒聚合一次，把这段时间内所有调用聚合出来，就可以得到上图的一条数据，这就是端侧预聚合的概念。
那么为什么要做端侧预聚合呢？有两个原因，一个是我们的指标在预聚合之后它的量很少，另外一个是预聚合之后它的数据一定是准确的。同样在一些开源产品里，它是没有指标预聚合的，它统计出来的指标都是基于采样后的span，所以它的数据是不准确的。
在我们做了预聚合之后，我们会在端侧采集一些指标，上图右侧列了一些我们会去采集的指标以及给这些指标加的维度。这些指标和维度话基本都是通过在阿里内部服务电商业务以及服务公共云上的用户总结下来。通过这些指标能够定位线上大多数的问题。比如请求数、请求大小、响应大小、耗时、活跃请求数、线程池的指标。关键维度我们会去记录接口名、上游接口名以及状态码。
在做端测指标预聚合的时候，也会有一些比较困难的点。
做指标的应该都会知道维度发散的问题，在端侧我们要做维度收敛。大家可以看一下上图左侧，它的spanname是一个相对来说比较发散的情况。它聚合之后从7条数据变成了4条数据，聚合效果就没那么好了。如果它是更发散的情况，它的聚合效果就会更差，且会导致数据的上报量也会很大，端服务端存储成本也比较高，所以一定要做维度收敛。
在Spring MVC场景下，Spring MVC会放到request attribute里面的一个base matching pattern attribute这样的key里面，这个key一定会映射到后端用户的controller上面。
另外，在SpringCloud Gateway的场景下，它没有base matching pattern attribute的key，所以我们会把它的收敛后置到转发请求的后面业务服务上去做收敛。业务服务会把收敛的结果通过response heater返回给SpringCloud Gateway。然后SpringCloud Gateway再把返回来的结果前面加一个固定的前缀，比如API，来保证在任意场景下，都可以把发散的url收敛成一个固定的url。
在统计精准指标上，就像请求数这样的指标，因为它是counter一直递增的。我们采集指标可能是15秒采集一次，如果现在要拿一分钟的精确指标，就相当于它强依赖于定时任务调度的15秒的精确度。但精确度很难保证，所以我们在做指标的时候，会去考虑按时间分桶。在预聚合指标的时候就把一个指标聚合在那个上报周期了，以此保证统计一分钟请求数量的时候，不会出现偏差。
在准确统计分位数上，很难有一个方案把内存占用、二次聚合、精确性这三方面都照顾的很好。经过我们的调研，DDSketch 算法可以在这三方面有一个比较好的权衡。可以得到一个比较精确的结果，内存占用也是可预期的，结果也可以进行二次聚合。
带你读《Apache Tomcat的云原生演进》——Web容器可观测最佳实践（4）https://developer.aliyun.com/article/1377520
