最适合的监控方式是什么样的呢？那就是成本最低，监控范围最大，效率最快。而是否持久就不再是考虑的重点了，因为项目结束了，监控工具可能也被拆了。
在企业中，我们也是首先考虑快速的监控实现。但是，还要一点要考虑，就是监控的持久有效性，能一直用下去。所以，在快速实现了之后，在必要时，会做一些二次开发，定制监控。
对了，这里再提一句，我不建议一开始就把代码级的监控给加进来。不光是因为它消耗资源，更重要的是，真的没有太大的必要。像方法的执行时间这类监控，如果没有定位到它们有问题，我们为什么要去看呢？当我们有了证据链的时候，是不是更一针见血呢？
所以最重要的是，我想看到的数据，到底能不能看得到。
对于上述的每个组件，我都建议用下面这样的监控思路。敲黑板！下图是重点！
有人可能会想说：就这几个字还值当画个图吗？我觉得非常有必要。因为全局到定向的思路帮我解决了很多的问题。
全局监控设计 OS 层（CentOS 为例）就拿 OS 来说吧，我们一般进到系统中，看的就是 CPU、I/O、内存、网络的使用率，这是很常规的计数器。在很多人看来，这些计数器是可以反应出一个系统的全局健康状态的。
先不管通过这些计数器得到的结论是不是对的。我们首先要知道的是，要有这样全局监控的潜意识，之所以说潜意识，是因为很多人不知道为什么看这些，但还是这样看了。那么实际上做一个 OS 的全局监控需要看多少个计数器呢？我们看下架构图。
因为新版内核没有给更细的内核架构图，所以我用 2.6.26 版本的 Linux 内核架构图来说明思路。
给这张图的目的就是建议先看架构图，再考虑要监控的大分类有多少。
从上图中，我们可以看到有这么几类，system、processing、memory、storage、networking 等。
这里画出一个思维导图，给出我的经验计数器。
针对 OS，我通常看上图中红色计数器的部分，这是 OS 查看的第一层。有第一层就有第二层，所以才需要定向的监控。后面我们再说定向监控的思路。
DB 层（MySQL 为例）我们再说 DB层，以 MySQL 为例。和上面的理念一样，我们也要看架构图。
此图来自于 MySQL 官方，各大技术网站均有展示。
接着我们看下全局监控的分类，如下图所示：
同样，这也是 MySQL 全局监控的第一层。这个内容的整理并不具有什么技术性。稍微了解一下 Linux 和 MySQL 的架构，就可以整理出来。我们依此类推，按照这个思路，就可以把其他的组件都整理出第一层监控组件。有了全局监控，接着就是定向监控了。这是寻找证据链的关键一节。
定向监控有了 OS 层的全局监控计数器，我们首先要学会的，就是判断这些计数器说明了什么问题。我在第三模块中写监控分析工具，会详细说明这部分。这里呢，我先把定向监控细化地解释一下，把这个思路给你讲得明明白白，通通透透。