互联网业务故障投诉系统的设计与实现第4章下文档格式.docx
- 文档编号:18370998
- 上传时间:2022-12-15
- 格式:DOCX
- 页数:18
- 大小:306.71KB
互联网业务故障投诉系统的设计与实现第4章下文档格式.docx
《互联网业务故障投诉系统的设计与实现第4章下文档格式.docx》由会员分享,可在线阅读,更多相关《互联网业务故障投诉系统的设计与实现第4章下文档格式.docx(18页珍藏版)》请在冰豆网上搜索。
其次,考虑到当产生告警后,省公司用户可能仍然未及时处理故障工单,所以系统在超过一定时阀后需要对其进行重复告警提示。
针对同一告警流水号的告警信息,重复产生告警次数越多,该条告警的优先级就越高。
系统根据优先级对告警信息进行排列,对优先级高的信息先进行告警。
为防止多次告警后相关处理人员仍未及时处理投诉的情况发生,系统设置了管理员派发工单机制。
当某条工单重复告警超过三次时,系统消除该条告警信息,并自动给管理员发送邮件说明情况,由系统管理员统一对相关工单派发处理。
4.4.2告警详细流程设计
在系统后台告警程序中,主要分为两个部分,第一个部分针对工单表进行轮询,判断工单是否达到初次告警界限;
第二个部分针对实时告警表进行轮询,判断已产生的告警信息是否达到重复告警的界限。
初次告警判断流程如图4.15所示,系统对工单初次告警的判断流程为:
(1)后台轮询程序对is_list_info表(工单表)进行轮询,筛选出状态为“已提交”及状态为“处理中”的工单。
(2)针对状态为“已提交”的工单,将当前时间与工单投递时间相减,判断其时间差是否超过接单超时告警时间。
若未超过则不做处理,若已经超过接单超时告警时间,则在实时告警表中查询是否已有该条工单所生成的告警信息,防止一条工单产生多条告警信息,造成告警信息管理混乱。
如果实时告警表中已有该条工单存在,则不对其进行处理,如果没有该条工单,则产生接单不及时告警,将其添加进实时告警表中。
(3)针对新产生的接单不及时告警消息,先查询所有省公司用户上次发送邮件时间以及发送短信时间,将当前时间与上次发送时间相减,判断各个员工的时间差是否超过发送邮件时间间隔及发送短信时间间隔,若超过,则调用邮件模块和短信模块为该员工发送邮件及短信进行提示,若未超过则不发送。
(4)针对状态为“处理中”的工单,将当前时间与工单的接单时间相减,判断其时间差是否超过处理超时告警时间。
若未超过则不做处理,若已经超过处理超时告警时间,则在实时告警表中查询是否已有该条工单所生成的告警信息,防止一条工单产生多条告警信息。
如果实时告警表中已有该条工单存在,则不对其进行处理,如果没有该条工单,则产生处理不及时告警信息,将其添加进实时告警表中。
(5)针对新产生的处理不及时告警消息,查询该工单的接单人上次发送邮件时间以及发送短信时间,将当前时间与上次发送时间相减,判断该员工的时间差是否超过发送邮件时间间隔及发送短信时间间隔,若超过,则调用邮件模块和短信模块为该员工发送邮件及短信进行提示,若未超过则不发送。
(6)当系统完成一次轮询之后,间隔1分钟后再进行下一次轮询。
图4.15初次告警判断流程
工单重复告警的流程如下图所示:
图4.16重复告警判断流程
如图4.16所示,系统对工单初次告警的判断流程为:
(1)后台轮询程序对is_alarm_list表(实时告警表)进行轮询。
(2)将实时告警表中的告警信息以先优先级、后时间顺序的排序方式进行排序。
(3)针对状态为接单不及时告警的告警信息,将当前时间与工单告警时间相减,判断其时间差是否超过重复告警时间。
若未超过则不做处理,若已经超过重复告警时间,则更改该条告警信息的告警时间,增加其告警优先级。
(4)针对产生重复告警的接单不及时告警信息,判断其告警优先级是否达到3级,如果达到3级,则将相关工单递送给系统管理员进行派发工单。
如果未达到3级,则先查询所有省公司用户上次发送邮件时间以及发送短信时间,将当前时间与上次发送时间相减,判断各个员工的时间差是否超过发送邮件时间间隔及发送短信时间间隔,若超过,则调用邮件模块和短信模块为该员工发送邮件及短信进行提示,若未超过则不发送。
(5)针对状态为处理不及时告警的告警消息,将当前时间与工单的告警时间相减,判断其时间差是否超过重复告警时间。
(6)针对产生重复告警的处理不及时告警消息,判断其告警优先级是否达到3级,如果达到3级,则将相关工单递送给系统管理员,由管理员督促相关接单人员。
如果未达到3级,则查询该工单的接单人上次发送邮件时间以及发送短信时间,将当前时间与上次发送时间相减,判断该员工的时间差是否超过发送邮件时间间隔及发送短信时间间隔,若超过,则调用邮件模块和短信模块为该员工发送邮件及短信进行提示,若未超过则不发送。
(7)当系统完成一次轮询之后,间隔1分钟再进行下一次轮询。
以上告警流程由四个线程同时进行处理,考虑到对省公司用户进行告警提示,最主要的指标是准确性,在实时性上的要求并不需要特别高,所以结合系统的CPU占用情况,告警模块每次轮询会间隔1分钟。
4.5故障源定位模块设计
针对资源类互联网故障,按照应用类型进行分类,可分为网页类网络故障和软件类网络故障,本系统分别针对网页类故障和软件类故障的故障信息收集进行了设计。
对网络故障的故障源定位时,最重要的是获取故障源IP地址等故障信息,下面分别对网页类故障和软件类故障收集故障信息的方法进行介绍。
4.5.1网页类故障信息收集
对于网页类互联网故障,运营商的一般处理办法是使用HttpWatch软件对故障页面进行整体抓包,相关工作人员逐个对抓包文件进行分析,筛选出页面无法获取或等待超时等故障链接,再逐个对故障页面URL进行域名解析,获得故障源IP地址。
这种方法十分耗时,而且通过人工对抓包文件分析判断的过程可能不够准确、不够全面,所以本系统设计网络爬虫对整个网页中的故障进行抓取、定位。
1.网页类故障信息收集流程
利用网络爬虫收集网页类互联网业务故障信息的设计流程如下图所示:
图4.17网页类故障源定位流程
对于网页类互联网故障,可以比较直观的获取到故障页面的URL,通过域名解析系统即可解析出该URL所映射的IP地址,从而找出故障源。
但是考虑到在某一个故障页面中,可能存在多个故障链接无法打开的情况,所以系统选择网络爬虫对故障页面中所有URL进行爬取。
如图4.17所示,收集网页类互联网故障信息的流程为:
(1)当用户产生网页类互联网业务故障时,首先利用网络爬虫将故障页面中所包含的所有链接都抓取下来(包括图片URL)。
(2)通过C#中的WebClient类,对所抓取到的URL逐个建立虚拟访问。
(3)根据访问各个URL链接所返回的数据,判断URL是否产生故障。
若该URL未产生故障则结束对该URL的判断,转而对下一个URL进行判断,否则进行下一步处理。
(4)针对产生故障的URL,首先利用域名解析系统,解析出该URL所映射的IP地址,即为故障源IP地址。
(5)对故障源IP地址进行路由跟踪,获取从故障主机到目标服务器的路由路径。
(6)统计路由路径中各个路由节点,将路由节点与地址池中的所走出口地址进行比对,定位出所走出口所属的厂家。
系统在完成域名解析、路由跟踪等工作时,均使用C#调用操作系统中CMD命令,从而获取返回信息。
由于网络中故障类型繁多,本系统主要旨在提供一种针对网页类故障定位的方法,在对网页类故障进行故障源定位时,系统能够满足的故障类型有限,主要针对目标路由不可达、访问超时、目标内容不存在等基本故障进行定位。
另外,由于互联网中网页数量非常多,不同用户产生的故障网站也不同,历史案例库中很难找到与新故障网站相同的历史案例。
所以,本系统在对网页类故障进行定位时,未进行案例匹配。
2.网络爬虫的改进
对于传统的网络爬虫而言,其存在很多弊病,其中最突出的问题就是存储网页重复率过高。
在网络爬虫运行的过程中,经常会爬取到重复的链接。
系统需要消除这些重复URL,否则将影响爬虫软件的爬行效率[42]。
目前对网络爬虫所爬取到的URL进行重主要有两种方式:
(1)完全内存方式。
运用哈希算法,计算爬取到的URL的哈希值,将URL以哈希值的形式进行存储。
(2)基于磁盘的缓存方式。
这种去重方式是将大部分爬取到的网页存放到磁盘中,在内存中开设一部分缓存,根据实际需求更新缓存。
对于基于磁盘的缓存方式而言,在进行URL比较时,如果在缓存中查找不到该URL,就必须在磁盘中继续查找,但是磁盘存取速度比内存慢,会影响程序运行效率。
所以本系统采用完全内存方式进行去重。
其中,在哈希算法的选择上,本系统采用MD5算法。
MD5算法的功能就是将任意长度的数据经过运算转换成128位固定长度的数据,将URL通过MD5运算转换为128位数据。
但是MD5()函数产生的值很大,为2128个不同的数,需要巨大的内存空间。
因此,在实际处理中还要将URL经过MD5()函数运算所产生的值进行模运算映射到哈希表中。
其公式设为:
(4.1)
其中,URL为所抓取的地址,N为存储哈希表的位长,本系统选取其为13。
通过哈希表映射,可使URL地址被映射到大小为N的哈希表的某位上,方便确定该地址是否被抓取过。
其次,在URL保存问题上,由于第一个网页所获取的等待URL非常多,假如采取表格的形式对其进行存储,就会占据很大的内存,并且会影响存取速度[43]。
因此,本系统将等待URL存入数据库,再建立存入缓存和取出缓存两个缓存区,三个部分互相配合以提高存取速度。
图4.18URL保存示意图
如图4.18所示,URL保存模块分为存入缓存、数据库和取出缓存三部分。
如果网络爬虫爬取的URL过多,存入缓存中的数据出现溢出时,系统以队列“先入先出”的方式,将最早产生的数据存储到数据库中;
当提取URL时,爬虫软件从取出缓存中进行提取,同时,将数据库中的URL逐步添加到取出缓存中。
这样既可以保证数据存取速度,还能节约内存。
3.故障链接判断方法
本文使用C#中WebClient类对爬取到的URL进行虚拟访问后,判断该URL是否为故障链接主要依靠对返回信息的HTTP状态码进行判断。
HTTP状态码(HTTPStatusCode)用来表示网站服务器对客户端请求的响应状态,它是一个3位数数字。
它由RFC2616规范定义,并经过RFC2518、RFC2817、RFC2295、RFC2774、RFC4918等规范扩展。
HTTP状态码主要有以下几种类型:
(1)消息。
这类型状态码以1开头,形如1XX,表示服务器的响应是临时响应,客户端的请求未被服务器拒绝,如“100Continue”。
(2)成功。
这类型状态码以2开头,形如2XX,表示客户端的请求已被服务器顺利接收,服务器已针对客户请求成功执行了相应的操作,如“200OK”“202Accept”。
(3)重定向。
这类型状态码以3开头,形如3XX,表示服务器对客户请求的数据进行分析后,判定客户端必须采取进一步操作才能够完成整个请求,如“301MovedPermanently”。
(4)请求错误。
这类型状态码以4开头,形如4XX,表示客户端发起的请求有误,服务器无法对其进行解析,该请求影响服务器的处理工作,如“404NotFound”。
(5)服务器错误。
这类型状态码以5、6开头,形如5XX、6XX,表示服务器在处理请求的过程中发生错误或服务器无法对当前请求提供相应的软硬件资源,如“500InternalServerError”“600UnparseableResponseHeaders”。
本系统提取服务器响应中StatusCode字段内容,若HTTP状态码以4、5、6开头,则判定该URL为故障URL。
4.5.2软件类故障信息收集
针对软件类互联网故障,无法直接获取到故障软件的内容提供方的服务器IP地址,所以需要对该故障应用程序所产生的数据包进行抓取,再对数据包进行解析,从而获取到故障IP地址。
1.软件类故障信息收集流程
针对软件类互联网故障的故障信息收集流程如下图所示:
图4.19软件类故障定位流程
如图4.19所示,软件类互联网故障信息收集的流程为:
(1)当用户产生软件类互联网业务故障时,首先确定所产生故障的应用程序。
(2)调用系统“tasklist”命令,获取到计算机所有正在运行的应用程序及其进程号(PID),筛选出故障应用程序的PID。
(3)调用系统“netstat-ano”命令,根据故障应用程序的PID获取到该应用程序所占用的端口号。
(4)开启抓包程序,选择网卡,将网卡类型设置为混杂模式,并将抓取正则表达式设置为只抓取通过该端口的数据包,开始抓包。
(5)对抓取到的数据包进行解析,获取到数据包的目的IP地址,即故障源IP地址。
(6)对故障源IP地址进行路由跟踪,找到从故障主机到目标服务器的路由路径。
(7)统计路由路径中各个路由节点,将路由节点与地址池中的所走出口地址进行比对,定位出所走出口所属的厂家。
(8)根据相关匹配规则,将当前故障与数据库中的历史故障案例进行匹配,若有相似案例,则根据历史案例的处理信息给出故障诊断建议。
2.抓包软件设计
本系统旨在对网络故障自动定位出故障源,节省人力工作。
需要将数据包抓取、数据包解析、出口分析、案例匹配等工作都集成到一个软件中完成。
所以本系统在抓包时未采用Wireshark等抓包软件,而是重新开发抓包软件。
本系统所设计的抓包软件基于.NET类库SharpPcap.dll与PacketDotNet.dll进行开发。
SharpPcap.dll中封装了Winpcap所提供的大部分API函数,通过调用该类库,可以获取主机网卡信息,实现打开网卡、开始抓包、停止抓包等针对网卡的各种操作。
类库PacketDotNet.dll中封装的方法主要完成对捕获到的数据进行解析,目前提供可解析的协议包括:
Ethernet、SLL、ARP、IPv4、IPv6、TCP、UDP、ICMPv4、ICMPv6、IGMPv2、PPPoE、PTP、LLDP等。
在此基础上,本系统在类库中增加了PPP、LCP等协议。
为了能够对应用层协议进行分析,本系统设计了ApplicationProtocol类库,目前提供HTTP、FTP、DNS、SMTP、POP3协议的解析。
监听程序的基本实现步骤如下图所示。
图4.20监听程序实现步骤
在抓包软件中有两种监听模式:
标准模式和混杂模式。
在标准模式中,主机只接收目的地址是自己的数据包,丢弃目的地址不是自己的其他广播数据包。
而在混杂模式下,不论数据包的目的地址是不是该主机,主机均会接收。
分析经过主机的所有数据包有助于网络诊断,所以通常在进行抓包时,选择混杂模式。
此外,抓包软件需要设置合理的超时时间,即通过Winpcap每隔多久向程序推送一次监听到的数据。
超时时间如果设置过短,就可能因为频繁提交数据引起丢包,造成额外的性能开销;
而如果设置过长则会造成界面响应缓慢。
本系统经过多次测试在程序中将超时时间设置为1秒。
抓包软件支持打开*.pcap类型抓包文件,并可以将所抓取的数据保存为*.pcap格式文件。
本系统直接通过Sharppcap.dll调用Winpcap内置的数据包存取方式,这样就可以使用Wireshark等一些其他抓包工具打开这些文件,而不是只局限于本软件。
4.5.3故障案例匹配设计
在故障源定位模块中,新旧案例之间进行匹配时,最重要的是获得相关属性指标的权重及加权KNN算法与系统的结合应用。
1.确定属性指标权重
本文请五位运营商内部专家对各项指标权重进行评价。
故障信息主要包括用户投诉信息及预处理信息,这两项所占权重比例如表4.5所示。
表4.5故障信息权重专家评定结果表
属性指标
专家1
专家2
专家3
专家4
专家5
均值
用户投诉信息
25
30
27
20
26.4
预处理信息
75
70
73
80
73.6
总和
100
由表4.5可知,用户投诉信息所占权重比例为26.4%,预处理信息为73.6%。
这是由于用户投诉信息仅是对故障的直观描述,对故障处理的帮助不大,预处理信息为分公司用户对故障进行抓包分析等操作后得到的故障IP地址等信息,在对故障分析、处理时其关键作用。
其中预处理信息包括投诉名称、投诉地点、故障描述等属性指标,各项指标所占权重比例如表4.6所示。
表4.6用户投诉信息权重专家评定结果表
故障类型
18
28
24.2
投诉名称
5
4
6
7
5.2
投诉地点
3
4.2
网络环境
10
8
9
7.4
游戏类型
视频类型
7.8
系统类型
12
13
故障描述
35
40
33
33.6
由表4.6可知在用户投诉信息中,故障类型和故障描述所占权重较大。
但是由于故障描述信息是对故障现象的一段描述文字,而汉语是意会性语言,所以本文在对故障描述信息进行匹配时,判断两段文字的重复率是否达到50%,如果重复率高于50%,则判定两段文字相似。
这种判断方法会降低匹配的准确性,所以本文适当降低了故障描述信息所占权重。
最后确定用户投诉信息中各项属性指标所占权重为:
故障类型占30%,投诉名称占7%,投诉地点占6%,网络环境占7%,游戏类型占10%,视频类型占10%,系统类型占10%,故障描述占20%。
预处理信息包括故障IP地址、所走出口地址、归属厂商三项性能指标,各项指标所占权重比例如表4.7所示。
表4.7预处理信息权重专家评定结果表
故障IP地址
23
所走出口地址
29
归属厂商
50
45
55
48
由表4.7可知,在预处理信息当中,归属厂商所占权重最大,这是因为运营商对故障信息进行处理的最主要目的就是为了得到负责对故障网络节点进行建设、维护的设备厂商,通知相关厂商对故障设备进行处理维护。
在预处理信息中,各项属性指标所占权重为:
故障IP地址占23%,所走出口地址占29%,归属厂商占48%。
2.算法与系统结合
基于权重的KNN分类算法在进行相似度计算时,通过计算新旧案例之间各个属性指标的欧氏距离得到相似度,这要求属性指标均为数值类型,但是互联网业务故障投诉系统中的关键属性指标大多为文字类型,无法进行运算。
所以本系统在进行故障案例匹配时,借用基于权重的KNN分类算法的思想,将新旧案例之间的关键属性指标进行同或加权运算,得到新旧案例之间的相似值,相似值越大,匹配程度越好。
相似值
为:
(4.2)
其中
为用户投诉信息值,
为预处理信息值,
为数据库中同类型案例个数。
用户投诉信息值
的取值为:
(4.3)
在公式4.3中,所有数据中下标为
的数据为当前故障的数据,下标为
的数据库中第i个历史案例的数据。
例如,
为当前故障的投诉名称(故障应用名称),
为数据库中第i个历史案例的投诉名称。
为故障类型,
为投诉地点,
为网络环境,
为游戏类型,
为系统类型,
为视频类型,
为故障描述。
其中,对于故障类型、网络环境等规则属性指标(即该属性指标的值由系统设置,用户只能够选择,无法自由输入)直接判断各项属性的取值是否相同,而对于投诉名称、故障描述这两项不规则属性指标(即该属性指标的值可由用户自由输入)判断新旧故障间该属性指标取值的重复率是否达到50%,如果重复率高于50%,则判定新旧故障间该属性指标相同。
预处理信息值
(4.4)
在公式4.4中
为故障解析IP地址,
为所走出口地址,
为归属厂商。
在将数据库中各个历史案例进行加权运算后,取加权值最大的案例作为匹配案例:
(4.5)
最后,查询最佳匹配案例的故障原因、处理过程、处理结果等信息,给出故障诊断建议。
3.案例匹配实现
在实际进行新旧案例匹配时,案例匹配的流程如下图所示:
图4.21故障案例匹配流程
如图4.21所示,匹配过程如下:
(1)将所收集到的故障信息输入系统,根据“故障类型”项在数据库中筛选与其故障类型相同的历史案例,并将历史案例的工单编号、故障描述、解析IP地址等信息存入一个二维数组
当中。
(2)对故障信息的各属性指标逐个进行判断,如果该指标为规则数据(即该属性指标的值由系统设置,用户只能够选择,无法自由输入),则判断新旧案例间该属性指标的值是否相同,若相同,则该指标的相似度为1,若不同,则该指标的相似度为0;
如果该指标为不规则数据(即该属性指标的值由系统设置,用户只能够选择,无法自由输入),则判断新旧案例间该属性指标的重复率是否达到50%,若达到,则该指标的相似度为1,若未达到,则该指标的相似度为0。
(3)根据步骤
(2)中的方法,将数组
中的数据逐个
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 互联网 业务 故障 投诉 系统 设计 实现