如今的中国企业正处在传统生产、经营模式向互联网+转型的风口浪尖，企业业务对IT和互联网的依赖越来越重，IT部门在企业的价值也是水涨船高。而IT部门要为企业创造更大的价值，同样需要改变过去被动响应的工作模式，主动走在业务的前面，来引导业务需求，驱动业务改变。

云智慧监控宝是一款面向运维的全栈实时监控工具，在运维圈素有IT监控神器的美誉，那么监控宝是如何帮助一家电商企业实现业务数据监控，并让IT部门走在业务部门之前，成为企业价值中心的呢？请看下面来自监控宝忠实用户的分享。

一家做多渠道出版物(图书、音像)销售的电子商务公司，公司有自建的官网、移动官网、移动APP，也依托天猫、京东、当当、亚马逊、微信等平台开设自营旗舰店，另外还跟各大图书电商及各地新华书店开展各种供货、代发等业务。

由于公司业务线繁多，过去往往是业务部门通过月底报表发现业务出现明显滑坡后，才知道相关平台的IT系统出现故障，这时可能已经对企业经营造成不小的影响。为了保障业务系统的高效运行，公司要求对所有业务平台纳入监控，需要监控的业务指标非常多，靠人工去盯并不现实。因此，技术部门在监控好IT系统各环节运行情况的同时，还需要提供自动化工具给业务部门实现业务指标都系统自动监控。

现在网上有各种开源的、收费的、本地部署的、云上的监控工具，大多都是针对纯技术部门提供系统功能、性能及运行环境的监控，基本没有看到针对业务数据的监控工具，估计大家都认为业务数据的监控应该由报表来提供吧，据我了解的一些报表，要么没有，要么做的太粗糙不适合大规模使用。

业务数据监控相比系统监控的特点在于业务数据监控各公司、各岗位差异性很大，定制化要求很高，并且随着公司业务地发展可能随时需要调整。通过精挑细选，四川文轩在线于2013年开始使用云智慧监控宝，在监控宝独家功能——自定义监控的基础上，灵活构建起适应公司业务发展需要的监控体系。

首先公司的总经理、部门经理、业务主管肯定不会随时去关注具体的业务指标，他们也没时间去关注那么多，他们更适合使用报表查询分析结果来支撑他们制定业务策略。

而一线的业务运营人员呢？他们就需要时刻关注各项业务指标了，上级已经制定好各种业务操作办法，他们根据各项指标照着做。下面这张图简单说了下我们网店运营人员需要经常监控的几个指标：

（图一）

图上只简单列了几个常用的指标，网店运营人员当然还需要关注网店流量、用户特征、商品转换率、支付率、上架品种数等等指标，如果我们系统能够获取相关数据也是可以做成自动监控的。

图中列了3个指标，这些数据在报表中都能查到，但靠人查报表来监控实在太落后了，下班、请假、放假了怎么办？就应该当指标出现异常时监控系统及时给与相关人员报警通知才对。具体怎样来设计这些指标的告警呢？下面我们大致介绍下销售相关的三个指标监控：

1、销售额：

每个公司肯定都有报表可以查到每日、每周、每月等等时间维度的销售额的，对于网店运营人员可能需要关注的更细，往往需要关注每小时的销售情况。当某个时点销售额急剧下降，可能意味着系统或者业务规则出现问题了，需要马上召集相关环节一起排查，尽快恢复，否则销售就丢失了。下面是我们关于某网店销售额的监控截图(出于公司信息保密原则，屏蔽了一些信息，请见谅)：

（图二）

图二中有三条线：

当前小时的销售额 ： 例如当前是9:08，则获取8:08~9:08的销售额

前一个时点销售额 ： 例如当前是9:08，则获取7:08~8:08的销售额

昨天同时段销售额 ：例如当前是9:08，则获取前一天8:08~9:08的销售额

我们可以看到，每天时间段不同，销售额会有很大差异，貌似很难针对当前小时销售额来设置一个阀值，所以我们用跟前一小时环比及跟昨天同时段同比来设置告警阀值，如下图：

（图三）

图三中分别是同比和环比差额。最终监控告警策略为：环比差额、同比差额低于一定阀值则报警，那么凌晨2点左右可能会有告警通知，但那时候业务也完全不用去管了，正常销售高峰期应该差额都不大的。

通过监控宝的自定义监控能够轻松实现销售额监控告警，当然监控宝暂时不支持自定义报警时段设置，否则还可以针对不同时间段，针对销售额绝对值设置不同告警阀值。例如凌晨不告警，白天分成几个时段分别设置几个最低销售额阀值。

2、销售平均折扣、销售平均客单价

这两个指标都对营销费用有很大影响，业务需要时刻关注，当折扣或客单价大幅降低时，需要马上知晓，曾经不止一家电商都由于系统、人为、第三方平台等原因导致的价格错误，最后要么认亏要么得罪消费者。这两个指标监控很简单，低于某个特定阀值就报警，在此不上图了。但如果订单量非常大时，就算出现有异常折扣订单，可能对整体销售折扣影响不大，这就需要另外设置一个指标：低于3折订单数监控。

其次技术人员是否需要监控业务数据？答案当然是需要的。下面举个我们网店系统运维人员需要监控的两个指标：

（图四）

网店转单时效 ：网店订单支付时间与订单转入作业系统时间之间时效是否达到要求。我们要求订单支付后半小时内必须进入作业系统占用库存并安排发货，我们无论怎么设计这个系统，怎样监控系统的可用性和性能，最终我们仍然需要知道到底是否有漏网之鱼超出时效的，那一定是我们系统设计之初没有预见的。

网店转单性能 ：转单程序每分钟转单数量。

这些指标的监控方式都比较简单，关键在于怎么从后端业务系统获取数据。

无论是一线业务运营人员还是系统运维人员根据各自的职责、业务特性都可以设计出很多监控指标，方式都是雷同的，在此不再赘述了。现在问题来了，这么多数据怎么提供给监控宝？

监控宝自定义监控设计地非常灵活，有兴趣去试用下或者看看帮助文档都能轻松掌握，关键是我们后端系统如何提供数据给监控宝呢？下面大致讲下我们监控系统的设计。

（图五）

第一版的系统设计非常简单，监控宝的数据都通过monitor提供，monitor系统只需要一张表记录各监控指标查询语句，所有的业务数据都直接通过sql查询业务数据库。这个结构随着业务量增加，会导致业务数据库压力越来越大，有些复杂业务监控sql语句执行性能已经不能被接收了，从而演变成下面这种结构：

（图六）

在监控数据库中根据业务监控指标对销售、商品、库存等指标进行建模，这些数据由业务系统流转过程中抽离出影响指标数据提交给业务数据收集器汇总保存，例如：从网店转单时，将订单的金额、折扣、网店支付时间等数据通过AMQ异步提交给收集器，收集器累计一个时间单元后计算出该时间单元内的总销售额、品均折扣、平均客单价等信息记录在监控库中，为了方便收集器快速配置，需要预先设置几种计算模型：直接保存、汇总、求平均、取最小值、最大值等等。

监控宝作为云智慧面向业务的全栈性能管理解决方案中的一环，与面向业务的端到端应用性能管理平台透视宝，和基于真实业务场景的大规模应用性能测试平台压测宝一起，共同以全面提升企业业务流程为目标，解决用户体验前置和云计算的快速发展带来的系统架构变化的挑战，帮助企业致胜互联网+。