* 报警系统的意义
* 报警方式
* 报警系统触发条件
* 接入方式
* 应用场景举例
## 报警系统的意义 ##
> 结合我们现有的系统,没有对生产环境运行情况的监控,每天都会报出很多用户投诉信息,而且开发人员对自己做的系统的运行情况没有一个全面的掌握,SOA架构里面,接口满天飞,单一业务出问题,很难找出是哪个模块导致的, 搞得开发人员处理问题很被动,而且故障都让用户第一时间发现并投诉,体验也不好。
>大家设想一下这样的场景: 一个用户在前端页面下订单,支付成功后,页面仍然显示未支付,在用户焦虑等待后要投诉时,我们的客服电话或者短信已经通知了用户,并告知”系统出现异常,我们正在紧急为你处理,请耐心等待后续通知“ ,用户会感到满满的安全感。
总结:先于用户发现系统异常,并及时处理
##报警方式##
> 根据异常级别,采用短信、邮件方式通知。
> 每周给出报警汇总。
## 报警系统的触发条件##
1. 所有FATA级别错误。
2. Error错误根据指定ErrorCode触发。
3. Info类型根据指定ErrorCode频次触发。
4. 根据指定接口的响应时长阀值触发。
5. 根据业务场景自定义。
## 接入方式##
1. 根据所有业务方接入日至系统中的日志来做分析。
2. 平台指定根据Appid,确定邮件组。
3. 平台指定ErrorCode,映射邮件人及短信接收人。
## 应用场景举例##
1. 前段时间生产环境集群cpu load值居高不下,php进程持续高位的问题,根据服务器端排查,确定为php程序链接外部资源超时所致,但系统的复杂性,没办法确定是什么项目在调用什么服务(接口、数据、分布式文件)时导致的,在排查半天无果后,自动恢复了, 追其原因是因为A项目修改了memcache的链接服务器,因memcache响应缓慢导致A项目对外提供的接口偶尔超时导致。
2. 订单支付处理异常的问题,偶尔也会接到用户投诉,根据支付处理的规则分为两种:
1. 支付方系统故障,延迟回调。
2. 我方接受到支付回调结果,但支付脚本异常导致。
针对这个问题, 支付脚本在处理支付时,会记录文本及数据库log,但是不会主动通知到开发者,导致开发者很被动,而且开发者排查问题时,能借助的就是服务器端的log和数据记录,而无法还原出错场景。
3. 数据库连接错误、队列无法写入、 重要日志记录失败(文件、DB无法写入)