提高监控效率，打造完善的全局和定向监控策略！

随着性能测试行业的发展，许多人仍在谈论性能测试的理论和思维，以及性能测试工具的使用和实现。虽然性能监控部分也有数据描述，但大多数只停留在数据列表中，描述CPU 90%、内存不足、IO 100M等现象。

为什么是CPU？ 90%？具体原因如何定位？解决方案是什么？大多数性能工程师不知道，甚至不知道。

面试被问及“生产数据库CPU突然飙升，如何定位问题的原因”。由于固定的批量执行计划，小组讨论；查看监控数据，查看缓慢的SQL等，猜测。最后，面试官直接给出了答案：因为Redis被击穿，数据库压力很大，所以CPU很高。当时，有些人认为这与主题描述现象没有直接的逻辑关系。

可以看出，性能监控数据不足的问题是没有分析的证据链。真正的性能分析是从现象到结论有一个完整的分析链接，否则就是猜测。

许多企业的监控似乎是全面的，但没有详细的监控水平，没有详细的监控，导致经常需要分析数据，只能重新操作场景来捕获数据，但也临时添加监控工具。

如何设计全局定向监控策略，希望大家能理解从全局到定向的思路，提前设计好监控策略。

设计监控策略的第一步是分析架构，确定哪些需要监控。

1 分析架构

列出系统中的机器：

绘制系统架构：

需要监控的组件应从上述信息中列出，即以下表格。现在只配置了一个上述各层的例子，但这并不意味着我们只需要一个。

在后续的测试过程中，当需要增加实例时再增加。

2 监控选型

所选第一层监控工具，即全局监控工具。目前还不确定定向监控所需的工具，因为定向监控工具取决于性能分析过程中的问题。

在通过全球监控计数器发现问题后，如果您想定位问题的具体原因，您必须分析更详细的监控数据。然而，全球监控计数器无法做到这一点，因此我们应该选择合适的定向监控工具，以获得更详细的监控数据，即定向监控。

全球监控与定向监控的区别：全球监控是第一层监控，它可以反映技术组件各模块的关键性能，如OSCPU是典型的全球监控计数器。

3 全球监控策略和工具选型

全局监控是判断整个系统瓶颈点的方向，但不能给出具体原因。因此，应注意全局监控工具：

1. 数据准确性：性能计数器的数据准确性直接决定下一步
2. 低成本：包括成本和劳动力成本。成本很容易计算。劳动力成本，直接计算员工的工资和时间。对于临时项目，最好选择流行和通用的监控工具
3. 范围大：监控工具应足以覆盖全局监控计数器。监控工具应尽可能覆盖性能分析决策树中列出的计数器。如果工具的能力有限，没有时间扩展，请在选择工具后明确哪些计数器无法监控。然后，在性能分析过程中，使用命令来弥补工具的不足
4. 历史数据可以保存：在性能项目中，需要实时查看性能数据，监控的历史数据也很重要。因为历史数据将用于场景实施后的性能分析和性能报告

所选工具应根据系统结构进行监控：

• 第一层，物理主机
• 第二层，KVM虚拟机
• 第三层，Kubernetes套件
• 第四层，各应用所需的技术组件

对应的监控工具：

以上工具免费开源，完全满足监控需求，部署即可。RESAR性能分析逻辑中解释了OS监控工具的局限性。

在这个系统中，物理机和KVM都是完整的os，所以node_exporter可以完全覆盖。

但是上一层的k8s是如何全面监控的呢？涉及Kubernetes的监控套件。查看Kubernetes全局监控套件：

有很多类似的模板。虽然每个工具的显示方式不同，但都可以实现对Kubernetes的全球监控目标。只需选择适合您业务系统的Kubernetes监控套件。

k8s监控套件，监控什么，上面图中显示的K8 master 和 K8 workercpu等指标，想知道K8 微服务部署在master机器上吗？所有node资源。被测系统必须部署服务。如果不了解这个架构，建议自己部署一套k8s。httpsps基础知识点补基础知识点://mp.weixin.qq.com/s/L-jnlwyKFWGoKX6L5fz5A。

如何选择一个监控套件来满足各级的监控需求是整体监控的难点。整体监控应该是“分层的”。人们常说：“我们完全监控它。”但当我自己检查时，我只看到OS级数据，其他操作内容消失了。

在培训一家金融机构时，他们说网上有问题。让我帮忙分析一下。他们也有信心：“我们的监控数据非常完整，但我们不知道问题在哪里。”当我看到数据时，没有Java线程级数据，监控平台也不支持将其细化到线程级。从系统数据的角度来看，这恰好是线程的问题。因此，他们不得不重新收集数据。当数据再次被拿走时，问题一目了然。

这是缺乏全局监控数据导致分析链路断裂的典型例子。因此，全局监控的完整性是性能分析的重要组成部分。

全球监控是在启动压力测量时同时启动监控，对吧？还需要注意监控工具的性能消耗，对吧？是的，全球监控一直存在。监控工具的选择通常主要是生产和维护的监控工具。如果没有操作和维护工具，请考虑使用其他工具。对于监控的计数器级别，最好与操作和维护监控工具一致，过多确实会影响性能。

当全局监控发现问题时，是否需要通过定向监控再次运行场景以获取更详细的数据？是的。需要。

4 定向监控策略和工具选型

性能场景完成全局监控后即可运行。但是，当出现问题时，全局监控数据只能看到CPU高、内存不足、IO高等第一层计数器、网络带宽大等。CPU降低，内存使用少，IO低，无法从这些信息中知道优化。、网络变小。

此时，有必要进行有针对性的监控，以找到更详细的证据。在RESAR性能项目中，由于性能分析有逻辑链接，数据被分为全球和定向。如果没有区别，全面看，会让你觉得数据太多，不知道关键是什么。

性能影响

整体和方向必须分开。由于整体监控数据将被收集和保存一段时间，因此对系统的整体性能影响不大。但是，如果定向数据也被收集，则会影响系统的整体性能，如线程堆栈的数据收集、对象的内存消耗收集等。这些操作对性能有影响。无论工具制造商吹得多么完美，在实践中都有足够的数据来证明这一点。

然而，目前市场上的许多监控工具并没有区分全球监控和定向监控。因此，您还可以在上面列出的全球监控工具中看到定向监控所需的数据。例如，用JvisualVM监控Java不仅可以看到CPU、JVM、Class、Thread等全局信息，也有栈、方法、对象等定向信息。

用表格列出Java微服务应用程序的工具，可以看到细节数据。如方法级、对象级等，Spring Boot Admin、JvisualVM和其他JDK自带的监控工具都可以做到。如果在使用中感觉不足，也可以考虑其他定向监控工具。

还有Spring 在Cloud微服务的监控工具之后，在提供服务的过程中，我们需要看到的是业务链接。此时，上述监控单个微服务的工具无法实现。

所以这里使用APM工具SkyWalking进行链路监控。在SkyWalking中，不仅可以看到链路图，还可以看到更详细的数据。

属于全局监控的SkyWalking链路图：

下图是SkyWalking工具看到的更详细的数据，属于定向监控数据：

这张图显示了定向分析的中间环节。从图中可以看出，一个请求对应的每一段都很耗时，比如一个接口调用另一个接口，JDBC、Redis和其他后续组件。根据定向监控数据，找出哪一段耗时较长，然后向下分析耗时较长的组件。

到目前为止，我们知道定向监控需要哪些数据。在分析了系统架构后，还应准备定向监控工具的选择，以避免在出现问题时没有工具可用。

定向监控只是先准备好，不需要一开始就用。

可用于示例系统的定向分析工具主要包括系统级、代码级、数据库级和缓存级：

5 总结

全局和定向必须分开，不分开会导致资源浪费，所需数据可能会丢失。

监控的全面性直接取决于项目级性能分析决策树的建设。使用什么工具不是关键。关键在于这些监控工具是否覆盖了性能分析决策树的叶子。

选择监控工具，主要考虑成本、范围、层次和使用的连续性。合理的监控策略和监控工具可以实施性能分析决策树，找到性能瓶颈证据链。

不要认为监控技术组件水平就足够了。关键是覆盖相应技术组件的模块和模块对应的计数器。因为在分析瓶颈的过程中，为了找到计数器之间的相关性，如果计数器丢失，分析就会中断。

FAQ

1. 如何判断您选择的性能监控工具是否覆盖了全性能分析决策树？根据系统中涉及的系统和服务类型进行选择
2. 为什么不建议选择更多的定向监控分析工具？定向监控分析工具本身也会消耗性能