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

我们可以拿现在最常用的node_exporter+Prometheus+Grafana套件来看一下。

首先说CPU ，前面我们列了11个计数器，这里面现在有的是us、sy、load average ，这几个明明确确是一对一覆盖的。其他的，我在这个界面中都没看到。
这时，应该会有人想反驳我：“那不是有总使用率吗？这个值是从1-%idle计算来的，不就覆盖了所有的CPU计数器了吗？”
这种问题我建议你不要这么大而化之。我们做性能分析，是要看到“每一个”计数器的，而不是总使用率，这个值没有办法给出依据，指导我们下一步怎么做。
如果在你的项目中，出现了这种总使用率的计数器，但除此之外就没有其他的计数器了。那可能有些问题体现不到这个总使用率的计数器上来。即便能体现出来，你的下一步动作也只能是去看每一个CPU计数器，而不可能直接知道性能分析的明确方向。
对于整个项目级的性能分析决策树，你可以自己去一一对一下监控工具，看缺少哪些性能分析决策树中的计数器，少的都要加上。当把整个项目的性能分析决策树，都覆盖到监控工具中之后，全局监控才算是完成了。
如果实在无法在短时间内加上这些计数器，那你就要在分析的时候记得用其他的工具命令来补充。
对这样量级的监控，通常会有人提出疑问：监控这么多数据，对性能没有影响吗？请记住，我们的逻辑是，要覆盖全性能分析决策树，但不是一股脑地把所有不重要的计数器都加上。这是不理智的。如果你发现监控工具对性能有很大的影响了，可以降低采样率，但这个风险是数据采集不准确，所以还是要评估好。比如在做性能分析时，把采集粒度调小一点；不分析时，把粒度调大一点。
全链路压测的监控逻辑有了上面的监控思路，我们就可以对任何一个性能项目进行全方位的监控策略设计了。
那全链路压测中又有啥特别的呢？它的特别之处在于，改造的内容产生了新的组件。其实从方案中就可以看出来，我们要做的改造是哪几个模块。

我们必须把这些改造产生的新组件（影子库等）都监控起来。也就是说，原本我监控一个MySQL数据库就好了，现在分库了，就要监控两个库才可以。
举个例子，像Zipkin中，之前的链路中只有一个MySQL ，现在就多出来一个shadow的MySQL 。

在全局监控时，我们要把这些改造产生的组件全部覆盖。
同时，最好能够结合链路追踪系统，做到识别正常流量与压测流量。这样方便快速分析问题。
最后，为了应对线上的风险，我们还要着重及时关注异常情况，比如核心业务指标异常、基础资源 Metric 水位过高、异常错误集中等情况。
结合压测方案章节中的全局监控视图。
<img src=https://mparticle.uc.cn/"https://static001.geekbang.org/resource/image/80/e7/804bfd247d384ee37ba2185e44a545e7.jpg?wh=1920x809\" alt=\"!图片\" />
你可以看到的是，在技术栈的每个组件都有对应的监控工具。
当然，如果你所在的企业可以投入成本，可以考虑集成这些开源的监控工具，形成自己的监控平台，这也是现在很多企业在做的。市面上也有集成了这些开源监控工具的商业平台，总之，监控的内容都相差不大。
总结在这一篇，我给你描述了从系统架构细化到性能分析决策树，再细化到全局监控的全过程。这个过程在任何一个性能项目中都是可以复用的。
而全链路压测需要格外注意的，首先就是要全，其次要准。不过也不要觉得做全链路压测就是改变了之前的技术逻辑，监控工具和思路完全不能用了。其实，相比通常压测项目的监控策略，全链路压测的主要的区别都是由于改造产生了新组件和压测流量所引起的。这些组件只是原有技术组件的叠加，在监控时考虑进去就行了。对于压测流量最好能做到自动识别出来。