直播业务的故障检测方法、装置、电子设备及可读存储介质与流程

本申请涉及计算机技术领域，尤其涉及云服务和大数据技术。

背景技术：

直播服务作为一种应用越来越广泛的云服务，已经深入各行各业，但直播过程中经常出现黑屏和卡顿等故障，严重影响用户体验。目前针对直播业务中的故障，往往是用户感知到后告知服务提供方，服务提供方再进行故障的检测定位。

技术实现要素：

本公开提供了一种直播业务的故障检测方法、装置、电子设备及可读存储介质。

根据本公开的一方面，提供了一种直播业务的故障检测方法，包括：

获取直播业务的日志数据；

按照待检测的多个维度，对所述日志数据进行统计，得到每个维度下的日志统计数据；

分别对所述每个维度下的日志统计数据进行解析，得到解析结果；

根据所述解析结果，确定所述每个维度下的日志统计数据对应的直播链路部分是否存在故障。

根据本公开的另一方面，提供了一种直播业务的故障检测装置，包括：

获取模块，用于获取直播业务的日志数据；

统计模块，用于按照待检测的多个维度，对所述日志数据进行统计，得到每个维度下的日志统计数据；

解析模块，用于分别对所述每个维度下的日志统计数据进行解析，得到解析结果；

确定模块，用于根据所述解析结果，确定所述每个维度下的日志统计数据对应的直播链路部分是否存在故障。

根据本公开的另一方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的方法。

根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行如上所述的方法。

根据本申请的技术解决了目前直播业务的故障检测效率低的问题，提高了故障检测效率。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是本申请实施例中的直播链路的示意图；

图2是本申请实施例中的日志收集方案的示意图；

图3是本申请实施例中的日志收集过程的示意图；

图4是本申请实施例中的直播业务的故障检测方法的示意图；

图5是本申请实施例中的故障检测定位方案的示意图；

图6是本申请实施例中的数据展示过程的示意图；

图7是本申请实施例中的直播业务的故障检测装置的框图；

图8是用来实现本申请实施例的直播业务的故障检测方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例可以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。说明书以及权利要求中“和/或”表示所连接对象的至少其中之一。

为了便于理解本申请实施例，首先说明以下内容。

本申请实施例中，如图1所示，直播业务的直播链路可以包括但不限于：推流端、推流侧的内容分发网络(contentdeliverynetwork，cdn)、直播服务器(livestreamingservice，lss)源站、客户源站、播放端和拉流侧的cdn等。其中，lss源站可以包括直播流媒体服务器livesrs、推流组件inner和拉流组件outer。推流侧的cdn可以将推流端的直播流转推到lss源站的livesrs。推流端可以经直推源站将直播流推送至lss源站的livesrs。客户源站可以通过外网拉流从lss源站的livesrs获取直播流，和/或通过边缘拉流从拉流侧的cdn获取直播流。拉流侧的cdn可以经lss源站的livesrs、inner和outer获取直播流并转推到播放端。

为了高效检测定位直播业务的故障，本申请实施例中建立的日志系统可以将推流侧、cdn侧和拉流侧的日志数据整合在一起并统一管理和存储，以支持对全链路的日志数据进行检索跟踪。如图2所示，本申请实施例在收集日志数据时，可以全量收集直播链路所涉及的网络组件、机器等中的日志数据，例如，对于推流侧和拉流侧的cdn，可以采用cdn日志组件收集日志数据；对于lss源站，可以采用filebeat作为日志采集组件。filebeat是用于转发和集中日志数据的轻量级传送工具，可以监视指定的日志文件或位置，并收集日志事件。本实施例中的日志系统可以使用kafka聚合和处理日志数据。

可选的，如图3所示，本实施例中的日志收集过程可包括：s31：针对直播全链路，使用kafka聚合日志数据；s32：按照场景特点，判断日志数据中是否存在特征字段；比如主播推流场下，相应日志数据中是否存在推流失败、数据包重传等字段，或者第三方源站拉流下，相应日志数据中是否存在域名解析失败等字段；s33：若存在特征字段，则提取特征字段，并检验所提取的特征字段的合法性和有效性，对异常字段值进行过滤，并按预设格式构造日志提取记录；s34：若不存在特征字段，则正则提取所有字段；s35：封装日志记录对象；s36：将日志记录对象进行存储。此处存储可以是使用分布式文档数据库es存储数据，并保证存储的唯一性。此处存储的数据即日志数据可以用于直播业务的故障检测定位。

下面结合附图对本申请实施例进行详细说明。

请参见图4，图4是本申请实施例提供的一种直播业务的故障检测方法的流程图，该方法由电子设备执行，如图4所示，该方法包括如下步骤：

步骤41：获取直播业务的日志数据。

本申请实施例可以应用于直播业务的故障检测定位场景中。直播业务可以包括但不限于赛事直播、资讯直播、娱乐直播、游戏直播等。此步骤可以从日志系统收集的全量日志数据中获取所需的日志数据。

步骤42：按照待检测的多个维度，对日志数据进行统计，得到每个维度下的日志统计数据。

本申请实施例中，上述多个维度可以包括但不限于以下至少两项：域名、运营商、地区、直播流等。其中，域名又称网域，是由一串用点分隔的名字组成的网络中某计算机的名称，比如为xxx.com，可以涉及多条直播流。不同的直播流可以通过各自标识比如id1、id2等区分。运营商可以理解为直播服务的提供方，不同运营商在同一时间、同一地点所提供的服务质量通常不同。地区可以基于不同省份、城市等划分。

步骤43：分别对每个维度下的日志统计数据进行解析，得到解析结果。

可选的，在对日志统计数据进行解析时，可以是基于日志统计数据中的直播状态指标进行解析。该直播状态指标可以包括但不限于帧率、黑屏率、卡顿率、中央处理器(centralprocessingunit，cpu)利用率、网卡利用率等等。该直播状态指标可以通过日志数据中的标签字段体现。

一种实施方式中，上述解析结果可以为日志统计数据中的帧率、黑屏率和/或卡顿率。

步骤44：根据解析结果，确定每个维度下的日志统计数据对应的直播链路部分是否存在故障。

可选的，此步骤在确定直播链路部分是否存在故障时，可以结合业务特征进行判断。比如相比于资讯直播，游戏直播的实时性要求会更高，此时若基于卡顿率进行故障判断，则游戏直播的卡顿率要求比资讯直播的卡顿率要求高。

上述每个维度下的日志统计数据对应的直播链路部分可理解为每个维度匹配的直播链路部分。例如，以域名yyy.com为例，该yyy.com下的日志统计数据对应的直播链路部分即为该yyy.com匹配的直播链路部分；或者以运营商1为例，该运营商1下的日志统计数据对应的直播链路部分即为该运营商1匹配的直播链路部分；或者以直播流id1为例，该直播流id1下的日志统计数据对应的直播链路部分即为该直播流id1匹配的直播链路部分。

本申请实施例的故障检测方法，通过获取直播业务的日志数据，按照待检测的多个维度，对日志数据进行统计，得到每个维度下的日志统计数据，并分别对每个维度下的日志统计数据进行解析，根据解析结果，确定每个维度下的日志统计数据对应的直播链路部分是否存在故障，可以主动实现不同维度匹配的直播链路部分的故障检测定位，从而提高了故障检测效率。

比如参见图5所示，对于某直播业务的拉流链路，可以采用四元组(域名domain，运营商ism，地区prov，时间戳ts)，即分别按照域名、运营商和地区，对相应时间段内的拉流链路的日志数据进行解析，以进行故障异常判断。

本申请实施例中，由于直播链路越流畅时表明相应直播链路出现故障的可能性越小，因此可以根据直播链路的流畅度来确定其是否存在故障。可选的，上述分别对每个维度下的日志统计数据进行解析，得到解析结果的过程可以包括：

分别从每个维度下的日志统计数据中提取直播状态指标；其中，该直播状态指标可以包括但不限于帧率、黑屏率、卡顿率等；

根据提取的直播状态指标，确定每个维度下的日志统计数据对应的直播链路部分的流畅度。

需指出的，以提取的直播状态指标包括帧率、黑屏率和卡顿率为例，可以根据业务场景和预先配置，利用帧率、黑屏率和卡顿率计算得到相应的流畅度。对于计算流畅度的方式，本申请实施例不进行限制，可以基于实际需求配置。

可选的，在确定流畅度之后，可以采用与预设阈值比较的方式，确定相应直播链路部分是否存在故障。比如，假设确定的直播链路部分1的流畅度为a，预设阈值为k，则若a大于或等于k，则可确定直播链路部分1不存在故障，而若a小于k，则可确定直播链路部分1存在故障。这样借助流畅度，可以准确确定出相应链路是否存在故障。

本申请实施例中，为了方便用户了解故障情况，降低排障的时间成本，可以对故障相关信息进行展示，比如通过图表、文本等进行展示。

可选的，本申请实施例中的故障检测方法还可以包括：

针对所述每个维度，在预置页面展示以下至少一项：

从每个维度下的日志统计数据中提取的直播状态指标；

每个维度下的日志统计数据对应的直播链路部分的流畅度；

每个维度下的日志统计数据对应的直播链路部分是否存在故障。

比如参见图6，在待检测维度包括运营商、域名、地区时，可以采用图5所述的预置页面分别展示运营商xxx、域名yyy.com以及地区zzz匹配的直播链路部分的流程度、带宽、黑屏率、是否故障。

这样借助展示功能，可以方便用户了解故障情况，降低排障的时间成本。一具体实例中，通过本方案可以将原人工排障所需的几十分钟缩短至几分钟。

可选的，为了方便用户实时了解是否存在直播故障情况，可以每个预设时间比如5分钟、6分钟等，获取一次直播业务的最新的日志数据。上述步骤41可以包括：每隔预设时间，获取直播业务的日志数据。该预设时间可以基于实际需求设置。

请参见图7，图7是本申请实施例提供的一种直播业务的故障检测装置的结构示意图，如图7所示，该故障检测装置70包括：

获取模块71，用于获取直播业务的日志数据；

统计模块72，用于按照待检测的多个维度，对所述日志数据进行统计，得到每个维度下的日志统计数据；

解析模块73，用于分别对所述每个维度下的日志统计数据进行解析，得到解析结果；

确定模块74，用于根据所述解析结果，确定所述每个维度下的日志统计数据对应的直播链路部分是否存在故障。

可选的，所述解析模块73包括：

提取单元，用于分别从所述每个维度下的日志统计数据中提取直播状态指标；

确定单元，用于根据提取的直播状态指标，确定所述每个维度下的日志统计数据对应的直播链路部分的流畅度。

可选的，该故障检测装置70还包括：

展示模块，用于针对所述每个维度，在预置页面展示以下至少一项：

从所述每个维度下的日志统计数据中提取的直播状态指标；

所述每个维度下的日志统计数据对应的直播链路部分的流畅度；

所述每个维度下的日志统计数据对应的直播链路部分是否存在故障。

可选的，所述多个维度可以包括以下至少两项：

域名、运营商、地区、直播流。

可选的，所述获取模块71具体用于：

每隔预设时间，获取所述直播业务的日志数据。

可理解的，本申请实施例的直播业务的故障检测装置70，可以实现上述图4所示方法实施例中实现的各个过程，以及达到相同的有益效果，为避免重复，这里不再赘述。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图8所示，是根据本申请实施例的直播业务的故障检测方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图8所示，该电子设备包括：一个或多个处理器801、存储器802，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示gui的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图8中以一个处理器801为例。

存储器802即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的直播业务的故障检测方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的直播业务的故障检测方法。

存储器802作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的直播业务的故障检测方法对应的程序指令/模块(例如，附图7所示的获取模块71、统计模块72、解析模块73和确定模块74)。处理器801通过运行存储在存储器802中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的直播业务的故障检测方法。

存储器802可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据直播业务的故障检测的电子设备的使用所创建的数据等。此外，存储器802可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器802可选包括相对于处理器801远程设置的存储器，这些远程存储器可以通过网络连接至故障检测的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

用于直播业务的故障检测的电子设备还可以包括：输入装置803和输出装置804。处理器801、存储器802、输入装置803和输出装置804可以通过总线或者其他方式连接，图8中以通过总线连接为例。

输入装置803可接收输入的数字或字符信息，以及产生与故障检测的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置804可以包括显示设备、辅助照明装置(例如，led)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(lcd)、发光二极管(led)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用asic(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(pld))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系，服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

根据本申请实施例的技术方案，通过获取直播业务的日志数据，按照待检测的多个维度，对日志数据进行统计，得到每个维度下的日志统计数据，并分别对每个维度下的日志统计数据进行解析，根据解析结果，确定每个维度下的日志统计数据对应的直播链路部分是否存在故障，可以主动实现不同维度匹配的直播链路部分的故障检测定位，从而提高了故障检测效率。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。