报警系统设想

* 报警系统的意义
* 报警方式
* 报警系统触发条件
* 接入方式
* 应用场景举例

## 报警系统的意义 ##

> 结合我们现有的系统,没有对生产环境运行情况的监控,每天都会报出很多用户投诉信息,而且开发人员对自己做的系统的运行情况没有一个全面的掌握,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无法写入)

时间: 2024-11-02 01:08:31

报警系统设想的相关文章

跟我一起学extjs5(20--模块Grid的其他功能的设想,前20节源码)

跟我一起学extjs5(20--模块Grid的其他功能的设想,前20节源码) 经过对自定义模块和Grid的设计和编码,现在已经能对一个有配置信息的模块来生成界面并进行一些简单的CURD操作.由于这是一个全解释性的前台的架构,因此你想到的任何新主意都可以放到所有的模块中. 比如对于"Grid列宽的自动适应"这个功能,我们可以在系统设置项里加入"列宽自适应模式",下面有三个选项:1.不自动适应:2.首次加载数据时自动适应:3?每次加载数据都自动适应.因为列宽自动适应需要

对理想团队模式构建的设想以及对软件流程的理解

对理想模式构建团队的设想: 1.使用妥善定义的流程,流程的每一步都是可以重复,可以衡量结果的. 2.团队中的每个成员都能理解团队的目标,角色,产品. 3.尽量使用成熟的技术和做法. 4.尽量多收集数据,并参考数据做理性决定. 5.制定切实可行的团队计划. 6.增加团队的自我管理能力. 对软件流程的理解: 一群人在开发,运营,维护软件的过程中有很多级数,做法,习惯和思想.软件工程中把这些相关的技术和过程统一到一个体系中,叫做“软件开发流程”.软件开发流程的目的是为了提高软件开发,运营和维护的效率,

设想:搭建一个历史WebGIS系统

历史知识的学习对于我们来说,非常的重要.因为历史总是惊人的相似,所以对于我们来说,学习历史可以使人明智. 现在网络已经非常普及,很多人都通过网络来获取知识.GIS可以以地图的形式表示数据,能够管理空间数据,可以进行查询和空间分析,考虑历史和GIS技术结合,构建一个"历史WebGIS系统". WebGIS是B/S架构,用户通过浏览器便可以访问.既然是B/S架构,就必须要有web服务器,地图服务器,数据库.有人会问,网络应用只需要一个web服务器就行了,为什么需要地图服务器.这就涉及到GI

关于任务分配方式的一种设想

场景1:一个5个人的小团队在开会,他们在对工作包进行时间的估算,他们每人手上一幅牌,牌上面是一些1/2,1,2,4,5这些数字.A:4,B:1+2,C:4+1/2,D:5...这样他们各自表达了自己对当前任务的开发时间的估计,由于每个人的善长点,考虑的点都不同,所以时间几乎不相同.然后组长在分别收集他们每人对当前讨论任务给出时间的依据,特别注意用时最长和用时最短的人的想法,最后他们沟通后找到一个折中的时间,如果其中有些成员想法没有统一,最后也只能双方妥协,听组长安排,比如A说,这个地方肯定会用2

独立游戏开发调查问卷结果分析及设想实现

初步游戏设想为沙盒生存类,于是通过网络调查问卷稍微收集了27位用户的意见.总结如下 首先,在“爱玩的游戏类型”选项中,18/27的用户选择了RPG(角色扮演类型),占据了绝大多数.这个与我们游戏的开发设想一致——生存类本身就属于RPG的一种分支. 15/27人一天的游戏时间在1小时到3小时之间,所以游戏单次流程需要控制在两小时左右. 因为超过半数(16/27)的用户比较倾向于联机游戏,所以决定在游戏的单机部分完成后在其中加入局域网联机功能,可以选择合作或者对抗. 13/27的用户对于游戏的要求是

关于部门后端全部转向java前初步设想

Java服务有些什么形式?目前来看主要是以下几类: 1.  运行在Web应用服务器的Servlet 2.  Thrift.PB.Avro等类似框架写的java服务 3.  WebService(JAX-WS.JAX-RS) 现在我们服务端要全面转向java.若后端子系统全部用Servlet写,将无法实现跨语言,我们现在客户端大部分还是.NET平台. 如果用Thrift等框架,现在满足了.NET调用Java服务,以后若客户端也全面使用用Java了,并且是Web客户端,那么用Thrift写的java

shell编程项目【邮件报警系统】

一.自己编写的报警邮件监控系统与专业的监控软件的优缺点 自己编写的监控脚本优点 1.若在一台服务器上拷贝了编写的脚本则这台服务器会自己监控自己,若机器上发生了脚本编写的监控项目相关的错误,则会自己发送报警邮件. 2.这种自己编写的脚本比较小巧占用系统资源较少.功能可以定制化.不用专门抽一台或多台机器做监控的服务端. 3.由于自己编写的脚本若技术能力很强则可以实现监控的自动化,即不用找人每天专门搞监控. 缺点: 1.自己编写的脚本会出现很多bug,并且维护起来的容易程度会根据运维人员的经验有很大关

互联网大型应用软件架构设想与推荐

见过很多成长中的企业,随着业务的扩大,数据流的增加,自家的软件越来越受到成长性的颈瓶,于是乎高薪招来大牛,然后就急急忙忙的乱设计架构做试验,最后搞的头痛医头,脚痛医脚的局面. 这样的企业国内太多,多的我都不好意思说了. 无论什么软件受到成长性的颈瓶,除了历史架构原因,没有别的因素了. 目前解决数据流颈瓶的技术方案有很多种,我在这里仅仅做一个设想,因为不想为那种所谓的成熟方案所吸引. 在我看来,最大的数据流软件就是google了. 据说,google为了解决此问题,采用的硬件模块化,数据内存化(含

杂篇-自动化监控设想与设计

做运维的,一个月总有那么一两天晚上睡不好,早上醒不来,不为别的,系统不稳定等等原因.导致了我们要进行各种折腾.就和整天抱着炸弹睡觉一样,这里做了一些设想,当然部分功能已经实现.发出了,让大牛们看看给点指导意见, 最核心的系统有两个ELK和老牌的nagios.naigos作为监控程序存在,主要做它擅长的应用程序状态监控,使用mk-livestatus抽出数据.然后有自己开发的mylive进行相应处理,对有问题的服务进行处理,同时也处理基于日志发现的问题,例如某些特殊情况下的攻击,waf模块拦截下的