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

现在我们的技术栈已经有了，那就来看下对应的树状结构吧。
第一，识别架构中所有的技术组件。

在这里，我们要尽量识别出全部的技术组件。当然，如果有遗漏，在后续的工作中你还可以接着
补充，只是要耽误些项目时间了。
第二，细化技术组件的模块。
这一步如果在专栏正文中全部展示给你的话，肯定会占用大量的篇幅，而且这个动作是重复的，没有必要一一细化，我只是想告诉你这个逻辑。
这里我拿操作系统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模块上去，就得到了一个更加详细的性能分析决策树。

为了方便查看，我把操作系统细化出的性能分析决策树单独拿了出来。

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

把Processing模块去掉了。因为我觉得在第一层的全局监控计数器中，是不需要细化到进程/线程这个粒度的；另外，在CPU上也可以反映出来Processing模块出现的性能问题，所以它不会被遗漏掉。
增加了swap模块。虽然swap在性能项目中通常都是关着的，但为了不忘记它的存在，也要标记出来。
画了关联线。我将需要关联分析的计数器建立起了联系，方便梳理思路。

看到这里，你就能彻底理解性能分析决策树是什么了。对表中所有的技术组件进行模块、计数器的细化，就可以得到这个项目中全部的性能计数器。这个过程怎么进行要看你的技术功底，如果一个人做不到，也可以组织团队一起来做。
那有了性能分析决策树，下一步怎么办呢？它当然不只是用来看的，我们要把这些计数器都监控起来。
全链路压测全局监控全局监控就是把性能分析决策树中的所有计数器都监控起来。
还是拿操作系统来说，你可以再看一下上面的细化视图。这么多的计数器，有没有必要全都监控呢？这个要根据情况综合考虑。在上面的视图中，我把我觉得必须要监控到的计数器标成了红色，这些都是根据我的经验标注的，如果你不认可，那就标识出你认为重要的。针对这些重要的计数器，我们到监控工具中去看一下是不是都覆盖全面了。