CN111030888B - 域名系统dns容量测量方法、装置、设备及介质 - Google Patents

Abstract

本发明公开了一种域名系统DNS容量测量方法、装置、设备及介质。该方法包括：获取目标域名系统DNS的历史日志信息；提取历史日志信息中的至少一个域名及其对应的时间戳；根据至少一个域名及其对应的时间戳，生成测试脚本；利用测试脚本，向目标DNS发送请求信息，以使目标DNS解析请求信息；接收目标DNS的解析结果，根据解析结果计算第一预设指标；当第一预设指标满足第一预设条件时，将目标DNS对应的每秒查询率QPS作为目标DNS的实际容量。根据本发明实施例，能够在尽可能真实的模拟现网环境下，测量目标域名系统DNS的实际容量。

Description

域名系统DNS容量测量方法、装置、设备及介质

技术领域

本发明属于计算机技术领域，尤其涉及一种域名系统DNS容量测量方法、装置、设备及计算机存储介质。

背景技术

代理域名系统(Domain Name System，DNS)性能劣化的其中一个重要原因是代理DNS的容量超限，目前是直接将代理DNS的理论容量值作为告警和扩充容量的依据。但是代理DNS所处的网络环境复杂，容易出现“容量缩水”的情况，将代理DNS的理论容量值作为阈值则不够准确。

因此，如何测量代理DNS的实际容量是本领域技术人员亟需解决的技术问题。

发明内容

本发明实施例提供一种域名系统DNS容量测量方法、装置、设备及计算机可读存储介质，能够在尽可能真实的模拟现网环境下，测量目标域名系统DNS的实际容量。

第一方面，本发明实施例提供一种域名系统DNS方法，方法包括：

获取目标域名系统DNS的历史日志信息；

提取历史日志信息中的至少一个域名及其对应的时间戳；

根据至少一个域名及其对应的时间戳，生成测试脚本；

利用测试脚本，向目标DNS发送请求信息，以使目标DNS解析请求信息；

接收目标DNS的解析结果，根据解析结果计算第一预设指标；

当第一预设指标满足第一预设条件时，将目标DNS对应的每秒查询率QPS作为目标DNS的实际容量。

在第一方面一种可能的实施例中，在利用测试脚本，向目标DNS发送请求信息之前，方法包括：

对测试脚本包括的域名进行增量处理，以增加测试脚本中的域名数量。

利用测试脚本，向目标DNS发送请求信息，具体包括：

利用增量处理后的测试脚本，向目标DNS发送请求信息。

在第一方面一种可能的实施例中，对测试脚本包括的域名进行增量处理，包括：

获取与目标DNS属于同一集群中的其它DNS的历史日志信息；

在测试脚本中增加预设比例的同一集群中的其它DNS的历史日志信息中的域名，以得到增量处理后的测试脚本。

在第一方面一种可能的实施例中，对测试脚本包括的域名进行增量处理，包括：

统计测试脚本中每个域名对应的数量；

按照预设比例向测试脚本中增加测试脚本中域名数量大于预设阈值的域名，以得到增量处理后的测试脚本。

在第一方面一种可能的实施例中，在至少一个域名为至少两个的情况下，根据至少一个域名及其对应的时间戳，生成测试脚本，包括：

根据至少两个域名中的每个域名对应的时间戳，对每两个域名的时间间隔进行压缩，得到压缩后的域名对应的时间戳；

根据至少一个域名及压缩后的域名对应的时间戳，生成测试脚本。

在第一方面一种可能的实施例中，利用测试脚本，向目标DNS发送请求信息，包括：

按照预设时间间隔，利用测试脚本，多次向目标DNS发送请求信息。

在第一方面一种可能的实施例中，当第一预设指标满足第一预设条件时，将目标DNS对应的每秒查询率QPS作为目标DNS的实际容量之后，方法还包括：

计算多个第二预设指标在目标DNS达到实际容量前后的预设时间范围内的数值；

从多个第二预设指标中选取数值满足第二预设条件的候选监控指标，以使用户利用候选监控指标监控目标DNS。

在第一方面一种可能的实施例中，从多个第二预设指标中选取数值满足第二预设条件的候选监控指标，包括：

从多个第二预设指标中确定数值满足第二预设条件的第二预设指标；

从满足第二预设条件的第二预设指标中排除非性能指标，得到候选监控指标。

在第一方面一种可能的实施例中，在从多个第二预设指标中选取数值满足第二预设条件的候选监控指标之后，方法还包括：

利用Pearson相关系数法计算各候选监控指标之间的相关度；

根据各候选监控指标之间的相关度，从各候选监控指标中确定实际监控指标，以使用户利用实际监控指标监控目标DNS。

在第一方面一种可能的实施例中，第一预设指标包括系统解析成功率，对应的，第一预设条件为第一阈值；

和/或，第一预设指标包括吞吐量差值与QPS的比值，对应的第一预设条件为第二阈值。

第二方面，本发明实施例提供了一种DNS容量测量装置，装置包括：

历史日志获取模块，用于获取目标域名系统DNS的历史日志信息；

域名信息提取模块，用于提取历史日志信息中的至少一个域名及其对应的时间戳；

测试脚本生成模块，用于根据至少一个域名及其对应的时间戳，生成测试脚本；

请求模块，用于利用测试脚本，向目标DNS发送请求信息，以使目标DNS解析请求信息；

计算模块，用于接收目标DNS的解析结果，根据解析结果计算第一预设指标；

实际容量确定模块，用于当第一预设指标满足第一预设条件时，将目标DNS对应的每秒查询率QPS作为目标DNS的实际容量。

第三方面，本发明实施例提供了一种DNS容量测量设备，设备包括：处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如第一方面所述的DNS容量测量方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如第一方面所述的DNS容量测量方法。

本发明实施例的DNS容量测量方法、装置、设备及计算机可读存储介质，该方法通过获取目标DNS的历史日志信息，并提取历史日志信息中的域名及其对应的时间戳，从而生成测试脚本。该测试脚本是基于目标DNS的真实历史日志生成的，因此该测试脚本能够尽可能真实的模拟现网环境。进一步的，利用该测试脚本，向目标DNS发送请求，接收并分析目标DNS的解析结果，当第一预设指标满足第一预设条件时，将目标DNS对应的每秒查询率(Queries-per-second，QPS)作为目标DNS的实际容量，从而能够准确的确定目标DNS的实际容量。

进一步的，利用Pearson相关系数法精简了指标监控体系，更方便运维人员监控DNS的运行情况。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一个实施例提供的域名系统DNS容量测量方法的流程示意图；

图2是本发明一个实施例提供的吞吐量曲线示意图；

图3是本发明又一个实施例提供的吞吐量曲线示意图；

图4是本发明一个实施例提供的吞吐量分析示意图；

图5是本发明一个实施例提供的DNS响应时延的示意图；

图6是本发明一个实施例提供的DNS容量测量装置的结构示意图；

图7是本发明一个实施例提供的DNS容量测量设备的结构示意图。

具体实施方式

下面将详细描述本发明的各个方面的特征和示例性实施例，为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本发明进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本发明，并不被配置为限定本发明。对于本领域技术人员来说，本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

一般情况下，代理DNS主要应用于个人计算机或企业级DNS请求的代理，请求量较小，用户类型及喜好集中，现网环境简单，测试终端执行的测试脚本往往仅是针对几个或是几十个常见域名进行反复域名解析请求。但是作为一个运营商，是为全省客户进行DNS请求代理，请求域名数量、种类、响应结果更为复杂。由于请求量巨大，运营商代理DNS分为缓存及递归两级架构，并且部署在不同的物理服务器上。这样划分的好处是，减少了直接DNS递归请求，因为递归请求的代价和时延均远远大于直接请求缓存。但是这也同时增加了应用架构的复杂程度。当用户请求的域名缓存命中率不同时，DNS的容量也大相径庭。在未命中的请求中，域名不存在，没有返回结果的情况占比较高，所以与普通代理DNS压测中请求的域名均有返回结果不同，运营商代理DNS压测过程中请求大量不存在及无结果的域名完全属于正常测试用例。因此压测方案在运营商省级代理DNS场景下显得尤为重要。

申请人发现，现网环境中用户请求的域名多种多样，在递归时，源站权威DNS做出的响应时延也大相径庭，因此，尽可能的模拟现网情况才能测定可用作告警阈值及扩容依据的实际容量。

以某省运营商手机用户代理DNS为例，单节点请求峰值可达80694QPS，既每秒可达8万次解析请求。巨大的访问量已经可以引起量变到容量阈值质变的结果。递归请求的峰值可达18777QPS，而递归请求的时延代价较高，更多的递归请求会快速增加代理DNS的压力。单节点请求的域名不存在的峰值可达2234QPS，既一秒钟有2234个DNS请求的域名是不存在的。客户端对于请求失败的域名往往还会继续按照一定频率发起数次请求，使得请求量恶性循环式突增。由于代理DNS无法将这些没有结果的域名加入缓存，客户端发起的数次请求都需要代理DNS进行递归请求，使得代理DNS容量迅速缩减。

申请人进一步发现，对比用户解析成功率及系统解析成功率，真正由于DNS系统内部问题导致DNS响应失败很少，更多的是由于客户原因导致的DNS响应失败，即客户请求的域名输入错误或域名已过期，这部分请求的占比无法计算，但是长期保持稳定。

另外，除现网DNS请求内容复杂以外，一些软件或硬件原因也可导致代理DNS容量缩水。

例如，开启某些功能后DNS服务器单台容量会有一定程度的下降。如在开启日志记录功能后，DNS性能下降，体现为缓存服务器在递归时无法按时得到响应，返回servfail(查询服务提供失败)给用户。日志记录功能是一项软件调试辅助功能，在日常业务分析或是遭受攻击时需对日志记录的内容进行分析和数据统计。

又例如，DNS部分功能与操作系统紧密相连，某些类型或版本的操作系统会限制DNS进程的处理能力。如在DNS的bind优化定制后的高性能缓存架构中，由于solaris系统下的高性能缓存太过依赖于软件本身的处理能力，无法利用硬件，尤其是网卡的高输入/输出(Input/Output，I/O)性能处理业务。但是在新型高性能缓存在支持netmap框架的网卡及基于netmap开发的业务软件的架构下，处理能力就有了质的飞越。

为了解决现有技术问题，综合考虑以上因素，本发明实施例提供了一种域名系统DNS容量测量方法、装置、设备及计算机可读存储介质。下面首先对本发明实施例所提供的域名系统DNS容量测量方法进行介绍。

图1示出了本发明一个实施例提供的域名系统DNS容量测量方法的流程示意图。如图1所示，该方法包括以下步骤：

S10，获取目标域名系统DNS的历史日志信息；

S20，提取历史日志信息中的至少一个域名及其对应的时间戳；

S30，根据至少一个域名及其对应的时间戳，生成测试脚本；

S40，利用测试脚本，向目标DNS发送请求信息，以使目标DNS解析请求信息；

S50，接收目标DNS的解析结果，根据解析结果计算第一预设指标；

S60，当第一预设指标满足第一预设条件时，将目标DNS对应的每秒查询率QPS作为目标DNS的实际容量。

示例性的，目标DNS可以是运营商省级代理DNS。由于运营商省级代理DNS的用户量足够巨大，用户使用习惯分布均匀，再无异常及攻击的情况下，DNS缓存命中率比较稳定。可以不关注DNS容量可能的极值(缓存全部命中或全部未命中)，而更关注在尽可能完全复现现网实际命中率情况下DNS的容量。

在S10中，可以先拷贝一定时间段之内的目标DNS的历史记录，例如拷贝24小时之内的。以目标DNS为某省运营商DNS为例，该省运营商DNS日志单节点单日约80G左右，所有日志按照记录时间命名，将所有日志首先拷贝至非生产服务器以避免影响现网DNS性能。另外，也可以提取目标DNS现存的所有记录

示例性的，在用户使用运营商代理DNS进行域名解析请求时，代理DNS网管系统会记录请求日志。日志文件统一采用latin1编码格式。

日志示例如下：

请求类型为A，解析结果含3个CNAME记录和2个A记录：

111.123.222.12|www.63.com|20170308055153|111.26.137.143|0|A|www.163.com.cloudcdn.net；

www.163.com.cloudglb.com；c01.i05.cmbhl.lv3.cloudglb.com||117.180.180.180

在S20中，可以按照解析域名、请求时间、请求类型等提取历史日志中的信息，例如抽取域名与时间戳两个字段信息。根据这些字段可以最大程度的模拟现网请求的内容及频率。

在S30中，可以按照日志中域名的实际时间间隔生成测试脚本。即正式开始测试时，播放的脚本已经生成好，无需边播放边生成，可以增加请求效率。进一步的，在测试过程中观察和记录指标波动情况。

另外，由于DNS压测方案主要用于新版本入网，新版本是旧版本的扩容升级版，容量更高。并且代理DNS属于运营商重要网元，在旧版本承载业务量超过容量三分之一时就开始启动扩容，所以按照历史日志中实际的域名请求量不足以使压测量达到新版本处理极限。

在一些实施例中，在S40之前，该方法还可以包括：对测试脚本包括的域名进行增量处理，以增加测试脚本中的域名数量。进一步的，S40具体可以包括：利用增量处理后的测试脚本，向目标DNS发送请求信息。

对测试脚本包括的域名进行增量处理，即增加测试脚本中的请求量，以尽可能的达到目标DNS容量的临界点，从而更准确的测量DNS的实际容量。

在一些实施例中，对测试脚本包括的域名进行增量处理的步骤可以包括：获取与目标DNS属于同一集群中的其它DNS的历史日志信息；在测试脚本中增加预设比例的同一集群中的其它DNS的历史日志信息中的域名，以得到增量处理后的测试脚本。

例如，可以按照多节点历史日志合并的方式增加请求量。由于代理DNS是运营商的重要网元，所以会以多节点集群方式工作，负载分担的同时也具备了热备能力。可以将多个节点的DNS日志融合后增加DNS压测请求量。根据本发明实施例，可以模拟单一节点故障后，其它节点接管该节点业务的场景。

又例如，可以按照融合式增加请求量。申请人发现，代理DNS在现网运行过程中多节点同时服务失败的情况比较少见，主要以单节点服务失败的场景为主。单节点失败后，其上的业务量会按一定比例均匀分配至其它节点，而不是将所有业务全部分配到单一节点。可以按照一定比例将多个节点的DNS历史日志融合在一起。根据本发明实施例，可以完全模拟现网环境且可以对请求量进行微调。

在一些实施例中，对测试脚本包括的域名进行增量处理的步骤可以包括：统计测试脚本中每个域名对应的数量；按照预设比例向测试脚本中增加测试脚本中域名数量大于预设阈值的域名，以得到增量处理后的测试脚本。

例如，可以按照一定比例增加在DNS请求中请求量为TOP10000的域名。如设定增加域名数量比例为60％，则原始日志中在21:31:45时请求www.baidu.com，实际测试时间为21:31:45，在该时间点发起两次对www.baidu.com的DNS请求的概率为60％。根据本发明实施例，可以对请求量进行微调。

在一些实施例中，在至少一个域名为至少两个的情况下，S30具体包括：根据至少两个域名中的每个域名对应的时间戳，对每两个域名的时间间隔进行压缩，得到压缩后的域名对应的时间戳；根据至少一个域名及压缩后的域名对应的时间戳，生成测试脚本。

例如，直接将原来现网一天的请求压缩至12小时或者更短，即利用缩频的方式增加请求量。该方案简单，可以减少计算量。

在一些实施例中，S40具体包括：按照预设时间间隔，利用测试脚本，多次向目标DNS发送请求信息。

示例性的，按照时移并发的方式增加请求量。例如，实际测试中10:00:00进程1开始回放历史日志，即运行生成的测试脚本，10:05:00进程2开始回放历史日志，即再次运行生成的测试脚本，以此类推，在达到代理DNS容量极限前不断增加发起测试的进程以达到增加请求量的目的。根据本发明实施例，可以不更改已生成的测试脚本，进而减少计算量。

在上述实施例中，都可以是提前生成测试脚本，测试终端只需要按照生成的测试脚本进行DNS请求，而无需实时进行是否发起请求的概率判断，增加测试终端请求的效率。

在S50中，可以接收目标DNS返回的解析结果中的目的IP、响应结果等，用以对比解析正确率。可以同步记录目标DNS质量劣化情况。

在S60中，第一预设指标包括系统解析成功率，对应的，第一预设条件为第一阈值；和/或，第一预设指标包括吞吐量差值与QPS的比值，对应的第一预设条件为第二阈值。

示例性的，第一预设指标为系统解析成功率，当系统解析成功率低于98％并开始逐步下降时，则认为该点容量即为目标DNS实际容量。或者，第一预设指标为吞吐量差值与QPS的比值，即(ppsin-ppsout)/QPS，当(ppsin-ppsout)/QPS>5％，则认为该点容量即为代理DNS实际容量。

根据本发明实施例提供的DNS容量测量方法，通过获取目标DNS的历史日志信息，并提取历史日志信息中的域名及其对应的时间戳，从而生成测试脚本。该测试脚本是基于目标DNS的真实历史日志生成的，因此该测试脚本能够尽可能真实的模拟现网环境。进一步的，利用该测试脚本，向目标DNS发送请求，接收并分析目标DNS的解析结果，当第一预设指标满足第一预设条件时，将目标DNS对应的QPS作为目标DNS的实际容量，从而能够准确的确定目标DNS的实际容量。

进一步的，申请人发现目前常见的代理DNS可监控指标有15大类，70个指标，若70个指标全部直接用于日常小时粒度监控频率过于繁杂。有些DNS维护人员会根据自己的经验挑出CPU、内存利用率，系统响应成功率，QPS等指标，进而简化监控，但是这种监控范围是否能够全面的反映出代理DNS性能劣化的所有常见情况并未经过严格论证。

因此，为了保证指标体系尽可能全面得反映出代理DNS性能劣化的所有常见情况，应该在取得实际阈值(即实际容量)后，再观察容量超限前后具体有规律性波动的指标。

在一些实施例中，在S60之后，该方法还可以包括：计算多个第二预设指标在目标DNS达到实际容量前后的预设时间范围内的数值；从多个第二预设指标中选取数值满足第二预设条件的候选监控指标，以使用户利用候选监控指标监控目标DNS。

示例性的，计算多个第二预设指标在目标DNS达到实际容量前后的预设时间范围内的数值，确定在目标DNS达到实际容量前后的预设时间范围内波动最明显的指标。可以是围绕DNS容量确认DNS性能劣化时能观测到的波动最明显的指标，根据这些指标圈定大致的监控指标选取范围。

以下，以融合式增加请求量的方案为例，说明压测过程中确立监控指标的方法。

如图2所示，在仅使用基于bind9优化和定制开发的DNS解析软件环境下，开启日志记录功能时，4台DNS缓存服务器节点的容量由80万QPS的理论值降至17.5万QPS的实际值(此处QPS≈PPS)。超过该缩水容量阈值后，表现为QPS正常，但是DNS系统解析成功率下降。图2中，曲线1表示接收包的数量(ppsin_total)随时间的变化情况，曲线2表示发送包的数量(ppsout_total)随时间的变化情况。

如图3所示，在仅使用基于bind9优化和定制开发的DNS解析软件环境下，关闭日志记录功能时，4台DNS缓存服务器节点的容量由80万QPS的理论值降至20.05万QPS的实际值(此处QPS≈PPS)。超过该缩水容量阈值后，表现为QPS和DNS系统解析成功率监控均正常，但是DNS所部属操作系统的ppsin与ppsout的差值(即DNS所部属操作系统的吞吐量差值)不断增加。图3中，曲线1表示接收包的数量(ppsin_total)随时间的变化情况，曲线2表示发送包的数量(ppsout_total)随时间的变化情况。

分析可知，在实际容量测定准确的情况下，容量超限仍然是导致DNS性能质差的第一原因，所以应纳入监控指标体系。另外，成功率指标是DNS服务性能的第一标志，但是成功率指标算法有多种，每种都有优势和劣势，需要分析对比一个最佳算法。

SEQ系统中DNS解析成功率的计算公式(1)如下：

DNS解析成功率＝DNS REQUEST/DNS RESPONSE (1)

其中，DNS REQUES表示DNS请求量，DNS RESPONSE表示DNS响应量。

所有情况下的DNS服务能力下降都会导致SEQ系统DNS解析成功率下降，但是该指标下降不一定是DNS本身性能问题，还有可能是网络质量问题。SEQ系统中的算法更接近DNS系统成功率。

集中性能管理系统中DNS解析成功率计算公式(2)如下：

DNS解析成功率＝DNS RESPONSE(RESPONSE＝0)消息的次数/DNS Query的次数(2)

其中，DNS Query表示DNS查询。

集中性能管理系统DNS解析成功率：掺杂源站原因和网络层原因较多，作为监控指标不够合理。集中性能管理系统中的算法更接近DNS用户成功率。

DNS网管系统DNS系统解析成功率计算公式(3)如下：

DNS系统解析成功率＝(success+referral+nxrrset+nxdomain)/(sucess+referral+nxrrset+nxdomain+failure) (3)

其中，success表示名字服务器处理的成功的查询数目，成功的查询是那些不以指向别的名字服务器或者错误为结果的查询。referral表示名字服务器处理的以指向别的名字服务器为结果的查询的个数。nxrrset表示名字服务器处理的一种查询的数目，这种查询的结果是响应会说：对于指定的域名没有所要求的记录类型。nxdomain表示名字服务器处理的结果为查询者所指定的域名不存在的查询个数。recursion表示名字服务器收到的请求递归查询处理获得回答的查询的个数。failure表示名字服务器收到的一种查询的个数，这种查询的结果是除了nxrrset和nxdomain中所包括的以外的其他错误。其中，Failure＝servfail+refuse。

DNS网管系统DNS系统解析成功率：部分情况下，性能已经下降，但是成功率仍保持不变。

综上可知，DNS系统解析成功率虽然不能涵盖所有场景，但是在仅解释成功率的场景下，最能标准的反映出DNS系统本身的性能。最终选取该指标为主指标。

吞吐量指标确认：DNS业务重要程度高，为保障DNS服务的稳定性，承载DNS的服务器往往仅承载域名解析服务，不在与其它应用共用硬件。

此外由于DNS的请求包与响应包较小，不需要拆分，绝大部分的请求与响应都仅产生一个包，理论上承载DNS服务器操作系统的ppsin＝ppsout。但由于实际上操作系统还要进行一些基础通讯，并且客户端肯能会产生一些非法格式的请求，所以ppsin总是略大于ppsout，但是(ppsin-ppsout)/QPS不应超过5％。

示例性的，如图4所示，QPS超过容量阈值时，新到的域名解析请求无法得到处理，基于bind优化定制后的高性能缓存，被迫删除(drop)。该类请求无法计入日志，不计算在失败(failure)中。由于程序限制，DNS解析成功率不会下降。但是未处理的请求用户侧会不断重新发起请求，因而产生蝴蝶效应，导致访问量迅速攀升。操作系统层面正常情况下吞吐量差值与QPS的比值((ppsin-ppsout)/QPS)小于5％，但是此时该指标远远大于5％。

在一些实施例中，从多个第二预设指标中选取数值满足第二预设条件的候选监控指标，包括：从多个第二预设指标中确定数值满足第二预设条件的第二预设指标；从满足第二预设条件的第二预设指标中排除非性能指标，得到候选监控指标。

示例性的，第二预设条件可以是指标波动具有规律性。可以从满足第二预设条件的第二预设指标中排除波动无规律的指标。图5为DNS响应时延的示意图，分析可知，时延类指标虽然直接反应用户感知，但由于其影响因素较多(如源站权威DNS性能质差)，波动无规律性，即使发生劣化也不能直接确定是由DNS系统自身原因引起，不具备成为日常监控指标的条件，但可以用作特定场景下代理DNS性能分析的辅助依据。另外，缓存命中率在用户使用习惯不发生大规模的改变下基本保持稳定，无规律性波动。

进一步的，可以从满足第二预设条件的第二预设指标中排除非性能瓶颈指标。在DNS容量到达阈值产生质差时，CPU利用率并没有达到主机告警标准。并且在部分容量超阈值的情况下CPU利用率几乎不会增长，可以将CPU判定为非性能瓶颈指标。

还可以从满足第二预设条件的第二预设指标中排除非性能指标。由于服务器在现网运行中开启内存“懒模式”，在没有新的内容加入内存时，内存不会主动释放现有内存中的内容，所以无法作为性能瓶颈的依据。接收报文状态、缓存状态、发出报文状态均为业务类指标，与性能不相关。

在一些实施例中，在从多个第二预设指标中选取数值满足第二预设条件的候选监控指标之后，方法还包括：利用Pearson相关系数(Pearson Correlation Coefficient)法计算各候选监控指标之间的相关度；根据各候选监控指标之间的相关度，从各候选监控指标中确定实际监控指标，以使用户利用实际监控指标监控目标DNS。

Pearson相关系数是用来衡量两个数据集合是否在一条线上面，它用来衡量定距变量间的线性关系。

Pearson相关系数的表达式(4)如下所示：

对表达式(4)进一步变换得到表达式(5)：

式中，两个连续变量(X，Y)的pearson相关性系数(Px,y)等于它们之间的协方差cov(X,Y)除以它们各自标准差的乘积(σX,σY)。系数(Px,y)的取值总是在-1.0到1.0之间，接近0的变量被成为无相关性，接近1或者-1被称为具有强相关性。

示例性的，将候选监控指标带入Pearson相关系数的表达式，计算候选监控指标之间的相关度。表1为部分候选监控指标之间的相关度。表1中pps及bps均表示DNS所部署操作系统的端口流量，端口流量pps的单位是数据包，端口流量bps的单位是字节。

表1

可以从相关度高的多个候选指标中仅选取一个监控指标作为实际监控指标，从而简化监控指标的数量，尽可能监控最少的指标覆盖最全面的场景，更方便用户利用比较少量的实际监控指标监控DNS的性能。

根据本发明实施例，利用合理的DNS压测方案，在尽可能真实的模拟现网环境下，准确的测量DNS的实际容量，且能够更准确获得指标在时间序列上的波动情况，也使Pearson相关系数计算的结果更加准确，增加了指标体系的可信度。并且对剩余指标压缩，排除其它指标后，剩余指标通过计算其协同性分类，并找到该类中波动最明显的指标，即第一时间上升或下降，且上升下降幅度最大的指标，简化了监控指标体系，更方便用户利用简化后的指标监控DNS的性能。

图6是本发明一个实施例提供的DNS容量测量装置的结构示意图。该装置包括：

历史日志获取模块601，用于获取目标域名系统DNS的历史日志信息；

域名信息提取模块602，用于提取历史日志信息中的至少一个域名及其对应的时间戳；

测试脚本生成模块603，用于根据至少一个域名及其对应的时间戳，生成测试脚本；

请求模块604，用于利用测试脚本，向目标DNS发送请求信息，以使目标DNS解析请求信息；

计算模块605，用于接收目标DNS的解析结果，根据解析结果计算第一预设指标；

实际容量确定模块606，用于当第一预设指标满足第一预设条件时，将目标DNS对应的每秒查询率QPS作为目标DNS的实际容量。

在一些实施例中，该装置还包括增量处理模块，用于：

对测试脚本包括的域名进行增量处理，以增加测试脚本中的域名数量。

进一步的，请求模块604，具体用于：

利用增量处理后的测试脚本，向目标DNS发送请求信息。

在一些实施例中，增量处理模块具体用于：

获取与目标DNS属于同一集群中的其它DNS的历史日志信息；

在测试脚本中增加预设比例的同一集群中的其它DNS的历史日志信息中的域名，以得到增量处理后的测试脚本。

在一些实施例中，增量处理模块具体用于：

统计测试脚本中每个域名对应的数量；

按照预设比例向测试脚本中增加测试脚本中域名数量大于预设阈值的域名，以得到增量处理后的测试脚本。

在一些实施例中，在至少一个域名为至少两个的情况下，测试脚本生成模块603具体用于：

根据至少两个域名中的每个域名对应的时间戳，对每两个域名的时间间隔进行压缩，得到压缩后的域名对应的时间戳；

根据至少一个域名及压缩后的域名对应的时间戳，生成测试脚本。

在一些实施例中，请求模块604具体用于：

按照预设时间间隔，利用测试脚本，多次向目标DNS发送请求信息。

在一些实施例中，该装置还包括候选监控指标确定模块，用于：

计算多个第二预设指标在目标DNS达到实际容量前后的预设时间范围内的数值；

从多个第二预设指标中选取数值满足第二预设条件的候选监控指标，以使用户利用候选监控指标监控目标DNS。

在一些实施例中，候选监控指标确定模块具体用于：

从多个第二预设指标中确定数值满足第二预设条件的第二预设指标；

从满足第二预设条件的第二预设指标中排除非性能指标，得到候选监控指标。

在一些实施例中，该装置还包括实际监控指标确定模块，用于：

利用Pearson相关系数法计算各候选监控指标之间的相关度；

根据各候选监控指标之间的相关度，从各候选监控指标中确定实际监控指标，以使用户利用实际监控指标监控目标DNS。

在一些实施例中，第一预设指标包括系统解析成功率，对应的，第一预设条件为第一阈值；和/或，第一预设指标包括吞吐量差值与QPS的比值，对应的第一预设条件为第二阈值。

本发明实施例的DNS容量测量装置，通过获取目标DNS的历史日志信息，并提取历史日志信息中的域名及其对应的时间戳，从而生成测试脚本。该测试脚本是基于目标DNS的真实历史日志生成的，因此该测试脚本能够尽可能真实的模拟现网环境。进一步的，利用该测试脚本，向目标DNS发送请求，接收并分析目标DNS的解析结果，当第一预设指标满足第一预设条件时，将目标DNS对应的QPS作为目标DNS的实际容量，从而能够准确的确定目标DNS的实际容量。

进一步的，利用Pearson相关系数法精简了指标监控体系，更方便运维人员监控DNS的运行情况。

图7示出了本发明实施例提供的DNS容量测量设备的硬件结构示意图。

在DNS容量测量设备可以包括处理器301以及存储有计算机程序指令的存储器302。

具体地，上述处理器301可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本发明实施例的一个或多个集成电路。

存储器302可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器302可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器302可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器302可在综合网关容灾设备的内部或外部。在特定实施例中，存储器302是非易失性固态存储器。在特定实施例中，存储器302包括只读存储器(ROM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、电可改写ROM(EAROM)或闪存或者两个或更多个以上这些的组合。

处理器301通过读取并执行存储器302中存储的计算机程序指令，以实现上述实施例中的任意一种DNS容量测量方法。

在一个示例中，DNS容量测量设备还可包括通信接口303和总线310。其中，如图7所示，处理器301、存储器302、通信接口303通过总线310连接并完成相互间的通信。

通信接口303，主要用于实现本发明实施例中各模块、装置、单元和/或设备之间的通信。

总线310包括硬件、软件或两者，将DNS容量测量设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线310可包括一个或多个总线。尽管本发明实施例描述和示出了特定的总线，但本发明考虑任何合适的总线或互连。

该DNS容量测量设备可以执行本发明实施例中的DNS容量测量方法，从而实现结合图1和图6描述的DNS容量测量方法和装置。

另外，结合上述实施例中的DNS容量测量方法，本发明实施例可提供一种计算机存储介质来实现。该计算机存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种DNS容量测量方法。

需要明确的是，本发明并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本发明的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本发明的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本发明中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本发明不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

以上所述，仅为本发明的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。

Claims (12)

1.一种域名系统DNS容量测量方法，其特征在于，包括：

获取目标域名系统DNS的历史日志信息；

提取所述历史日志信息中的至少一个域名及其对应的时间戳；

根据所述至少一个域名及其对应的时间戳，生成测试脚本；

利用所述测试脚本，向所述目标DNS发送请求信息，以使所述目标DNS解析所述请求信息；

接收所述目标DNS的解析结果，根据所述解析结果计算第一预设指标；

当所述第一预设指标满足第一预设条件时，将所述目标DNS对应的每秒查询率QPS作为所述目标DNS的实际容量；

所述第一预设指标包括系统解析成功率，对应的，所述第一预设条件为第一阈值；

和/或，所述第一预设指标包括吞吐量差值与所述QPS的比值，对应的所述第一预设条件为第二阈值。

2.根据权利要求1所述的方法，其特征在于，在所述利用所述测试脚本，向所述目标DNS发送请求信息之前，所述方法包括：

对所述测试脚本包括的域名进行增量处理，以增加所述测试脚本中的域名数量；

所述利用所述测试脚本，向所述目标DNS发送请求信息，具体包括：

利用增量处理后的所述测试脚本，向所述目标DNS发送请求信息。

3.根据权利要求2所述的方法，其特征在于，所述对所述测试脚本包括的域名进行增量处理，包括：

获取与所述目标DNS属于同一集群中的其它DNS的历史日志信息；

在所述测试脚本中增加预设比例的所述同一集群中的其它DNS的历史日志信息中的域名，以得到增量处理后的所述测试脚本。

4.根据权利要求2所述的方法，其特征在于，所述对所述测试脚本包括的域名进行增量处理，包括：

统计所述测试脚本中每个域名对应的数量；

按照预设比例向所述测试脚本中增加所述测试脚本中域名数量大于预设阈值的域名，以得到增量处理后的所述测试脚本。

5.根据权利要求1所述的方法，其特征在于，在所述至少一个域名为至少两个的情况下，所述根据所述至少一个域名及其对应的时间戳，生成测试脚本，包括：

根据所述至少两个域名中的每个域名对应的时间戳，对每两个所述域名的时间间隔进行压缩，得到压缩后的所述域名对应的时间戳；

根据至少一个所述域名及压缩后的所述域名对应的时间戳，生成所述测试脚本。

6.根据权利要求1所述的方法，其特征在于，所述利用所述测试脚本，向所述目标DNS发送请求信息，包括：

按照预设时间间隔，利用所述测试脚本，多次向所述目标DNS发送请求信息。

7.根据权利要求1所述的方法，其特征在于，所述当所述第一预设指标满足第一预设条件时，将所述目标DNS对应的每秒查询率QPS作为所述目标DNS的实际容量之后，所述方法还包括：

计算多个第二预设指标在所述目标DNS达到所述实际容量前后的预设时间范围内的数值；

从多个所述第二预设指标中选取所述数值满足第二预设条件的候选监控指标，以使用户利用所述候选监控指标监控所述目标DNS。

8.根据权利要求7所述的方法，其特征在于，所述从多个所述第二预设指标中选取所述数值满足第二预设条件的候选监控指标，包括：

从多个所述第二预设指标中确定所述数值满足所述第二预设条件的第二预设指标；

从满足所述第二预设条件的第二预设指标中排除非性能指标，得到所述候选监控指标。

9.根据权利要求7或8所述的方法，其特征在于，在所述从多个所述第二预设指标中选取所述数值满足第二预设条件的候选监控指标之后，所述方法还包括：

利用Pearson相关系数法计算各所述候选监控指标之间的相关度；

根据各所述候选监控指标之间的相关度，从各所述候选监控指标中确定实际监控指标，以使用户利用所述实际监控指标监控所述目标DNS。

10.一种DNS容量测量装置，其特征在于，所述装置包括：

历史日志获取模块，用于获取目标域名系统DNS的历史日志信息；

域名信息提取模块，用于提取所述历史日志信息中的至少一个域名及其对应的时间戳；

测试脚本生成模块，用于根据所述至少一个域名及其对应的时间戳，生成测试脚本；

请求模块，用于利用所述测试脚本，向所述目标DNS发送请求信息，以使所述目标DNS解析所述请求信息；

计算模块，用于接收所述目标DNS的解析结果，根据所述解析结果计算第一预设指标；

实际容量确定模块，用于当所述第一预设指标满足第一预设条件时，将所述目标DNS对应的每秒查询率QPS作为所述目标DNS的实际容量；

所述第一预设指标包括系统解析成功率，对应的，所述第一预设条件为第一阈值；

和/或，所述第一预设指标包括吞吐量差值与所述QPS的比值，对应的所述第一预设条件为第二阈值。

11.一种DNS容量测量设备，其特征在于，所述设备包括：处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如权利要求1-9任意一项所述的DNS容量测量方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1-9任意一项所述的DNS容量测量方法。

Images