带你读《Apache Tomcat的云原生演进》——Web容器可观测最佳实践（1）https://developer.aliyun.com/article/1377524
接下来介绍一下Trace和Metrics的基本原理。
首先看一下Trace的原理，这里列了一个场景。一个HTTP请求进来，在最上面会过一个Tomcat的方法，StandarHostValve.invoke。进来之后会调一次数据库，在里面sleep了一秒，然后再往外发了一个http请求。
那么这个调用链路，我们怎么通过Trace技术用柱状图的形式，反映它的耗时情况呢？
我们会通过埋点的技术来实现，这种埋点技术可能是用户手动埋点，也有可能通过Java的agent技术字节码增强，也就是在用户运行时动态地插入一些代码。我们会在每个方法执行的前后打上点，然后把整个方法执行的上下文记录下来，包括方法的执行耗时等等，这样就形成了上图右侧的粉色柱状图了。
此外，在sleep一秒的位置，还有一个绿色的柱状图。这个方法调用由于没有埋点，所以在整个Trace里是看不到的，相当于是一个监控的盲点。所以我们也无法知道它耗时在哪里，后面会详细介绍通过Profiling技术来解决这个问题，帮助我们定位调用慢、调用出错等问题。
接下来介绍一下Metrics的基本原理，Metrics目前的标准是基于Prometheus提出的单指标、多维度的指标模型，以及它提出的一些指标类型，比如Counter、Gauge、Histogram、Summary。还有它提出的关键概念包括时间点、时间线，PromQL等等。
我们在传统的web容器里做耗时埋点的时候，有一个很关键的点是，我们要把埋点的地方尽可能的提前，来保证用户的业务代码都能获取上下文。因为在一些开源的探针，比如我们现在Skywalking和OpenTelemetry的探针里，还有一些商业化的产品里，他们对Tomcat的埋点可能会去复用Tomcat的filter的技术。它会在Tomcat的filter链里加一个filter进去，在filter里面做一些耗时的统计。
但阿里云的商业化产品就会把这个埋点提前到StandarHostValve.invoke的地方，来保证在每一个用户的filter里都能有Trace的上下文，然后把Trace的上下关联到日志和指标里。
此外，在新型的web服务端技术里，这里主要指的是构建在Reactor-netty上，像SpringCloud Gateway、Flex这样的技术里面，埋点的复杂点在于，因为它是一个纯异步的框架，你很难在一个方法里准确的统计它的调用耗时。所以针对这种纯异步的框架，我们把创建一个span和关闭一个span的操作进行异步化了，来保证我们统计到的指标是准确的。
带你读《Apache Tomcat的云原生演进》——Web容器可观测最佳实践（3）https://developer.aliyun.com/article/1377521
