聊一聊资源监控

为什么要进行资源监控？

为什么在稳定性测试的时候需要进行相应的资源监控呢？简单来说因为我们需要知道在程序运行的时候能够主动观察到资源的消耗情况以便及时发现问题

怎么进行监控？

目前我们常用对资源的监控可以分为如下表格：

监控类别	工具举例	备注
监控工具	free、vmstat、df…	主要应用于问题定位，并且实时分析，适用于服务器量少，非图标
监控系统	Zabbix、 Open-Falcon、Prometheus…	拥有比较完整的流程，从数据采集到数据存储再到数据分析最后是展示和告警，可以满足一个企业级的监控需求

要监控什么？

根据不同的稳定性要求，我们会监控不同的稳定性资源，那究竟我们会监控哪些资源呢？下面表格给出了一般环境中我们需要监控的资源。

监控类型	具体项	Prometheus支持程度
硬件监控	温度：CPU/主板/内存、硬件故障：硬盘/RAID卡/电源等	社区支持，使用第三方插件
系统监控	CPU、内存等	支持
应用监控	服务，例如：vsl服务、中间件：Nginx/Tomcat、数据库：MySQL	支持
日志监控	系统日志、服务日志、访问日志、错误日志等	不支持
安全监控	WAF(网站应用级入侵防御系统)、敏感文件监控等	基本不支持
API监控	可用性、接口请求、响应时间等	支持
业务监控	如电商网站，每分钟产生多少订单、注册多少用户、多少活跃用户、推广活动效果等	不支持
流量分析	根据流量获取用户相关信息，列入用户地理位置，某页面访问状态，页面停留等	不支持

监控前要做哪些准备工作？

熟悉被监控的产品/方案

既然我们需要进行稳定性测试并且进行相应的资源监控，那么我们首先就需要熟悉被监控的产品或者方案。关于产品/方案熟悉的程度包含但不局限于如下方面：

稳定性测试的整体组网图；
稳定性测试的物理逻辑组网；
方案级包含的产品以及每个产品主要涉及的自研服务；
产品或者方案包含的中间件，如RabbitMQ，Redis；
产品或者方案涉及的数据库；
…

整理监控指标

一般情况下，稳定性测试是测试代表主导进行的，既然我们对自己的产品熟悉以后，那么就需要对整理在本次稳定性测试中，我们需要对资源监控的一些指标。

告警阈值定义

当我们梳理完需要被监控产品/方案的监控指标以后，我们肯定要对每个监控指标设置一个阈值，当被监控的产品/方案某个监控指标达到或者超过阈值以后肯定需要进行相应的报警行为，因为我们不可能7*24小时的紧盯着我们的监控数值然后去发现问题。这个是不现实的。所以就要设定一定的报警阈值，只要产品/方案中某个被监控的指标超过阈值就进行报警。