CN107769957A - 一种域名***故障原因分析方法和装置 - Google Patents
一种域名***故障原因分析方法和装置 Download PDFInfo
- Publication number
- CN107769957A CN107769957A CN201710766110.2A CN201710766110A CN107769957A CN 107769957 A CN107769957 A CN 107769957A CN 201710766110 A CN201710766110 A CN 201710766110A CN 107769957 A CN107769957 A CN 107769957A
- Authority
- CN
- China
- Prior art keywords
- dns
- bag
- exception
- packet
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/06—Generation of reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种域名***故障原因分析方法和装置。涉及计算机网络领域;解决了人工抓取、判断故障方式造成的效率低下、人工成本高、精准性差的问题。该方法包括:监测域名***DNS进程;在DNS进程异常退出时,开启抓包,抓取异常请求包;对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元。本发明提供的技术方案适用于DNS软件开发应用,实现了***自动精确的故障定位。
Description
技术领域
本发明涉及计算机网络领域,尤其涉及一种域名***(DNS)故障原因分析方法和装置。
背景技术
DNS解析作为互联网访问的入口,在网络访问过程中起到至关重要的作用。出于提升网络服务质量和可用性的目的,目前很多公司或组织选择自研或者在开源DNS软件基础上进行二次开发,使DNS软件满足特殊的需求。在自研和二次开发过程中,如果不能清楚了解所有DNS的协议规范和技术特性,存在很大风险发生由于疑似异常请求报文导致程序异常对出的故障,而由于对问题的预见性不足,此时程序很可能没有Core Dump或者准备详细的错误日志,给异常包的定位和故障原因确认带来巨大困难。
现有的故障定位方式一般由人工抓取、判定来完成,存在如下缺陷:
a)人工抓取异常报文和确认原因,效率差、人工成本高;
b)人工判定故障时间、手动停止抓包,再根据监控的告警时间确认异常请求包的范围,精准性差,常在分钟级,影响定位效率,且抓取的数据包文件会非常大,影响后续过滤处理。
发明内容
本发明旨在解决上面描述的问题。
根据本发明的第一方面,提供了一种DNS故障原因分析方法,包括:
监测DNS进程;
在DNS进程异常退出时,开启抓包,抓取异常请求包;
对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元。
优选的,对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元的步骤包括:
(1)获取所述异常请求包中的每个最小业务单元;
(2)选择所述异常请求包中的一个最小业务单元,替换所述标准正常数据包中的相应最小业务单元,得到重组请求包:
(3)发送所述重组请求包给DNS软件;
(4)在所述DNS软件接收到所述重组请求包退出后,判定步骤(2)中选择的最小业务单元为问题业务单元;
(5)重复步骤(1)-(4),直至遍历所述异常请求包中的全部最小业务单元;
(6)分析确定的至少一个问题业务单元,得到唯一匹配所述异常请求包的异常包唯一特征规则。
优选的,所述监测域名***DNS进程的步骤包括:
监测是否发生DNS进程退出;
在监测到发生DNS进程退出时:
过滤操作日志,和/或,
过滤***日志和/或报错日志;
在过滤操作日志发现异常操作时,和/或,
在过滤***日志和/或报错日志发现指示DNS进程异常退出的报错信息时,
判定发生DNS进程异常退出。
优选的,所述在DNS进程异常退出时,开启抓包,抓取异常请求包的步骤包括:
抓取数据包,所述数据包包括请求包和应答包;
过滤***日志和错误日志,获取DNS进程退出时报错信息的第一时间;
分析所述第一时间前的请求报文,筛选得到疑似异常请求报文;
将所述疑似异常请求报文发送给所述异常退出的DNS进程,检测所述疑似异常请求报文中的各个数据包是否会导致所述DNS进程的异常退出;
对于会导致所述DNS进程的异常退出的数据包,标记为异常请求包。
优选的,分析所述第一时间前的请求报文,筛选得到疑似异常请求报文的步骤包括:
在所述第一时间之前的最后一个请求报文是所述第一时间之前第一个只有请求包且没有应答包的报文时,提取所述请求报文作为疑似异常请求报文;
在第一个只有请求包且没有应答包的请求报文在所述第一时间之后时,分别提取所述第一时间之前的最后N个请求报文和最早的N个只有请求包且没有应答包的请求报文,作为疑似异常请求报文,N为正整数;
在不存在报错信息且无法确定所述第一时间时,提取最早的N个没有应答报文的请求报文作为疑似异常请求报文;
在不存在报错信息、无法确定所述第一时间且不存在只有请求包没有应答包的请求报文时,获取本地解析失败的第二时间,提取所述第二时间之后的N个请求包,作为疑似异常请求报文。
优选的,抓取数据包的步骤之前,还包括:
自中央服务器获取当前已经开启抓包的DNS服务器列表;
在开启抓包的DNS服务器对应的域名服务器记录NS的数量超过预置的抓包阈值时,不开启本DNS服务器的抓包操作;
在开启抓包的DNS服务器对应的域名服务器记录NS的数量没有超过所述预置的抓包阈值时,开启本DNS服务器的抓包操作,并通知中央服务器本DNS服务器已开启抓包,提示所述中央服务器更新已开启抓包的DNS服务器列表。
优选的,抓取数据包的步骤之后,还包括
每隔一个预置的验证周期,就向本DNS服务器进行请求,确认正常获取解析结果;
在能够正常获取解析结果时,判定未再次发生DNS进程异常退出,继续抓包;
在不能够正常获取解析结果时,判定再次发生DNS进程异常退出,开始分析获取疑似异常请求报文。
优选的,对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元的步骤之后,还包括:
发送分析报告,在所述分析报告中至少携带以下信息中的任一或任意多项:
异常请求包,问题业务单元,发生异常的DNS软件版本,版本差异文档(changelog),异常包唯一特征规则。
优选的,对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元的步骤之后,还包括:
拦截与所述异常包唯一特征规则匹配的请求包。
根据本发明的另一方面,还提供了一种DNS故障原因分析装置,包括:
进程监测模块,用于监测DNS进程;
抓包模块,用于在DNS进程异常退出时,开启抓包,抓取异常请求包;
故障分析定位模块,用于对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元。
优选的,所述故障分析定位模块包括:
数据包拆分单元,用于获取所述异常请求包中的每个最小业务单元;
重组单元,用于选择所述异常请求包中的一个最小业务单元,替换所述标准正常数据包中的相应最小业务单元,得到重组请求包:
请求包发送单元,用于发送所述重组请求包给DNS软件;
异常判定单元,用于在所述DNS软件接收到所述重组请求包退出后,判定所述重组单元选择的最小业务单元为问题业务单元;
规则生成单元,用于控制所述数据包拆分单元、所述重组单元、所述请求发送单元和所述异常判定单元重复执行问题业务单元检测,直至遍历所述异常请求包中的全部最小业务单元,分析确定的至少一个问题业务单元,得到唯一匹配所述异常请求包的异常包唯一特征规则。
优选的,所述进程监测模块包括:
退出监测单元,用于监测是否发生DNS进程退出;
日志分析单元,用于在监测到发生DNS进程退出时:
过滤操作日志,和/或,
过滤***日志和/或报错日志;
异常判定单元,用于在过滤操作日志发现异常操作时,和/或,
在过滤***日志和/或报错日志发现指示DNS进程异常退出的报错信息时,
判定发生DNS进程异常退出。
优选的,所述抓包模块包括:
第一抓取单元,用于抓取数据包,所述数据包包括请求包和应答包;
报错信息解析单元,用于过滤***日志和错误日志,获取DNS进程退出时报错信息的第一时间;
疑似异常请求报文筛选单元,用于分析所述第一时间前的请求报文,筛选得到疑似异常请求报文;
异常验证单元,用于将所述疑似异常请求报文发送给所述异常退出的DNS进程,检测所述疑似异常请求报文中的各个数据包是否会导致所述DNS进程的异常退出;
异常请求包确定单元,用于对于会导致所述DNS进程的异常退出的数据包,标记为异常请求包。
本发明提供了一种DNS故障原因分析方法和装置,对DNS进程进行监测,在发现DNS进程异常退出时,首先抓取导致异常退出出现的异常请求包,然后再在异常请求包中进一步定位得到导致异常的最小业务单位,实现了***自动精确的故障定位,解决了人工抓取、判断故障方式造成的效率低下、人工成本高、精准性差的问题。
参照附图来阅读对于示例性实施例的以下描述,本发明的其他特性特征和优点将变得清晰。
附图说明
并入到说明书中并且构成说明书的一部分的附图示出了本发明的实施例,并且与描述一起用于解释本发明的原理。在这些附图中,类似的附图标记用于表示类似的要素。下面描述中的附图是本发明的一些实施例,而不是全部实施例。对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,可以根据这些附图获得其他的附图。
图1示例性地示出了本发明的实施例一提供的一种DNS故障原因分析方法的流程;
图2示例性地示出了本发明的实施例二提供的一种DNS故障原因分析装置的结构;
图3示例性的示出了图2中故障分析定位模块203的结构;
图4示例性的示出了图2中进程监测模块201的结构;
图5示例性的示出了图2中抓包模块202的结构。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互任意组合。
现有的故障定位方式一般由人工抓取、判定来完成,存在如下缺陷:
a)人工抓取异常报文和确认原因,效率差、人工成本高;
b)人工判定故障时间、手动停止抓包,再根据监控的告警时间确认异常请求包的范围,精准性差,常在分钟级,影响定位效率,且抓取的数据包文件会非常大,影响后续过滤处理。
为了解决上述问题,本发明的实施例提供了一种DNS故障原因分析方法和装置,对DNS进程进行监测,在发现DNS进程异常退出时,首先抓取导致异常退出出现的异常请求包,然后再在异常请求包中进一步定位得到导致异常的最小业务单位,实现了***自动精确的故障定位,解决了人工抓取、判断故障方式造成的效率低下、人工成本高、精准性差的问题。
首先结合附图,对本发明的实施例一进行说明。
本发明实施例提供了一种DNS故障原因分析方法,使用该方法完成DNS故障的自动发现与故障定位的流程如图1所示,包括:
步骤101、监测域名***DNS进程;
本步骤具体包括:
1、监测是否发生DNS进程退出;
2、在监测到发生DNS进程退出时:
过滤操作日志,和/或,
过滤***日志和/或报错日志;
3、在过滤操作日志发现异常操作时,和/或,
在过滤***日志和/或报错日志发现指示DNS进程异常退出的报错信息时,
判定发生DNS进程异常退出。
异常操作主要包括restart、stop、杀掉进程等操作。
步骤102、在DNS进程异常退出时,开启抓包,抓取异常请求包;
本步骤具体包括:
1、抓取数据包,所述数据包包括请求包和应答包;
2、过滤***日志和错误日志,获取DNS进程退出时报错信息的第一时间;
3、分析所述第一时间前的请求报文,筛选得到疑似异常请求报文;
具体的,在所述第一时间之前的最后一个请求报文是所述第一时间之前第一个只有请求包且没有应答包的报文时,提取所述请求报文作为疑似异常请求报文;
在第一个只有请求包且没有应答包的请求报文在所述第一时间之后时,分别提取所述第一时间之前的最后N个请求报文和最早的N个只有请求包且没有应答包的请求报文,作为疑似异常请求报文,N为正整数;
在不存在报错信息且无法确定所述第一时间时,提取最早的N个没有应答报文的请求报文作为疑似异常请求报文;
在不存在报错信息、无法确定所述第一时间且不存在只有请求包没有应答包的请求报文时,获取本地解析失败的第二时间,提取所述第二时间之后的N个请求包,作为疑似异常请求报文。
4、将所述疑似异常请求报文发送给所述异常退出的DNS进程,检测所述疑似异常请求报文中的各个数据包是否会导致所述DNS进程的异常退出;
5、对于会导致所述DNS进程的异常退出的数据包,标记为异常请求包。
优选的,在进行抓取数据包的操作之前,还可以先确认当前网络中DNS服务器的工作情况,在执行故障检测抓包的DNS服务器过多时在本DNS服务器一侧暂不执行抓包,以保障正常业务的进行,具体的:
1、自中央服务器获取当前已经开启抓包的DNS服务器列表。
2、在开启抓包的DNS服务器对应的域名服务器记录NS的数量超过预置的抓包阈值时,不开启本DNS服务器的抓包操作;抓包阈值可根据网络负载情况设置。
3、在开启抓包的DNS服务器对应的域名服务器记录NS的数量没有超过所述预置的抓包阈值时,开启本DNS服务器的抓包操作,并通知中央服务器本DNS服务器已开启抓包,提示所述中央服务器更新已开启抓包的DNS服务器列表。
优选的,在开始抓包后,同步的,还可以继续对发生了DNS进程异常退出的DNS服务器的工作状态进行检测,并根据检测结果,判定是否需要继续执行抓包操作,具体的:
1、每隔一个预置的验证周期,就向本DNS服务器进行请求,确认正常获取解析结果;
2、在能够正常获取解析结果时,判定未再次发生DNS进程异常退出,继续抓包;
3、在不能够正常获取解析结果时,判定再次发生DNS进程异常退出,开始分析获取疑似异常请求报文。
步骤103、对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元;
本步骤具体包括:
(1)获取所述异常请求包中的每个最小业务单元;
(2)选择所述异常请求包中的一个最小业务单元,替换所述标准正常数据包中的相应最小业务单元,得到重组请求包:
(3)发送所述重组请求包给DNS软件;
(4)在所述DNS软件接收到所述重组请求包退出后,判定步骤(2)中选择的最小业务单元为问题业务单元;
(5)重复步骤(1)-(4),直至遍历所述异常请求包中的全部最小业务单元;
(6)分析确定的至少一个问题业务单元,得到唯一匹配所述异常请求包的异常包唯一特征规则。
步骤104、发送分析报告;
本发明实施例中,在所述分析报告中至少携带以下信息中的任一或任意多项:
异常请求包,问题业务单元,发生异常的DNS软件版本,版本差异文档changelog,异常包唯一特征规则。
根据该异常包唯一特征规则,能够过滤出匹配该异常包唯一特征规则的请求包,对这部分请求包进行拦截处理,能够有效的避免新的异常出现。
下面结合附图,对本发明的实施例二进行说明。
本发明实施例提供了一种域名***故障原因分析装置,其结构如图2所示,包括:
进程监测模块201,用于监测DNS进程;
抓包模块202,用于在DNS进程异常退出时,开启抓包,抓取异常请求包;
故障分析定位模块203,用于对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元。
优选的,所述故障分析定位模块203的结构如图3所示,包括:
数据包拆分单元301,用于获取所述异常请求包中的每个最小业务单元;
重组单元302,用于选择所述异常请求包中的一个最小业务单元,替换所述标准正常数据包中的相应最小业务单元,得到重组请求包:
请求包发送单元303,用于发送所述重组请求包给DNS软件;
异常判定单元304,用于在所述DNS软件接收到所述重组请求包退出后,判定所述重组单元选择的最小业务单元为问题业务单元;
规则生成单元305,用于控制所述数据包拆分单元、所述重组单元、所述请求发送单元和所述异常判定单元重复执行问题业务单元检测,直至遍历所述异常请求包中的全部最小业务单元,分析确定的至少一个问题业务单元,得到唯一匹配所述异常请求包的异常包唯一特征规则。
优选的,所述进程监测模块201的结构如图4所示,包括:
退出监测单元401,用于监测是否发生DNS进程退出;
日志分析单元402,用于在监测到发生DNS进程退出时:
过滤操作日志,和/或,
过滤***日志和/或报错日志;
异常判定单元403,用于在过滤操作日志发现异常操作时,和/或,
在过滤***日志和/或报错日志发现指示DNS进程异常退出的报错信息时,
判定发生DNS进程异常退出。
优选的,所述抓包模块202的结构如图5所示,包括:
第一抓取单元501,用于抓取数据包,所述数据包包括请求包和应答包;
报错信息解析单元502,用于过滤***日志和错误日志,获取DNS进程退出时报错信息的第一时间;
疑似异常请求报文筛选单元503,用于分析所述第一时间前的请求报文,筛选得到疑似异常请求报文;
异常验证单元504,用于将所述疑似异常请求报文发送给所述异常退出的DNS进程,检测所述疑似异常请求报文中的各个数据包是否会导致所述DNS进程的异常退出;
异常请求包确定单元505,用于对于会导致所述DNS进程的异常退出的数据包,标记为异常请求包。
下面结合附图,对本发明的实施例三进行说明。
本发明实施例提供了一种DNS故障原因分析方法,判断DNS软件进行是否存在因为DNS疑似异常请求报文导致的异常退出,发现进程异常退出后自动开启抓包程序并同时探测DNS可用性,使用穷举法自动发现故障原因,为后续丢弃异常包的应急处理和故障原因定位提供依据。可降低90%异常包确认时间和95%以上原因定位时间。
本发明实施例中进行故障定位的流程如下:
1、判断DNS出现异常,达到抓包分析条件:
i.监控发现DNS进程退出,监控程序触发进行抓包判定;
ii.进行抓包条件判定,确认DNS进程是否为异常退出,如果为异常退出继续判定,如果判定为正常退出则不进行后续抓包条件判定及抓包。判定方法为:
A.过滤操作日志,如果有异常操作,如:restart、stop、杀掉进程等操作,则认定为正常退出,否则继续判定;
B.过滤***日志和报错日志,如果出现异常进程退出指定的报错信息,则认定为异常退出,继续下一步判定;否则认定为正常退出;
iii.判定当前已经开启抓包的DNS服务器数量,如果超过抓包阈值的NS对应的DNS服务器已经开始抓包,则不继续下一步抓包操作;如果没有达到抓包阈值,则进行下一步抓取疑似异常报文操作。抓包阈值可设置为NS数量的一半。
A.每台DNS服务器开始抓包前均像中央服务器询问已开启抓包的DNS服务器占比;
B.确认没有超过半数,则继续抓包步骤,并向中央服务器发送消息,说明此DNS服务器开始抓包步骤;
C.中央服务器更新已开启抓包步骤的DNS服务器列表,并计算新的占比情况。
2、抓取疑似异常报文:
i.开启抓包程序,抓取bind的服务端口请求包和应答包(udp和tcp),保留最近3min的抓包结果;
ii.每隔一个预置的验证周期(例如1毫秒)向本DNS服务器进行请求,确认能否正常获取解析结果,如果能获取解析结果,说明本机未再次发生进程异常退出,继续抓包;如果出现解析失败,说明本机再次发生进行异常退出,则停止抓包,进行疑似异常请求报文分析;
iii.过滤***日志和错误日志,获取进行退出时报错信息的第一时间,在抓取的数据包中,确认在此第一时间之前的最后一个请求报文是否为第一个只有请求包且没有应答包的报文,如果是,则此报文认定为疑似异常请求报文,如果没有符合的数据包则继续确认;
iv.如果存在报错信息,但找到的第一个只有请求包且没有应答包的报文的数据与报错信息不符(第一时间前不存在只有请求包没有应答名的报文),则分别获取第一时间之前的最后N个报文(在发生错误信息的第一时间前后的报文存在疑似异常请求报文的可能性较高)和最早的N个没有应答包报文的请求报文,认定为疑似异常请求报文,如果没有符合的数据包则继续确认;
v.如果不存在报错信息,则将最早的N个没有应答包报文的请求报文,认定为疑似异常请求报文;
vi.如果不存在报错信息及没有应答报文的请求报文,则获取本地解析失败的时间,在解析失败时间的最后N个请求包,为疑似异常请求报文。所述解析失败时间是两次解析的间隔时间,在不存在报错信息时,在解析失败时间内出现疑似异常请求报文的可能性较大。
其中,N为正整数,为经验配置值。
3、确认异常请求包:
i.获取疑似异常请求报文和抓取的全部数据包,包括请求包和应答包;
ii.通过发包程序将疑似异常请求报文的数据包依次发送给所有待确认的DNS软件(可能是多个分布于不同平台的DNS软件,也可以是同一DNS软件的不同历史版本),并判定每个数据包是否会影响线上服务的DNS进程,造成DNS进程异常退出,如果可以导致异常退出,则确认此数据包为异常请求包,并获取所有DNS软件版本的退出情况;如果均不会导致进程异常退出,则继续下一步;一般发送的数据包为请求包。
iii.获取抓取数据包中的所有请求报文,通过发包程序将疑似异常请求报文依次发送给所有待确认的DNS软件,并判定每个数据包是否会影响线上服务的DNS软件异常退出,如果可以导致退出,则确认此数据包为异常请求包,并获取所有DNS软件版本的退出情况及DNS软件版本的changelog;如果均不会导致进程异常退出,发送告警信息给管理员,提示无法获取异常数据包,需要人工介入。
4、确认请求包引起异常的原因:
i.获取异常请求包;
ii.启动数据包重组程序,获取异常请求包的每一个最小业务单元的信息,并逐个将标准正常数据包中的对应信息进行替换;将替换后的重组请求包发送给DNS软件,判定是否会造成DNS进程异常退出,会导致异常退出的重组请求包对应的最小业务单元即为问题业务单元,记录相关信息;如果所有都正常,则发送告警信息给管理员,发送异常数据包,提示无法获取异常原因,需要人工介入。
最小业务单元包括数据包中的不同类型的报文信息,包括但不限于:IP、请求域名、记录类型、flags、协议信息、edns0、DNSSEC等等。即,可按照上述信息的角度划分最小业务单元。
iii.将异常请求包与正常数据包库中的请求包、本地抓取的数据包进行特征分析,分析出可唯一匹配成异常数据包的异常包唯一特征规则;正常数据包库为日常积累的可正常处理的数据包内容。
5、发送分析报告:
分析报告中至少携带以下信息中的任一或任意多项:
异常数据包、问题业务单元、发生异常的DNS软件版本及changelog、异常包唯一特征规则。
分析报告可上报专用于记录故障分析结果的***单元,也可以直接发送给管理员,以向管理员发出告警,提醒管理员进行故障排除。
本发明的实施例提供了一种DNS故障原因分析方法和装置,对DNS进程进行监测,在发现DNS进程异常退出时,首先抓取导致异常退出出现的异常请求包,然后再在异常请求包中进一步定位得到导致异常的最小业务单位,实现了***自动精确的故障定位,解决了人工抓取、判断故障方式造成的效率低下、人工成本高、精准性差的问题。降低90%异常包确认时间和95%的定位时间。
上面描述的内容可以单独地或者以各种方式组合起来实施,而这些变型方式都在本发明的保护范围之内。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制。尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (13)
1.一种域名***故障原因分析方法,其特征在于,包括:
监测域名***DNS进程;
在DNS进程异常退出时,开启抓包,抓取异常请求包;
对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元。
2.根据权利要求1所述的域名***故障原因分析方法,其特征在于,对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元的步骤包括:
(1)获取所述异常请求包中的每个最小业务单元;
(2)选择所述异常请求包中的一个最小业务单元,替换所述标准正常数据包中的相应最小业务单元,得到重组请求包:
(3)发送所述重组请求包给DNS软件;
(4)在所述DNS软件接收到所述重组请求包退出后,判定步骤(2)中选择的最小业务单元为问题业务单元;
(5)重复步骤(1)-(4),直至遍历所述异常请求包中的全部最小业务单元;
(6)分析确定的至少一个问题业务单元,得到唯一匹配所述异常请求包的异常包唯一特征规则。
3.根据权利要求1所述的域名***故障原因分析方法,其特征在于,所述监测域名***DNS进程的步骤包括:
监测是否发生DNS进程退出;
在监测到发生DNS进程退出时:
过滤操作日志,和/或,
过滤***日志和/或报错日志;
在过滤操作日志发现异常操作时,和/或,
在过滤***日志和/或报错日志发现指示DNS进程异常退出的报错信息时,
判定发生DNS进程异常退出。
4.根据权利要求1所述的域名***故障原因分析方法,其特征在于,所述在DNS进程异常退出时,开启抓包,抓取异常请求包的步骤包括:
抓取数据包,所述数据包包括请求包和应答包;
过滤***日志和错误日志,获取DNS进程退出时报错信息的第一时间;
分析所述第一时间前的请求报文,筛选得到疑似异常请求报文;
将所述疑似异常请求报文发送给所述异常退出的DNS进程,检测所述疑似异常请求报文中的各个数据包是否会导致所述DNS进程的异常退出;
对于会导致所述DNS进程的异常退出的数据包,标记为异常请求包。
5.根据权利要求4所述的域名***故障原因分析方法,其特征在于,分析所述第一时间前的请求报文,筛选得到疑似异常请求报文的步骤包括:
在所述第一时间之前的最后一个请求报文是所述第一时间之前第一个只有请求包且没有应答包的报文时,提取所述请求报文作为疑似异常请求报文;
在第一个只有请求包且没有应答包的请求报文在所述第一时间之后时,分别提取所述第一时间之前的最后N个请求报文和最早的N个只有请求包且没有应答包的请求报文,作为疑似异常请求报文,N为正整数;
在不存在报错信息且无法确定所述第一时间时,提取最早的N个没有应答报文的请求报文作为疑似异常请求报文;
在不存在报错信息、无法确定所述第一时间且不存在只有请求包没有应答包的请求报文时,获取本地解析失败的第二时间,提取所述第二时间之后的N个请求包,作为疑似异常请求报文。
6.根据权利要求4所述的域名***故障原因分析方法,其特征在于,抓取数据包的步骤之前,还包括:
自中央服务器获取当前已经开启抓包的DNS服务器列表;
在开启抓包的DNS服务器对应的域名服务器记录NS的数量超过预置的抓包阈值时,不开启本DNS服务器的抓包操作;
在开启抓包的DNS服务器对应的域名服务器记录NS的数量没有超过所述预置的抓包阈值时,开启本DNS服务器的抓包操作,并通知中央服务器本DNS服务器已开启抓包,提示所述中央服务器更新已开启抓包的DNS服务器列表。
7.根据权利要求4所述的域名***故障原因分析方法,其特征在于,抓取数据包的步骤之后,还包括
每隔一个预置的验证周期,就向本DNS服务器进行请求,确认正常获取解析结果;
在能够正常获取解析结果时,判定未再次发生DNS进程异常退出,继续抓包;
在不能够正常获取解析结果时,判定再次发生DNS进程异常退出,开始分析获取疑似异常请求报文。
8.根据权利要求2所述的域名***故障原因分析方法,其特征在于,对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元的步骤之后,还包括:
发送分析报告,在所述分析报告中至少携带以下信息中的任一或任意多项:
异常请求包,问题业务单元,发生异常的DNS软件版本,版本差异文档changelog,异常包唯一特征规则。
9.根据权利要求2所述的域名***故障原因分析方法,其特征在于,对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元的步骤之后,还包括:
拦截与所述异常包唯一特征规则匹配的请求包。
10.一种域名***故障原因分析装置,其特征在于,包括:
进程监测模块,用于监测DNS进程;
抓包模块,用于在DNS进程异常退出时,开启抓包,抓取异常请求包;
故障分析定位模块,用于对比所述异常请求包与标准正常数据包,确定所述异常请求包中问题业务单元。
11.根据权利要求10所述的域名***故障原因分析装置,其特征在于,所述故障分析定位模块包括:
数据包拆分单元,用于获取所述异常请求包中的每个最小业务单元;
重组单元,用于选择所述异常请求包中的一个最小业务单元,替换所述标准正常数据包中的相应最小业务单元,得到重组请求包:
请求包发送单元,用于发送所述重组请求包给DNS软件;
异常判定单元,用于在所述DNS软件接收到所述重组请求包退出后,判定所述重组单元选择的最小业务单元为问题业务单元;
规则生成单元,用于控制所述数据包拆分单元、所述重组单元、所述请求发送单元和所述异常判定单元重复执行问题业务单元检测,直至遍历所述异常请求包中的全部最小业务单元,分析确定的至少一个问题业务单元,得到唯一匹配所述异常请求包的异常包唯一特征规则。
12.根据权利要求10所述的域名***故障原因分析装置,其特征在于,所述进程监测模块包括:
退出监测单元,用于监测是否发生DNS进程退出;
日志分析单元,用于在监测到发生DNS进程退出时:
过滤操作日志,和/或,
过滤***日志和/或报错日志;
异常判定单元,用于在过滤操作日志发现异常操作时,和/或,
在过滤***日志和/或报错日志发现指示DNS进程异常退出的报错信息时,
判定发生DNS进程异常退出。
13.根据权利要求10所述的域名***故障原因分析装置,其特征在于,所述抓包模块包括:
第一抓取单元,用于抓取数据包,所述数据包包括请求包和应答包;
报错信息解析单元,用于过滤***日志和错误日志,获取DNS进程退出时报错信息的第一时间;
疑似异常请求报文筛选单元,用于分析所述第一时间前的请求报文,筛选得到疑似异常请求报文;
异常验证单元,用于将所述疑似异常请求报文发送给所述异常退出的DNS进程,检测所述疑似异常请求报文中的各个数据包是否会导致所述DNS进程的异常退出;
异常请求包确定单元,用于对于会导致所述DNS进程的异常退出的数据包,标记为异常请求包。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710766110.2A CN107769957B (zh) | 2017-08-30 | 2017-08-30 | 一种域名***故障原因分析方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710766110.2A CN107769957B (zh) | 2017-08-30 | 2017-08-30 | 一种域名***故障原因分析方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107769957A true CN107769957A (zh) | 2018-03-06 |
CN107769957B CN107769957B (zh) | 2018-07-06 |
Family
ID=61265906
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710766110.2A Active CN107769957B (zh) | 2017-08-30 | 2017-08-30 | 一种域名***故障原因分析方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107769957B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109819060A (zh) * | 2018-12-15 | 2019-05-28 | 深圳壹账通智能科技有限公司 | 异常检测方法、装置、计算机装置及存储介质 |
CN111131756A (zh) * | 2019-12-26 | 2020-05-08 | 视联动力信息技术股份有限公司 | 一种基于视联网的异常检测方法、装置、设备及介质 |
CN113055225A (zh) * | 2021-02-08 | 2021-06-29 | 网宿科技股份有限公司 | 网络故障分析数据的获取方法、终端及服务器 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7853719B1 (en) * | 2002-02-11 | 2010-12-14 | Microsoft Corporation | Systems and methods for providing runtime universal resource locator (URL) analysis and correction |
CN103716198A (zh) * | 2013-07-05 | 2014-04-09 | 中国南方电网有限责任公司 | 数据网络质量自动拨测方法及*** |
CN104880222A (zh) * | 2015-04-28 | 2015-09-02 | 国家电网公司 | 基于3g无线通信的二次设备状态监测*** |
CN106533722A (zh) * | 2015-09-11 | 2017-03-22 | 北京国双科技有限公司 | 网络监测方法和装置 |
CN106571981A (zh) * | 2016-11-15 | 2017-04-19 | 中国互联网络信息中心 | 一种dns服务器自动化测试方法与*** |
-
2017
- 2017-08-30 CN CN201710766110.2A patent/CN107769957B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7853719B1 (en) * | 2002-02-11 | 2010-12-14 | Microsoft Corporation | Systems and methods for providing runtime universal resource locator (URL) analysis and correction |
CN103716198A (zh) * | 2013-07-05 | 2014-04-09 | 中国南方电网有限责任公司 | 数据网络质量自动拨测方法及*** |
CN104880222A (zh) * | 2015-04-28 | 2015-09-02 | 国家电网公司 | 基于3g无线通信的二次设备状态监测*** |
CN106533722A (zh) * | 2015-09-11 | 2017-03-22 | 北京国双科技有限公司 | 网络监测方法和装置 |
CN106571981A (zh) * | 2016-11-15 | 2017-04-19 | 中国互联网络信息中心 | 一种dns服务器自动化测试方法与*** |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109819060A (zh) * | 2018-12-15 | 2019-05-28 | 深圳壹账通智能科技有限公司 | 异常检测方法、装置、计算机装置及存储介质 |
CN111131756A (zh) * | 2019-12-26 | 2020-05-08 | 视联动力信息技术股份有限公司 | 一种基于视联网的异常检测方法、装置、设备及介质 |
CN111131756B (zh) * | 2019-12-26 | 2022-11-01 | 视联动力信息技术股份有限公司 | 一种基于视联网的异常检测方法、装置、设备及介质 |
CN113055225A (zh) * | 2021-02-08 | 2021-06-29 | 网宿科技股份有限公司 | 网络故障分析数据的获取方法、终端及服务器 |
CN113055225B (zh) * | 2021-02-08 | 2023-12-05 | 网宿科技股份有限公司 | 网络故障分析数据的获取方法、终端及服务器 |
Also Published As
Publication number | Publication date |
---|---|
CN107769957B (zh) | 2018-07-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101201786B (zh) | 一种故障日志监控方法及装置 | |
US8576724B2 (en) | Method, system, and computer program product, for correlating special service impacting events | |
US7266758B2 (en) | Network monitoring program, network monitoring method, and network monitoring apparatus | |
US7058861B1 (en) | Network model audit and reconciliation using state analysis | |
CN107769957B (zh) | 一种域名***故障原因分析方法和装置 | |
US6836798B1 (en) | Network model reconciliation using state analysis | |
GB2456914A (en) | Network management involving cross-checking identified possible root causes of events in different data subsets of events | |
CN107707375B (zh) | 一种定位解析故障的方法和装置 | |
CN108933693B (zh) | 一种域名服务***故障处理方法和*** | |
CN110088744A (zh) | 一种数据库维护方法及其*** | |
CN106708700A (zh) | 一种应用于服务端的运维监控方法和装置 | |
CN107635003A (zh) | ***日志的管理方法、装置及*** | |
US20160352573A1 (en) | Method and System for Detecting Network Upgrades | |
CN114363151A (zh) | 故障检测方法和装置、电子设备和存储介质 | |
CN112350854A (zh) | 一种流量故障定位方法、装置、设备及存储介质 | |
CN111130848B (zh) | 身份验证授权统计aaa的故障检测方法及装置 | |
CN107181721A (zh) | 一种基于日志的信息处理方法及装置 | |
CN111526109B (zh) | 自动检测web威胁识别防御***的运行状态的方法及装置 | |
CN109218050B (zh) | 一种域名***故障处理方法和*** | |
US7421493B1 (en) | Orphaned network resource recovery through targeted audit and reconciliation | |
CN116204386B (zh) | 应用服务关系自动识别及监控方法、***、介质和设备 | |
CN111385157A (zh) | 一种服务器异常检测方法及装置 | |
CN112835780B (zh) | 一种业务检测方法及装置 | |
CN113852984A (zh) | 一种无线终端接入监控***、方法、电子设备及可读存储装置 | |
CN112463572A (zh) | 一种跨境多服务拨测的软件测试***及其方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CP01 | Change in the name or title of a patent holder | ||
CP01 | Change in the name or title of a patent holder |
Address after: 100015 5 floor, block E, 201 IT tower, electronic city, 10 Jiuxianqiao Road, Chaoyang District, Beijing. Patentee after: Guizhou Baishan cloud Polytron Technologies Inc Address before: 100015 5 floor, block E, 201 IT tower, electronic city, 10 Jiuxianqiao Road, Chaoyang District, Beijing. Patentee before: Guizhou white cloud Technology Co., Ltd. |