CN106130816A - 一种内容分发网络监控方法、监控服务器及系统 - Google Patents

Abstract

本发明实施例公开了一种CDN监控方法、监控服务器及系统，CDN监控方法包括：接收客户端发送的数据检测报告；解析数据检测报告得到检测数据；根据检测数据计算CDN中每个节点服务器的平均请求时延，以及计算CDN中每条线路的平均请求时延和请求成功率；将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应线路是否出现异常；当CDN中出现异常的节点服务器或线路时，向运维平台发送告警提示消息。本发明实施例能够从用户侧展开监控，及时发现CDN异常。

Description

一种内容分发网络监控方法、监控服务器及系统

技术领域

本发明实施例涉及通信技术领域，具体涉及一种内容分发网络监控方法、监控服务器及系统。

背景技术

内容分发网络(Content Delivery Network，CDN)，是通过在网络各处放置的节点服务器所构成的网络基础之上增加的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到客户端的距离和响应时间等综合信息将客户端的请求重新导向离客户端最近的服务节点上，其目的是使客户端可就近取得所需内容，解决网络拥挤的状况，提高用户访问网站的响应速度。

CDN的正常运营离不开对CDN的监控，现有的CDN监控系统，是从服务端展开的，从服务端直接获取监控指标，即直接监控CDN中的节点服务器的实时状态，监控的指标有进出流量，中央处理器(Central Processing Unit，CPU)使用率，内存使用情况，磁盘输入输出，连接数等等。

在对现有技术的研究和实践过程中，本发明的发明人发现，从节点服务器侧展开监控，无法反映现网用户的真实体验，时常出现客户反馈CDN出现问题，而监控却没发现任何异常的情况。

发明内容

有鉴于此，本发明实施例提供了一种内容分发网络监控方法、监控服务器及系统，能够从用户侧展开监控，及时发现CDN异常。

一种CDN监控方法，所述方法包括：

接收客户端发送的数据检测报告；

解析所述数据检测报告得到检测数据；

根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；

将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；

当所述CDN中出现异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。

一种监控服务器，包括：

接收单元，用于接收客户端发送的数据检测报告；

解析单元，用于解析所述数据检测报告得到检测数据；

计算单元，用于根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；

异常判断单元，用于将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；

告警单元，用于当所述CDN中存在异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。

一种CDN监控系统，包括客户端及上述监控服务器；

所述客户端用于，通过触发预设业务中嵌入的测速脚本向所述CDN发送测速请求得到数据检测报告，将所述数据检测报告发送给所述监控服务器；

所述监控服务器用于，接收客户端发送的数据检测报告；解析所述数据检测报告得到检测数据；根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；当所述CDN中存在异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。

本发明实施例中，监控服务器可以接收客户端发送的数据检测报告，通过解析客户端发送的数据检测报告计算CDN中每个节点服务器的平均请求时延，以及CDN中每条线路的平均请求时延和请求成功率，从而分析CDN中是否存在异常的节点服务器或异常的线路，当CDN中存在出现异常的节点服务器或异常的线路时，向运维平台发送告警提示消息，即本发明实施例中，可以从客户端展开监控，监控数据来自客户端，因而能直接反映用户侧的真实体验，根据客户端发送的监控数据监控CDN是否出现异常，能够及时发现异常。

附图说明

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

图1a是本发明实施例所提供的CDN监控方法的一个场景示意图；

图1b是本发明实施例所提供的CDN监控方法的一个流程示意图；

图2是本发明实施例所提供的CDN监控方法的另一流程示意图；

图3是本发明实施例所提供的监控服务器的一个结构示意图；

图4是本发明实施例所提供的监控服务器的另一结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

现有技术的CDN监控方法，通常是从节点服务器侧展开的，无法反映现网用户的真实体验，时常出现客户反馈CDN出现问题，而监控却没发现任何异常的情况。造成这种情况的原因有很多，比如说，节点服务器的性能存在差异，跨运营商的调度造成了请求延迟的升高，丢包率升高，这些情况从节点服务器侧监控是不会上报任何告警的，从节点服务器侧进行监控，还有一个缺点就是无法发现线路故障，即节点服务器并没有出现异常，单纯是线路故障造成的大面积请求失败。总结来说，现网的问题是复杂多样的，从节点服务侧展开监控，忽视了现网用户侧的真实情况，无法取到足够的数据来判断现网是否有故障，是否需要告警。

因而，本发明实施例提供了一种CDN监控方法，将从用户侧展开监控，本发明实施例CDN监控方法一个具体场景可如图1a所示，客户端向CDN发送测速请求(具体可以通过触发预设业务中嵌入的测速脚本向CDN发送测速请求)，CDN中的节点服务器将测速请求发往源站，源站获取节点服务器的相关数据并通过节点服务器反馈给客户端，客户端根据CDN的反馈生成数据检测报告，并将数据检测报告发送给监控服务器，监控服务器解析所述数据检测报告得到检测数据，根据检测数据计算CDN中每个节点服务器的平均请求时延，以及根据检测数据计算CDN中每条线路的平均请求时延和请求成功率，将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常，当确定CDN中存在异常的节点服务器或异常的线路时，监控服务器向运维平台发送告警提示消息，运维平台可以根据告警提示消息及时发现CDN中的异常并处理，即本发明实施例中，监控服务器采用来自客户端的数据分析CDN的状态，因而能够反映现网用户的真实体验，及时发现CDN异常。

以下分别进行详细说明，需说明的是，以下实施例的序号不作为对实施例优选顺序的限定。

实施例一

本实施例将从监控服务器的角度描述本发明提供的CDN监控方法，如图1b所示，本实施例的方法包括以下步骤：

步骤101、接收客户端发送的数据检测报告；

具体实现中，可以预先在预设业务(例如腾讯业务)中嵌入测速脚本，客户端可以通过触发预设业务中的测速脚本向CDN发送测速请求(例如客户端可以在用户点击腾讯业务时触发腾讯业务中嵌入的测速脚本向CDN发送测速请求)，利用该测速脚本获取相关数据，然后客户端根据CDN的反馈及测速脚本获取的相关数据生成所述数据检测报告。

客户端向CDN发送测速请求之后，CDN的负载均衡系统可以将该测速请求分配给CDN中响应速度最快的节点服务器，该节点服务器向源站发送测速请求，源站解析该节点服务器发送的测速请求的标头字段以获取该节点服务器的IP地址，源站将该节点服务器的IP地址通过该节点服务器反馈给客户端，与此同时，客户端利用测速脚本获取了该测速请求的请求时延(响应时间)，请求结果(成功或失败，请求结果可以用具体的数值表示，例如用1表示请求成功，0表示请求失败，反之亦可)及处理该测速请求的节点服务器的标识ID，客户端可以将自身的IP地址封装在标头字段，将处理该测速请求的节点服务器的IP地址、ID、请求时延及请求结果封装在数据字段形成数据检测报告，将该数据检测报告发送给监控服务器，监控服务器接收该数据检测报告。

当然，监控服务器接收到的数据检测报告中还可以携带其他检测数据，例如请求状态码等，此处不做具体限定。

具体地，例如腾讯业务，腾讯业务具有庞大的用户群，每天有5000万以上的人次访问腾讯业务，腾讯业务每被访问一次，将产生一份数据检测报告，所以监控服务器将接收到客户端反馈的大量的数据检测报告。

步骤102、解析所述数据检测报告得到检测数据；

具体地，解析所述数据检测报告的标头字段可以获取所述客户端的IP地址；解析所述数据检测报告的数据字段可以获取所述测速请求的请求时延、请求结果，处理所述测速请求的节点服务器的IP地址与ID。

步骤103、根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；

计算CDN中每个节点服务器的平均请求时延的过程可如下：

(1)可以根据节点服务器的IP地址定时从解析得到的全部检测数据中整理出每个节点服务器的检测数据，每个节点服务器的检测数据可以包括：节点服务器的IP地址、ID和请求时延，定时时长例如可以为一分钟、两分钟等，此处不做具体限定。

(2)根据每个节点服务器的检测数据计算定时时长内每个节点服务器的平均请求时延。具体地，在定时时长内每个节点服务器的平均请求时延可以为：在定时时长内每个节点服务器处理的所有测速请求的请求时延的平均值。例如，定时时长为1分钟，1分钟内某个节点服务器处理了10个测速请求，则该节点服务器在1分钟内的平均请求时延为这10个测速请求的请求时延的平均值。

(3)将计算得到的每个节点服务器的平均请求时延存入数据库中。例如定时时长为1分钟，则监控服务器每分钟将计算一次各个节点服务器的平均请求时延，然后将计算得到的数据存入数据库中。

CDN中的线路可由地域加运营商构成，通过客户端的IP地址即可确定客户端所处的地域及所属的运营商(地域例如上海、武汉、陕西等，运营商例如移动、电信、联通等，每个运营商及地域对应固定的IP地址段)，据此可以统计每条线路的状态，例如统计陕西移动、陕西电信、武汉联通等这些线路的状态，具体地，例如陕西移动这条线路的状态，可以通过分析陕西的客户端与CDN中的节点服务器进行交互后反馈的数据检测报告得到。

计算CDN中每条线路的平均请求时延和请求成功率的过程可如下：

(1)可以根据客户端的IP地址定时从解析得到的全部检测数据中整理出每条线路的检测数据(一条线路中包括一个固定IP地址段的所有客户端)，每条线路的检测数据包括：客户端的IP地址、请求时延和请求结果，定时时长例如可以为一分钟、两分钟等，此处不做具体限定。

(2)根据每条线路的检测数据计算定时时长内每条线路的平均请求时延和请求成功率。具体地，每条线路的平均请求时延为在定时时长内该线路发送的所有测速请求的请求时延的平均值，每条线路的请求成功率为在定时时长内该线路上处理结果为成功的测速请求的数量与该线路上经过的全部测速请求的数值的比值。例如，定时时长为1分钟，1分钟内某条线路发送了100个测速请求，则该线路在1分钟内的平均请求时延为这100个测速请求的请求时延的平均值；该线路在1分钟内的请求成功率为这100个测速请求中请求结果为成功的测速请求所占的比例。

(3)将计算得到的每条线路的平均请求时延及请求成功率存入数据库中。例如定时时长为1分钟，则监控服务器每分钟将计算一次各个线路的平均请求时延及请求成功率，然后将计算得到的数据存入数据库中。

步骤104、将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；

节点服务器是否异常的判断方法具体可如下：

(1)从数据库中取出预设时长内存储的每个节点服务器的所有平均请求时延。具体实现中，预设时长可以大于定时时长，例如预设时长可以为10分钟、20分钟等，此处不做具体限定。如果定时时长为1分钟，预设时长为10分钟，则从数据库中取出的预设时长内存储的每个节点服务器的平均请求时延将有10个，这10个平均请求时延值可能相同，也可能不同，视具体实际情况而定。

(2)统计每个节点服务器的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量。具体实现中，可以根据实际情况(例如性能)为不同的节点服务器为设置不同的时延阈值，统计预设时长内每个节点服务器的超过对应预设时延阈值的平均请求时延的数量。

(3)判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值。预设数量阈值可以根据定时时长、预设时长等实际数据进行设置。例如定时时长为1分钟，预设时长为10分钟，则预设时长内每个节点服务器将有10个平均请求时延数据，则预设数量阈值可以设置为5、6等数值，即10个平均请求时延数据如果有5个以上，或者6个以上超过对应预设时延阈值，则认为该节点服务器出现异常。

(4)确定超过对应预设时延阈值的平均请求时延的数量大于预设数量阈值的节点服务器出现异常。

线路是否异常的判断方法具体可如下：

(1)从数据库中取出预设时长内存储的每条的所有平均请求时延及请求成功率。具体实现中，预设时长可以大于定时时长，例如预设时长可以为10分钟、20分钟等，此处不做具体限定。如果定时时长为1分钟，预设时长为10分钟，则从数据库中取出的预设时长内存储的每个节点服务器的平均请求时延将有10个，请求成功率也有10个。

(2)统计每条线路的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量，以及统计每条线路的所有请求成功率中超过对应预设成功率的请求成功率的数量。具体实现中，可以根据实际情况(例如带宽)为不同的线路为设置不同的时延阈值，为不同的线路设置不同的成功率阈值，统计预设时长内每条线路的超过对应预设时延阈值的平均请求时延的数量，以及每条线路的超过对应预设成功率的请求成功率的数量。

(3)判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值，以及判断超过对应预设成功率的请求成功率的数量是否大于预设数量阈值。预设数量阈值可以根据定时时长、预设时长等实际数据进行设置。例如定时时长为1分钟，预设时长为10分钟，则预设时长内每个节点服务器将有10个平均请求时延数据，则预设数量阈值可以设置为5、6等数值，即10个平均请求时延数据如果有5个以上，或者6个以上超过对应预设时延阈值，则认为该节点服务器出现异常；或者10个请求成功率中如果有5个以上，或者6个以上超过对应预设成功率，则认为该节点服务器出现异常。

(4)确定超过对应预设时延阈值的平均请求时延的数量大于预设数量阈值的节点服务器出现异常，或者确定超过对应预设成功率的请求成功率的数量大于预设数量阈值的节点服务器出现异常。

步骤105、当所述CDN中出现异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。

如果CDN中出现异常的节点服务器，则监控服务器可以生成第一告警提示消息，第一告警提示消息中可以包括异常节点服务器的数量、IP地址、ID等信息，将第一告警提示消息发送给运维平台。在向运维平台发送第一告警提示消息之前，监控服务器可以检查在预设时长内，是否已向运维平台发送了相同的第一告警提示信息，若已发送，则继续监控，若未发送，则向运维平台发送第一告警提示消息，以避免预设时长内重复发送相同告警，节省信令开销。

如果CDN中出现异常的线路，则监控服务器可以生成第二告警提示消息，第二告警提示消息中可以包括异常线路的数量、客户端的IP地址等信息，将第二告警提示消息发送给运维平台。在向运维平台发送第二告警提示消息之前，监控服务器可以检查在预设时长内，是否已向运维平台发送了相同的第二告警提示信息，若已发送，则继续监控，若未发送，则向运维平台发送第二告警提示消息，以避免预设时长内重复发送相同告警，节省信令开销。

其中，告警提示信息发送渠道可以包括邮件、短信、和/或社交平台或即时通信平台的消息等。

具体实现中，可以只对CDN中节点服务器的异常进行监控，也可以只对CDN中的线路的异常进行监控，当然也可以同时对CDN中的节点服务器及线路的异常进行监控，此处不做具体限定。

本实施例中，可以根据客户端反馈的数据分析CDN中的节点服务器和/或线路是否出现异常，由于监控数据来自客户端，因而能直接反映用户侧的真实体验，及时发现异常。经研究表明，从时延、成功率等各个维度出发，同时监控CDN中的节点服务器及线路，告警精确率达到95％以上(即告警误报不到5％)，覆盖面达到95％以上(即漏掉未发现的问题不到5％)，且实时快速。

采用本实施例提供的方法，可以精确发现问题，定位问题，帮助运维人员快速解决问题，大大提升了CDN服务的稳定性，从而提升了CDN服务质量，同时大幅度缩短排查问题的时间，节省了运维成本。

实施例二

实施例一所描述的方法，本实施例将举例作进一步详细说明，如图2所示，本实施例的方法包括：

步骤201、接收客户端发送的数据检测报告；

具体实现中，可以预先在预设业务(例如腾讯业务)中嵌入测速脚本，客户端可以通过触发预设业务中的测速脚本向CDN发送测速请求(例如客户端在用户点击腾讯业务时触发测速脚本发送测速请求)，利用该测速脚本获取相关数据，然后客户端根据CDN的反馈及测速脚本获取的相关数据生成所述数据检测报告。

客户端向CDN发送测速请求之后，CDN的负载均衡系统可以将该测速请求分配给CDN中响应速度最快的节点服务器，该节点服务器向源站发送测速请求，源站解析该节点服务器发送的测速请求的标头字段以获取该节点服务器的IP地址，源站将该节点服务器的IP地址通过该节点服务器反馈给客户端，与此同时，客户端利用测速脚本获取了该测速请求的请求时延(响应时间)，请求结果(成功或失败，请求结果可以用具体的数值表示，例如用1表示请求成功，0表示请求失败，反之亦可)及处理该测速请求的节点服务器的标识ID，客户端将自身的IP地址封装在标头字段，将处理该测速请求的节点服务器的IP地址、ID、请求时延及请求结果封装在数据字段形成数据检测报告，将该数据检测报告发送给监控服务器，监控服务器接收该数据检测报告。

当然，监控服务器接收到的数据检测报告中还可以携带其他检测数据，例如请求状态码等，此处不做具体限定。

具体地，例如腾讯业务，腾讯业务具有庞大的用户群，每天有5000万以上的人次访问腾讯业务，腾讯业务每被访问一次，将产生一份数据检测报告，所以监控服务器将接收到客户端反馈的大量的数据检测报告。

步骤202、解析所述数据检测报告得到检测数据；

解析所述数据检测报告的标头字段可以获取所述客户端的IP地址；解析所述数据检测报告的数据字段可以获取所述测速请求的请求时延、请求结果，处理所述测速请求的节点服务器的IP地址与ID。

步骤203、定时整理出CDN中每个节点服务器的检测数据；

可以定时根据节点服务器的IP地址从解析得到的数据中整理出每个节点服务器的检测数据，每个节点服务器的检测数据可以包括：节点服务器的IP地址、ID和请求时延，定时时长例如可以为一分钟、两分钟等，此处不做具体限定。

步骤204、计算每个节点服务器在定时时长内的平均请求时延；

具体地，在定时时长内每个节点服务器的平均请求时延可以为：在定时时长内每个节点服务器处理的所有测速请求的请求时延的平均值。例如，定时时长为1分钟，1分钟内某个节点服务器处理了10个测速请求，则该节点服务器在1分钟内的平均请求时延为这10个测速请求的请求时延的平均值。

步骤205、将计算得到的每个节点服务器的平均请求时延存入数据库中；

例如定时时长为1分钟，则监控服务器每分钟将计算一次各个节点服务器的平均请求时延，然后将计算得到的数据存入数据库中。

步骤206、从所述数据库中取出预设时长内存储的每个节点服务器的所有平均请求时延；

具体实现中，预设时长可以大于定时时长，例如预设时长可以为10分钟、20分钟等，此处不做具体限定。如果定时时长为1分钟，预设时长为10分钟，则从数据库中取出的预设时长内存储的每个节点服务器的平均请求时延将有10个，这10个平均请求时延值可能相同，也可能不同，视具体实际情况而定。

步骤207、统计每个节点服务器的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量；

具体实现中，可以根据实际情况(例如性能)为不同的节点服务器为设置不同的时延阈值，统计预设时长内每个节点服务器的超过对应预设时延阈值的平均请求时延的数量。

步骤208、判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值，若大于，则执行步骤209，否则，继续监控；

预设数量阈值可以根据定时时长、预设时长等实际数据进行设置。例如定时时长为1分钟，预设时长为10分钟，则预设时长内每个节点服务器将有10个平均请求时延数据，则预设数量阈值可以设置为5、6等数值，即10个平均请求时延数据如果有5个以上，或者6个以上超过对应预设时延阈值，则认为该节点服务器出现异常。

步骤209、生成第一告警提示消息；

步骤210、向所述运维平台发送所述第一告警提示消息；

其中，告警提示信息发送渠道可以包括邮件、短信、和/或社交平台或即时通信平台的消息等。

第一告警提示消息中可以包括异常节点服务器的数量、IP地址、ID等信息，在向运维平台发送第一告警提示消息之前，监控服务器可以检查在预设时长内，是否已向运维平台发送了相同的第一告警提示信息，若已发送，则继续监控，若未发送，则向运维平台发送第一告警提示消息，以避免预设时长内重复发送相同告警，节省信令开销。

步骤211、定时从所述检测数据中整理出每条线路的检测数据；

CDN中的线路可由地域加运营商构成，通过客户端的IP地址即可确定客户端所处的地域及所属的运营商(地域例如上海、武汉、陕西等，运营商例如移动、电信、联通等，每个运营商及地域对应固定的IP地址段)，据此可以统计每条线路的状态，例如统计陕西移动、陕西电信、武汉联通等这些线路的状态，具体地，例如陕西移动这条线路的状态，可以通过分析陕西的客户端与CDN中的节点服务器进行交互后反馈的数据检测报告得到。

可以根据客户端的IP地址定时从解析得到的全部检测数据中整理出每条线路的检测数据(一条线路中包括一个固定IP地址段的所有客户端)，每条线路的检测数据包括：客户端的IP地址、请求时延和请求结果，定时时长例如可以为一分钟、两分钟等，此处不做具体限定。

步骤212、根据每条线路的检测数据计算定时时长内每条线路的平均请求时延和请求成功率；

具体地，每条线路的平均请求时延为在定时时长内该线路发送的所有测速请求的请求时延的平均值，每条线路的请求成功率为在定时时长内该线路上处理结果为成功的测速请求的数量与该线路上经过的全部测速请求的数值的比值。例如，定时时长为1分钟，1分钟内某条线路发送了100个测速请求，则该线路在1分钟内的平均请求时延为这100个测速请求的请求时延的平均值；该线路在1分钟内的请求成功率为这100个测速请求中请求结果为成功的测速请求所占的比例。

步骤213、将计算得到的每条线路的平均请求时延及请求成功率存入数据库中；

例如定时时长为1分钟，则监控服务器每分钟将计算一次各个线路的平均请求时延及请求成功率，然后将计算得到的数据存入数据库中。

步骤214、从所述数据库中取出预设时长内存储的每条线路的所有平均请求时延及所有请求成功率；

预设时长可以大于定时时长，例如预设时长可以为10分钟、20分钟等，此处不做具体限定。如果定时时长为1分钟，预设时长为10分钟，则从数据库中取出的预设时长内存储的每个节点服务器的平均请求时延将有10个，请求成功率也有10个。

步骤215、统计每条线路的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量，以及统计每条线路的所有请求成功率中超过对应预设成功率的请求成功率的数量；

具体实现中，可以根据实际情况(例如带宽)为不同的线路为设置不同的时延阈值，为不同的线路设置不同的成功率阈值，统计预设时长内每条线路的超过对应预设时延阈值的平均请求时延的数量，以及每条线路的超过对应预设成功率的请求成功率的数量。

步骤216、判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值，以及判断超过对应预设成功率的请求成功率的数量是否大于预设数量阈值；若其中任意一个超过了预设数量阈值，则执行步骤217，否则，继续监控；

预设数量阈值可以根据定时时长、预设时长等实际数据进行设置。例如定时时长为1分钟，预设时长为10分钟，则预设时长内每个节点服务器将有10个平均请求时延数据，则预设数量阈值可以设置为5、6等数值，即10个平均请求时延数据如果有5个以上，或者6个以上超过对应预设时延阈值，则认为该节点服务器出现异常；或者10个请求成功率中如果有5个以上，或者6个以上超过对应预设成功率，则认为该节点服务器出现异常。

步骤217、生成第二告警提示消息；

步骤218、向所述运维平台发送所述第二告警提示消息。

其中，告警提示信息发送渠道可以包括邮件、短信、和/或社交平台或即时通信平台的消息等。

第二告警提示消息中可以包括异常线路的数量、客户端的IP地址等信息，，在向运维平台发送第二告警提示消息之前，监控服务器可以检查在预设时长内，是否已向运维平台发送了相同的第二告警提示信息，若已发送，则继续监控，若未发送，则向运维平台发送第二告警提示消息，以避免预设时长内重复发送相同告警，节省信令开销。

本实施例中，可以根据客户端发送的数据分析CDN中的节点服务器和/或线路是否出现异常，由于监控数据来自客户端，因而能直接反映用户侧的真实体验，及时发现异常。经研究表明，从时延、成功率等各个维度出发，同时监控CDN中的节点服务器及线路，告警精确率达到95％以上(即告警误报不到5％)，覆盖面达到95％以上(即漏掉未发现的问题不到5％)，且实时快速。

采用本实施例提供的方法，可以精确发现问题，定位问题，帮助运维人员快速解决问题，大大提升了CDN服务的稳定性，从而提升了CDN服务质量，同时大幅度缩短排查问题的时间，节省了运维成本。

实施例三

为了更好地实施以上方法，本发明实施例还提供一种监控服务器，如图3所示，本实施例的监控服务器包括：

接收单元301，用于接收客户端发送的数据检测报告；

解析单元302，用于解析所述数据检测报告得到检测数据；

计算单元303，用于根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；

异常判断单元304，用于将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；

告警单元305，用于当所述CDN中出现异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。

在一种可能的实现方式中，接收单元301具体用于，接收所述客户端通过触发预设业务中嵌入的测速脚本，以使得所述测速脚本向所述CDN发送测速请求得到的所述数据检测报告。

在一种可能的实现方式中，所述解析单元302具体用于，解析所述数据检测报告的标头字段得到所述客户端的互联网协议IP地址；解析所述数据检测报告的数据字段得到所述测速请求的请求时延和请求结果，以及处理所述测速请求的节点服务器的IP地址和标识ID。

在一种可能的实现方式中，所述计算单元303包括：

第一整理子单元，用于定时从所述检测数据中整理出每个节点服务器的检测数据，每个节点服务器的检测数据包括：节点服务器的IP地址、ID和请求时延；

第一计算子单元，用于根据每个节点服务器的检测数据计算定时时长内每个节点服务器的平均请求时延；

第一存储子单元，用于将计算得到的每个节点服务器的平均请求时延存入数据库中。

在一种可能的实现方式中，所述异常判断单元304包括：

第一取数子单元，用于从所述数据库中取出预设时长内存储的每个节点服务器的所有平均请求时延；

第一统计子单元，用于统计每个节点服务器的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量；

第一判断子单元，用于判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值；

第一确定子单元，用于当超过对应预设时延阈值的平均请求时延的数量大于预设数量阈值时，确定对应的节点服务器出现异常。

在一种可能的实现方式中，所述告警单305元包括：

第一生成子单元，用于当所述CDN中存在异常的节点服务器时，生成第一告警提示消息；

第一发送子单元，用于所述运维平台发送所述第一告警提示消息。

在一种可能的实现方式中，所述计算单元303包括：

第二整理子单元，用于定时从所述检测数据中整理出每条线路的检测数据，每条线路的检测数据包括：客户端的IP地址、请求时延和请求结果；

第二计算子单元，用于根据每条线路的检测数据计算定时时长内每条线路的平均请求时延和请求成功率；

第二存储子单元，用于将计算得到的每条线路的平均请求时延及请求成功率存入数据库中。

在一种可能的实现方式中，所述异常判断单元304包括：

第二取数子单元，用于从所述数据库中取出预设时长内存储的每条线路的所有平均请求时延及所有请求成功率；

第二统计子单元，用于统计每条线路的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量，以及统计每条线路的所有请求成功率中超过对应预设成功率的请求成功率的数量；

第二判断子单元，用于判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值，以及判断超过对应预设成功率的请求成功率的数量是否大于预设数量阈值；

第二确定子单元，用于当超过对应预设时延阈值的平均请求时延的数量大于预设数量阈值，或者超过对应预设成功率的请求成功率的数量大于预设数量阈值时，确定对应的线路出现异常。

在一种可能的实现方式中，所述告警单元305包括：

第二生成子单元，用于当所述CDN中存在异常的线路时，生成第二告警提示消息；

第二发送子单元，用于向所述运维平台发送所述第二告警提示消息。

需要说明的是，上述实施例提供的监控服务器在进行CDN监控时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的监控服务器与CDN监控方法属于同一构思，其具体实现过程详见方法实施例，此处不再赘述。

本实施例中，接收单元可以接收客户端发送的数据检测报告，解析单元及计算单元可以通过解析客户端发送的数据检测报告计算CDN中每个节点服务器的平均请求时延，以及CDN中每条线路的平均请求时延和请求成功率，异常判断单元可以据此分析CDN中是否存在异常的节点服务器或异常的线路，当CDN中存在出现异常的节点服务器或异常的线路时，告警单元向运维平台发送告警提示消息，即本实施例中，可以从客户端展开监控，监控数据来自客户端，因而能直接反映用户侧的真实体验，根据客户端发送的监控数据监控CDN是否出现异常，能够及时发现异常。

另外，本实施例中，监控服务器可以根据客户端反馈的数据同时分析CDN中的节点服务器及线路是否出现异常，经研究表明，从时延、成功率等各个维度出发，同时监控CDN中的节点服务器及线路，告警精确率达到95％以上(即告警误报不到5％)，覆盖面达到95％以上(即漏掉未发现的问题不到5％)，且实时快速。

采用本实施例提供的方法，可以精确发现问题，定位问题，帮助运维人员快速解决问题，大大提升了CDN服务的稳定性，从而提升了CDN服务质量，同时大幅度缩短排查问题的时间，节省了运维成本。

实施例四

相应的，本发明实施例还提供一种CDN监控系统，包括客户端，以及本发明实施例提供的任一种监控服务器，具体可参见实施例三，例如，可以如下：

客户端用于，通过触发预设业务中嵌入的测速脚本向所述CDN发送测速请求得到数据检测报告，将所述数据检测报告发送给所述监控服务器；

监控服务器用于，接收客户端发送的数据检测报告；解析所述数据检测报告得到检测数据；根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；当所述CDN中存在异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。

以上各个设备的具体实施可参见前面的实施例，在此不再赘述。

由于该CDN监控系统可以包括本发明实施例提供的任一种监控服务器，因此，可以实现本发明实施例所提供的任一种监控服务器所能实现的有益效果。

实施例五

本发明实施例还提供一种监控服务器，如图4所示，其示出了本发明实施例所涉及的服务器的结构示意图，具体来讲：

该服务器可以包括一个或者一个以上处理核心的处理器401、一个或一个以上计算机可读存储介质的存储器402、射频(Radio Frequency，RF)电路403、电源404、输入单元405、以及显示单元406等部件。本领域技术人员可以理解，图4中示出的服务器结构并不构成对服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器401是该服务器的控制中心，利用各种接口和线路连接整个服务器的各个部分，通过运行或执行存储在存储器402内的软件程序和/或模块，以及调用存储在存储器402内的数据，执行服务器的各种功能和处理数据，从而对服务器进行整体监控。可选的，处理器401可包括一个或多个处理核心；优选的，处理器401可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器401中。

存储器402可用于存储软件程序以及模块，处理器401通过运行存储在存储器402的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器402可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据服务器的使用所创建的数据等。此外，存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器402还可以包括存储器控制器，以提供处理器401对存储器402的访问。

RF电路403可用于收发信息过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器401处理；另外，将涉及上行的数据发送给基站。通常，RF电路403包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(SIM)卡、收发信机、耦合器、低噪声放大器(LNA，Low Noise Amplifier)、双工器等。此外，RF电路403还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(GSM，Global System of Mobilecommunication)、通用分组无线服务(GPRS，General Packet Radio Service)、码分多址(CDMA，Code Division Multiple Access)、宽带码分多址(WCDMA，Wideband CodeDivision Multiple Access)、长期演进(LTE，Long Term Evolution)、电子邮件、短消息服务(SMS，Short Messaging Service)等。

服务器还包括给各个部件供电的电源404(比如电池)，优选的，电源404可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源404还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该服务器还可包括输入单元405，该输入单元405可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，在一个具体的实施例中，输入单元405可包括触敏表面以及其他输入设备。触敏表面，也称为触摸显示屏或者触控板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面上或在触敏表面附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触敏表面可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器401，并能接收处理器401发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触敏表面。除了触敏表面，输入单元405还可以包括其他输入设备。具体地，其他输入设备可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

该服务器还可包括显示单元406，该显示单元406可用于显示由用户输入的信息或提供给用户的信息以及服务器的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元406可包括显示面板，可选的，可以采用液晶显示器(LCD，Liquid Crystal Display)、有机发光二极管(OLED，Organic Light-EmittingDiode)等形式来配置显示面板。进一步的，触敏表面可覆盖显示面板，当触敏表面检测到在其上或附近的触摸操作后，传送给处理器401以确定触摸事件的类型，随后处理器401根据触摸事件的类型在显示面板上提供相应的视觉输出。虽然在图4中，触敏表面与显示面板是作为两个独立的部件来实现输入和输入功能，但是在某些实施例中，可以将触敏表面与显示面板集成而实现输入和输出功能。

尽管未示出，服务器还可以包括摄像头、蓝牙模块等，在此不再赘述。具体在本实施例中，服务器中的处理器401会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器402中，并由处理器401来运行存储在存储器402中的应用程序，从而实现各种功能，如下：

接收客户端发送的数据检测报告；

解析所述数据检测报告得到检测数据；

根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；

将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；

当所述CDN中出现异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。

可选的，该处理器401可按如下方式解析所述数据检测报告：

解析所述数据检测报告的标头字段得到所述客户端的互联网协议IP地址；

解析所述数据检测报告的数据字段得到所述测速请求的请求时延和请求结果，以及处理所述测速请求的节点服务器的IP地址和标识ID。

可选的，该处理器401可按如下方式计算所述CDN中每个节点服务器的平均请求时延：

定时从所述检测数据中整理出每个节点服务器的检测数据，每个节点服务器的检测数据包括：节点服务器的IP地址、ID和请求时延；

根据每个节点服务器的检测数据计算定时时长内每个节点服务器的平均请求时延；

将计算得到的每个节点服务器的平均请求时延存入数据库中。

可选的，该处理器401可按照如下方式判断节点服务器是否异常：

统计每个节点服务器的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量；

判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值；

若大于，则确定对应的节点服务器出现异常。

可选的，当所述CDN中存在异常的节点服务器时，该处理器401生成第一告警提示消息；向运维平台发送所述第一告警提示消息。

可选的，该处理器401可按照如下方式计算所述CDN中每条线路的平均请求时延和请求成功率：

定时从所述检测数据中整理出每条线路的检测数据，每条线路的检测数据包括：客户端的IP地址、请求时延和请求结果；

根据每条线路的检测数据计算定时时长内每条线路的平均请求时延和请求成功率；

将计算得到的每条线路的平均请求时延及请求成功率存入数据库中。

可选的，该处理器401可按照如下方式判断线路是否异常：

从所述数据库中取出预设时长内存储的每条线路的所有平均请求时延及所有请求成功率；

统计每条线路的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量，以及统计每条线路的所有请求成功率中超过对应预设成功率的请求成功率的数量；

判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值，以及判断超过对应预设成功率的请求成功率的数量是否大于预设数量阈值；

当超过对应预设时延阈值的平均请求时延的数量大于预设数量阈值，或者超过对应预设成功率的请求成功率的数量大于预设数量阈值时，确定对应的线路出现异常。

可选的，当所述CDN中存在异常的线路时，该处理器401生成第二告警提示消息；向运维平台发送所述第二告警提示消息。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

由上可知，本实施例的服务器监控服务器可以接收客户端发送的数据检测报告，通过解析客户端发送的数据检测报告计算CDN中每个节点服务器的平均请求时延，以及CDN中每条线路的平均请求时延和请求成功率，从而分析CDN中是否存在异常的节点服务器或异常的线路，当CDN中存在出现异常的节点服务器或异常的线路时，向运维平台发送告警提示消息，即本发明实施例中，可以从客户端展开监控，监控数据来自客户端，因而能直接反映用户侧的真实体验，根据客户端发送的监控数据监控CDN是否出现异常，能够及时发现异常。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，RandomAccess Memory)、磁盘或光盘等。

以上对本发明实施例所提供的一种内容分发网络监控方法、监控服务器及系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (19)

1.一种内容分发网络CDN监控方法，其特征在于，包括：

接收客户端发送的数据检测报告；

解析所述数据检测报告得到检测数据；

根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；

将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；

当所述CDN中出现异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。

2.根据权利要求1所述的方法，其特征在于，所述接收所述客户端发送的数据检测报告包括：

接收所述客户端通过触发预设业务中嵌入的测速脚本，以使得所述测速脚本向所述CDN发送测速请求得到的所述数据检测报告。

3.根据权利要求2所述的方法，其特征在于，所述解析所述数据检测报告得到检测数据包括：

解析所述数据检测报告的标头字段得到所述客户端的互联网协议IP地址；

解析所述数据检测报告的数据字段得到所述测速请求的请求时延和请求结果，以及处理所述测速请求的节点服务器的IP地址和标识ID。

4.根据权利要求3所述的方法，其特征在于，所述根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延包括：

定时从所述检测数据中整理出每个节点服务器的检测数据，每个节点服务器的检测数据包括：节点服务器的IP地址、ID和请求时延；

根据每个节点服务器的检测数据计算定时时长内每个节点服务器的平均请求时延；

将计算得到的每个节点服务器的平均请求时延存入数据库中。

5.根据权利要求4所述的方法，其特征在于，所述将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常包括：

从所述数据库中取出预设时长内存储的每个节点服务器的所有平均请求时延；

统计每个节点服务器的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量；

判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值；

若大于，则确定对应的节点服务器出现异常。

6.根据权利要求5所述的方法，其特征在于，所述当所述CDN中存在异常的节点服务器或异常的线路时，向运维平台发送告警提示消息包括：

当所述CDN中存在异常的节点服务器时，生成第一告警提示消息；

向所述运维平台发送所述第一告警提示消息。

7.根据权利要求3所述的方法，其特征在于，所述根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率包括：

定时从所述检测数据中整理出每条线路的检测数据，每条线路的检测数据包括：客户端的IP地址、请求时延和请求结果；

根据每条线路的检测数据计算定时时长内每条线路的平均请求时延和请求成功率；

将计算得到的每条线路的平均请求时延及请求成功率存入数据库中。

8.根据权利要求7所述的方法，其特征在于，所述将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成率进行比较以判断对应的线路是否出现异常包括：

从所述数据库中取出预设时长内存储的每条线路的所有平均请求时延及所有请求成功率；

统计每条线路的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量，以及统计每条线路的所有请求成功率中超过对应预设成功率的请求成功率的数量；

判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值，以及判断超过对应预设成功率的请求成功率的数量是否大于预设数量阈值；

当超过对应预设时延阈值的平均请求时延的数量大于预设数量阈值，或者超过对应预设成功率的请求成功率的数量大于预设数量阈值时，确定对应的线路出现异常。

9.根据权利要求8所述的方法，其特征在于，所述当所述CDN中存在异常的节点服务器或异常的线路时，向运维平台发送告警提示消息包括：

当所述CDN中存在异常的线路时，生成第二告警提示消息；

向所述运维平台发送所述第二告警提示消息。

10.一种监控服务器，其特征在于，包括：

接收单元，用于接收客户端发送的数据检测报告；

解析单元，用于解析所述数据检测报告得到检测数据；

计算单元，用于根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；

异常判断单元，用于将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；

告警单元，用于当所述CDN中出现异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。

11.根据权利要求10所述的监控服务器，其特征在于，

所述接收单元具体用于，接收所述客户端通过触发预设业务中嵌入的测速脚本，以使得所述测速脚本向所述CDN发送测速请求得到的所述数据检测报告。

12.根据权利要求11所述的监控服务器，其特征在于，

所述解析单元具体用于，解析所述数据检测报告的标头字段得到所述客户端的互联网协议IP地址；解析所述数据检测报告的数据字段得到所述测速请求的请求时延和请求结果，以及处理所述测速请求的节点服务器的IP地址和标识ID。

13.根据权利要求12所述的监控服务器，其特征在于，所述计算单元包括：

第一整理子单元，用于定时从所述检测数据中整理出每个节点服务器的检测数据，每个节点服务器的检测数据包括：节点服务器的IP地址、ID和请求时延；

第一计算子单元，用于根据每个节点服务器的检测数据计算定时时长内每个节点服务器的平均请求时延；

第一存储子单元，用于将计算得到的每个节点服务器的平均请求时延存入数据库中。

14.根据权利要求13所述的监控服务器，其特征在于，所述异常判断单元包括：

第一取数子单元，用于从所述数据库中取出预设时长内存储的每个节点服务器的所有平均请求时延；

第一统计子单元，用于统计每个节点服务器的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量；

第一判断子单元，用于判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值；

第一确定子单元，用于当超过对应预设时延阈值的平均请求时延的数量大于预设数量阈值时，确定对应的节点服务器出现异常。

15.根据权利要求14所述的监控服务器，其特征在于，所述告警单元包括：

第一生成子单元，用于当所述CDN中存在异常的节点服务器时，生成第一告警提示消息；

第一发送子单元，用于所述运维平台发送所述第一告警提示消息。

16.根据权利要求12所述的监控服务器，其特征在于，所述计算单元包括：

第二整理子单元，用于定时从所述检测数据中整理出每条线路的检测数据，每条线路的检测数据包括：客户端的IP地址、请求时延和请求结果；

第二计算子单元，用于根据每条线路的检测数据计算定时时长内每条线路的平均请求时延和请求成功率；

第二存储子单元，用于将计算得到的每条线路的平均请求时延及请求成功率存入数据库中。

17.根据权利要求16所述的监控服务器，其特征在于，所述异常判断单元包括：

第二取数子单元，用于从所述数据库中取出预设时长内存储的每条线路的所有平均请求时延及所有请求成功率；

第二统计子单元，用于统计每条线路的所有平均请求时延中超过对应预设时延阈值的平均请求时延的数量，以及统计每条线路的所有请求成功率中超过对应预设成功率的请求成功率的数量；

第二判断子单元，用于判断超过对应预设时延阈值的平均请求时延的数量是否大于预设数量阈值，以及判断超过对应预设成功率的请求成功率的数量是否大于预设数量阈值；

第二确定子单元，用于当超过对应预设时延阈值的平均请求时延的数量大于预设数量阈值，或者超过对应预设成功率的请求成功率的数量大于预设数量阈值时，确定对应的线路出现异常。

18.根据权利要求17所述的监控服务器，其特征在于，所述告警单元包括：

第二生成子单元，用于当所述CDN中存在异常的线路时，生成第二告警提示消息；

第二发送子单元，用于向所述运维平台发送所述第二告警提示消息。

19.一种内容分发网络CDN监控系统，其特征在于，包括客户端与监控服务器；

所述客户端用于，通过触发预设业务中嵌入的测速脚本向所述CDN发送测速请求得到数据检测报告，将所述数据检测报告发送给所述监控服务器；

所述监控服务器用于，接收客户端发送的数据检测报告；解析所述数据检测报告得到检测数据；根据所述检测数据计算所述CDN中每个节点服务器的平均请求时延，以及根据所述检测数据计算所述CDN中每条线路的平均请求时延和请求成功率；将每个节点服务器的平均请求时延与对应的预设时延阈值进行比较以判断对应的节点服务器是否出现异常，以及将每条线路的平均请求时延与对应的预设时延阈值进行比较，并将每条线路的请求成功率与对应的预设成功率进行比较以判断对应的线路是否出现异常；当所述CDN中存在异常的节点服务器或异常的线路时，向运维平台发送告警提示消息。