故障定位方法及装置与流程
1.本技术涉及数据处理技术领域，尤其涉及一种故障定位方法及装置。
背景技术：
2.分布式系统是一个硬件或软件组件分布在不同的设备上，彼此之间仅通过消息传递进行通信和协调的系统。分布式系统可靠性高、可扩展性好、通信快捷，同时能更方便地实现用户间的资源共享，但是由于分布式系统中的分布式业务所涉及到的设备规模庞大，设备间的调用和设备内模块间的调用错综复杂，导致出现故障时难以对故障进行定位。
3.现有的故障定位方法中，可以通过调用链标识(trace id)埋点来跟踪各设备间的调用，在出现故障后根据出现异常的业务的trace id进行全局索引，然后再进行分析定位。在上述过程中，当出现故障时，只有故障设备会上报故障信息，其它参与处理该异常业务的设备可能并不会上报故障相关信息，因此，服务器获取到的与故障相关的信息非常有限，不利于后续故障定位分析。另外，该故障定位方法会采集大量正常的业务流程数据，所采集的正常业务流程数据大概率与故障无关，会带来不必要的数据分析成本，增大分析难度。
技术实现要素：
4.本技术实施例提供一种故障定位方法及装置，用于解决数据较多导致分析难度较大、分析结果准确度较低的问题。
5.为达到上述目的，本技术的实施例采用如下技术方案：
6.第一方面，提供了一种故障定位方法，该方法包括：在检测到第一分布式业务存在故障时，获取待分析日志集合，其中，待分析日志集合包括第一设备、第二设备上传的故障日志和流水日志，故障日志和流水日志均包括第一分布式业务的标识(可以为trace id)，第一设备为最先检测到第一分布式业务出现故障的设备，第二设备与第一设备关联；确定故障时刻，故障时刻为第一分布式业务发生故障的时刻；基于所述故障时刻从所述待分析日志集合筛选得到关联日志，所述关联日志包括所述第一设备、所述第二设备在所述故障时刻的流水日志；从故障日志、关联日志中提取出多个节点的节点信息，每个节点表征一次调用的发起端或执行端，每个节点的节点信息包括第一分布式业务的标识、该节点的跨度标识以及父跨度标识；根据多个节点的节点信息构建调用树；若调用树中任意一个节点的出度和入度不相同，确定任意一个节点为故障节点，其中，每个节点的出度包括该节点发送信息的次数，每个节点的入度包括该节点接收到信息的次数。
7.可以看出，本技术实施例先基于第一分布式业务的标识进行了第一次筛选，接着基于故障时刻进行了第二次筛选，从而可以筛选得到与第一分布式业务相关的、且在故障发生时刻的流水日志，既能使服务器收集到更多与故障相关的信息，在进行故障定位时有更多与故障相关的信息可以利用，又能避免因为大量流水日志与故障无关导致分析难度增加的问题，可以提高故障定位的效率。另外，本技术还可以自动构建调用树以及自动定位故障节点，无需人工定位、分析，可以提升故障定位的效率。
8.在第一方面的一种实施方式中，故障时刻包括第一故障时刻、第二故障时刻，第一故障时刻为第一设备上第一分布式业务发生故障的时刻，第二故障时刻为第二设备上第一分布式业务发生故障的时刻；确定故障时刻包括：解析第一故障日志，得到第一故障时刻，第一故障日志为第一设备检测到第一分布式业务出现故障时上传的故障日志；根据第一分布式业务的标识从待分析日志集合中解析得到第一分布式业务的交互数据，交互数据包括第一设备、第二设备每次交互的时间戳；根据交互数据确定第一设备的系统时间与第二设备的系统时间的映射关系；根据第一故障时刻、映射关系计算第二故障时刻。
9.可以看出，本技术考虑到第一设备与第二设备间存在时间误差，故分别确定第一故障时刻、第二故障时刻，使得获取的流水日志更接近第一分布式业务发生故障的真实时刻。
10.在第一方面的一种实施方式中，关联日志包括第一关联流水日志以及第二关联流水日志，基于故障时刻从待分析日志集合筛选得到关联日志，包括：基于第一故障时刻、第一设备的标识从待分析日志集合筛选得到第一关联流水日志，第一关联流水日志为第一设备在第一故障时刻的流水日志；基于第二故障时刻、第二设备的标识从待分析日志集合筛选得到第二关联流水日志，第二关联流水日志为第二设备在第二故障时刻的流水日志。
11.在第一方面的一种实施方式中，在第一方面的一种实施方式中，交互数据包括第一设备、第二设备最近一次交互的第一时间戳、第二时间戳、第三时间戳及第四时间戳，第一时间戳为第一设备向第二设备发送调用请求的时间，第二时间戳为第二设备接收到调用请求的时间，第三时间戳为第二设备向第一设备发送反馈信息的时间，第四时间戳为第一设备接收到反馈信息的时间；映射关系指示第一设备的系统时间与第二设备的系统时间的差值与第一时间戳、第二时间戳、第三时间戳及第四时间戳关联，第一时间戳、第三时间戳与差值呈正相关，第二时间戳、第四时间戳与差值呈负相关。
12.在第一方面的一种实施方式中，映射关系满足算式：
[0013][0014]
其中，ta为第一设备的系统时间，为第二设备的系统时间，cs为第一时间戳，sr为第二时间戳，ss为第三时间戳，cr为第四时间戳。
[0015]
在第一方面的一种实施方式中，从故障日志、关联日志中提取出多个节点的节点信息，包括：从故障日志中提取多个第一节点的节点信息，每个第一节点的节点信息包括第一分布式业务的标识、该第一节点的跨度标识以及父跨度标识；从关联日志中提取多个第二节点的节点信息，每个第二节点的节点信息包括第一分布式业务的标识、该第二节点的跨度标识和父跨度标识，以及该第二节点与其他第二节点的交互情况；根据多个节点的节点信息构建调用树，包括：根据多个第一节点的节点信息构建第一调用树；根据多个第二节点的节点信息构建第二调用树；合并第一调用树、第二调用树得到调用树。
[0016]
在第一方面的一种实施方式中，根据多个第一节点的节点信息构建第一调用树，包括：若多个第一节点中存在两个相邻的第一节点，连接两个相邻的第一节点，以构建第一调用树，其中，两个相邻的第一节点中的一个第一节点的跨度标识为另一个第一节点的父跨度标识。
[0017]
在第一方面的一种实施方式中，方法还包括：若多个第一节点中不存在两个相邻
的第一节点，确定两个不相邻的第一节点；根据两个不相邻的第一节点的节点信息构建虚拟节点，虚拟节点的跨度标识为两个不相邻的第一节点中一个第一节点的父跨度标识，虚拟节点的父跨度标识为两个不相邻的第一节点中另一个第一节点的跨度标识；依次连接两个不相邻的第一节点中的一个第一节点、虚拟节点、两个不相邻的第一节点中的另一个第一节点，以构建第一调用树。
[0018]
在第一方面的一种实施方式中，根据多个第二节点的节点信息构建第二调用树，包括：连接多个第二节点中两个相邻的第二节点，以构建第二调用树，其中，两个相邻的第二节点中的一个第二节点的跨度标识为另一个第一节点的父跨度标识，两个相邻的第二节点的连接关系与两个相邻的第二节点的交互情况对应，若两个相邻的第二节点间存在客户端发送、服务端接收的过程，两个相邻的第二节点间建立第一连接；若两个相邻的第二节点间存在服务端发送、客户端接收的过程，两个相邻的第二节点间建立第二连接。
[0019]
在第一方面的一种实施方式中，合并第一调用树、第二调用树得到调用树，包括：若第一调用树和第二调用树中存在节点信息相同的两个节点，合并节点信息相同的两个节点；若第一调用树和第二调用树中不存在相同的节点，构建虚拟根节点，虚拟根节点的跨度标识和父跨度标识为0；连接虚拟根节点与第一调用树的根节点，连接虚拟根节点与第二调用树的根节点。
[0020]
在第一方面的一种实施方式中，在获取待分析日志集合之前，方法还包括：接收第一设备在第一分布式业务发生故障时上传的第一故障日志，第一故障日志包括事件id、第一设备的标识、关联设备的标识以及第一分布式业务的标识，关联设备包括第二设备；接收第二设备在接收到第一通知后上传的第二故障日志，第一通知指示第一分布式业务发生故障，第二故障日志包括事件id、第二设备的标识以及第一分布式业务的标识；将第一故障日志、第二故障日志添加至事件信息，事件信息包括多个故障日志。
[0021]
在第一方面的一种实施方式中，方法还包括：遍历事件信息中的每个故障日志，并判断每个故障日志携带的事件id是否与分布式故障的事件id集合匹配；若第一故障日志携带的事件id与分布式故障的事件id集合匹配，确定第一分布式业务存在故障。
[0022]
在第一方面的一种实施方式中，获取待分析日志集合，包括：判断第一设备的设备类型为第一类型或第二类型；若第一设备的设备类型为第一类型，根据第一故障日志携带的第一运行标识，并将第一运行标识所指示的流水日志添加至待分析日志集合；若第一设备的设备类型为第二类型，将第一故障日志添加至待分析日志集合；从第一故障日志解析得到第一分布式业务的标识和第二设备的标识；根据第一分布式业务的标识和第二设备的标识在事件信息进行检索，得到第二故障日志；判断第二设备的设备类型为第一类型或第二类型；若第二设备的设备类型为第一类型，根据第二故障日志携带的第二运行标识，并将第二运行标识所指示的流水日志添加至待分析日志集合；若第二设备的设备类型为第二类型，将第二故障日志添加至待分析日志集合。
[0023]
在第一方面的一种实施方式中，关联日志包括第一设备在t1～t2期间的流水日志，以及第二设备在t3～t4期间的流水日志，t1为第一故障时刻与第一预设时间的差值，t2为第一故障时刻与第二预设时间的和，t3为第二故障时刻与第一预设时间的差值，t4为第二故障时刻与第二预设时间的和。
[0024]
在第一方面的一种实施方式中，第二设备包括与第一设备共同执行第一分布式业
务的终端设备，或者包括分布式系统中在故障时刻的前预设时间内在线的终端设备。
[0025]
在第一方面的一种实施方式中，第一分布式业务内采用同步调用方式或异步调用方式。
[0026]
第二方面，本技术实施例提供了一种故障定位方法，所述方法包括：第一设备在检测到第一分布式业务发生故障时，向服务器上传第一故障日志，所述第一故障日志包括事件id、所述第一设备的标识、关联设备的标识以及所述第一分布式业务的标识，所述关联设备包括所述第二设备；第一设备向第二设备发送第一通知，所述第一通知携带有所述第一分布式业务的标识；第二设备向所述服务器上传第二故障日志，所述第二故障日志包括所述事件id、所述第二设备的标识以及所述第一分布式业务的标识。
[0027]
可见，第一设备在检测到分布式故障后，可以主动通知其他关联上报故障日志，这样可使得服务器收集到更多与故障相关的信息，在进行故障定位时有更多与故障相关的信息可以利用。
[0028]
第三方面，本技术实施例提供了一种故障定位装置，包括处理器，所述处理器和存储器耦合，所述存储器存储有程序指令，当所述存储器存储的程序指令被所述处理器执行时使得所述故障定位装置实现第一方面或第二方面中任一项所述的方法。
[0029]
第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在故障定位装置上运行时，使得故障定位装置可以执行上述第一方面或第二方面中任一项所述的方法。
[0030]
其中，第三方面至第四方面中任一种设计方式所带来的技术效果可参见第一方面中不同设计方式所带来的技术效果，此处不再赘述。
附图说明
[0031]
图1为本技术实施例提供的一种分布式系统的结构示意图；
[0032]
图2为本技术实施例提供的一种分布式系统的应用场景图；
[0033]
图3为本技术实施例提供的一种服务器的结构示意图；
[0034]
图4为本技术实施例提供的一种终端设备的结构示意图；
[0035]
图5为本技术实施例提供的故障定位方法的部分流程图；
[0036]
图6为本技术实施例提供的故障定位方法的部分流程图；
[0037]
图7为本技术实施例提供的第一设备与第二设备的一种时间映射图；
[0038]
图8为本技术实施例提供的第一设备与第二设备的又一种时间映射图；
[0039]
图9为本技术实施例提供的一种第一调用树的结构示意图；
[0040]
图10为本技术实施例提供的又一种第一调用树的结构示意图；
[0041]
图11为本技术实施例提供的一种调用树的结构示意图；
[0042]
图12为本技术实施例提供的一种合成调用树的示意图；
[0043]
图13为本技术实施例提供的一种芯片系统的结构示意图。
具体实施方式
[0044]
下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。其中，在本技术的描述中，除非另有说明，“至少一个”是指一个或多个，“多个”是指两个或多
于两个。另外，为了便于清楚描述本技术实施例的技术方案，在本技术的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
[0045]
为了下述各实施例的描述清楚简洁，首先给出相关概念或技术的简要介绍：
[0046]
分布式系统(distributed system)是由多个软件或者硬件构成的系统，使得多个软件或者硬件以一个统一的整体的方式呈现给用户。也就是说，对于用户而言分布式系统是一个整体。当用户向分布式系统发起业务请求时，分布式系统中的各软件或硬件可以为执行该业务提供不同的服务。
[0047]
埋点是数据采集领域(尤其是用户行为数据采集领域)的术语，指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。埋点的技术实质，是先应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获。埋点包括代码埋点、可视化埋点和无埋点。其中，代码埋点通过加入一些代码使得用户触发相应行为时，进行数据上报；可视化埋点利用了可视化交互手段，先配置相关事件，再进行数据采集；无埋点是指开发人员集成采集软件开发工具包(software development kit，sdk)后，sdk便直接开始捕捉和监测用户在应用里的所有行为，并全部上报，不需要开发人员添加额外代码。需要说明的是，在本技术实施例中，埋点与用户行为无关，只与业务流上的故障相关。
[0048]
远程过程调用(remote procedure call，rpc)的出现主要是为了解决分布式系统间的通信透明性的问题。也就意味着，rpc让用户不用理会调用的是哪个设备上的服务，在用户的角度，这个远程服务和调用本地服务一样安全可靠。远程调用一般涉及四个过程：客户端发送(client send，cs)、服务端接收(service receive，sr)、服务端发送(service send，ss)和客户端接收(client receive，cr)。其中，客户端可以称为调用端，服务端也可以称为执行端。另外，客户端、服务端可以指具有硬件的终端设备，也可以为终端设备内的软件模块，在此不做具体限制。在本技术实施例中，终端设备可以在rpc的过程中进行埋点，以记录分布式业务的调用情况。
[0049]
通用唯一识别码(universally unique identifier，uuid)是由计算机根据网卡媒体存取控制(media access control，mac)地址、时间戳、名字空间(name space)、随机或伪随机数、时序等元素生成的在一定范围内的唯一标识符。uuid是16字节128位长的数字，通常以36字节的字符串表示，例如为3f2504e0-4f89-11d3-9a0c-0305e82c3301。
[0050]
事件id(event id)是一个数字，表示错误信息，即阻碍业务继续进行的原因，不同的event id表示的错误信息不同，根据event id可以大概确定故障模块、故障影响、甚至根因，进而编程人员和维护人员解决问题。
[0051]
故障日志，即错误日志，包括软件运行时出错信息，该出错信息可包括event id、故障设备的设备类型以及关于故障的描述等。编程人员和维护人员等可以利用错误日志对系统进行调试和维护。
[0052]
流水日志，包括软件在正常运行过程中的各种信息，例如执行分布式业务发生的日常事件记录、发生日常事件记录的日期以及发生日常事件记录的时间戳等信息。日常事件可以包括参数重置、rpc调用等事件。
[0053]
本技术实施例提供一种故障定位方法，可以应用于分布式系统。具体的，该分布式
系统包括至少一个服务器和多个终端设备。当多个终端设备参与的分布式业务出现故障时，检测到故障的终端设备可以向服务器上报故障日志，并通知其他终端设备上报故障日志。这样可使得服务器收集到更多与故障相关的信息，在进行故障定位时有更多与故障相关的信息可以利用。
[0054]
在服务器接收到所有终端设备上报的故障日志后，还可以筛选出各终端设备在发生故障前后的流水日志。如此，可避免因为大量流水日志与故障无关导致分析难度增加的问题，可以提高故障定位的效率。
[0055]
在服务器接收到多个终端设备的故障日志，以及筛选出多个终端设备在发生故障前后的流水日志后，可基于获取的故障日志和发生故障前后的流水日志定位故障的出处，并分析故障发生的原因，无需人工定位、分析，可以提升故障定位的效率。
[0056]
示例性的，本技术实施例提供的分布式系统可以如图1所示。如图1所示，该分布式系统包括服务器10、终端设备20、终端设备30、终端设备40和终端设备50。其中，终端设备20、终端设备30、终端设备40及终端设备50可与服务器10通信。终端设备20、终端设备30、终端设备40及终端设备50之间彼此通信。
[0057]
在图1所示的分布式系统一种可能的应用场景中，终端设备20、终端设备30、终端设备40及终端设备50可以是智能家居系统中的各种设备，例如，用户的智能手机、个人计算机(personal computer，pc)、平板、智能电视、智能手表、智能音响等，这些设备可以通过用户id相互关联，且关联后的各个设备可以通过蓝牙、无线网络、近场通信(near field communication，nfc)等方式建立通信连接。例如，终端设备20、终端设备30、终端设备40之间可以通过wifi和/或蓝牙建立通信连接。在该应用场景下，分布式业务被执行时需要通过多个终端设备配合完成，多个终端设备间存在调用关系。多个终端设备的调用关系及调用顺序可以通过调用链来反映。
[0058]
调用链包括多个节点，每个节点可执行分布式业务中的部分业务流程。节点与节点之间可以传递调用请求。示例性的，如图2所示，终端设备20可以为智能手机，终端设备30可以为智能电视，终端设备40可以为智能音响。分布式业务例如为，用户通过智能手机发起播放视频的业务，并通过智能电视播放该视频的图像，以及通过智能音响播放该视频的音频。在该分布式业务中存在的调用链为：用户向智能手机发起请求以执行视频播放业务，智能手机响应于该请求启动视频播放业务，并调用智能电视播放视频的图像，并且智能电视调用智能音响播放该视频的音频。又例如，智能设备20可以为智能手机a，终端设备30可以为平板。分布式业务例如为，在智能手机a接到来电时，智能手机a向平板发送来电信息，使得平板上同步提示用户接听来电，若用户通过平板接听来电，平板可以借助手机的通信功能进行通话。在该分布式业务中存在的调用链为：智能手机b响应于用户接听电话的操作，调用智能手机a的通信功能进行通话。
[0059]
在其他实施方式中，分布式业务还可以包括无线端请求、网页请求等，在此不做具体限制。
[0060]
在执行分布式业务的过程中，分布式系统中的终端设备(例如终端设备20-终端设备50)可能会出现故障。其中，该故障可包括rpc请求失败或超时、无响应、设备重启、进程崩溃、应用卡死、系统服务故障等。
[0061]
为了便于在分布式业务执行过程中对上述可能出现的故障进行跟踪定位，在分布
式业务的调用链的每个节点，例如，终端设备20、终端设备30、终端设备40、终端设备50，均会进行埋点操作，生成调用链信息。调用链信息中可以包括trace id、跨度标识(span id)、父跨度标识(parent spanid)、节点(终端设备)数量和业务名称等。其中，trace id在调用链首节点(也可以称为根节点)直接生成，并通过调用链协议向后续节点逐级传递，首节点为发起分布式业务的终端设备。trace id是调用链的唯一标识，也可以是该分布式业务的唯一标识，例如，trace id也可以作为一项分布式业务的唯一标识写入诸如故障日志、业务日志、终端设备日志等的分布式业务的数据文件中。span id可以在节点接收到调用请求时可生成。此外，节点还可以将trace id以及本节点的span id一起传递给下游节点。当携带有该span id、trace id的调用请求传到下游节点时，下游节点将生成新的span id，并将调用请求中携带的span id记录为parent spanid。基于此逻辑，可以根据不同节点的span id、parent spanid还原节点间的调用关系，从而还原调用链。节点数量包括当前节点在内的被调用的节点的数量，可以用于确定各节点的调用关系；随着调用次数的增加，节点数量增大。上述调用链信息所包括的内容仅仅作为一个示例，在其他的实施方式中，调用链信息还可包括其他内容，例如，还可以包括当前节点调用的下一个节点(子节点)的标识，在此不做具体限制。
[0062]
可以理解地，图1所示的分布式系统仅为本技术实施例中的一种示例，本技术实施例提供的分布式系统包括但不仅限于以上结构。分布式系统还可以包括比图1所示的更多或更少的终端设备，在此不做具体限制。
[0063]
图1中的服务器10可以为普通服务器(也可以称为物理服务器)，其可以为具有独立的硬盘、宽带、真实存在的物理设备。或者为它多个服务器组成的服务器集，在此不做具体限制。
[0064]
本技术实施例以服务器10物理服务器为例进行说明。如图3所示，服务器10可以包括处理器110、存储器120及通信模块130。
[0065]
处理器110可用于读取和执行计算机可读指令。具体地，处理器110可以包括控制器、运算器和寄存器。其中，控制器主要负责指令译码，并为指令对应的操作发出控制信号。运算器主要负责保存指令执行过程中临时存放的寄存器操作数和中间操作结果等。具体实现中，处理器110的硬件架构可以是专用集成电路(application specific integrated circuit，asic)架构、mips(microprocessor without interlocked piped stages)架构、arm(advanced risc machines)架构或者网络处理器(net processor，np)架构等等。
[0066]
存储器120与处理器110耦合，用于存储各种软件程序和/或多组指令。具体实现中，存储器120可包括高速随机存取的存储器，并且也可包括非易失性存储器，例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。存储器120可以存储操作系统，例如ucos，vxworks、rtlinux等嵌入式操作系统。
[0067]
通信模块130可用于通过网络建立服务器10与其它通信终端(如图1中的多个终端设备)之间的通信连接，并用于通过网络收发数据。
[0068]
可以理解的是，本实施例示意的结构并不构成对服务器10的具体限定。在另一些实施例中，服务器10可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
[0069]
图1中的终端设备可指任何一种具有计算处理能力的设备、器械或者机器，在本申
请实施例中可以为具有数据处理能力，或者具有功能外设的终端设备。终端设备20、终端设备30和终端设备40、终端设备50包括但不局限于，膝上型设备、台式机、手持pc、个人数字助理、嵌入式处理器、数字信号处理器(digital signal processor，dsp)、图形设备、视频游戏设备、机顶盒、微控制器、蜂窝电话、便携式媒体播放器、手持设备、可穿戴设备，虚拟现实(virtual reality，vr)和/或增强现实(augment reality，ar)设备，物联网(internet of things，iot)设备，智能摄像头，智能音响系统，车载信息娱乐设备，流媒体客户端设备，电子书阅读设备，电动车辆的控制系统，以及各种其他电子设备。一般地，能够包含本文中所公开的处理器和/或其它执行逻辑的多个装置和电子设备一般都是合适的。
[0070]
本技术实施例中以图1所示的终端设备是手机为例，对本技术实施例提供的终端设备的结构进行举例说明。如图4所示，终端设备(如手机)可以包括：处理器210，外部存储器接口220，内部存储器221，通用串行总线(universal serial bus，usb)接口230，充电管理模块240，电源管理模块241，电池242，天线1，天线2，移动通信模块250，无线通信模块260，音频模块270，扬声器270a，受话器270b，麦克风270c，耳机接口270d，传感器模块280，按键290，马达291，指示器292，摄像头293，显示屏294，以及用户标识模块(subscriber identification module，sim)卡接口295等。
[0071]
其中，上述传感器模块280可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器和骨传导传感器等传感器。
[0072]
可以理解的是，本实施例示意的结构并不构成对终端设备的具体限定。在另一些实施例中，终端设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
[0073]
处理器210可以包括一个或多个处理单元，例如：处理器210可以包括应用处理器(application processor，ap)，调制解调处理器，图形处理器(graphics processing unit，gpu)，图像信号处理器(image signal processor，isp)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，dsp)，基带处理器，和/或神经网络处理器(neural-network processing unit，npu)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
[0074]
控制器可以是终端设备的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
[0075]
处理器210中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器210中的存储器为高速缓冲存储器。该存储器可以保存处理器210刚用过或循环使用的指令或数据。如果处理器210需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器210的等待时间，因而提高了系统的效率。
[0076]
在一些实施例中，处理器210可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，i2c)接口，集成电路内置音频(inter-integrated circuit sound，i2s)接口，脉冲编码调制(pulse code modulation，pcm)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，uart)接口，移动产业处理器接口(mobile industry processor interface，mipi)，通用输入输出(general-purpose input/output，gpio)接口，用户标识模块(subscriber identity module，sim)接口，和/或
通用串行总线(universal serial bus，usb)接口等。
[0077]
可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对终端设备的结构限定。在另一些实施例中，终端设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
[0078]
充电管理模块240用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。充电管理模块240为电池242充电的同时，还可以通过电源管理模块241为终端设备供电。
[0079]
电源管理模块241用于连接电池242，充电管理模块240与处理器210。电源管理模块241接收电池242和/或充电管理模块240的输入，为处理器210，内部存储器221，外部存储器，显示屏294，摄像头293，和无线通信模块260等供电。在一些实施例中，电源管理模块241和充电管理模块240也可以设置于同一个器件中。
[0080]
终端设备的无线通信功能可以通过天线1，天线2，移动通信模块250，无线通信模块260，调制解调处理器以及基带处理器等实现。在一些实施例中，终端设备的天线1和移动通信模块250耦合，天线2和无线通信模块260耦合，使得终端设备可以通过无线通信技术与网络以及其他设备通信。
[0081]
天线1和天线2用于发射和接收电磁波信号。终端设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
[0082]
移动通信模块250可以提供应用在终端设备上的包括2g/3g/4g/5g等无线通信的解决方案。移动通信模块250可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，lna)等。移动通信模块250可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。
[0083]
移动通信模块250还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块250的至少部分功能模块可以被设置于处理器210中。在一些实施例中，移动通信模块250的至少部分功能模块可以与处理器210的至少部分模块被设置在同一个器件中。
[0084]
无线通信模块260可以提供应用在终端设备上的包括wlan(如(wireless fidelity，wi-fi)网络)，蓝牙(bluetooth，bt)，全球导航卫星系统(global navigation satellite system，gnss)，调频(frequency modulation，fm)，近距离无线通信技术(near field communication，nfc)，红外技术(infrared，ir)等无线通信的解决方案。
[0085]
无线通信模块260可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块260经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器210。无线通信模块260还可以从处理器210接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。
[0086]
终端设备通过gpu，显示屏294，以及应用处理器等实现显示功能。gpu为图像处理的微处理器，连接显示屏294和应用处理器。gpu用于执行数学和几何计算，用于图形渲染。处理器210可包括一个或多个gpu，其执行程序指令以生成或改变显示信息。
[0087]
显示屏294用于显示图像，视频等。该显示屏294包括显示面板。
[0088]
终端设备可以通过isp，摄像头293，视频编解码器，gpu，显示屏294以及应用处理
器等实现拍摄功能。isp用于处理摄像头293反馈的数据。摄像头293用于捕获静态图像或视频。在一些实施例中，终端设备可以包括1个或n个摄像头293，n为大于1的正整数。
[0089]
外部存储器接口220可以用于连接外部存储卡，例如micro sd卡，实现扩展终端设备的存储能力。外部存储卡通过外部存储器接口220与处理器210通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
[0090]
内部存储器221可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令，从而执行终端设备的各种功能应用以及数据处理。例如，在本技术实施例中，处理器210可以通过执行存储在内部存储器221中的指令，内部存储器221可以包括存储程序区和存储数据区。
[0091]
其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储终端设备使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器221可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，ufs)等。
[0092]
终端设备可以通过音频模块270，扬声器270a，受话器270b，麦克风270c，耳机接口270d，以及应用处理器等实现音频功能。例如音乐播放，录音等。
[0093]
按键290包括开机键，音量键等。按键290可以是机械按键。也可以是触摸式按键。马达291可以产生振动提示。马达291可以用于来电振动提示，也可以用于触摸振动反馈。指示器292可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。sim卡接口295用于连接sim卡。sim卡可以通过插入sim卡接口295，或从sim卡接口295拔出，实现和终端设备的接触和分离。终端设备可以支持1个或n个sim卡接口，n为大于1的正整数。sim卡接口295可以支持nano sim卡，micro sim卡，sim卡等。
[0094]
下面将结合附图说明本技术实施例提供的故障定位方法。
[0095]
在本技术实施例中，故障定位方法可包括三个步骤，分别为：一、多个终端设备向服务器上报故障；二、服务器筛选与故障相关的故障日志和流水日志；三、服务器根据故障日志和关联日志定位故障节点。下面将分别详细说明上述三个步骤。
[0096]
一、多个终端设备向服务器上报故障
[0097]
在多个终端设备处理第一分布式业务的过程中出现故障，最先发现故障的终端设备以及与该终端设备关联的设备(后称为关联设备)可以主动向服务器上报故障日志。其中，第一分布式业务并不指代任何特定的分布式业务，仅为分布式业务的示例。
[0098]
其中，关联设备可以为参与第一分布式业务的多个终端设备中除最先发现故障并上报故障日的终端设备以外的其他设备。例如，终端设备20、终端设备30、终端设备40及终端设备50共同参与第一分布式业务，其中终端设备20为最先发现故障且上报故障日志的终端设备，则终端设备30、终端设备40及终端设备50为关联设备。
[0099]
可选的，关联设备还可以为分布式系统内当前在线的终端设备以及在故障发生前的预设时间(例如1分钟、10分钟、半小时)内在线的终端设备。例如，分布式系统包括终端设备20、终端设备30、终端设备40及终端设备50，其中终端设备20为最先发现故障的设备，在故障发生前的1分钟内，仅有终端设备20、终端设备30、终端设备40在线，在故障发生后，终端设备40掉线，则关联设备包括终端设备30和终端设备40。
[0100]
下面，以第一设备为最先发现第一分布式业务出现故障的设备，关联设备为第二设备为例，结合图5说明多个终端设备上报故障的过程。如图5所示，为本技术实施例提供的故障定位方法的部分流程图。该故障定位方法包括：
[0101]
s501，在第一分布式业务发生故障时，第一设备向服务器发送第一故障日志。
[0102]
第一设备在同一时间可以处理多个分布式业务。例如，第一设备可以为手机，多个分布式业务可以包括：业务1，手机将视频投屏至智能电视，由智能电视播放视频画面；业务2，手机将接收到的来电信息转发给平板，用户通过平板接听电话时，平板调用手机的通话模块接收/传输音频流。第一分布式业务可以为多个分布式业务中的任意一个。
[0103]
具体的，若第一设备在处理第一分布式业务的过程中发生故障，第一设备可生成第一故障日志，并向服务器发送第一故障日志。
[0104]
在本技术实施例中，第一故障日志包括event id、故障时间、故障设备(即第一设备)的设备类型、故障模块、故障类型、故障设备的uuid、关联设备的uuid、第一分布式业务的trace id等。
[0105]
其中，设备类型可以包括终端、pc、服务器、路由器等。进一步的，该根据故障设备所使用的操作系统，可以将设备类型分为两类：第一类为使用windows操作系统的设备，例如pc；第二类为使用非windows操作系统的设备，例如手机、路由器。
[0106]
故障模块指第一设备中发生故障的模块，该模块可以是硬件模块，也可以是软件模块，在此不做具体限制。该故障类型可包括rpc请求失败或超时、无响应、设备重启、进程崩溃、应用卡死、系统服务故障等。
[0107]
在一种可选的实施方式中，第一设备中可以预先存储第一分布式业务的调用关系(可以称为第一调用关系)。该第一调用关系用于指示该第一分布式业务所涉及的设备，以及每个设备的uuid。示例性的，该第一调用关系指示第一设备、第二设备及第三设备参与了第一分布式业务，则第一设备可以查询到第二设备的uuid和第三设备的uuid，并在第一故障日志中添加第二设备的uuid和第三设备的uuid。这样一来，关联设备均为参与第一分布式业务的设备，关联设备上传的信息与故障相关的可能性较大，可以为服务器定位故障提供更准确的信息。
[0108]
在另一种可选的实施方式中，第一设备中可以预存储有分布式系统内每个终端设备的状态以及uuid。在第一分布式业务出现故障后，第一设备可以获取分布式系统内当前在线的终端设备的uuid以及在一分布式业务出现故障前的预设时间内(例如发生故障前1分钟)在线的终端设备的uuid，并在第一故障日志中添加获取到的uuid。这样一来，即使掉线的设备也需要上传与故障相关的信息，使得服务器获取的信息更加全面。
[0109]
在本技术实施例中，若第一设备的设备类型为第二类，则该第一故障日志还包括运行标识(running id)，该running id用于标识第一流水日志，该第一流水日志为第一设备发生故障前第一时间到第一设备发生故障后第二时间内的流水日志。服务器可根据该running id快速查到与故障相关的流水日志。若第一设备的设备类型为第二类，第一设备还会在第一分布式业务发生故障时，将第一流水日志所包括的内容添加到第一故障日志中并发送给服务器，也就是说，该第一故障日志还包括第一流水日志所包括的内容，这样一来，服务器无需再额外查流水日志。
[0110]
s502，第一设备向第二设备发送第一通知。
[0111]
根据上文可知，第一设备可以获取关联设备的uuid，则第一设备可以从关联设备的uuid中查询到第二设备的uuid，并向第二设备发送第一通知。需要说明的是，第二设备包括所有的关联设备。
[0112]
该第一通知可包括event id、第一分布式业务的trace id、第一分布式业务发生故障的时刻等。
[0113]
s503，第二设备接收第一通知。
[0114]
具体的，第二设备接收第一设备发送的第一通知，即第二设备可以接收到event id以及第一分布式业务的trace id。在接收到第一通知后，第二设备可确定第一分布式业务出现故障。
[0115]
s504，第二设备向服务器发送第二故障日志。
[0116]
第二设备确定第一分布式业务出现故障后，可以生成第二故障日志，并向服务器发送第二故障日志。其中，第二故障日志包括event id、第二设备的设备类型、第二设备的uuid以及第一分布式业务的trace id等。
[0117]
可见，在多个终端设备处理第一分布式业务的过程中出现故障，最先发现故障的终端设备以及与该终端设备关联的设备(后称为关联设备)可以主动向服务器上报故障日志，无需用户手动上报故障，简化用户操作。
[0118]
需要说明的是，s501～s504中仅以关联设备包括一个第二设备为例进行说明，实际上关联设备可以包括多个第二设备。当关联设备包括多个第二设备时，第一设备可以在第一分布式业务发生故障时，向多个第二设备均发送第一通知。多个第二设备接收到该第一通知后，均可以向服务器发送第二故障日志。其原理与s501～s504类似，在此不再赘述。
[0119]
可选的，用户还可以选择手动向服务器上报故障。示例性的，第一设备在处理第一分布式业务的过程中发生故障，用户可以打开第一设备上的第一应用(例如为智能家居应用)。第一设备可显示第一应用的第一界面，该第一界面包括上报故障的选项。响应于用户点击该上报故障的选项的操作，第一设备可向服务器提交第一故障单。该第一故障单包括第一单号以及故障信息，故障信息可包括event id、故障时间、第一设备的设备类型、故障模块、故障类型、第一设备的uuid、第一分布式业务的trace id等。此外，响应于用户点击该上报故障的选项的操作，第一设备还可以向第二设备发送提交故障单的通知。第二设备接收到提交故障单的通知后，可向服务器提交第二故障单。第二故障单包括第二单号及故障信息。其中，第一单号与第二单号相同，表明第一设备与第二设备关联。
[0120]
需要说明的是，第一设备和第二设备除了上传故障日志，第一设备、第二设备还可以实时或定时上传流水日志，以便于服务器从流水日志中查询与故障相关的信息。流水日志包括终端设备记录的事件以及对应的时间戳，例如包括在启动期间装入驱动程序或者其他系统组件失败的事件、第一分布式业务的调用事件(例如cs、sr、ss、cr)等。第一分布式业务的调用事件可以记录第一分布式业务的调用链信息，例如第一分布式业务的trace id、span id、parent spanid、节点数量等。
[0121]
二、服务器筛选与故障关联的故障日志和流水日志
[0122]
服务器确定存在分布式故障后，可以获取待分析日志集合，该待分析日志集合包括故障设备、关联设备上传的故障日志和流水日志。
[0123]
下面以故障业务为第一分布式业务，第一设备为最先发现第一分布式业务出现故
障的设备，第二设备为关联设备，具体说明服务器获取待分析日志集合的过程。
[0124]
如图6所示，本技术实施例提供的故障定位方法包括：
[0125]
s601，服务器遍历事件信息中的每个故障日志，并判断每个故障日志携带的事件id与分布式故障的事件id集合是否匹配。
[0126]
服务器在接收到终端设备上传的故障日志(例如，第一设备上传的第一故障日志、第二设备上传的第二故障日志)，可以将故障日志存储至特定的文件夹内，例如服务器可以将故障日志存储至事件信息(event info)中。如此，该event info中包括多个故障日志。
[0127]
服务器可以遍历该事件信息中的每个故障日志，以判断是否存在分布式故障。其中，分布式故障可以理解为在处理分布式业务过程中出现的故障，可包括rpc请求失败或超时、无响应、设备重启、进程崩溃、应用卡死、系统服务故障等。前文已经说明，故障日志包括event id、分布式业务的trace id、故障设备的uuid等信息。在本技术实施例中，服务器可以读取每个故障日志中的event id，并判断每个故障日志携带的事件id是否与分布式故障的事件id集合匹配。若第一故障日志携带的事件id与分布式故障的事件id集合匹配，确定第一分布式业务存在故障。其中，分布式故障的事件id集合包括所有由分布式故障造成event id。其中，故障日志携带的事件id与分布式故障的事件id集合匹配可指，分布式故障的事件id集合包括该故障日志携带的事件id。
[0128]
可选的，服务器还可以判断该故障日志携带的事件id是否是以特定字符开头的字符串，例如为950*******或者951*******(即以950或951开头的字符串)。若某个故障日志携带的event id为以特定字符开头的字符串，则服务器可以确定存在分布式故障；若不存在event id为以特定字符开头的字符串，则服务器可以确定不存在分布式故障。
[0129]
可选的，服务器可以按照预设的时间间隔遍历事件信息中的每个故障日志，判断是否存在分布式故障。示例性的，服务器可以每间隔10分钟、1小时或者1天，遍历一次事件信息，以判断是否存在分布式故障。
[0130]
s602，若第一故障日志携带的事件id与分布式故障的事件id集合匹配，服务器确定第一分布式业务存在故障。
[0131]
s603，服务器判断第一设备的设备类型为第一类型或第二类型。
[0132]
具体的，设备类型可包括第一类型和第二类型。其中，第一类型为使用andriod系统的设备，例如手机。第二类型为使用windows系统的设备，例如pc。其中，第一类型的终端设备上传的故障日志中，包括running id，可用于查询该终端设备在发生故障前第一时间到终端设备发生故障后第二时间内的流水日志。第二类型的终端设备上传的故障日志中，包括该终端设备在发生故障前第一时间到终端设备发生故障后第二时间内的流水日志的内容。
[0133]
其中，若第一设备的设备类型为第一类型，服务器执行s604；若第一设备的设备类型为第二类型，服务器执行s605。
[0134]
s604，服务器根据第一故障日志携带的运行标识，并将运行标识所指示的流水日志添加至待分析日志集合。
[0135]
其中，该第一故障日志携带的运行标识也可以称为第一运行标识。
[0136]
s605，服务器将第一故障日志添加至待分析日志集合。
[0137]
由于第二类型的终端设备上传的故障日志中，原本就包括流水日志的内容，因此
服务器无需查，直接将其添加至待分析日志集合即可。
[0138]
可见，本技术针对不同类型的终端设备可以采用不过聚合流水日志的方法，方便、高效。
[0139]
s606，服务器从第一故障日志解析得到第一分布式业务的trace id和第二设备的uuid。
[0140]
s607，服务器根据第一分布式业务的trace id和第二设备的uuid在事件信息进行检索，得到第二故障日志。
[0141]
s608，服务器判断第二设备的设备类型为第一类型或第二类型。
[0142]
若第二设备的设备类型为第一类型，服务器执行s609；若第二设备的设备类型为第二类型，服务器执行s610。
[0143]
s609，服务器根据第二故障日志携带的运行标识，并将运行标识所指示的流水日志添加至待分析日志集合。
[0144]
其中，该第二故障日志携带的运行标识也可以称为第二运行标识。
[0145]
s610，服务器将第二故障日志添加至待分析日志集合。
[0146]
需要说明的是，在第一设备、第二设备的设备类型为第一类型的情况下，服务器也可将第一故障日志、第二故障日志添加至待分析日志集合，使待分析日志中包括与第一分布式业务关联的故障日志。
[0147]
如此，服务器便可以获得待分析日志集合，且该待分析日志集合包括与第一分布式业务关联的流水日志、故障日志，这能减少后续服务器需要分析的日志的数量，降低分析难度，便于后续进行分析、定位故障节点和原因。
[0148]
需要说明的是，根据前文可知，当分布式业务出现故障时，最早发现该故障的设备(例如，第一设备)以及关联设备(例如，第二设备)均会上传故障日志，但其上传的故障日志所包括的内容并不相同。例如，第一设备上传了第一故障日志，第二设备上传了第二故障日志，第一故障日志包括event id、第一分布式业务的trace id、故障设备(例如，第一设备)的uuid以及关联设备(例如，第二设备)的uuid，第二故障日志包括event id、第一分布式业务的trace id以及故障设备(即第二设备)的uuid。也即，只有最先发现故障的设备所上传的故障日志中，包括关联设备的uuid。在这种情况下，若服务器基于第一故障日志确定存在分布式故障，则服务器可以获取关联设备的uuid，并执行s606～s610；若服务器基于第二故障日志确定存在分布式故障，则服务器则无需获取关联设备的uuid，仅执行s601～s605；另外，服务器还可以继续遍历事件信息，直至遍历到第一故障日志时，再重新执行s601～s610。
[0149]
在获取待分析日志集合后，服务器可以确定故障时刻，并进一步根据故障时刻对待分析日志进行筛选得到关联日志，进一步减少待分析的日志的数量。
[0150]
其中，故障时刻为第一分布式业务出现故障的时刻。考虑到第一设备与第二设备作为两个独立的系统，其具有不同的授时系统，即第一设备上第一分布式业务发生故障的时刻与第二设备上第一分布式业务发生故障的时刻可能并不相同。因此，该故障时刻包括第一故障时刻、第二故障时刻，第一故障时刻为第一设备上第一分布式业务发生故障的时刻，第二故障时刻为第二设备上第一分布式业务发生故障的时刻。该关联日志包括第一关联流水日志以及第二关联流水日志，第一关联流水日志包括第一设备在第一故障时刻的流
水日志，第二关联流水日志包括第二设备在第二故障时刻的流水日志。
[0151]
其中，第一设备作为最先检测到第一分布式业务出现故障的设备，其上传第一故障日志中携带的时间戳为第一分布式业务出现故障的真实时刻。因此，服务器可以将第一故障日志中携带的时间戳作为第一故障时刻。
[0152]
在确定第一故障时刻后，服务器可以基于第一故障时刻及第一设备的uuid在待分析日志集合中进行检索，得到第一关联流水日志。具体的，第一关联流水日志可包括时间戳在t1～t2期间(包括t1时刻和t2时刻)的流水日志，t1为第一故障时刻与第一预设时间的差值，t2为第一故障时刻与第二预设时间的和。又或者，第一关联流水日志可包括时间戳在t1～t1期间(包括t1时刻和t1时刻)的流水日志，t1为第一故障时刻。也即，第一关联流水日志包括第一设备上传的第一分布式业务发生故障前预设时间内的流水日志以及第一分布式业务发生故障时的流水日志即可，本技术在此不做具体限制。
[0153]
在本技术实施例中，服务器可根据第一分布式业务的埋点情况，估算第一设备与第二设备之间的时间误差，并根据第一故障时刻及该时间误差得到第二故障时刻。
[0154]
具体的，服务器可以先根据第一分布式业务的trace id从待分析日志集合中解析得到第一分布式业务的交互数据，并根据该交互数据估算第一设备与第二设备之间的时间误差。
[0155]
其中，该交互数据包括第一设备与第二设备每次交互的时间戳。具体的，交互数据可包括第一设备与第二设备最近一次交互过程中(其中以第一设备为客户端，第二设备为服务端为例)，cs点的时间戳(也可以称为第一时间戳)、sr点的时间戳(也可以称为第二时间戳)、ss点的时间戳(也可以称为第三时间戳)、cr点的时间戳(也可以称为第四时间戳)。
[0156]
接着，服务器可基于第一时间戳、第二时间戳、第三时间戳及第四时间戳计算第一设备与第二设备之间的时戳校正值，该时戳校正值可以理解为时间误差。
[0157]
在一种可选的实施方式中，服务器可以先根据第一时间戳、第二时间戳、第三时间戳及第四时间戳计算时戳校正值的无偏估计，并计算时戳校正值。其中，该无偏估计满足算式：
[0158][0159]
其中，δt为时戳校正值的无偏估计，cs为第一时间戳，sr为第二时间戳，ss为第三时间戳，cr为第四时间戳。
[0160]
根据图7可知：当δt1≤δt2时，ε+δt1＝δt、ε+δt＝δt2；
[0161]
当δt1＞δt2时，ε+δt2＝δt、ε+δt＝δt1；
[0162]
进而，ε≤δt。ε可以理解为第一设备与第二设备的时戳校正值，该时戳校正值小于等于δt。
[0163]
也就是说，若要满足算式1，ε需满足：ε≤δt。
[0164]
另外，根据图7可以看出：第一设备上cs点的时刻与第二设备上a点的时刻(sr-δt)对应。如此，第一设备上的ta时刻与第二设备上的tb时刻可存在映射关系：
[0165]
ta-cs＝tb-(sr-δt)
……
算式2
[0166]
对算式2进行等式变化可得：其中，为
时戳校正值。
[0167]
其中，对于调用链内的时刻，第一设备上的ta时刻与第二设备上的tb时刻可存在映射关系：其中，ε≤δt，ta∈[cs,cr]，tb∈[sr-δt,ss+δt]。
[0168]
对于调用链外的时刻，第一设备上的ta时刻与第二设备上的tb时刻可存在映射关系：其中，ε≤δt。
[0169]
示例性的，第一设备与第二设备最近一次的调用情况可以如图8中的(a)所示，其中cs＝10，sr＝20，ss＝30，cr＝50。将cs＝10，sr＝20，ss＝30，cr＝50代入上述算式2可得到：ta＝tb+5，且ε≤15。如此，可得到图8中的(b)所示的映射情况：第一设备上的时间戳为10时，第二设备上的时间戳为5；第一设备上的时间戳为25时，第二设备上的时间戳为20；第一设备上的时间戳为35时，第二设备上的时间戳为30；第一设备上的时间戳为50时，第二设备上的时间戳为45。进一步的，对图8中的(b)所示的映射图进行校正后，可得到如图8中的(c)所示的映射图。图8仅示出了在调用链内的时间戳的对应情况，实际上调用链外的时刻也具备该映射关系，例如第一故障时刻为55时，可以确定第二故障时刻为50。
[0170]
通过上述调用链的埋点时刻计算时戳校正值，无需进行大量计算，可以在无功耗损失的前提下，获取较为精准的时戳校正值。
[0171]
需要说明的是，上述仅仅给出了一种计算时戳校正值的方法，实际上还可以利用神经网络模型等方法估算第一设备与第二设备的时戳校正值。例如，服务器可以将第一时间戳、第二时间戳、第三时间戳及第四时间戳输入预先建立的神经网络模型，由神经网络模型输出时戳校正值，该预先建立的神经网络模型由大量的训练数据进行训练得到，训练数据可包括一次调用过程中的cs时间点、sr时间点、ss时间点、cr时间点以及两个设备之间的时间误差。
[0172]
在确定第二故障时刻后，服务器可以根据该第二故障时刻和第二设备uuid在待分析日志集合中进行检索，得到第二关联流水日志。具体的，第二关联流水日志可包括时间戳在t3～t4期间(包括t3时刻和t4时刻)的流水日志，t3为第二故障时刻与第一预设时间的差值，t4为第二故障时刻与第二预设时间的和。
[0173]
可选的，服务器也可以不计算第二故障时刻。服务器可以基于该时戳校正值将第一设备上的t1时刻映射至第二设备上的t3时刻，将第一设备上的t2时刻映射至第二设备上的t4时刻，并进一步筛选第二设备上传的时间戳在t3～t4期间(包括t3时刻和t4时刻)的流水日志。
[0174]
服务器通过两次筛选后得到关联日志，可以进一步缩小服务器待分析的流水日志的数量，减小服务器的分析难度。
[0175]
需要说明的是，上述的第二设备可以为一个也可以为多个，在此不做具体限制。其中，当第二设备为多个的具体流程与第二设备为一个的流程类似：服务器可以基于图6所示的流程查每个第二设备的流水日志并将其添加至待分析日志集合。以及，确定第一设备与每个第二设备的时戳校正值，并基于故障时刻和对应的时戳校正值在待分析日志集合中进行检索，得到对应的关联流水日志，从而完成流水日志的筛选。
[0176]
三、服务器根据故障日志和关联日志定位故障节点
[0177]
服务器在故障日志和关联日志后，可以根据故障日志和关联日志构建调用树。
[0178]
具体的，服务器可以基于第一分布式业务的trace id从故障日志提取多个第一节点的节点信息，并根据多个第一节点的节点信息构建第一调用树。其中，第一节点的节点信息可包括trace id、span id以及parent spanid。其中，
[0179]
其中，若存在具有相同节点信息的多个第一节点，服务器可以将多个第一节点合并为一个节点。
[0180]
前文已经说明，同一调用链中的每个节点具有相同的trace id；每个节点在接收到调用请求时可以生成span id，以及将本节点的span id一起传递给下游节点。当携带有该span id的调用请求传到下游节点时，下游节点将生成新的span id，并将调用请求中携带的span id记录为parent spanid。因此，若多个第一节点中存在相邻的两个第一节点，服务器可以连接相邻的两个第一节点，以构建第一调用树。其中，两个相邻的第一节点中的一个第一节点的span id为另一个第一节点的parent spanid。
[0181]
示例性的，服务器提取出两个第一节点，其中节点1的节点信息包括：parent spanid＝0，span id＝0，trace id＝0xe962f174aeb4205；节点2的节点信息包括：parent spanid＝0，span id＝1，trace id＝0xe962f174aeb4205。其中，节点1的span id为节点2parent spanid＝0，因此可以连接节点1、节点2，从而构建如图9所示的第一调用树。
[0182]
可选的，若两个第一节点的节点信息指示该两个第一节点不相邻，服务器可以基于该两个第一节点的节点信息构建虚拟节点，并该两个第一节点、虚拟节点构建第一调用树。其中，不相邻的两个第一节点(例如节点a、节点b)可指：节点a的span id不为节点b的parent spanid，以及节点b的span id不为节点a的parent spanid。
[0183]
具体的，服务器可以将节点a的span id作为虚拟节点的parent spanid，将节点b的parent spanid作为虚拟节点的span id，或者，将节点b的span id作为虚拟节点的parent spanid，将节点a的parent spanid作为虚拟节点的span id，并依次连接节点a、虚拟节点和节点b，从而构建虚拟节点。
[0184]
示例性的，节点a的节点信息包括：parent spanid＝0，span id＝0，trace id＝0xe962f174aeb4205；节点b的节点信息包括：parent spanid＝1，span id＝6，trace id＝0xe962f174aeb4205。其中，节点a的parent spanid与span id相同(均为0)，因此可以确定第一节点为根节点。如此，服务器可以构建出虚拟节点c：parent spanid＝0，span id＝1，trace id＝0xe962f174aeb4205，并基于节点a、虚拟节点c、节点b构建出如图10所示的第一调用树。
[0185]
服务器还可以从关联日志中提取多个第二节点的节点信息，并根据多个第二节点的节点信息构建第二调用树。
[0186]
每个第二节点的节点信息包括trace id、该第二节点的span id、该第二节点的parent spanid以及该第二节点与其他第二节点的交互情况。第二调用树相对于第一调用树，具备更丰富的信息，有利于还原完整的调用链。
[0187]
服务器可以连接多个第二节点中两个相邻的第二节点，以构建第二调用树，其中，两个相邻的第二节点中的一个第二节点的span id为另一个第二节点的parent spanid，两个相邻的第二节点的连接关系与两个相邻的第二节点的交互情况对应，若两个相邻的第二
节点间存在cs、sr的过程，两个相邻的第二节点间建立第一连接；若两个相邻的第二节点间存在ss、cr的过程，两个相邻的第二节点间建立第二连接。
[0188]
示例性的，服务器可以从关联日志中提取出7个第二节点的节点信息，其中，7个第二节点的节点信息如表1所示：
[0189]
表1
[0190][0191]
根据节点2的parent spanid(即0)为节点1的span id(即0)，节点3的parent spanid(即0)为节点1的span id(即0)可确定，节点1与节点2、节点3相邻；根据节点4的parent spanid(即2)为节点2的span id(即2)，节点5的parent spanid(即2)为节点2的span id(即2)可确定，节点2与节点4、节点5相邻；根据节点6的parent spanid(即1)为节点3的span id(即1)，节点7的parent spanid(即1)为节点3的span id(即1)可确定，节点3与节点6、节点7相邻。另外，根据交互情况可知，节点3未向节点1发送反馈，节点3与节点1之间不存在第二连接(图11以虚线表示)；节点7未向节点3发送反馈，节点7与节点3之间不存在第二连接；其他相邻节点存在第一连接、第二连接(图11以实线表示)。也即，基于表1所示的节点信息，服务器可以构建得到如图11所示的第二调用树。如图11所示，该第二调用树包括7个节点，该第二调用树是trace id为0xe962f174aeb4205所指示的分布式业务。其中，节点与节点之间由实线或虚线连接，实线表示两个节点之间进行了相应的交互，虚线表示两个节点之间未进行相应的交互。例如，节点3与节点1之间的“cs-sr”这一实线表示节点3接收到了节点1的请求，“ss-cr”这一虚线表示节点3未向节点1发送反馈。
[0192]
接着，服务器可以合并第一调用树和第二调用树，得到调用树。具体的，若第一调用树和第二调用树中存在节点信息相同的两个节点，服务器可以合并节点信息相同的两个
节点；若第一调用树和第二调用树中不存在相同的节点，可以令parent spanid＝0、span id＝0，以建立虚拟根节点，并将第一调用树中的根节点和第二调用树的根节点连接到立虚拟根节点。
[0193]
示例性的，第一调用树可以为图10所示，第二调用树可以为图11所示，其中节点a与节点1相同，节点b与节点3相同，节点c与节点7相同，因此服务器可以合并节点a与节点1、节点b与节点3、节点c与节点7，从而得到如图11所示的调用树。
[0194]
又例如，如图12所示，第一调用树和第二调用树不存在相同的节点，其中第一调用树的根节点为节点2，第二调用树的根节点为节点3，则可以构建虚拟根节点1：parent spanid＝0、span id＝0、trace id＝0xe962f174aeb4205，并将节点2、节点3分别连接至节点1，以得到如图12所示的调用树。
[0195]
构建得到调用树后，服务器可以自动定位故障节点。具体的，根据分布式系统的调用方式不同，其定位故障节点的方法有所不同。其中，调用方式包括：异步调用和同步调用。同步调用指调用方需要等待执行方的调用结果后，才能进行下一步操作。异步调用指调用方无须等待执行方的执行结果，也能进行下一步操作。不过在正常情况下，不管是同步调用还是异步调用，调用方向执行方发出调用请求后，总会收到执行方反馈的执行结果。
[0196]
对于异步调用而言，服务器可以确定每个节点的入度和出度，若某个节点的入度和出度不相同，则可以确定该节点为故障节点。其中，入度指节点接收到消息的数量，出度为节点发出消息的数量。
[0197]
对于同步调用而言，服务器可以确定每个节点的入度和出度，若某个节点的入度和出度不相同，或者该节点无法形成自环，则可以确定该节点为故障节点。其中，自环指一个完整的cs、sr、ss、cr的调用过程。示例性，图11中的节点7，其入度为1，出度为0，可以确定该节点为故障节点。又例如，节点3的入度为2，出度为2，但其在与节点1的交互过程中未形成自环，以及在与节点7的交互过程中未形成自环，可以确定节点3为故障节点。
[0198]
需要说明是，该调用树还可供用户进行人工诊断。在进行人工诊断时，用户可以简单地将第一调用树中的第一节点确定为疑似故障节点，并基于其他日志进行确认。
[0199]
本技术实施例还提供一种芯片系统，如图13所示，该芯片系统包括至少一个处理器1301和至少一个接口电路1302。处理器1301和接口电路1302可通过线路互联。例如，接口电路1302可用于从其它装置(例如，终端设备的存储器)接收信号。又例如，接口电路1302可用于向其它装置(例如处理器1301)发送信号。
[0200]
例如，接口电路1302可读取终端设备中存储器中存储的指令，并将该指令发送给处理器1301。当所述指令被处理器1301执行时，可使得终端设备(如图1中的终端设备20、终端设备30等)执行上述实施例中的各个步骤。
[0201]
又例如，接口电路1302可读取服务器中存储器中存储的指令，并将该指令发送给处理器1301。当所述指令被处理器1301执行时，可使得服务器(如图1中的服务器10)执行上述实施例中的各个步骤。
[0202]
当然，该芯片系统还可以包含其他分立器件，本技术实施例对此不作具体限定。
[0203]
本技术实施例还提供了一种故障定位装置，所述装置可以按照功能划分为不同的逻辑单元或模块，各单元或模块执行不同的功能，以使得所述装置执行上述方法实施例中终端设备、服务器执行的各个功能或者步骤。
[0204]
本技术实施例还提供一种计算机程序产品，当所述计算机程序产品在故障定位装置上运行时，使得故障定位装置执行上述方法实施例中故障定位装置执行的各个功能或者步骤。当所述计算机程序产品在服务器上运行时，使得所述服务器执行上述方法实施例中服务器执行的各个功能或者步骤。
[0205]
在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0206]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0207]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0208]
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
[0209]
以上内容，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何在本技术揭露的技术范围内的变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。
技术特征：
1.一种故障定位方法，其特征在于，包括：所述方法包括：在检测到第一分布式业务存在故障时，获取待分析日志集合，其中，所述待分析日志集合包括第一设备、第二设备上传的故障日志和流水日志，所述故障日志和所述流水日志均包括所述第一分布式业务的标识，所述第一设备为最先检测到所述第一分布式业务出现故障的设备，所述第二设备与所述第一设备关联；确定故障时刻，所述故障时刻为所述第一分布式业务发生故障的时刻；基于所述故障时刻从所述待分析日志集合筛选得到关联日志，所述关联日志包括所述第一设备、所述第二设备在所述故障时刻的流水日志；从所述故障日志、所述关联日志中提取出多个节点的节点信息，每个节点表征一次调用的发起端或执行端，每个节点的节点信息包括所述第一分布式业务的标识、该节点的跨度标识以及父跨度标识；根据所述多个节点的节点信息构建调用树；若所述调用树中任意一个节点的出度和入度不相同，确定所述任意一个节点为故障节点，其中，所述每个节点的出度包括该节点发送信息的次数，所述每个节点的入度包括该节点接收到信息的次数。2.根据权利要求1所述的方法，其特征在于，所述故障时刻包括第一故障时刻、第二故障时刻，所述第一故障时刻为所述第一设备上所述第一分布式业务发生故障的时刻，所述第二故障时刻为所述第二设备上所述第一分布式业务发生故障的时刻；所述确定故障时刻包括：解析第一故障日志，得到所述第一故障时刻，所述第一故障日志为所述第一设备检测到第一分布式业务时上传的故障日志；根据所述第一分布式业务的标识从所述待分析日志集合中解析得到所述第一分布式业务的交互数据，所述交互数据包括所述第一设备、所述第二设备每次交互的时间戳；根据所述交互数据确定所述第一设备的系统时间与所述第二设备的系统时间的映射关系；根据所述第一故障时刻、所述映射关系计算所述第二故障时刻。3.根据权利要求2所述的方法，其特征在于，所述关联日志包括第一关联流水日志以及第二关联流水日志，所述基于所述故障时刻从所述待分析日志集合筛选得到关联日志，包括：基于所述第一故障时刻、所述第一设备的标识从所述待分析日志集合筛选得到所述第一关联流水日志，所述第一关联流水日志为所述第一设备在所述第一故障时刻的流水日志；基于所述第二故障时刻、所述第二设备的标识从所述待分析日志集合筛选得到所述第二关联流水日志，所述第二关联流水日志为所述第二设备在所述第二故障时刻的流水日志。4.根据权利要求2所述的方法，其特征在于，所述交互数据包括所述第一设备、所述第二设备最近一次交互的第一时间戳、第二时间戳、第三时间戳及第四时间戳，所述第一时间戳为所述第一设备向所述第二设备发送调用请求的时间，所述第二时间戳为所述第二设备接收到所述调用请求的时间，所述第三时间戳为所述第二设备向所述第一设备发送反馈信
息的时间，所述第四时间戳为所述第一设备接收到所述反馈信息的时间；所述映射关系指示所述第一设备的系统时间与所述第二设备的系统时间的差值与所述第一时间戳、所述第二时间戳、所述第三时间戳及所述第四时间戳关联，所述第一时间戳、所述第三时间戳与所述差值呈正相关，所述第二时间戳、所述第四时间戳与所述差值呈负相关。5.根据权利要求4所述的方法，其特征在于，所述映射关系满足算式：其中，ta为所述第一设备的系统时间，所述为所述第二设备的系统时间，cs为所述第一时间戳，sr为所述第二时间戳，ss为所述第三时间戳，cr为所述第四时间戳。6.根据权利要求1-5中任意一项所述的方法，其特征在于，所述从所述故障日志、所述关联日志中提取出多个节点的节点信息，包括：从所述故障日志中提取多个第一节点的节点信息，每个第一节点的节点信息包括所述第一分布式业务的标识、该第一节点的跨度标识以及父跨度标识；从所述关联日志中提取多个第二节点的节点信息，每个第二节点的节点信息包括所述第一分布式业务的标识、该第二节点的跨度标识和父跨度标识，以及该第二节点与其他第二节点的交互情况；所述根据所述多个节点的节点信息构建调用树，包括：根据所述多个第一节点的节点信息构建第一调用树；根据所述多个第二节点的节点信息构建第二调用树；合并所述第一调用树、所述第二调用树得到所述调用树。7.根据权利要求6所述的方法，其特征在于，所述根据所述多个第一节点的节点信息构建第一调用树，包括：若所述多个第一节点中存在两个相邻的第一节点，连接所述两个相邻的第一节点，以构建所述第一调用树，其中，所述两个相邻的第一节点中的一个第一节点的跨度标识为另一个第一节点的父跨度标识。8.根据权利要求6所述的方法，其特征在于，所述方法还包括：若所述多个第一节点中不存在两个相邻的第一节点，确定两个不相邻的第一节点；根据所述两个不相邻的第一节点的节点信息构建虚拟节点，所述虚拟节点的跨度标识为所述两个不相邻的第一节点中一个第一节点的父跨度标识，所述虚拟节点的父跨度标识为所述两个不相邻的第一节点中另一个第一节点的跨度标识；依次连接所述两个不相邻的第一节点中的一个第一节点、所述虚拟节点、所述两个不相邻的第一节点中的另一个第一节点，以构建所述第一调用树。9.根据权利要求6所述的方法，其特征在于，所述根据所述多个第二节点的节点信息构建第二调用树，包括：连接所述多个第二节点中两个相邻的第二节点，以构建所述第二调用树，其中，所述两个相邻的第二节点中的一个第二节点的跨度标识为另一个第一节点的父跨度标识，所述两个相邻的第二节点的连接关系与所述两个相邻的第二节点的交互情况对应，若所述两个相邻的第二节点间存在客户端发送、服务端接收的过程，所述两个相邻的第二节点间建立第
一连接；若所述两个相邻的第二节点间存在服务端发送、客户端接收的过程，所述两个相邻的第二节点间建立第二连接。10.根据权利要求6所述的方法，其特征在于，所述合并所述第一调用树、所述第二调用树得到所述调用树，包括：若第一调用树和第二调用树中存在节点信息相同的两个节点，合并所述节点信息相同的两个节点；若第一调用树和第二调用树中不存在相同的节点，构建虚拟根节点，所述虚拟根节点的跨度标识和父跨度标识为0；连接所述虚拟根节点与所述第一调用树的根节点，连接所述虚拟根节点与所述第二调用树的根节点。11.根据权利要求1-5中任意一项所述的方法，其特征在于，在所述获取待分析日志集合之前，所述方法还包括：接收所述第一设备在所述第一分布式业务发生故障时上传的第一故障日志，所述第一故障日志包括事件id、所述第一设备的标识、关联设备的标识以及所述第一分布式业务的标识，所述关联设备包括所述第二设备；接收所述第二设备在接收到第一通知后上传的第二故障日志，所述第一通知指示所述第一分布式业务发生故障，所述第二故障日志包括所述事件id、所述第二设备的标识以及所述第一分布式业务的标识；将所述第一故障日志、所述第二故障日志添加至事件信息，所述事件信息包括多个故障日志。12.根据权利要求11所述的方法，其特征在于，所述方法还包括：遍历所述事件信息中的每个故障日志，并判断每个故障日志携带的事件id是否与分布式故障的事件id集合匹配；若所述第一故障日志携带的事件id与分布式故障的事件id集合匹配，确定所述第一分布式业务存在故障。13.根据权利要求12所述的方法，其特征在于，所述获取待分析日志集合，包括：判断所述第一设备的设备类型为第一类型或第二类型；若所述第一设备的设备类型为第一类型，根据所述第一故障日志携带的第一运行标识，并将所述第一运行标识所指示的流水日志添加至所述待分析日志集合；若所述第一设备的设备类型为第二类型，将所述第一故障日志添加至所述待分析日志集合；从所述第一故障日志解析得到所述第一分布式业务的标识和所述第二设备的标识；根据所述第一分布式业务的标识和所述第二设备的标识在所述事件信息进行检索，得到所述第二故障日志；判断所述第二设备的设备类型为第一类型或第二类型；若所述第二设备的设备类型为第一类型，根据所述第二故障日志携带的第二运行标识，并将所述第二运行标识所指示的流水日志添加至所述待分析日志集合；若所述第二设备的设备类型为第二类型，将所述第二故障日志添加至所述待分析日志集合。
14.根据权利要求1-5中任意一项所述的方法，其特征在于，所述关联日志包括所述第一设备在t1～t2期间的流水日志，以及所述第二设备在t3～t4期间的流水日志，t1为第一故障时刻与第一预设时间的差值，t2为所述第一故障时刻与第二预设时间的和，t3为第二故障时刻与所述第一预设时间的差值，t4为第二故障时刻与所述第二预设时间的和。15.根据权利要求1-5中任意一项所述的方法，其特征在于，所述第二设备包括与所述第一设备共同执行所述第一分布式业务的终端设备，或者包括分布式系统中在所述故障时刻的前预设时间内在线的终端设备。16.根据权利要求1-5中任意一项所述的方法，其特征在于，所述第一分布式业务内采用同步调用方式或异步调用方式。17.一种故障定位方法，其特征在于，所述方法包括：第一设备在检测到第一分布式业务发生故障时，向服务器上传第一故障日志，所述第一故障日志包括事件id、所述第一设备的标识、关联设备的标识以及所述第一分布式业务的标识，所述关联设备包括第二设备；第一设备向所述第二设备发送第一通知，所述第一通知携带有所述第一分布式业务的标识；所述第二设备向所述服务器上传第二故障日志，所述第二故障日志包括所述事件id、所述第二设备的标识以及所述第一分布式业务的标识。18.一种故障定位装置，其特征在于，包括处理器，所述处理器和存储器耦合，所述存储器存储有程序指令，当所述存储器存储的程序指令被所述处理器执行时使得所述故障定位装置实现权利要求1-16或17中任一项所述的方法。19.一种计算机可读存储介质，其特征在于，包括计算机指令；当所述计算机指令在故障定位装置上运行时，使得所述故障定位装置执行如权利要求1-16或17中任一项所述的方法。
技术总结
本申请实施例提供一种故障定位方法及装置，涉及数据处理技术领域，可以减少待分析日志的数量，降低分析难度提高分析结果准确率。该方法包括：在检测到第一分布式业务存在故障时获取待分析日志集合；确定故障时刻；基于故障时刻从待分析日志集合筛选得到关联日志；从故障日志、关联日志中提取出多个节点的节点信息，每个节点表征一次调用的发起端或执行端，每个节点的节点信息包括第一分布式业务的标识、该节点的跨度标识以及父跨度标识；根据多个节点的节点信息构建调用树；若调用树中任意一个节点的出度和入度不相同，确定任意一个节点为故障节点。点为故障节点。点为故障节点。
