没有监控完备，何来“剁手”畅快——电商平台监控详解_软件工程_京东云应用研发部

FCon7折倒计时最后一周：日程已上线70%！查看详情>>> 了解详情 



 写点什么

按《SRE Google 运维解密》对监控的划分，监控可以分为“黑盒监控”与“白盒监控”，黑盒监控解决的是“系统哪些功能出问题了”，白盒监控解决的问题是“什么原因导致了上述故障”。

通俗来讲——白盒监控可以帮助我们快速定位问题原因，但要知道服务出了什么问题，还需要我们从黑盒监控入手。

黑盒监控

监控对象

电商网站的哪些功能发生故障会使用户认为网站宕机？评价、优惠、库存等功能异常显然无法使我们得到上述的结论，而登录、加入购物车、下单、指定收货地址等功能中任一环节异常都会导致用户无法下单。因此，我们将电商平台的核心流程即订单流程功能点概括如表 1 所示，并且我们将核心页面的流量情况做出仪表盘展现出来（图 1）：

表 1 订单核心功能点

图 1 各核心页面流量 PV

监控经验

触发反作弊策略

用于订单监控的账号达到单位时间内允许登录、下单的上限被电商项目内部反作弊系统或下游交易系统判定为异常行为，从而出现弹出验证码、下单被告知已达上限等现象，导致订单监控抛出异常。

针对此类问题可以在运营后台添加账号白名单，如果电商系统不支持此功能，可以通过多个账号轮询发起订单监控，最终聚合监控结果来规避此问题。

在售商品库存被耗尽

订单监控在预发环境进行调试时，频繁下单导致在售商品库存耗尽，影响了商品售卖。我们创建了测试商品（无法被用户浏览到）用于订单监控，规避此问题。

服务变更导致订单监控异常

在产品快速迭代的同时，代码实现逻辑、接口参数等也在不断迭代，如果监控滞后于服务代码的变更，必然会引起订单监控的异常，某电商项目近半年因变更导致订单监控异常的有：

登录密码加密逻辑变更
价格获取逻辑变更
商详页 URL 变更
电子发票获取逻辑变更

支付页同样需要监控

虽然因为电商关联众多支付平台（各大银行网银、移动支付工具）且订单监控会产生真实交易数据，导致我们无法监控真实支付环境节，但我们也需要确认下单流程能否正常跳转支付页。

白盒监控

白盒监控依靠的是系统内部暴露的性能指标。我们对用户请求进行了全链路的监控，包括 CDN 和高防访问成功率、不同地域不同运营商 VIP 访问成功率、模块及实例级别监控状态、第三方依赖状态的内容。

监控对象

从用户的使用角度，架构分为接入层、应用层、数据及依赖层、基础服务及实例，共 4 部分。

接入层：CDN、IP 高防、云 WAF、负载均衡。

应用层：应用模块，比如我们会对关键 URL 的服务质量进行语义监控，关键 URL 包括运维工程师经验得到的关键 URL（可枚举的关键页面、关键接口），以及通过全量分析日志找出访问请求量 TOP10 的 URL。

数据及依赖层：缓存、数据库、ElasticSearch、Kafka、云存储、外部 API 接口依赖。

基础服务及实例：实例出公网的连通性、内网机器之间的 ping 延时、性能指标（CPU、内存、网络流量、网络连接、磁盘 IO、磁盘使用率等）。

监控经验

对于处在公网的接入层组件，我们使用分布在全国各地的探测节点进行语义监控。
对于 CDN 既要监控各边缘节点缓存的静态资源是否可被访问到，同时也要监控未被缓存的静态资源回源访问是否正常。
报警阈值建议以百分比代替绝对值，可以帮助我们省去后续因流量、实例等规模变更导致反复调整报警阈值的问题。
以监控请求延时为例，我们推荐使用分组计数代替平均值，即延迟在 0~100ms 的请求量有多少，100~300ms 的请求量有多少。原因是 1%的异常请求耗时是平均值的 10 倍，通过平均值监控无法发现异常。
添加监控策略后一定要进行回归验证（比如在业务低峰期进行故障演练），不能等故障发生时再检验报警的有效性。
报警策略的设置会直接影响报警的准确性（比如 3/3 和 3/5 的策略，前者表示连续三个周期有三次不符合阈值规则就报警，后者表示五个周期中有三次不符合阈值规则就报警。3/3 要更加严格，可以避免波动的监控报警，比如网络的可用性会受到网络抖动的影响；而 3/5 要更加敏感，适用于相对比较稳定的监控项，比如磁盘使用率）。
误报会降低运维工程师对报警信息的敏感性和警惕性，也会增加工作之外的生活压力，对于不能明确反映系统故障的报警项应该降级为邮件报警，遵循少即是多的道理。