* 报警系统的意义
* 报警方式
* 报警系统触发条件
* 接入方式
* 应用场景举例
## 报警系统的意义 ##
> 结合我们现有的系统，没有对生产环境运行情况的监控，每天都会报出很多用户投诉信息，而且开发人员对自己做的系统的运行情况没有一个全面的掌握，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无法写入）
本文出自 “架构技术文摘” 博客，请务必保留此出处http://wufaliang.blog.51cto.com/3160882/1543599
原文地址：http://wufaliang.blog.51cto.com/3160882/1543599
