小米科技|全栈监控：如何设计全栈监控策略？汽车

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

你好，我是高楼。这一篇，我们来看看怎样设计全链路压测的全局监控。
对于全链路压测来说，因为涉及到的服务比较多，所以分析逻辑难度加大，对监控的要求当然也更加复杂。
如果我们总是在性能瓶颈出现之后再去做分析，很可能会发现缺少各种数据。这时能做的就只有重新运行一遍场景，再增加监控工具，实现更多的数据采集，以补充分析逻辑中需要的数据。
但是这样的事情肯定是越少发生越好，所以在全链路压测场景执行之前，我们就要把监控策略考虑清楚。
怎么样来规划监控策略呢？跟着RESAR性能工程理念，我们从系统架构、性能分析决策树、全局监控几个方面来有节奏、有层次地思考一下。
系统架构对于性能分析来说，我们要分析的是整个系统架构中，压测场景中涉及到的每一个技术组件，这些技术组件只有从架构的视角才能看得清楚。
从服务视角，我们可以知道需要监控的服务有哪些，保证服务的覆盖；从资源视角，可以让我们知道资源使用率应该达到多少才是合理的，同时资源视角也和容量模型有关，是重要的容量模型输入。
服务视角：

资源视角：
【小米科技|全栈监控：如何设计全栈监控策略？】
看到这样的系统架构，我们可不能只知道里面有几个框，还要清楚四点。

服务列表和调用关系。

这一点在系统架构的文档中应该有描述。举例来说，在我们这个系统中，当我们发起一个登录请求时，对应上面的架构就是：gateway - member - auth - mysql(redis) 。了解了调用关系之后，等你要分析登录业务的性能时，就可以一层层剥离问题了。

服务的规模。

服务中都有一个副本数量，看到这个副本数量之后，对应系统的最大容量，就要有概念了。一个副本能支持的最大容量是多少呢？这需要通过压测得知，而整个系统能支持多大的容量，就要根据副本做相应的扩展模型来计算了。
系统的容量根据每个业务系统的不同有很大的差别，像对一些共用服务（比如说ID服务），由于业务逻辑非常简单，所以单副本的容量就会高。而一些业务服务（比如说电商的订单服务、银行中的转帐服务），由于业务逻辑复杂，单副本的容量就会低一些。做压测的人对这些内容都要有事先的了解和大概的计算，以便判断它和最终的容量是否差距较大。

硬件投入。

知道了服务的规模，当然也要知道硬件的规模。由于在K8s+Docker这样的服务编排逻辑中，我们事先并不知道每个服务会被调用到哪个硬件资源上，所以无法直接根据某个硬件资源来做相应的计算。但是在系统架构的规划中，应该明确给出每个服务应该配置多少的资源，如果你是容器化的服务，直接限制就好了。限制资源是为了让整个系统更加稳定，不要产生相互的影响。