《互联网应用告警中心的开发》由会员分享，可在线阅读，更多相关《互联网应用告警中心的开发（48页珍藏版）》请在金锄头文库上搜索。
1、自学考试毕业设计自学考试毕业设计互联网应用告警中心的开发互联网应用告警中心的开发专专 业业 计算机及应用计算机及应用学学 生生 xxxxxx指导老师指导老师 xxxxxx日日 期期 20172017 年年 3 3 月月摘要在互联网应用中，随着业务的发展，使用监控系统对系统出现的异常情况进行告警是确保系统稳定性的必然要求。面对成千上万的告警信息，很容易出现被称为“告警疲劳”的现象，而如何确保重要的告警被可靠的通知给合适的人，并迅速的得到处理，而不被别的报警信息所淹没，正是本软件要解决的问题。本软件集中收集各种监控的告警信息，根据值班设置，将告警发送给值班人员；通过告警分析报告，帮助提升报警处理团
2、队的工作效率。本软件基于 B/S 结构，采用的主要技术是 Bootstrap + SpringMVC + SpringData，开发语言使用 Java，数据库使用 MongoDB。软件上线后，有效改善了原来团队中告警处理流程混乱、效率低下的情况。本文一共分为 7 个章节，内容组织和章节安排上，首先是背景和意义，接下来是需求分析，然后是功能设计和详细设计、项目特点和使用情况，最后是总结和进一步的工作展望。关键字关键字： 告警中心，告警疲劳，告警压制，告警分析目录目录引言61开发背景、选题意义.71.1开发背景 71.2选题意义 72软件需求分析 82.1国内外研究现状.82.2问题域分析.82.
3、2.1告警集成(Integration)82.2.2告警归集(Aggregation).92.2.3告警路由(Routing)92.2.4告警分析(Analysis).92.3非功能性需求.102.3.1安全性 102.3.2可用性 102.3.3并发性 102.3.4客户端兼容性.102.4技术栈选型 102.4.1Java112.4.2BS 架构 .112.4.3MongoDB 112.4.4Spring112.4.5Spring Data112.4.6Spring Security 112.4.7Spring Web MVC.122.4.8Velocity .122.4.9Bootstr
4、ap 122.4.10Hazelcast.122.5章节小结 123软件总体结构、功能设计.133.1软件总体结构.133.2软件功能设计.133.2.1角色/权限管理.143.2.2用户管理.143.2.3团队管理.153.2.4服务管理.163.2.5告警管理.163.2.6报表管理.173.2.7API 管理183.3章节小结 184软件详细设计 194.1数据模型设计.194.1.1IdName194.2数据库设计 204.2.1Sequence.204.2.2Embeded document Team, 表示团队，由多名用户构成；Service，表示服务，是监控的业务对象主体，比如公
5、司的某产品。该服务的告警由某个团队负责处理。Trigger，表示告警触发，比如由某监控系统发出的某告警信息；Notification, 表示告警通知，如某告警被触发后，给某用户发送的邮件通知；ActivityLog，表示告警活动日志，包括触发、通知、确认、已解决、备注等日志；Incident，表示告警事件，记录告警被归并后的实体；Token，表示 API 凭证。4.1.1 IdNameIdName，是一个泛型类，用来封装属性对。以 Service 为例，服务有个负责团队属性，该属性使用的 IdName，而不是 Team类，这样避免了对象层次太深，同时兼顾了页面显示需要使用 Team.name
6、的要求。在本项目中，由于项目特性，User.name, Team.name, Service.name 都有不可变更的属性，因此 IdName 中的名称是最新的。在对应对象 name 属性可变的场景下，需要单独使用NameService，用来获取最新的 name 属性。4.2 数据库设计数据库设计在 MongoDB 中，对象的集合称为 collection，对象称为 document。在本项目中，collection 包括：Sequence，User, Team，Service, Incident, Token 等。4.2.1 Sequence在 MongoDB 中，_id 属性为 Objec
7、tId 类型，可以自动生成，但它是一个形如“507f1f77bcf86cd799439011”的字符串，不便于识记。为使用唯一标识的数字作为对象的 ID，在 MongoDB 数据库中，添加名为 sequence 的collection。在该 collection 中，记录每个业务对象的下一个可用序列值。比如，在新建 Incident 事件时，对应 ID 为 sequence 中 id=Incident 的序列值，同时将该序列值自增 1，该自增操作使用 MongoDB 的原子自增更新操作实现，避免多并发情况下出现序列值错乱的情况。4.2.2 Embeded document headers，为需
8、要参与签名的请求头（目前仅包括 x-api-date） ，各 header 按照: headerKey:headerValue + n + headerKey:headerValue +.格式拼接；sortedUri，为请求 uri 中各查询参数按字典升序排序后的字符串。签名的秘钥使用客户端的 API Token 的 secret，该 secret 是在申请 Token 时，使用SecureRandom 随机生成的 32 位字符串；签名的加密算法使用 hmacsha1。签名完成后，将 API Token 的 key，与签名结果 sign，以key:sign的格式拼接后，以Authorizati
9、on为 headerKey，添加到请求的 header 中。服务端对签名进行核对的过程如下：图 4-6 API 签名验证流程4.4.2 API 接口设计接口设计本项目中，目前只有一个接口，newTrigger，为告警集成者提供告警接入服务。接口 uri 为：newTrigger.json，参数包括：参数名参数名说明说明service接入的服务名title告警标题content告警内容urgency告警的紧急程度; High, Normal, Low服务名、告警标题、告警内容等，由于有中文，需要使用 URLEncoder 进行转码，编码使用 UTF-8。为了避免在调用接口时，堵塞主线程，使用 E
10、xecutorService，进行异步调用。如果调用失败，在日志中记录失败详情。4.5 告警通知告警通知在本项目中，当前仅支持邮件通知这一种通知方式。在真正应用的时候，一般需要添加对电话、短信、即时消息等的通知支持。为此，按照开放式设计原则，使用 Provider 模式，设计类层次结构如下。图 4-7 告警通知类图NotificationServiceProvider，是各通知服务提供者的抽象。需要添加电话、短信、即时消息等通知服务时，实现该类，并在初始化时注册即可。EmailNotificationServiceProvider，是邮件通知服务的提供者。init()方法向 Notifier
11、注册自己；getSupportedType()声明自己支持的通知类型；notify()方法进行邮件通知。MailSender，是邮件通知的实际实现类，使用 Java Mail API，进行邮件发送。Notifier，是通知服务的门面类。Providers 中存储所有当前已注册的通知服务提供者；registerProvider()方法提供底层通知服务提供者的注册方法；notify()方法使用异步线程，根据通知类型，使用相应的服务提供者进行相应的通知操作。以上类结构，易于扩展。后续需要添加新的通知服务时只要实现NotificationServiceProvider 即可，Notifier 会自动找
12、到相应的服务提供者，并调用该服务者以完成通知服务。4.6 告警处理告警处理4.6.1 告警状态图告警状态图图 4-8 告警状态图上图是告警的状态图。告警由三个状态：新建、已确认、已解决。“新触发” ，表示由监控系统发送过来的新的告警触发，或者用户在界面上手动添加的告警触发。如果有相同标题的、状态不是“已解决”的告警，则维持该告警的状态不变，更新该告警的触发列表，并发送通知；否则，新建告警事件。“确认” ，用户收到告警通知后，查看告警详情，点击“确认”按钮。确认操作将告警标记为“已确认”状态。“解决” ，用户处理完告警事件后，点击“解决”按钮。该操作将告警标记为“已解决”状态。 “已解决”状态为
13、告警事件的最终状态。4.6.2 新告警新告警图 4-9 新告警流程图上图是新告警的流程图。告警根据服务名和标题，进行归并。相同的服务名和标题的触发，被归并为同一个告警事件，除非该告警事件已经被解决，这时创建新告警。为了避免对告警处理者造成过多的骚扰，需要对告警进行相应的压制。具体的压制策略包括：i.只在收到新的告警触发时，进行告警通知;ii.对于紧急程度为低的告警，不进行通知；iii.对于状态为”已确认”的告警，不进行通知；iv.同一个告警事件，对于同一个处理者，五分钟内最多通知一次。实行以上压制策略后，可以避免告警通知过多，导致告警处理人员无法专心处理问题的情况，从而有效的提高告警处理的效率
14、。4.6.3 自动解决告警自动解决告警有些告警，比如紧急程度为低的告警，由于告警压制策略的原因，用户不会收到告警通知，这些告警可能不会及时被标记为“已解决” ；另一方面，告警一般都有时效性，比如“服务器 CPU 利用率较高” ，该告警如果发生一段时间后不再出现，则很可能是该问题已消失或处理完毕。因此，告警的自动解决功能是很可行，也很有必要的。本项目使用 Spring 的 Scheduled 注解，实现该功能。一分钟执行一次，找出系统中各服务下的超时告警，将其自动修改为“已解决”状态。告警的超时时间，可在服务管理界面进行设置。4.7 章节小结章节小结本章通过对实现中的几个关键点，包括数据模型设计
15、、数据库设计、UI 设计、API 设计以及关键功能点实现等进行描述，展现了系统的详细设计。5软件的特点和实现难点软件的特点和实现难点5.1 MongoDB 的数据库设计的数据库设计本项目使用的 MongoDB 是一种开源、schema-free、高性能、高可用、可自动扩展、基于文档的数据库。5.1.1 文档数据库文档数据库在 MongoDB 中，一条记录就是一个文档，该文档是一个“字段-值”对构成的数据结构。MongoDB 的文档跟 JSON 对象有点相似。各字段的值可以包括文档、数组以及文档的数组。使用文档的好处包括：i.文档（特别是对象）在很多编程语言中是最基础的数据类型；ii.嵌入的文档
16、和数组，减少了数据查询时做代价昂贵的连接(join)的必要；iii.动态 schema 可以支持多态特性，更避免了传统关系型数据库做 schema 变更时的种种麻烦。MongoDB 中的数据具有灵活动态的 schema。与传统的 SQL 数据库不同，在 SQL 数据库中，插入数据之前必须定义清楚表(table)的 schema。在 MongoDB 中，集合(collection)不强制要求文档的结构。这种灵活性使得将一个文档映射为一个实体或者对象时变得更为简单。每个文档可以单独匹配对应实体中的数据字段，即使该数据有各种变体，如多态性。在实际使用中，同一个集合中的文档一般共享相似的结构。在数据建模时关键的挑战在于应用需求、数据库引擎的性能特性、以及数据存取模式等的平衡。当设计数据模型时，总是需要考虑数据的业务应用（比如查询、更新和数据的处理等） 。5.1.2 实体实体-文档映射（文档映射（Entity-Document Map
