CN116662129B

CN116662129B - 日志获取方法、装置、芯片、电子设备及介质

Info

Publication number: CN116662129B
Application number: CN202211364332.9A
Authority: CN
Inventors: 赵高阁
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-11-02
Filing date: 2022-11-02
Publication date: 2024-07-23
Anticipated expiration: 2042-11-02
Also published as: CN116662129A

Abstract

本申请实施例提供了一种日志获取方法、装置、芯片、电子设备及介质，日志获取方法应用于第一电子设备，第一电子设备为第一类型的电子设备，该方法包括：获取第一故障类型，第一故障类型用于描述第一电子设备或者与第一电子设备相连的第二电子设备所存在故障的故障类型；根据第一故障类型获得第一信息，第一信息用于描述与第一故障类型相关的设备类型；获取符合第一信息的电子设备的日志文件。本申请实施例有助于收集电子设备发生故障时的故障相关日志文件。

Description

日志获取方法、装置、芯片、电子设备及介质

技术领域

本申请涉及电子设备技术领域，特别涉及一种日志获取方法、装置、芯片、电子设备及介质。

背景技术

电子设备在运行过程中可能会发生故障。可行地，可以通过日志文件对故障进行分析。如此，有必要提供一种日志获取方法。

发明内容

本申请实施例提供了一种日志获取方法、装置、芯片、电子设备及介质，有助于收集电子设备发生故障时的故障相关日志文件。

第一方面，本申请实施例提供一种日志获取方法，应用于第一电子设备，日志获取方法包括：获取第一故障类型，第一故障类型用于描述第一电子设备或者与第一电子设备相连的第二电子设备所存在故障的故障类型；根据第一故障类型获得第一信息，第一信息用于描述与第一故障类型相关的设备类型；获取符合第一信息的电子设备的日志文件。

可选地，日志获取方法还包括：在第三电子设备与第一电子设备相连、且第三电子设备符合第一信息的情况下，将第一信息发送给第三电子设备。

可选地，第一电子设备和第三电子设备均为第一类型的电子设备，第二电子设备为第二类型的电子设备。

可选地，根据第一故障类型获得第一信息这一步骤可以包括：根据预先设置好的故障类型和设备类型间的关联关系，获取与第一故障类型相关联的设备类型，以得到第一信息。

可选地，第一电子设备为第一类型的电子设备，第二电子设备为第二类型的电子设备；获取符合第一信息的电子设备的日志文件这一步骤可以包括：获取与第一电子设备相连、且符合第一信息的第二类型的电子设备的日志文件。

可选地，获取符合第一信息的电子设备的日志文件这一步骤可以包括：获取第一电子设备的日志文件。

可选地，获取符合第一信息的电子设备的日志文件这一步骤可以包括：获取符合第一信息的电子设备的、与第一故障类型相关的日志文件，并将获取到的日志文件对应于第一电子设备或者第二电子设备所存在的故障的标识；日志获取方法还包括：将获取的日志文件上传至预设的日志管理模块。

可选地，获取第一故障类型这一步骤可以包括：获取用于表示第一电子设备或者第二电子设备存在故障的故障提单信息；获取故障提单信息包括的第一故障类型。

可选地，日志获取方法还包括：检测第一电子设备在运行过程中是否存在故障；获取第一故障类型这一步骤可以包括：在检测到第一电子设备在运行过程中存在故障的情况下，获取检测到的故障的第一故障类型。

第二方面，本申请实施例提供一种日志获取方法，应用于第一电子设备，日志获取方法包括：接收第四电子设备发来的第二信息，其中，第二信息由第四电子设备根据第四电子设备或者与第四电子设备相连的第五电子设备所存在故障的第二故障类型得到，第二信息用于描述与第二故障类型相关的设备类型；获取符合第二信息的电子设备的日志文件。

可选地，第一电子设备和第四电子设备均为第一类型的电子设备，第五电子设备为第二类型的电子设备。

可选地，接收第四电子设备发来的第二信息这一步骤可以包括：接收第四电子设备在确定出第一电子设备符合第二信息的情况下发来的第二信息。

可选地，日志获取方法还包括：确定第一电子设备是否符合第二信息；在确定出第一电子设备符合第二信息的情况下，执行获取符合第二信息的电子设备的日志文件的步骤。

可选地，第一电子设备为第一类型的电子设备；获取符合第二信息的电子设备的日志文件这一步骤可以包括：获取与第一电子设备相连、且符合第二信息的第二类型的电子设备的日志文件。

可选地，获取符合第二信息的电子设备的日志文件这一步骤可以包括：获取第一电子设备的日志文件。

可选地，获取符合第二信息的电子设备的日志文件这一步骤可以包括：获取符合第二信息的电子设备的、与第二故障类型相关的日志文件，并将获取到的日志文件对应于第四电子设备或者第五电子设备所存在的故障的标识；日志获取方法还包括：将获取的日志文件上传至预设的日志管理模块。

第三方面，本申请实施例提供一种日志获取装置，应用于第一电子设备，日志获取装置包括：第一获取模块，用于获取第一故障类型，第一故障类型用于描述第一电子设备或者与第一电子设备相连的第二电子设备所存在故障的故障类型；第二获取模块，用于根据第一故障类型获得第一信息，第一信息用于描述与第一故障类型相关的设备类型；第三获取模块，用于获取符合第一信息的电子设备的日志文件。

第四方面，本申请实施例提供一种日志获取装置，应用于第一电子设备，日志获取装置包括：接收模块，用于接收第四电子设备发来的第二信息，其中，第二信息由第四电子设备根据第四电子设备或者与第四电子设备相连的第五电子设备所存在故障的第二故障类型得到，第二信息用于描述与第二故障类型相关的设备类型；获取模块，用于获取符合第二信息的电子设备的日志文件。

第五方面，本申请实施例提供一种电子芯片，包括：处理器，其用于执行存储在存储器上的计算机程序指令，其中，当计算机程序指令被处理器执行时，触发电子芯片执行如第一方面中任一项的方法。

第六方面，本申请实施例提供一种电子芯片，包括：处理器，其用于执行存储在存储器上的计算机程序指令，其中，当计算机程序指令被处理器执行时，触发电子芯片执行如第二方面中任一项的方法。

第七方面，本申请实施例提供一种电子设备，电子设备包括用于存储计算机程序指令的存储器、用于执行计算机程序指令的处理器和通信装置，其中，当计算机程序指令被该处理器执行时，触发电子设备执行如第一方面中任一项的方法。

第八方面，本申请实施例提供一种电子设备，电子设备包括用于存储计算机程序指令的存储器、用于执行计算机程序指令的处理器和通信装置，其中，当计算机程序指令被该处理器执行时，触发电子设备执行如第二方面中任一项的方法。

第九方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如第一方面中任一项的方法。

第十方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如第二方面中任一项的方法。

第十一方面，本申请实施例提供一种计算机程序产品，计算机程序产品包括计算机程序，当计算机程序在计算机上运行时，使得计算机执行如第一方面中任一项的方法。

第十二方面，本申请实施例提供一种计算机程序产品，计算机程序产品包括计算机程序，当计算机程序在计算机上运行时，使得计算机执行如第二方面中任一项的方法。

本申请实施例有助于收集电子设备发生故障时的故障相关日志文件。

附图说明

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

图1为本申请一个实施例提供的一种电子设备的结构示意图；

图2为本申请一个实施例提供的一种组网设备间的连接关系的示意图；

图3(a)和图3(b)为本申请一个实施例提供的手动提单下的一种日志获取流程的示意图；

图4为本申请一个实施例提供的自动提单下的一种日志获取流程的示意图；

图5为本申请一个实施例提供的一种手动提单下的日志获取流程的时序图；

图6为本申请一个实施例提供的一种自动提单下的日志获取流程的时序图；

图7为本申请一个实施例提供的一种日志获取方法的流程示意图；

图8为本申请一个实施例提供的另一种日志获取方法的流程示意图。

具体实施方式

为了更好的理解本申请的技术方案，下面结合附图对本申请实施例进行详细描述。

应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“至少一个”是指一个或者多个，“多个”是指两个或两个以上。本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。其中A，B可以是单数或者复数。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。“以下至少一项”及其类似表达，是指的这些项中的任意组合，包括单项或复数项的任意组合。例如，a，b和c中的至少一项可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。

应当理解，尽管在本申请实施例中可能采用术语第一、第二等来描述设定阈值，但这些设定阈值不应限于这些术语。这些术语仅用来将设定阈值彼此区分开。例如，在不脱离本申请实施例范围的情况下，第一设定阈值也可以被称为第二设定阈值，类似地，第二设定阈值也可以被称为第一设定阈值。

本申请的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。

本申请任一实施例提供的日志获取方法可以应用于图1所示的电子设备100中。图1示出了电子设备100的结构示意图。

电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。电源管理模块141用于连接电池142，充电管理模块140与处理器110。电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(codedivision multiple access，CDMA)，宽带码分多址(wideband code division multipleaccess，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidounavigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellitesystem，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

ISP用于处理摄像头193反馈的数据。摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备100的各种功能应用以及数据处理。

电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。电子设备100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，电子设备100根据压力传感器180A检测所述触摸操作强度。电子设备100也可以根据压力传感器180A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。

陀螺仪传感器180B可以用于确定电子设备100的运动姿态。气压传感器180C用于测量气压。在一些实施例中，电子设备100通过气压传感器180C测得的气压值计算海拔高度，辅助定位和导航。磁传感器180D包括霍尔传感器。加速度传感器180E可检测电子设备100在各个方向上(一般为三轴)加速度的大小。距离传感器180F，用于测量距离。电子设备100可以通过红外或激光测量距离。在一些实施例中，拍摄场景，电子设备100可以利用距离传感器180F测距以实现快速对焦。接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。环境光传感器180L用于感知环境光亮度。指纹传感器180H用于采集指纹。电子设备100可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。温度传感器180J用于检测温度。

触摸传感器180K，也称“触控器件”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位置不同。

SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和电子设备100的接触和分离。电子设备100可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口195可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口195可以同时插入多张卡。所述多张卡的类型可以相同，也可以不同。SIM卡接口195也可以兼容不同类型的SIM卡。SIM卡接口195也可以兼容外部存储卡。电子设备100通过SIM卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，电子设备100采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在电子设备100中，不能和电子设备100分离。电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。

第一类型的电子设备，比如可以有手机、平板电脑、个人电脑(PersonalComputer，PC)等，比如可以被称作“富设备”。第二类型的电子设备，比如可以有电子手表、蓝牙耳机等，比如可以被称作“瘦设备”。

富设备可具有发起故障提单(或称故障处理通知、故障反馈等，提单类型可以有自动提单和手动提单)的功能、产生故障事件信息(或简称故障事件)的能力、获取(或称收集)日志文件的功能。如此，富设备可用于获取日志文件(或简称日志)，比如可以获取本机日志文件和与本机相连的瘦设备的日志文件。富设备除了可以获取日志文件，还可上传日志文件，比如可将获取的日志文件上传至云端服务器等预设的日志管理模块/设备。

瘦设备可以不具有或者具有但不使用发起故障提单的功能、产生故障事件信息的能力、获取日志文件的功能。如此，可以由与瘦设备所连接的富设备来获取并上传该瘦设备的日志文件。

富设备作为日志文件的采集方，瘦设备作为日志文件的被采集方。

一个实施例中，若电子设备的设备类型在预设的至少一个设备类型中，该电子设备为富设备，否则为瘦设备。预设的至少一个设备类型可以包括手机、平板电脑、个人电脑等的设备类型，且不包括电子手表、蓝牙耳机等的设备类型。

一个富设备可以连接一个或者多个瘦设备，比如一个智能手机可以同时连接一个蓝牙耳机和一个智能手表。一个富设备还可以连接其他的富设备，比如一个智能手机可以连接一个平板电脑。

图2示出了组网设备间的连接关系的示意图，请参考图2，在网的设备可以有手机A201、蓝牙耳机A 202、智能手表A 203、手机B 204、蓝牙耳机B 205、智能手表B 206。其中，手机A201作为富设备，分别连接蓝牙耳机A 202和智能手表A 203这两个瘦设备，手机B 204作为富设备，分别连接蓝牙耳机B 205和智能手表B 206这两个瘦设备，且手机A 201和手机B204这两个富设备相连接。相连接的设备间保持通信连接。

可行地，设备之间可以通过无线信号和/或有线线路以保持通信连接。基于这些设备间的连接关系，这些设备均可作为组网设备。相连接的组网设备间可以传递信息。

为便于实现设备分布式故障检测功能，组网的某个设备存在故障(比如在设备运行过程中发生故障)时，可以将故障事件信息传递给在网的其他设备。一个实施例中，故障事件信息可以包括故障提单标识、故障类型信息、设备类型信息等。设备类型信息可以包括故障所涉及的设备类型，即可以包括与故障的故障类型相关的设备类型。可行地，对于分布式故障，可以理解为当某一组网设备发生某种故障时，除了获取该组网设备的故障相关日志文件，还有必要获取其他相关组网设备的故障相关日志文件，从而需要在组网设备间传递故障事件信息。通过对这些日志文件进行分析，可分析故障原因。如此，这种类型的故障可以作为分布式故障。一个实施例中，分布式故障比如可以为蓝牙耳机的蓝牙功能故障。

一个实施例中，一些类型的故障可以不作为分布式故障，组网设备发生这些类型的故障时，可以无需获取其他相关组网设备的故障相关日志文件，从而可以无需在组网设备间传递故障事件信息。

一个实施例中，在设备存在故障时，可以判断该故障是否为分布式故障，若为分布式故障则可以将相应的故障事件信息转发给在网的其他富设备，否则不进行故障事件信息的转发。

一种实现方式中，为了能够有效收集故障发生时故障所涉及的在网富设备和瘦设备的日志文件，可以通过无区别的日志获取方式，无区别的收集所有在网的富设备和瘦设备的日志文件。比如，产生故障事件信息的富设备可以获取并上传本机日志文件和相连各个瘦设备的日志文件，以及将分布式故障的故障事件信息转发给在网的每一个其他富设备。其他富设备在接收到故障事件信息后，可以获取并上传该其他富设备的本机日志文件和与该其他富设备相连的各个瘦设备的日志文件。

可行地，对应于故障发现方式的不同(人为发现设备故障/设备自动检测故障)，故障提单方式可以有两种，分别为手动提单和自动提单。

对于手动提单，在一种实现方式中，用户(User)可以通过富设备手动提单。其中，富设备故障时可通过该富设备进行手动提单，瘦设备故障时刻通过该瘦设备连接的富设备进行手动提单。

一个实施例中，富设备上可以安装有用于手动提单的应用程序，其可作为用于反馈设备故障的工具。

一个实施例中，可以对测试版本下的设备故障进行提单，不对正常发售版本下的设备故障进行提单。如此，在版本内测期间，富设备可以实现针对分布式故障的自动提单，且富设备上可以安装有用于手动提单的应用程序，比如手机上可以安装有“BetaClub APP”这一故障提单应用程序(或称手动提单应用程序)。用户通过BetaClub APP，可以反馈内测期间关于版本上的故障问题。对于正常发售版本，富设备可以不针对分布式故障进行自动提单，且富设备上不安装用于手动提单的应用程序。

对于自动提单，在一种实现方式中，富设备可以自动检测故障，比如富设备可以自动检测本机运行(或称使用)时是否发生异常，并在检测到故障时进行自动提单。富设备自动检测到故障时，可以针对检测到的故障自动生成提单(即生成自动提单)。

一种实现方式中，对应手动提单的日志获取流程可以包括：

当用户发现设备在使用过程中出现异常(即存在故障、发生故障)时，通过出现异常的富设备、或者与出现异常的瘦设备相连的富设备上安装的“BetaClub APP”这一故障提单应用程序进行设备故障手动提单。用户进行手动提单时可以输入设备所出现异常的故障类型。

1.1)用户手动提单后，富设备的BetaClub APP可以依据用户输入的故障类型生成相应的故障类型信息(比如可以记作“metricId”)，将metricId传递给本机的Hiview。BetaClub APP还可以将手动提单的提单号(即手动提单号)传递给Hiview。

根据故障类型得到的metricId可用于日志收集，使得收集的日志文件为针对设备所存在故障的相关日志文件，以便于后续可根据收集的日志进行故障分析。

提单号可用于跟踪同一设备故障，有助于汇总针对同一设备故障所获取的各个日志文件。

一个实施例中，Hiview可以是一个跨平台的终端设备维测服务集。

一个实施例中，相比于native_hiview，Hiview可以更面向用户，而native_hiview更面向底层。可行地，Hiview可以为设备中的更面向用户的顶层模块/组件，与native_hiview不同。native_hiview可以为设备中的更面向底层的基础模块/组件。

一个实施例中，在用户手动提单情况下可由Hiview获取本机日志文件，在设备自动提单情况下可由native_hiview获取本机日志文件。

一个实施例中，Hiview可以与其他第三方应用软件交互，则Hiview可用于获取与本机相连接的任一瘦设备的日志文件，具体可通过瘦设备上安装的应用软件来获取瘦设备的日志文件。

metricId可用于反映手动提单下的设备故障的故障类型，并与“eventId”这一故障类型信息相区分。eventId可用于反映自动提单下的设备故障的故障类型。

1.2)富设备的Hiview得到metricId后，可以根据metricId收集并打包上传本机日志文件、与本机相连接的各个瘦设备的日志文件。Hiview还可以判断设备存在的故障是否为分布式故障。如果是分布式故障，可以生成相应的故障事件信息(比如可以记作“951故障事件”)。生成的故障事件信息可以包括metricId和提单号。如果不是分布式故障，可以结束。

“951”可用于标识测试版本下的手动提单的设备分布式故障，使得“951故障事件”可以与“950故障事件”这一故障事件信息相区分。“950”可用于标识测试版本下的自动提单的设备分布式故障。

一个实施例中，可以通过判断提单的相应标识信息是否包括“951”和“950”中的任意一个，来确定设备存在的故障是否为分布式故障。

一个实施例中，生成的故障事件信息可以为字符串，该字符串至少可以由metricId和提单号组成。

1.3)富设备的Hiview将951故障事件传递给本机的native_hiview。native_hiview收到951故障事件后，可以将951故障事件分别发送给在网的其他富设备。

1.4)其他富设备的native_hiview收到951故障事件后，可以将951故障事件中携带的metricId发送给本机的Hiview，由Hiview依据metricId收集并上传本机日志文件以及与本机相连接的各个瘦设备的日志文件。

一个实施例中，1.2)中获取的日志文件和1.4)中获取的日志文件可以对应于同一提单号，比如均对应于手动提单的提单号，以便于不同富设备上传针对同一设备分布式故障所收集的日志文件时，可以根据提单号对这些日志文件进行统一分析以分析故障原因。

举例来说，请参考图2，假设用户发现蓝牙耳机A 202发生蓝牙故障，则可以通过手机A 201进行手动提单，并输入蓝牙故障的故障类型。手机A 201根据故障类型可以生成相应的951故障事件(含根据故障类型得到的metricId)。手机A 201可以根据metricId获取本机日志文件，以及获取所连接的蓝牙耳机A 202的日志文件和智能手表A 203的日志文件。手机A 201还可以将生成的951故障事件传递给所连接的富设备手机B 204，手机B 204根据接收到的951故障事件中的metricId，获取本机日志文件，以及获取所连接的蓝牙耳机B205的日志文件和智能手表B 206的日志文件。

一种实现方式中，对应自动提单的日志获取流程可以包括：

2.1)富设备在运行时检测本机是否发生故障，在检测到本机发生故障时进行自动提单，并针对发生的分布式故障生成相应的故障事件信息(比如可以记作“950故障事件”)。生成的故障事件信息可以包括eventId和自动提单号。

“950”可用于标识自动提单下的设备分布式故障。eventId可用于反映自动提单下的设备故障的故障类型。

一个实施例中，富设备可以针对发生的分布式故障进行自动提单，对非分布式故障不进行自动提单。另一实施例中，富设备可以在自动提单后，判断设备存在的故障是否为分布式故障，若是可以生成相应的950故障事件，否则不生成950故障事件。

一个实施例中，生成的故障事件信息可以为字符串，该字符串至少可以由eventId和自动提单号组成。

一个实施例中，可以由富设备的native_hiview产生950故障事件。另一实施例中，可以富设备将生成的950故障事件传递给本机的native_hiview。

2.2)富设备的native_hiview根据950故障事件中的eventId收集本机日志文件，并将eventId传递给本机的Hiview，Hiview根据eventId收集与本机相连接的各个瘦设备的日志文件。收集的这些日志文件可被打包上传。

2.3)富设备的native_hiview将950故障事件分别发送给在网的其他富设备。

2.4)其他富设备的native_hiview收到950故障事件后，可以根据950故障事件中携带的metricId收集本机日志文件，并将eventId传递给本机的Hiview，由Hiview根据eventId收集与本机相连接的各个瘦设备的日志文件。收集的这些日志文件可被打包上传。

一个实施例中，2.2)中获取的日志文件和2.4)中获取的日志文件可以对应于同一提单号，比如均对应于2.1)中自动提单的提单号，以便于不同富设备上传针对同一设备分布式故障所收集的日志文件时，可以根据提单号对这些日志文件进行统一分析以分析故障原因。

在无区别的日志获取方式中，无论是手动提单还是自动提单，产生故障事件信息的富设备可以获取本机日志文件和相连各个瘦设备的日志文件，以及将分布式故障的故障事件信息转发给在网的每一个其他富设备，以使其他富设备获取本机日志文件和相连各个瘦设备的日志文件。这一实现方式可以实现故障发生时对故障所涉及的在网富设备和瘦设备的日志文件的有效收集。

考虑到设备分布式故障通常会有其特定的发生设备，即设备的分布式故障涉及有特定的设备类型，而非全部设备类型，从而可以根据故障所涉及设备的日志文件进行故障分析，不根据故障所未涉及设备的日志文件进行故障分析。

对于无区别的日志获取方式，其不仅获取到的故障所涉及的在网富设备和瘦设备的日志文件，还会获取到故障所未涉及的在网富设备和瘦设备的日志文件(这些日志文件可被认为是进行故障分析的无效日志文件)，则这一实现方式通常会相应带来功耗上的浪费、数据处理压力的增加，不利于技术人员分析故障。

比如，通过执行用于获取故障未涉及设备的日志文件的相关操作，通常可以导致这些设备的功耗，这对于蓝牙耳机、智能手表等瘦设备的功耗影响尤为显著，容易浪费瘦设备的电量。

请参考图2示出的组网设备，若蓝牙耳机的故障，则蓝牙耳机的故障可以涉及富设备手机和瘦设备蓝牙耳机，而不涉及瘦设备智能手表。在无区别的日志获取方式中，不仅收集了所需的手机的日志文件和蓝牙耳机的日志文件，还收集了不需要的智能手表的日志文件，如此会额外增加智能手表的功耗，造成智能手表电量的浪费。

一个实施例中，可以根据故障所涉及的设备类型，通过有区别的日志获取方式，来获取故障所涉及的在网富设备和瘦设备的日志文件，而不去获取故障所未涉及的在网富设备和瘦设备的日志文件。如此，在支持故障分析的同时，还可降低组网设备日志采集功耗、降低数据处理压力。

一个实施例中，可以根据故障所涉及的设备类型，为每一故障事件设定相应的转发范围，使得产生故障事件的富设备将故障事件转发给符合设备类型的其他在网富设备，而不转发至不符合设备类型的其他在网富设备。

一个实施例中，故障所涉及的设备类型可以依据经验和实际需要来确定。比如可以由制定各个故障事件的领域技术人员按需确定。

另一实施例中，故障所涉及的设备类型可以根据可能发生该故障的设备及关联设备得到。比如蓝牙连接故障所涉及的设备类型可以有可能发生蓝牙连接故障的蓝牙耳机、蓝牙音箱等设备及智能手机、平板电脑等关联设备的设备类型。

请参考图2，举例来说，若蓝牙耳机A 202故障，则可以有区别的获取手机A 201、蓝牙耳机A 202、手机B 204、蓝牙耳机B 205这些设备的日志文件，而不获取智能手表A 203、智能手表B 206这些设备的日志文件。

在本申请一个实施例中，请参考图3(a)和图3(b)，其示出了手动提单下的一种日志获取流程，可以包括以下步骤301～步骤311。

在该日志获取流程中，根据故障所涉及的设备类型，富设备可以有区别的获取符合设备类型的所连接瘦设备的日志文件，以及有区别的向符合设备类型的其他富设备转发产生的故障事件，如此其他富设备同样可以有区别的获取符合设备类型的所连接瘦设备的日志文件。通过有区别的进行日志获取，可以降低组网设备日志采集功耗。

请参考图3(a)和图3(b)，所涉及的富设备可以有手机/平板31、手机/平板/大屏设备32、个人电脑(PC)33。大屏设备比如可以有智能电视等。一个实施例中，三个富设备之间可以通过“Magiclink”这一通信连接方式保持通信连接。

一个实施例中，富设备中的第一模块可以为设备中现有的Hiview，富设备中的第二模块可以为设备中现有的native_hiview。

当用户发现手机/平板31或者手机/平板31连接的瘦设备在使用过程中发生故障时，可以通过手机/平板31上安装的故障提单应用程序(比如BetaClub APP)311输入故障的故障类型以进行手动提单。

步骤301，手机/平板31上安装的故障提单应用程序311获取提单信息，提单信息用于指示手机/平板31、或者手机/平板31连接的蓝牙耳机和/或智能手表在使用过程中发生故障，根据提单信息包括的故障类型生成故障类型信息(比如可以记作“metricId”)，将故障类型信息传递给手机/平板31中的第一模块312。

手机/平板31上安装的故障提单应用程序311可以通过手机/平板31中的第一模块312的接口来传递故障类型信息。

步骤302，手机/平板31中的第一模块312根据故障类型信息获取本机日志文件。获取的日志文件可用作维测信息，以用于实现故障分析目的。

一个实施例中，无论发生的故障是否为分布式故障，用户进行手动提单所使用的富设备均需获取本机日志文件。另一实施例中，在发生的故障为分布式故障时，获取本机日志文件，否则不获取本机日志文件。

一个实施例中，可以默认用户进行手动提单所使用的富设备符合设备类型信息。另一实施例中，该富设备也可以判断本机是否符合设备类型信息，若是则获取本机日志文件，否则不获取本机日志文件。

步骤303，手机/平板31中的第一模块312根据故障类型信息判断发生的故障是否为分布式故障，若是，执行步骤304，否则结束。

步骤304，手机/平板31中的第一模块312根据故障类型信息获取设备类型信息(比如记作scope)，设备类型信息用于描述与故障的故障类型相关的设备类型，并生成包括故障类型信息和设备类型信息的故障事件信息(比如可以记作951故障事件)，将故障事件信息传递给手机/平板31中的第二模块313，并判断手机/平板31及其连接的蓝牙耳机和智能手表中是否仅手机/平板31符合设备类型信息，若是，执行步骤306，否则执行步骤305。

若是可以仅获取本机日志文件，否则还可按需获取本机连接的瘦设备的日志文件。

设备类型信息可用于决定设备范围，可以对设备范围内的设备进行相应日志的收集，而不对设备范围以外的设备进行日志收集。

一个实施例中，步骤304中可以通过判断设备类型信息是否仅涉及富设备，来判断手机/平板31及其连接的蓝牙耳机和智能手表中是否仅手机/平板31符合设备类型信息。

一个实施例中，故障事件信息还可以包括手动提单的提单号。

步骤305，手机/平板31中的第一模块312在连接的蓝牙耳机符合设备类型信息的情况下，根据故障类型信息获取蓝牙耳机的日志文件，以及在连接的智能手表符合设备类型信息的情况下，根据故障类型信息获取智能手表的日志文件，并执行步骤306。

一个实施例中，可以根据蓝牙耳机中安装的相应应用程序(比如可以为“智慧生活”应用程序)，来采集蓝牙耳机的日志文件。

一个实施例中，可以根据智能手表中安装的相应应用程序(比如可以为“运动健康”应用程序)，来采集智能手表的日志文件。

步骤306，手机/平板31中的第二模块313根据故障事件信息中的设备类型信息，确定手机/平板/大屏设备32、个人电脑33中的符合设备类型信息的设备，将故障事件信息发送给确定出的符合设备类型信息的设备，并执行步骤307和步骤310。

一个实施例中，富设备间可以通过基于D2D通信技术的D2D接口来传递故障事件信息。D2D通信技术(Device—to—Device Communication)可以为两个对等的用户节点之间直接进行通信的一种通信方式。

一个实施例中，生成故障事件信息的富设备通常符合设备类型信息，该富设备作为故障事件信息的发送方，确定出的符合设备类型信息的其他富设备作为故障事件信息的接收方。发送方可以将故障事件信息分别发送给各个接收方，各个接收方接收到发送方发来的故障事件信息后，可以根据故障事件信息进行相应日志的获取操作，而不再继续向其他富设备传递接收到的故障事件信息。

一个实施例中，可以判断其他富设备是否符合设备类型信息，若是，可以将故障事件信息转发给该其他富设备，否则不将故障事件信息转发给该其他富设备。

另一个实施例中，可以判断是否存在其他富设备及其连接的瘦设备中的至少一个符合设备类型信息，若是，可以将故障事件信息转发给该其他富设备，否则不将故障事件信息转发给该其他富设备。对应地，该其他富设备在接收到转发来的故障事件信息后，可以获取符合设备类型信息的所连接瘦设备的日志文件，以及可以判断本机是否符合设备类型信息，若是可以获取本机日志文件，否则可以不获取本机日志文件。

步骤307，手机/平板/大屏设备32中的第二模块321在接收到手机/平板31中的第二模块313发来的故障事件信息时，判断本机是否符合故障事件信息中的设备类型信息、且本机的版本类型是否为测试版本(比如可以记作Beta版本)，若均是，将故障事件信息传递给手机/平板/大屏设备32中的第一模块322，否则结束。

在其他富设备根据设备类型信息按需转发故障事件信息的情况下，接收到故障事件信息的富设备通过判断本机是否符合设备类型信息，可以实现日志按需获取的再次验证判断，以保证日志获取的准确性。

通过判断本机的版本类型，比如本机的操作系统的版本类型是否为测试版本，可以对测试版本下的设备日志文件进行获取，而不对某些版本(比如正常发售版本)下的设备日志文件进行获取，以保证日志文件的准确有效获取。

一个实施例中，可以通过手机/平板31中的第二模块313的接口，将故障事件信息传递给手机/平板/大屏设备32中的第一模块322。

步骤308，手机/平板/大屏设备32中的第一模块322根据故障事件信息中的故障类型信息，获取本机日志文件。

步骤309，手机/平板/大屏设备32中的第一模块322根据故障事件信息中的设备类型信息，在连接的蓝牙耳机符合设备类型信息的情况下，根据故障类型信息获取蓝牙耳机的日志文件，以及在连接的智能手表符合设备类型信息的情况下，根据故障类型信息获取智能手表的日志文件。

一个实施例中，可以先判断设备类型信息是否涉及瘦设备，在设备类型信息涉及瘦设备的情况下，可以进一步判断设备类型信息涉及蓝牙耳机还是智能手表，根据设备类型信息涉及的瘦设备，获取所涉及瘦设备的日志文件。

步骤310，个人电脑33中的第二模块331在接收到手机/平板31中的第二模块313发来的故障事件信息时，判断本机是否符合故障事件信息中的设备类型信息、且本机的版本类型是否为测试版本(比如可以记作Beta版本)，若均是，将故障事件信息传递给个人电脑33上安装的故障提单应用程序332(比如可以为BetaClub应用程序)，否则结束。

一个实施例中，个人电脑33中的第二模块331比如可以为个人电脑的管理器(Manager)的native_hiview。

一个实施例中，可以通过个人电脑33中的第二模块331的接口，将故障事件信息传递给个人电脑33上安装的故障提单应用程序332。

步骤311，个人电脑33上安装的故障提单应用程序332根据故障事件信息中的故障类型信息，获取本机日志文件。

个人电脑33可以没有连接蓝牙耳机、智能手表等瘦设备，如此可以仅按需采集本机日志文件。

在本申请一个实施例中，请参考图4，其示出了自动提单下的一种日志获取流程，可以包括以下步骤401～步骤410。图4所示日志获取流程与图3(a)和图3(b)所示日志获取流程中的一些实现原理相一致，本实施例在此不做赘述。

在图4所示日志获取流程中，根据故障所涉及的设备类型，富设备有区别的获取符合设备类型的所连接瘦设备的日志文件，以及有区别的向符合设备类型的其他富设备转发产生的故障事件，如此其他富设备同样可以有区别的获取符合设备类型的所连接瘦设备的日志文件。通过有区别的进行日志获取，可以降低组网设备日志采集功耗。

请参考图4，所涉及的富设备可以有手机/平板41、手机/平板/大屏设备42、个人电脑(PC)43。大屏设备比如可以有智能电视等。一个实施例中，三个富设备之间可以通过“Magiclink”这一通信连接方式保持通信连接。

一个实施例中，富设备中的第一模块可以为Hiview，富设备中的第二模块可以为native_hiview。

步骤401，手机/平板41中的故障检测模块411在检测到本机在运行时发生分布式故障的情况下，根据发生的分布式故障的故障类型信息(比如可以记作eventId)进行自动提单。

一个实施例中，故障类型信息可以根据相应的配置文件得到。

步骤402，手机/平板41中的故障检测模块411根据自动提单中的故障类型信息，获取设备类型信息(比如记作scope)，设备类型信息用于描述与故障的故障类型相关的设备类型。

步骤403，手机/平板41中的故障检测模块411生成包括故障类型信息和设备类型信息的故障事件信息(比如可以记作950故障事件)，将故障事件信息传递给手机/平板41中的第二模块412。

一个实施例中，故障事件信息还可以包括自动提单的提单号。

步骤404，手机/平板41中的第二模块412根据故障事件信息中的设备类型信息，判断本机连接的蓝牙耳机和智能手表中是否存在至少一个设备符合设备类型信息，若是，将故障事件信息传递给手机/平板41中的第一模块413并执行步骤405，否则执行步骤406。

一个实施例中，手机/平板41中的第二模块412可以先判断故障事件信息是否包括设备类型信息，若是再执行步骤404，否则结束。

一个实施例中，可以通过判断设备类型信息是否涉及瘦设备，来判断本机连接的蓝牙耳机和智能手表中是否存在至少一个设备符合设备类型信息。

步骤405，手机/平板41中的第一模块413在连接的蓝牙耳机符合设备类型信息的情况下，根据故障类型信息获取蓝牙耳机的日志文件，以及在连接的智能手表符合设备类型信息的情况下，根据故障类型信息获取智能手表的日志文件，并执行步骤406。

一个实施例中，在设备类型信息涉及瘦设备的情况下，可以进一步判断设备类型信息涉及蓝牙耳机还是智能手表，根据设备类型信息涉及的瘦设备，获取所涉及瘦设备的日志文件。

步骤406，手机/平板41中的第二模块412根据故障事件信息中的故障类型信息获取本机日志文件。

一个实施例中，可以默认进行自动提单的富设备符合设备类型信息。另一实施例中，该富设备也可以判断本机是否符合设备类型信息，若是则获取本机日志文件，否则不获取本机日志文件。

步骤407，手机/平板41中的第二模块412根据故障事件信息中的设备类型信息，确定手机/平板/大屏设备42、个人电脑43中的符合设备类型信息的设备，将故障事件信息发送给确定出的符合设备类型信息的设备，并执行步骤408和步骤410。

步骤408，手机/平板/大屏设备42中的第二模块421在接收到手机/平板41中的第二模块412发来的故障事件信息时，判断本机是否符合故障事件信息中的设备类型信息、且本机的版本类型是否为测试版本(比如可以记作Beta版本)，若均是，根据故障事件信息中的故障类型信息获取本机日志文件，并将故障事件信息传递给手机/平板/大屏设备42中的第一模块422，否则结束。

步骤409，手机/平板/大屏设备42中的第一模块422根据故障事件信息中的设备类型信息，在连接的蓝牙耳机符合设备类型信息的情况下，根据故障类型信息获取蓝牙耳机的日志文件，以及在连接的智能手表符合设备类型信息的情况下，根据故障类型信息获取智能手表的日志文件。

步骤410，个人电脑43中的第二模块431在接收到手机/平板41中的第二模块412发来的故障事件信息时，判断本机是否符合故障事件信息中的设备类型信息、且本机的版本类型是否为测试版本(比如可以记作Beta版本)，若均是，根据故障事件信息中的故障类型信息获取本机日志文件，否则结束。

在本申请一个实施例中，手机、平板、大屏设备等富设备可以包括Hiview和native_hiview。

在手动提单情况下，Hiview可用于执行以下操作：

当用户通过富设备的BetaClub APP对富设备或其连接的瘦设备所发生的故障进行手动提单时，Hiview可以接收BetaClub APP发送的提单信息，比如metricId、提单号等；metricId可以由BetaClub APP根据用户输入的故障类型得到；

Hiview可以根据metricId，判断富设备发生的故障是否为分布式故障；

Hiview可以根据metricId，获取metricId规定所需收集的本机日志文件并上传；

对于分布式故障，Hiview可以根据metricId，从配置文件中获取故障涉及的设备类型信息(scope)；

在富设备连接有智能手表(watch)和蓝牙耳机(headset)的情况下，Hiview可以判断scope中是否包含watch，若包含可以调用智能手表的运动健康应用，获取metricId规定所需收集的智能手表日志文件并上传；Hiview可以判断scope中是否包含headset，若包含可以调用蓝牙耳机的运动健康应用，获取metricId规定所需收集的蓝牙耳机日志文件并上传；

对于分布式故障，Hiview可以生成951故障事件，951故障事件可以包括metricId、scope、提单号等信息，并将951故障事件发送给本机的native_hiview；

Hiview在接收到本机的native_hiview发来的951故障事件(表示其他在网富设备或其连接的瘦设备发生了分布式故障)的情况下，根据951故障事件中的metricId，获取metricId规定所需收集的本机日志文件并上传，并根据951故障事件中的scope，在scope包括本机连接的任一瘦设备的设备类型的情况下，获取metricId规定所需收集的该瘦设备的日志文件并上传。

在手动提单情况下，native_hiview可用于执行以下操作：

native_hiview可以在接收到Hiview发送过来的951故障事件之后，获取所有在网富设备及其设备类型，并根据设备类型和951故障事件中的scope，确定需要转发951故障事件的各个在网富设备，其中，若scope包括某一在网富设备的设备类型，则向该在网富设备转发951故障事件，否则不转发；

native_hiview在收到其他在网富设备发来的951故障事件后，可以将951故障事件中的scope与本机的设备类型进行比对，若scope包括本机的设备类型，则可以将951故障事件转发给本机的Hiview。

在自动提单情况下，native_hiview可用于执行以下操作：

native_hiview可以处理富设备检测到自身故障时产生的950故障事件；其中，富设备可以检测本机运行时是否发生故障，若是即可根据故障类型发起自动提单，并基于发起的自动提单，根据eventId从配置文件中获取故障涉及的设备类型信息(scope)，并生成950故障事件，950故障事件可以包括eventId、scope、自动提单号等信息，进而将950故障事件发送给本机的native_hiview；

native_hiview可以根据950故障事件中的eventId，获取eventId规定所需收集的本机日志文件并上传；

native_hiview可以获取所有在网富设备及其设备类型，并根据950故障事件中的scope，确定需要转发950故障事件的各个在网富设备，其中，若scope包括某一在网富设备的设备类型，则向该在网富设备转发950故障事件，否则不转发；

若950故障事件中的scope包括所连接的任一瘦设备的设备类型，native_hiview可以将950故障事件转发给本机的Hiview；

native_hiview在接收到其他在网富设备发来的950故障事件(表示其他在网富设备检测到自身发生了分布式故障)的情况下，可以将950故障事件中的scope与本机的设备类型进行比对，若scope包括本机的设备类型，则可以根据950故障事件中的eventId，获取eventId规定所需收集的本机日志文件并上传，并在scope包括本机连接的任一瘦设备的设备类型的情况下，将950故障事件传递给本机的Hiview。

在自动提单情况下，Hiview可用于执行以下操作：

Hiview在接收到本机的native_hiview发来的950故障事件后，若本机连接有智能手表(watch)和蓝牙耳机(headset)，Hiview可以判断950故障事件中的scope是否包含watch，若包含可以调用智能手表的运动健康应用，获取950故障事件中的eventId规定所需收集的智能手表日志文件并上传；Hiview可以判断scope中是否包含headset，若包含可以调用蓝牙耳机的运动健康应用，获取950故障事件中的eventId规定所需收集的蓝牙耳机日志文件并上传。

在本申请一个实施例中，请参考图5，示出了手动提单下的日志获取流程的时序图。请参考图5，手动提单下的日志获取流程可以包括以下步骤：

步骤501，富设备A 51的故障提单应用程序(比如BetaClub APP)511获取经故障提单应用程序511输入的提单信息，提单信息包括富设备A 51或者其连接的蓝牙耳机52或智能手表53所发生故障的故障类型。

用户可以通过故障提单应用程序输入提单信息。

步骤502，富设备A 51的故障提单应用程序511根据提单信息中的故障类型生成故障类型信息(比如可以记作“metricId”)，并生成提单号，将故障类型信息和提单号发送给富设备A 51的第一模块(比如Hiview)512。

步骤503，富设备A 51的第一模块512根据故障类型信息获取设备类型信息(比如记作scope)，设备类型信息用于描述与故障的故障类型相关的设备类型，根据故障类型信息获取本机日志文件。

步骤504，富设备A 51的第一模块512在富设备A 51连接的蓝牙耳机52符合设备类型信息的情况下，根据故障类型信息获取蓝牙耳机52的日志文件，以及在富设备A 51连接的智能手表53符合设备类型信息的情况下，根据故障类型信息获取智能手表53的日志文件。

一个实施例中，富设备A 51可以将获取的日志文件对应于步骤502中生成的提单号并上传。

步骤505，富设备A 51的第一模块512生成包括故障类型信息、设备类型信息和提单号的故障事件信息(比如可以记作951故障事件)，将故障事件信息传递给富设备A 51的第二模块(比如native_hiview)513。

步骤506，富设备A 51的第二模块513根据故障事件信息中的设备类型信息，确定符合设备类型信息的其他富设备，在确定出的其他富设备包括富设备B 54的情况下，将故障事件信息发送给富设备B 54的第二模块(比如native_hiview)541。

步骤507，富设备B 54的第二模块541将接收到的故障事件信息传递给富设备B 54的第一模块(比如Hiview)542。

步骤508，富设备B 54的第一模块542根据故障事件信息中的故障类型信息获取本机日志文件。

一个实施例中，接收到故障事件信息的富设备可以默认需要获取本机日志文件。另一实施例中，接收到故障事件信息的富设备可以判断本机是否符合设备类型信息，若是则获取本机日志文件，否则不获取本机日志文件。

步骤509，富设备B 54的第一模块542根据故障事件信息中的设备类型信息，在富设备B 54连接的蓝牙耳机55符合设备类型信息的情况下，根据故障类型信息获取蓝牙耳机55的日志文件，以及在富设备B 54连接的智能手表56符合设备类型信息的情况下，根据故障类型信息获取智能手表56的日志文件。

一个实施例中，富设备B 54可以将获取的日志文件对应于步骤502中生成的提单号并上传。

在本申请一个实施例中，请参考图6，示出了自动提单下的日志获取流程的时序图。请参考图6，自动提单下的日志获取流程可以包括以下步骤：

步骤601，富设备A 61中的故障检测模块611在检测到本机在运行时发生故障的情况下，根据发生的故障的故障类型信息(比如可以记作eventId)进行自动提单。

步骤602，富设备A 61中的故障检测模块611根据自动提单中的故障类型信息，获取设备类型信息(比如记作scope)，设备类型信息用于描述与故障的故障类型相关的设备类型。

步骤603，富设备A 61中的故障检测模块611生成包括故障类型信息、设备类型信息和自动提单号的故障事件信息(比如可以记作950故障事件)，将故障事件信息传递给富设备A 61的第二模块(比如native_hiview)612。

步骤604，富设备A 61的第二模块612根据故障事件信息中的故障类型信息获取本机日志文件。

步骤605，富设备A 61的第二模块612将故障事件信息中的故障类型信息和设备类型信息转发给富设备A 61的第一模块(比如Hiview)613。

一个实施例中，富设备A 61的native_hiview可以对故障事件信息进行解析，将解析出的设备类型信息和故障类型信息传递给本机的Hiview。

另一实施例中，富设备A 61的native_hiview可以将故障事件信息传递给本机的Hiview。

步骤606，富设备A 61的第一模块613在富设备A 61连接的蓝牙耳机62符合设备类型信息的情况下，根据故障类型信息获取蓝牙耳机62的日志文件，以及在富设备A 61连接的智能手表63符合设备类型信息的情况下，根据故障类型信息获取智能手表63的日志文件。

一个实施例中，富设备A 61可以将获取的日志文件对应于故障事件信息中的自动提单号并上传。

步骤607，富设备A 61的第二模块612根据故障事件信息中的设备类型信息，确定符合设备类型信息的其他富设备，在确定出的其他富设备包括富设备B 64的情况下，将故障事件信息发送给富设备B 64的第二模块(比如native_hiview)641。

步骤608，富设备B 64的第二模块641根据故障事件信息中的故障类型信息获取本机日志文件。

步骤609，富设备B 64的第二模块641将故障事件信息中的故障类型信息和设备类型信息转发给富设备B 64的第一模块(比如Hiview)642。

一个实施例中，富设备B 64的native_hiview可以对故障事件信息进行解析，将解析出的设备类型信息和故障类型信息传递给本机的Hiview。

步骤610，富设备B 64的第一模块642在富设备B 64连接的蓝牙耳机65符合设备类型信息的情况下，根据故障类型信息获取蓝牙耳机65的日志文件，以及在富设备B 64连接的智能手表66符合设备类型信息的情况下，根据故障类型信息获取智能手表66的日志文件。

一个实施例中，富设备B 64可以将获取的日志文件对应于故障事件信息中的自动提单号并上传。

在本申请一个实施例中，用户的一个蓝牙耳机和一个智能手表与一个手机相连。用户还有一个平板与手机相连，平板上连接着另一个蓝牙耳机和另一块智能手表。

以手机连接的蓝牙耳机故障时，用户通过手机上的BetaClub APP输入故障类型以进行手动提单为例，相应的日志获取流程可以包括以下内容：

1)手机的BetaClub APP生成提单号和metricId，将提单号和metricId转发给手机的Hiview。

2)手机的Hiview收到提单号和metricId后，依据metricId抓取本机相关日志，并依据metricId判断发生的故障是否为分布式故障，若是，可以依据metricId从配置文件中读取到故障涉及的scope为“phone,pad,headset”，否则结束。

3)手机的HiView从scope中检测到headset后，调用蓝牙耳机上的智慧家居APP，从连接的蓝牙耳机中收集metricId所限定收集的日志。由于未能从scope中检测到watch，将不会调用智能手表上的运动健康APP，以不从连接的智能手表中收集metricId所限定收集的日志。

4)手机的HiView在完成本机及与之相连接的蓝牙耳机的日志收集后，生成951故障事件，951故障事件包括metricId、scope和提单号，并将951故障事件传递给手机的native_hiview。

5)手机的native_hiview在收到951故障事件后，可以从951故障事件中解析出scope。

6)手机的native_hiview获取与之相连的富设备及其类型信息，其中可以获取到连接的富设备为平板，平板的设备类型为pad。

7)手机的native_hiview将pad与scope进行比较，可以确定出scope包括pad，故而可以将951故障事件发送给平板的native_hiview。

8)平板的native_hiview在收到951故障事件后，可以从951故障事件中解析出scope，并将scope与本机的设备类型进行对比，可以确定出scope包括pad，故而可以将951故障事件转发给平板的Hiview。

9)平板的Hiview在收到951故障事件后，根据951故障事件中的metricId收集本机日志文件。

10)平板的Hiview根据951故障事件中的scope，从scope中检测到headset后，调用蓝牙耳机上的智慧家居APP，从蓝牙耳机中收集metricId所限定收集的日志。由于未能从scope中检测到watch，将不会调用智能手表上的运动健康APP，以不从连接的智能手表中收集metricId所限定收集的日志。

手机和平板收集的日志可以均对应于951故障事件中的提单号。手机和平板可以将各自收集的日志进行上传。

相比于无区分的日志获取方式，通过根据故障涉及的设备类型进行有区别的获取日志，以对符合设备类型的设备进行日志收集，而不收集不符合设备类型的设备的日志，如此不仅可以提升日志收集准确性，还可减少不必要的跨设备通信，从而相比于无区分的日志获取方式可以降低日志收集功耗。

除了本申请实施例示出了手机、平板、蓝牙耳机、智能手表等组网设备，同样可以对其他类型的组网设备进行有区别的日志获取。比如，可以对智慧生活环境中的“1+8+n设备”进行有区别的日志获取。其中1可以指手机，8可以指车机、音箱、耳机、手表/手环、平板、大屏、PC、AR(Augmented Reality，增强现实)/VR(Virtual Reality，虚拟现实)，N可以指泛IOT(Internet of Things，物联网)设备。

如图7所示，本申请实施例提供了一种日志获取方法，该方法可以应用于第一电子设备，该方法可以包括步骤701～步骤703。

步骤701，获取第一故障类型，第一故障类型用于描述第一电子设备或者与第一电子设备相连的第二电子设备所存在故障的故障类型。

一个实施例中，第一电子设备自身存在故障时，获取该故障的故障类型。

另一实施例中，第一电子设备所连接的第二电子设备故障时，第一电子设备获取该故障的故障类型。

在本申请一个实施例中，第一电子设备为第一类型的电子设备，第二电子设备为第二类型的电子设备。第一电子设备为第一类型的电子设备，其具有获取日志文件的功能，并用于获取日志文件，且具体可以按需获取本机日志文件和所连接的第二类型的电子设备的日志文件。第一类型的电子设备可以连接有第二类型的电子设备，第二类型的电子设备可以不具有获取日志文件的功能，不用于获取日志文件。

第一类型的电子设备可以为上述的富设备，第二类型的电子设备可以为上述的瘦设备。富设备可以获取本机及所连接瘦设备的日志文件，不获取其他富设备以及其他富设备所连接瘦设备的日志文件。

在第一电子设备或其连接的瘦设备存在故障时，第一电子设备可以获取该故障的故障类型。

一个实施例中，步骤701中获得的故障类型可以为本申请其他实施例所述的故障类型。另一实施例中，步骤701中获得的故障类型可以为本申请其他实施例所述的故障类型信息。

步骤702，根据第一故障类型获得第一信息，第一信息用于描述与第一故障类型相关的设备类型。第一信息可以为本申请其他实施例所述的设备类型信息。

富设备自身故障或富设备所连接的任一瘦设备故障时，该富设备均可根据故障的故障类型，获取相应的设备类型信息(比如上述scope)。设备类型信息与故障的故障类型相关，可用于有区别的获取故障相关日志文件，以用于获取与发生的故障相关的日志文件。

基于发现设备故障的不同方式，一个实施例中，步骤701可以响应于第一电子设备对故障的手动提单处理而执行，另一实施例中，步骤701可以响应于第一电子设备对故障的自动提单处理而执行。

对应于手动提单情况，在本申请一个实施例中，步骤701可以包括：获取用于表示第一电子设备或者第二电子设备存在故障的故障提单信息；获取故障提单信息包括的第一故障类型。

用户在发现富设备或其连接的任一瘦设备发生故障(比如在运行过程中发生故障)时，可以通过该富设备上安装的故障提单应用程序，输入故障类型等提单信息以对故障进行手动提单。富设备响应于用户的手动提单请求，可以获取故障类型，并根据故障类型获得设备类型信息。

对应于自动提单情况，在本申请一个实施例中，日志获取方法还包括：检测第一电子设备在运行过程中是否存在故障。步骤701可以包括：在检测到第一电子设备在运行过程中存在故障的情况下，获取检测到的故障的第一故障类型。

富设备可以在运行过程中实时或者周期性的检测自身是否存在故障。一种实现方式中，可以检测自身是否存在分布式故障。在检测到故障时，可以自动确定出故障的故障类型，进而可根据故障类型获得设备类型信息。

在本申请一个实施例中，根据第一故障类型获得第一信息可以包括：获取用于标识第一故障类型的目标故障类型信息；根据目标故障类型信息获得第一信息。

一个实施例中，可以根据故障的故障类型，得到故障类型信息(比如上述metricId、eventId)。在手动提单情况下，可以由用户输入故障的故障类型。在自动提单情况下，可以由发生故障的设备自身确定出故障的故障类型。

可行地，可以根据故障所涉及的设备，确定故障类型信息和设备类型间的关联关系。可以通过查找预设的关联关系以获得设备类型信息。设备类型信息可以包括与目标故障类型信息相关联的每一个设备类型。

一个实施例中，若某种电子设备上通常不会发生某种故障，则该种故障可以不涉及该种电子设备，若某种电子设备上可能会发生某种故障，则该种故障可以涉及该种电子设备。

一个实施例中，第一电子设备还可以判断存在的故障是否为预设的特定类型的故障(比如上述分布式故障)，若是则获取第一信息，否则可以结束以不获取第一信息。

故障类型信息可用于获得设备类型信息。可行地，故障类型信息还可用于日志文件的获取，具体可以为根据故障类型信息来获取设备的日志文件，以获取与发生的故障相关的日志文件。

在本申请一个实施例中，根据第一故障类型获得第一信息，包括：根据预先设置好的故障类型和设备类型间的关联关系，获取与第一故障类型相关联的设备类型，以得到第一信息。

可行地，可以建立故障类型与设备类型间的关联关系。可以直接根据第一故障类型获得第一信息。

可行地，可以建立故障类型与故障类型信息间的关联关系，以及建立故障类型信息和设备类型间的关联关系。可以根据第一故障类型获得相应故障类型信息，进而根据该故障类型信息获得第一信息。

步骤703，获取符合第一信息的电子设备的日志文件。

一个实施例中，第一电子设备可以在本机符合第一信息的情况下，获取本机日志文件。

一个实施例中，第一电子设备可以在本机连接的任一第二类型的电子设备符合第一信息的情况下，获取该第二类型的电子设备的日志文件。

一个实施例中，若本机不符合第一信息、本机未连接有符合第一信息的第二类型的电子设备，第一电子设备可以不执行步骤703。

在本申请一个实施例中，第一电子设备为第一类型的电子设备，第二电子设备为第二类型的电子设备；步骤703包括：获取与第一电子设备相连、且符合第一信息的第二类型的电子设备的日志文件。

一个实施例中，在第一电子设备连接有瘦设备的情况下，对于连接的每一个瘦设备，第一电子设备可以判断该瘦设备是否符合第一信息，若是即可根据故障类型信息获取该瘦设备的日志文件。

一个实施例中，第一电子设备可以将获取到的日志文件上传至预设的日志管理模块，比如上传至云端服务器。另一实施例中，外部(比如日志管理模块、用户等)也可以按需从第一电子设备中收集其获取的日志文件。

在本申请一个实施例中，步骤703包括：获取第一电子设备的日志文件。

一个实施例中，对于产生设备类型信息的富设备，可以默认其符合设备类型信息，故而可以直接获取本机日志文件。

另一实施例中，第一电子设备也可以判断本机是否符合第一信息，若是则获取本机日志文件。

在本申请一个实施例中，步骤703包括：获取符合第一信息的电子设备的、与第一故障类型相关的日志文件，并将获取到的日志文件对应于第一电子设备或者第二电子设备所存在的故障的标识；日志获取方法还包括：将获取的日志文件上传至预设的日志管理模块。故障的标识可以为对故障进行提单的提单号。

步骤703为针对于步骤701中所述故障所执行的日志获取操作，据此获得的日志文件对应于该故障，可用于对该故障进行分析。

在本申请一个实施例中，日志获取方法还可以包括：在第三电子设备与第一电子设备相连、且第三电子设备符合第一信息的情况下，将第一信息发送给第三电子设备。

步骤703中由第一电子设备根据第一信息获取日志文件。通过将第一信息发送给第三电子设备，进而可由第三电子设备根据第一信息获取符合第一信息的电子设备的日志文件。这些日志文件可以对应于步骤701中所述故障的唯一标识。

一种可行的实现方式中，第三电子设备根据第一信息获取日志文件之后，可以将获得的日志文件反馈给第一电子设备。对应地，第一电子设备可以接收第三电子设备发来的日志文件。

考虑到对应于同一故障的故障相关日志文件可以由不止一个富设备分别获取，为便于对该故障进行分析，可以令这些富设备分别获取的日志文件均对应于同一故障提单标识(比如上述手动/自动提单号)，以便于根据故障提单标识可以汇总同一故障的故障相关日志文件。

在本申请一个实施例中，第一电子设备和第三电子设备均为第一类型的电子设备，第二电子设备为第二类型的电子设备。第三电子设备可以为与第一电子设备相连的第一类型的其他电子设备。可行地，可以不将第一信息发送给与第一电子设备相连但不符合第一信息的第一类型的其他电子设备。

一个实施例中，第一电子设备通过转发第一信息，可以触发符合第一信息的第一类型的其他电子设备在其本机符合第一信息的情况下获取本机日志文件。

一个实施例中，第一电子设备通过转发第一信息，可以触发符合第一信息的第一类型的其他电子设备在其本机连接的任一第二类型的电子设备符合第一信息的情况下，获取该第二类型的电子设备的日志文件。

一个实施例中，若不存在符合第一信息的第一类型的其他电子设备，第一电子设备可以不转发第一信息。

一个实施例中，对于第一电子设备连接的每一个富设备，第一电子设备可以判断该富设备可以符合设备类型信息，若是即可将第一信息转发给该富设备。

一个实施例中，第一电子设备可以生成包括第一信息的故障事件信息，通过转发故障事件信息以转发第一信息。

一个实施例中，故障事件信息还可以包括故障类型信息。

一个实施例中，故障事件信息还可以包括故障提单标识。故障提单标识可以用于唯一标识所发生的一个故障。

一个实施例中，故障事件信息可以通过字符串的形式来体现。

一个实施例中，在富设备将产生的设备类型信息转发给符合该设备类型信息的其他富设备的情况下，其他富设备收到设备类型信息后，可以不再判断本机是否符合接收到的设备类型信息，直接获取本机日志文件。

另一实施例中，在富设备将产生的设备类型信息转发给符合该设备类型信息的其他富设备的情况下，其他富设备收到设备类型信息后，可以再次判断其本机是否符合接收到的设备类型信息，若是则获取本机日志文件，否则可不获取本机日志文件。通过对富设备和设备类型信息间的再次比对，可以进一步提升日志获取的准确度。

在本申请一个实施例中，第一电子设备可以将第一信息发送给与第一电子设备相连的每一个第一类型的其他电子设备。基于此，在其他电子设备接收到第一信息后，可以判断其本机是否符合第一信息，若是则可以获取本机日志文件，否则可以结束以不获取本机日志文件。

在本申请一个实施例中，在与第一电子设备相连的第一类型的目标电子设备和连接目标电子设备的第二类型的电子设备中的至少一个符合第一信息的情况下，第一电子设备可以将第一信息发送给目标电子设备。基于此，在目标电子设备接收到第一信息后，可以判断本机是否符合第一信息，若是则可以获取本机日志文件，否则可以不获取本机日志文件。

第一电子设备可以将第一信息转发给其他的在网富设备，也可以接收到其他的在网富设备发来的其他设备类型信息。同一富设备所发送的设备类型信息和所接收的设备类型信息所针对的故障可以为同一类型的故障，也可以为不同类型的故障。

请参考图8，本申请一个实施例提供了一种日志获取方法，应用于第一电子设备，该方法可以包括步骤801～步骤802：

步骤801，接收第四电子设备发来的第二信息，其中，第二信息由第四电子设备根据第四电子设备或者与第四电子设备相连的第五电子设备所存在故障的第二故障类型得到，第二信息用于描述与第二故障类型相关的设备类型。

步骤802，获取符合第二信息的电子设备的日志文件。

在本申请一个实施例中，第一电子设备和第四电子设备均为第一类型的电子设备，第五电子设备为第二类型的电子设备。

第四电子设备可以为上述富设备，与第四电子设备相连的第二类型的电子设备可以为上述瘦设备。

富设备在接收到其他富设备发来的设备类型信息时，可以获取符合接收到的设备类型信息的电子设备的日志文件。

一个实施例中，第四电子设备可以先判断第一电子设备是否符合第二信息，若是则将第二信息转发给第一电子设备。

在本申请一个实施例中，接收第四电子设备发来的第二信息可以包括：接收第四电子设备在确定出第一电子设备符合第二信息的情况下发来的第二信息。

在本申请一个实施例中，日志获取方法还包括：确定第一电子设备是否符合第二信息；在确定出第一电子设备符合第二信息的情况下，执行获取符合第二信息的电子设备的日志文件的步骤。

在本申请一个实施例中，第一电子设备为第一类型的电子设备；步骤802包括：获取与第一电子设备相连、且符合第二信息的第二类型的电子设备的日志文件。

在本申请一个实施例中，步骤802包括：获取第一电子设备的日志文件。

在本申请一个实施例中，步骤802包括：获取符合第二信息的电子设备的、与第二故障类型相关的日志文件，并将获取到的日志文件对应于第四电子设备或者第五电子设备所存在的故障的标识；日志获取方法还包括：将获取的日志文件上传至预设的日志管理模块。

第一电子设备根据第二信息进行故障相关日志获取操作的实现逻辑与第三电子设备根据第一信息进行故障相关日志获取操作的实现逻辑相一致，本实施例在此不做赘述。

第一电子设备根据第一信息进行故障相关日志获取操作的实现逻辑与第四电子设备根据第二信息进行故障相关日志获取操作的实现逻辑相一致，本实施例在此不做赘述。

本申请一个实施例还提供一种日志获取装置，应用于第一电子设备，日志获取装置装置包括：第一获取模块，用于获取第一故障类型，第一故障类型用于描述第一电子设备或者与第一电子设备相连的第二电子设备所存在故障的故障类型；第二获取模块，用于根据第一故障类型获得第一信息，第一信息用于描述与第一故障类型相关的设备类型；第三获取模块，用于获取符合第一信息的电子设备的日志文件。

本申请一个实施例还提供一种日志获取装置，应用于第一电子设备，日志获取装置装置包括：接收模块，用于接收第四电子设备发来的第二信息，其中，第二信息由第四电子设备根据第四电子设备或者与第四电子设备相连的第五电子设备所存在故障的第二故障类型得到，第二信息用于描述与第二故障类型相关的设备类型；获取模块，用于获取符合第二信息的电子设备的日志文件。

本申请一个实施例还提供一种电子芯片，该任务处理芯片安装在电子设备(UE)中，电子芯片包括：处理器，其用于执行存储在存储器上的计算机程序指令，其中，当计算机程序指令被处理器执行时，触发电子芯片执行本申请任意方法实施例提供的方法步骤。

本申请一实施例还提出了一种终端设备，终端设备包括通信模块、用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发终端设备执行本申请任意方法实施例提供的方法步骤。

本申请一实施例还提出了一种服务器设备，服务器设备包括通信模块、用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发服务器设备执行本申请任意方法实施例提供的方法步骤。

本申请一个实施例还提供一种电子设备，电子设备包括多根天线、用于存储计算机程序指令的存储器、用于执行计算机程序指令的处理器和通信装置(比如可以基于NR协议实现5G通信的通信模块)，其中，当计算机程序指令被该处理器执行时，触发电子设备执行本申请任意方法实施例提供的方法步骤。

具体的，在本申请一实施例中，一个或多个计算机程序被存储在上述存储器中，该一个或多个计算机程序包括指令，当该指令被上述设备执行时，使得上述设备执行本申请实施例所述的方法步骤。

具体的，在本申请一实施例中，电子设备的处理器可以是片上装置SOC(System onChip，系统级芯片)，该处理器中可以包括中央处理器(Central Processing Unit，CPU)，还可以进一步包括其他类型的处理器。具体的，在本申请一实施例中，电子设备的处理器可以是PWM控制芯片。

具体的，在本申请一实施例中，涉及的处理器可以例如包括CPU、DSP(digitalsignal processor，数字信号处理器)或微控制器，还可包括GPU(graphics processingunit，图形处理器)、嵌入式神经网络处理器(Neural-network Process Units，NPU)和图像信号处理器(Image Signal Processing，ISP)，该处理器还可包括必要的硬件加速器或逻辑处理硬件电路，如ASIC，或一个或多个用于控制本申请技术方案程序执行的集成电路等。此外，处理器可以具有操作一个或多个软件程序的功能，软件程序可以存储在存储介质中。

具体的，在本申请一实施例中，电子设备的存储器可以是只读存储器(read-onlymemory，ROM)、可存储静态信息和指令的其它类型的静态存储设备、随机存取存储器(random access memory，RAM)或可存储信息和指令的其它类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备，或者还可以是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何计算机可读介质。

具体的，在本申请一实施例中，处理器可以和存储器可以合成一个处理装置，更常见的是彼此独立的部件，处理器用于执行存储器中存储的程序代码来实现本申请实施例所述方法。具体实现时，该存储器也可以集成在处理器中，或者，独立于处理器。

进一步的，本申请实施例阐明的设备、装置、模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。

本领域内的技术人员应明白，本申请实施例可提供为方法、装置、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质上实施的计算机程序产品的形式。

在本申请所提供的几个实施例中，任一功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

具体的，本申请一实施例中还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例提供的方法步骤。

本申请一实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例提供的方法步骤。

本申请中的实施例描述是参照根据本申请实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器(Processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以意识到，本申请实施例中描述的各单元及算法步骤，能够以电子硬件、计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims

1.一种日志获取方法，其特征在于，应用于第一电子设备，所述方法包括：

获取第一故障类型，所述第一故障类型用于描述所述第一电子设备或者与所述第一电子设备相连的第二电子设备所存在故障的故障类型；

根据所述第一故障类型获得第一信息，所述第一信息用于描述与所述第一故障类型相关的设备类型；所述第一信息描述的设备类型为所存在故障所涉及的设备类型，所述第一信息根据故障类型和设备类型间的关联关系得到；

获取符合所述第一信息的电子设备的日志文件；

所述第一电子设备为第一类型的电子设备，所述第二电子设备为第二类型的电子设备，第一类型的电子设备用于获取日志文件，第二类型的电子设备用于被获取日志文件；

所述获取符合所述第一信息的电子设备的日志文件，包括：

获取与所述第一电子设备相连、且符合所述第一信息的所述第二类型的电子设备的日志文件；

所述方法还包括：

在第三电子设备与所述第一电子设备相连、且所述第三电子设备和与所述第三电子设备相连的第二类型的电子设备中的至少一个符合所述第一信息的情况下，将所述第一信息发送给所述第三电子设备；所述第三电子设备为第一类型的电子设备；

根据故障所涉及的设备类型，为每一故障事件设定相应的转发范围，使得产生故障事件的第一类型的电子设备将故障事件转发给符合设备类型的其他在网的第一类型的电子设备，而不转发至不符合设备类型的其他在网的第一类型的电子设备；

第一类型的电子设备之间通过Magiclink这一通信连接方式保持通信连接。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一故障类型获得第一信息，包括：

根据预先设置好的故障类型和设备类型间的关联关系，获取与所述第一故障类型相关联的设备类型，以得到所述第一信息。

3.根据权利要求1所述的方法，其特征在于，所述获取符合所述第一信息的电子设备的日志文件，包括：

获取所述第一电子设备的日志文件。

4.根据权利要求1所述的方法，其特征在于，所述获取符合所述第一信息的电子设备的日志文件，包括：

获取符合所述第一信息的电子设备的、与所述第一故障类型相关的日志文件，并将获取到的日志文件对应于所述第一电子设备或者所述第二电子设备所存在的所述故障的标识；

所述方法还包括：将获取的日志文件上传至预设的日志管理模块。

5.根据权利要求1所述的方法，其特征在于，所述获取第一故障类型，包括：

获取用于表示所述第一电子设备或者所述第二电子设备存在故障的故障提单信息；

获取所述故障提单信息包括的所述第一故障类型。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

检测所述第一电子设备在运行过程中是否存在故障；

所述获取第一故障类型，包括：

在检测到所述第一电子设备在运行过程中存在故障的情况下，获取检测到的故障的第一故障类型。

7.一种日志获取方法，其特征在于，应用于第一电子设备，所述方法包括：

接收第四电子设备在所述第一电子设备和与所述第一电子设备相连的第二类型的电子设备中的至少一个符合第二信息的情况下发来的所述第二信息，其中，所述第二信息由所述第四电子设备根据所述第四电子设备或者与所述第四电子设备相连的第五电子设备所存在故障的第二故障类型得到，所述第二信息用于描述与所述第二故障类型相关的设备类型；

所述第二信息描述的设备类型为所存在故障所涉及的设备类型，所述第二信息根据故障类型和设备类型间的关联关系得到；

获取符合所述第二信息的电子设备的日志文件；

所述第一电子设备和所述第四电子设备均为第一类型的电子设备，所述第五电子设备为第二类型的电子设备，第一类型的电子设备用于获取日志文件，第二类型的电子设备用于被获取日志文件；

所述获取符合所述第二信息的电子设备的日志文件，包括：

获取与所述第一电子设备相连、且符合所述第二信息的第二类型的电子设备的日志文件；

其中，所述第四电子设备根据故障所涉及的设备类型，为每一故障事件设定相应的转发范围，使得产生故障事件的第一类型的电子设备将故障事件转发给符合设备类型的其他在网的第一类型的电子设备，而不转发至不符合设备类型的其他在网的第一类型的电子设备；

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

确定所述第一电子设备是否符合所述第二信息；

在确定出所述第一电子设备符合所述第二信息的情况下，执行所述获取符合所述第二信息的电子设备的日志文件的步骤。

9.根据权利要求7所述的方法，其特征在于，所述获取符合所述第二信息的电子设备的日志文件，包括：

获取所述第一电子设备的日志文件。

10.根据权利要求7所述的方法，其特征在于，所述获取符合所述第二信息的电子设备的日志文件，包括：

获取符合所述第二信息的电子设备的、与所述第二故障类型相关的日志文件，并将获取到的日志文件对应于所述第四电子设备或者所述第五电子设备所存在的所述故障的标识；

11.一种日志获取装置，其特征在于，应用于第一电子设备，所述装置包括：

第一获取模块，用于获取第一故障类型，所述第一故障类型用于描述所述第一电子设备或者与所述第一电子设备相连的第二电子设备所存在故障的故障类型；

第二获取模块，用于根据所述第一故障类型获得第一信息，所述第一信息用于描述与所述第一故障类型相关的设备类型；所述第一信息描述的设备类型为所存在故障所涉及的设备类型，所述第一信息根据故障类型和设备类型间的关联关系得到；

第三获取模块，用于获取符合所述第一信息的电子设备的日志文件；

所述获取符合所述第一信息的电子设备的日志文件，包括：

所述日志获取装置还用于：

12.一种日志获取装置，其特征在于，应用于第一电子设备，所述装置包括：

接收模块，用于接收第四电子设备在所述第一电子设备和与所述第一电子设备相连的第二类型的电子设备中的至少一个符合第二信息的情况下发来的所述第二信息，其中，所述第二信息由所述第四电子设备根据所述第四电子设备或者与所述第四电子设备相连的第五电子设备所存在故障的第二故障类型得到，所述第二信息用于描述与所述第二故障类型相关的设备类型；

获取模块，用于获取符合所述第二信息的电子设备的日志文件；

所述获取符合所述第二信息的电子设备的日志文件，包括：

13.一种电子芯片，其特征在于，包括：

处理器，其用于执行存储在存储器上的计算机程序指令，其中，当所述计算机程序指令被所述处理器执行时，触发所述电子芯片执行权利要求1-10中任一项所述的方法。

14.一种电子设备，其特征在于，所述电子设备包括用于存储计算机程序指令的存储器、用于执行计算机程序指令的处理器和通信装置，其中，当所述计算机程序指令被该处理器执行时，触发所述电子设备执行如权利要求1-10中任一项所述的方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1-10中任一项所述的方法。