关于后端:全栈监控如何设计全栈监控策略

你好，我是高楼。这节课，咱们来看看怎么设计全链路压测的全局监控。

对于全链路压测来说，因为波及到的服务比拟多，所以剖析逻辑难度加大，对监控的要求当然也更加简单。

如果咱们总是在性能瓶颈呈现之后再去做剖析，很可能会发现短少各种数据。这时能做的就只有从新运行一遍场景，再减少监控工具，实现更多的数据采集，以补充剖析逻辑中须要的数据。

然而这样的事件必定是越少产生越好，所以在全链路压测场景执行之前，咱们就要把监控策略思考分明。

怎么样来布局监控策略呢？跟着 RESAR 性能工程理念，咱们从零碎架构、性能剖析决策树、全局监控几个方面来有节奏、有档次地思考一下。

零碎架构

对于性能剖析来说，咱们要剖析的是整个零碎架构中，压测场景中波及到的每一个技术组件，这些技术组件只有从架构的视角能力看得分明。

从服务视角，咱们能够晓得须要监控的服务有哪些，保障服务的笼罩；从资源视角，能够让咱们晓得资源使用率应该达到多少才是正当的，同时资源视角也和容量模型无关，是重要的容量模型输出。

服务视角：

资源视角：

看到这样的零碎架构，咱们可不能只晓得外面有几个框，还要分明四点。

1. 服务列表和调用关系。

这一点在零碎架构的文档中应该有形容。举例来说，在咱们这个零碎中，当咱们发动一个登录申请时，对应下面的架构就是：gateway – member – auth – mysql(redis)。理解了调用关系之后，等你要剖析登录业务的性能时，就能够一层层剥离问题了。

2. 服务的规模。

服务中都有一个正本数量，看到这个正本数量之后，对应零碎的最大容量，就要有概念了。一个副本能反对的最大容量是多少呢？这须要通过压测得悉，而整个零碎能反对多大的容量，就要依据正本做相应的扩大模型来计算了。

零碎的容量依据每个业务零碎的不同有很大的差异，像对一些共用服务（比如说 ID 服务），因为业务逻辑非常简单，所以单正本的容量就会高。而一些业务服务（比如说电商的订单服务、银行中的转帐服务），因为业务逻辑简单，单正本的容量就会低一些。做压测的人对这些内容都要有当时的理解和大略的计算，以便判断它和最终的容量是否差距较大。

3. 硬件投入。

晓得了服务的规模，当然也要晓得硬件的规模。因为在 K8s+Docker 这样的服务编排逻辑中，咱们当时并不知道每个服务会被调用到哪个硬件资源上，所以无奈间接依据某个硬件资源来做相应的计算。然而在零碎架构的布局中，应该明确给出每个服务应该配置多少的资源，如果你是容器化的服务，间接限度就好了。限度资源是为了让整个零碎更加稳固，不要产生互相的影响。

4. 技术栈。

晓得了下面的构造之后，就要剖析出整个架构所应用的技术组件有哪些，一一列出。如果有足够的信息撑持，也能够晓得每个组件是如何应用的。比如说分库分表、读写拆散、单元化部署等等和压测无关的关键技术。

然而如何应用这些技术呢？先看看我从架构上推导进去的内容。因为下面是宏观的形容，落地到具体的细节中，咱们须要晓得的是宏观的信息如何在具体的业务调用过程中应用的，所以咱们推导出如下内容。

• 业务调用链
  我画了一个登录调用链你来直观感受一下。

像这样的调用链，画进去当然清晰，然而所有的业务调用链都画一下，这图也没法看了，所以咱们能够列出来一个这样的表格。

把握这些调用链，前面的性能剖析才不会在拆分工夫时感到凌乱。

• 容量所需的资源
  咱们还能大略计算一下容量所需的资源。比方，依据我的教训，登录服务在一个 6C12G 的容器（这里指的是登录链路上的所有服务都有这样的硬件配置）中，700TPS 是稳稳的能够撑得住的，要是极其一点，上 1000TPS 也不是不可能，但对应的响应工夫也会减少。这个时候会须要多少硬件资源呢，下面说了，登录业务波及 member 和 auth 两个服务、一个 MySQL、一个 Redis。如果咱们是想撑持 2000TPS 的登录业务，那就是近 3 倍的资源需要（先这样线性计算，理论我的项目中还是要进行横向扩大测试，同时咱们还须要思考冗余，即水位系数），那么总共须要的资源是多少呢？这里我拿 CPU 来计算一下，其余资源相似。

• 技术栈
  有了下面的架构之后，咱们能够列出这样的技术栈来。
• 微服务框架：Spring Cloud、Spring Cloud Alibaba
• 容器 +MVC 框架：Spring Boot
• 认证和受权框架：Spring Security OAuth2
• ORM 框架：MyBatis
• 数据层代码生成：MyBatisGenerator
• MyBatis 物理分页插件：PageHelper
• 文档生产工具：Knife4j
• 搜索引擎：Elasticsearch
• 音讯队列：RabbitMQ
• 分布式缓存：Redis
• NoSQL 数据库：MongoDB
• 利用容器引擎：Docker
• 数据库连接池：Druid
• 对象存储：OSS、MinIO
• JWT 登录反对：JWT
• 日志收集、解决、转发：LogStash
• 日志队列和缓冲：Kafka
• 日志采集：Filebeat
• 可视化剖析与展现：Kibana
• 简化对象封装工具：Lombok
• 全局事务管理框架：Seata
• 利用容器治理平台：Kubernetes
• 服务爱护：Sentinel
• 分布式链路追踪零碎：Zipkin
• 根底资源监控：Prometheus
• 容器级链路监控：Weave Scope
• 可视化看板：Grafana

其实，从架构中失去的信息还远不止下面的三种。请留神，我这里说的架构材料并不限于下面的图，还有架构设计相干的其余各种材料。从这些材料中，咱们能够得出企业 IT 布局、架构设计思路、技术实现逻辑、运维技术的逻辑等等。

你可能会说，这些有什么用呢？这就是做性能要从工程的视角来解释的起因了。只有咱们把性能工程笼罩到零碎生命全周期中，压测这个动作才有真正的意义，能力贯通一个零碎从原始需要到线上运维的全流程。

当初，咱们曾经拿到了技术栈，接下来就要对应这个技术栈来确定咱们的性能剖析决策树了。

全链路压测性能剖析决策树

性能剖析决策树是什么？在第三讲里我讲过，针对我的项目中用到的技术栈，你通过剖析对应的技术组件以及组件对应的模块，失去全量计数器，而后把这个过程通过树状构造展现进去，并画出相应的关联关系，这就是性能剖析决策树了。

当初咱们的技术栈曾经有了，那就来看下对应的树状构造吧。

第一，辨认架构中所有的技术组件。

在这里，咱们要尽量辨认出全副的技术组件。当然，如果有脱漏，在后续的工作中你还能够接着补充，只是要耽搁些我的项目工夫了。

第二，细化技术组件的模块。

这一步如果在专栏注释中全副展现给你的话，必定会占用大量的篇幅，而且这个动作是反复的，没有必要一一细化，我只是想通知你这个逻辑。

这里我拿操作系统 CentOS 来举个例子。因为做性能剖析的时候，你没法绕过操作系统，所以拿操作系统来举例，会更有代入感。细化技术组件对应的模块时，咱们必须要晓得的是这个组件的架构，咱们来看一下操作系统的架构图。

这是一个简化的 Linux 内核图，足够咱们来判断有哪些内容了。

先看最下面一列大模块：System、Network、Storage、Memory、Processing。其实看到这一层就曾经够了，咱们至多能够判断进去有五个模块了。再看竖列，它示意的是每一模块在应用过程中的纵向关系，始终延长到硬件的元器件。

有人可能会有纳闷了，为啥没有 CPU 呢？这是因为，只有零碎用起来，就必然会应用 CPU。所以 CPU 这个视角必定不能脱漏。然而 CPU 是一个综合资源，不在咱们当初的探讨模块范畴里。其实你要去监控过程的时候，就肯定能够看到 CPU 相干的计数器了。

还有一点要阐明的是，这个模块是不是能够变动呢？当然是能够的，只有不脱漏，你怎么变动都是能够的，前面你还会看到我做的一个变动。

第三，细化模块对应的计数器。

有了模块，当然要有计数器来获取性能数据了。如何确定每个模块有哪些计数器呢？咱们拿 CPU 这个模块来举例，其余模块你能够用同样的思路本人去细化。

咱们晓得在 CentOS 中，看 CPU 的时候，通常会用 top、vmstat 之类的命令。在 top 中能够看到 9 个 CPU 计数器，别离是：us/sy/ni/id/hi/si/wa/st/load average，vmstat 中的计数器比 top 中少，所以咱们就不必再看了。

那是不是在 CentOS 中只有这 9 个计数器呢，其实也不止，命令 mpstat 中就有两个计数器 %guest 和 %gnice。把这些计数器都列到 CPU 模块下来，就失去了一个更加具体的性能剖析决策树。

为了不便查看，我把操作系统细化出的性能剖析决策树独自拿了进去。

我在这个图里做了几个调整：

1. 把 Processing 模块去掉了。因为我感觉在第一层的全局监控计数器中，是不须要细化到过程 / 线程这个粒度的；另外，在 CPU 上也能够反映进去 Processing 模块呈现的性能问题，所以它不会被遗漏掉。
2. 减少了 swap 模块。尽管 swap 在性能我的项目中通常都是关着的，但为了不遗记它的存在，也要标记进去。
3. 画了关联线。我将须要关联剖析的计数器建设起了分割，不便梳理思路。

看到这里，你就能彻底了解性能剖析决策树是什么了。对表中所有的技术组件进行模块、计数器的细化，就能够失去这个我的项目中全副的性能计数器。这个过程怎么进行要看你的技术功底，如果一个人做不到，也能够组织团队一起来做。

那有了性能剖析决策树，下一步怎么办呢？它当然不只是用来看的，咱们要把这些计数器都监控起来。

全链路压测全局监控

全局监控就是把性能剖析决策树中的所有计数器都监控起来。

还是拿操作系统来说，你能够再看一下下面的细化视图。这么多的计数器，有没有必要全都监控呢？这个要依据状况综合思考。在下面的视图中，我把我感觉必须要监控到的计数器标成了红色，这些都是依据我的教训标注的，如果你不认可，那就标识出你认为重要的。针对这些重要的计数器，咱们到监控工具中去看一下是不是都笼罩全面了。

咱们能够拿当初最罕用的 node_exporter+Prometheus+Grafana 套件来看一下。

首先说 CPU，后面咱们列了 11 个计数器，这外面当初有的是 us、sy、load average，这几个明明确确是一对一笼罩的。其余的，我在这个界面中都没看到。

这时，应该会有人想反驳我：“那不是有总使用率吗？这个值是从 1 -%idle 计算来的，不就笼罩了所有的 CPU 计数器了吗？”

这种问题我倡议你不要这么大而化之。咱们做性能剖析，是要看到“每一个”计数器的，而不是总使用率，这个值没有方法给出根据，领导咱们下一步怎么做。

如果在你的我的项目中，呈现了这种总使用率的计数器，但除此之外就没有其余的计数器了。那可能有些问题体现不到这个总使用率的计数器上来。即使能体现进去，你的下一步动作也只能是去看每一个 CPU 计数器，而不可能间接晓得性能剖析的明确方向。

对于整个我的项目级的性能剖析决策树，你能够本人去一一对一下监控工具，看短少哪些性能剖析决策树中的计数器，少的都要加上。当把整个我的项目的性能剖析决策树，都笼罩到监控工具中之后，全局监控才算是实现了。

如果切实无奈在短时间内加上这些计数器，那你就要在剖析的时候记得用其余的工具命令来补充。

对这样量级的监控，通常会有人提出疑难：监控这么多数据，对性能没有影响吗？请记住，咱们的逻辑是，要笼罩全性能剖析决策树，但不是一股脑地把所有不重要的计数器都加上。这是不理智的。如果你发现监控工具对性能有很大的影响了，能够升高采样率，但这个危险是数据采集不精确，所以还是要评估好。比方在做性能剖析时，把采集粒度调小一点；不剖析时，把粒度调大一点。

全链路压测的监控逻辑

有了下面的监控思路，咱们就能够对任何一个性能我的项目进行全方位的监控策略设计了。

那全链路压测中又有啥特地的呢？它的特别之处在于，革新的内容产生了新的组件。其实从计划中就可以看进去，咱们要做的革新是哪几个模块。

咱们必须把这些革新产生的新组件（影子库等）都监控起来。也就是说，本来我监控一个 MySQL 数据库就好了，当初分库了，就要监控两个库才能够。

举个例子，像 Zipkin 中，之前的链路中只有一个 MySQL，当初就多进去一个 shadow 的 MySQL。

在全局监控时，咱们要把这些革新产生的组件全副笼罩。

同时，最好可能联合链路追踪零碎，做到辨认失常流量与压测流量。这样不便疾速剖析问题。

最初，为了应答线上的危险，咱们还要着重及时关注异常情况，比方外围业务指标异样、根底资源 Metric 水位过高、异样谬误集中等状况。

联合压测计划章节中的全局监控视图。

](https://static001.geekbang.or…)

你能够看到的是，在技术栈的每个组件都有对应的监控工具。

当然，如果你所在的企业能够投入老本，能够思考集成这些开源的监控工具，造成本人的监控平台，这也是当初很多企业在做的。市面上也有集成了这些开源监控工具的商业平台，总之，监控的内容都相差不大。

总结

这节课的内容就讲完了。

在这一讲，我给你形容了从零碎架构细化到性能剖析决策树，再细化到全局监控的全过程。这个过程在任何一个性能我的项目中都是能够复用的。

而全链路压测须要分外留神的，首先就是要全，其次要准。不过也不要感觉做全链路压测就是扭转了之前的技术逻辑，监控工具和思路齐全不能用了。其实，相比通常压测我的项目的监控策略，全链路压测的次要的区别都是因为革新产生了新组件和压测流量所引起的。这些组件只是原有技术组件的叠加，在监控时思考进去就行了。对于压测流量最好能做到自动识别进去。

只有有了全局监控，才可能在呈现性能问题时，晓得如何进行定向监控剖析。在前面，我会对案例进行更详尽地剖析，让你看到剖析过程的逻辑。

思考题

最初，我想请你思考两个问题：

1. 性能剖析决策树要求什么技术背景？如何能力做到不脱漏计数器？
2. 全局监控对性能瓶颈剖析起到什么样的作用？

欢送你在评论区和我分享你的思考成绩，也能够把这节课分享给你的敌人一起交换、探讨，咱们下节课再见！