按《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要更加敏感，适用于相对比较稳定的监控项，比如磁盘使用率）。
误报会降低运维工程师对报警信息的敏感性和警惕性，也会增加工作之外的生活压力，对于不能明确反映系统故障的报警项应该降级为邮件报警，遵循少即是多的道理。

仪表盘

上述指标结合Grafana，可以帮助我们在服务发生故障时，快速精准定位，为实现服务第一时间快速止损提供有力保障。

订单监控的仪表盘分为如下四个部分，各个指标一目了然：

CDN和高防访问成功率

图2 仪表盘-CDN和高防访问成功率

VIP访问成功率

图3 仪表盘- VIP访问成功率

模块状态统计

图4 仪表盘- 模块状态统计

第三方依赖状态

图5 仪表盘-第三方依赖状态

常见故障及其预案建设

运营商故障

案例：电信运营商故障导致接入层IP无法提供服务。

应对预案：流量切换。我们制定了流量切换即切换流量入口IP作为应对运营商故障的预案：即为电商系统分地域（华南、华北）、分运营商（移动单线、电信单线、联通单线、BGP多线）申请多个接入IP。在综合考虑网络质量、延迟等因素后，我们总结流量切换的优先级如下：

切换到同地域同运营商的流量入口
切换到跨地域同运营商的流量入口
切换到同地域跨运营商的流量入口
切换到跨地域跨运营商的流量入口

接入层故障

案例： CDN二级节点部分缓存机器服务故障，导致服务页面异常。

应对预案：降级。我们通过添加一层域名指向，将IP高防、CDN、云WAF等接入层组件接入到系统中来，当这些组件部分节点或全部节点发生故障时，我们通过调用DNS接口快速完成CNAME变更，从而绕过故障组件。

IDC故障

案例： IDC无法访问公网，导致无法生成订单快照进而影响下单核心流程。

应对预案：多AZ建设。由下图可知，当N大于1时，N+1值越高，代表冗余度越低，硬件成本越低，但隐含项是IDC建设成本高昂，即图中拆线斜率越小。出于成本及冗余度考量，我们推荐AZ个数设定为4个，即当N等于3时，我们可以取得硬件成本与服务稳定性收益的最大平衡：

图6 硬件成本与服务稳定性收益趋势图

应用层故障

应对预案：以季度为周期，我们通过“chaos monkey”搭建故障演练平台，对多个电商项目逐个进行例行故障破坏演练，实现全产品线任意模块均可快速完成回滚、重启、扩容、迁移等预案。既可以提前暴露出架构中的薄弱环节、又可以让一线运维工程师、研发熟悉常见故障处理方法，熟悉应急故障组织管理流程。

第三方依赖故障

案例：因云缓存升级认证方式，导致登录页、商详页等页面无法展现，影响用户下单。

应对预案：为应对云数据库、云缓存等故障，我们通过如下方法优先保证核心页面可正常展现：

构建多级缓存。
访问率较高的首页、商详静态化，并上线CDN。
抽取页面公共静态资源，并进行动静资源分离。
部分数据异步请求。

创作场景

没有监控完备，何来“剁手”畅快——电商平台监控详解