A fault locating method based on multi-device interconnection and electronic device

Abstract

The application relates to a fault positioning method based on multi-device interconnection and an electronic device, and relates to the technical field of computer application; the method can improve the fault positioning difficulty in the multi-device interconnection scene, and improve the accuracy of fault positioning. When a first device detects a fault event, the first device collects first log information of the fault event, and reports the first log information to a cloud server; the first device determines a service identifier of a distributed service which has a fault from the fault event, and generates a notification message according to the service identifier; the first device sends the notification message to a second device, and the second device cooperates with the first device to execute the distributed service; after receiving the notification message, the second device determines second log information related to the fault event according to the service identifier in the notification message, and reports the second log information to the cloud server; and the cloud server combines the first log information and the second log information to position the fault of the distributed service.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a fault location method and electronic device based on multi-device interconnection. Background Technology

[0002] As users' demands for smart living increase, more and more businesses need to involve interaction between multiple devices. For example, mobile phones can connect to smart speakers, watches, headphones, etc., and smart speakers can further connect to smart home appliances such as air conditioners and televisions. Users can control multiple devices through a single mobile terminal, realizing a smart life across all scenarios.

[0003] In such scenarios, if a task fails, typically only one device will report the fault. For example, when a phone fails to transfer an image or audio file to a smartwatch, the phone displays a transmission failure message, while the smartwatch does not. During fault localization, the server can only collect log information from the device that reported the fault (such as the phone) to pinpoint the cause of the failure. If the true cause of the fault is not on the phone, the system will find it difficult to locate the cause. Summary of the Invention

[0004] In a first aspect, embodiments of this application provide a fault location method based on multi-device interconnection. In this method, when a first device detects a fault event, it collects first log information of the fault event and reports the first log information to a cloud server. The first device determines the service identifier of the distributed service that has failed from the fault event and generates a notification message based on the service identifier. The first device sends the notification message to a second device, wherein the second device and the first device collaboratively execute the distributed service. After receiving the notification message, the second device determines second log information related to the fault event based on the service identifier in the notification message and reports the second log information to the cloud server. The cloud server merges the first log information and the second log information to locate the fault in the distributed service that has failed.

[0005] This solution allows the cloud server to obtain log information from all devices involved in the distributed service (i.e., the first and second devices) when a failure occurs. By combining this log information with the logs from each device, the fault can be located more comprehensively, improving the accuracy of fault location. Furthermore, in existing technologies, device information is not permanently stored. For devices that haven't detected a fault, fault-related information can easily be overwritten or lost. In contrast, this solution notifies the second device upon detecting a fault, enabling the second device to promptly report relevant information to the cloud server. This prevents information on the second device from being overwritten or lost, thus improving the effectiveness of fault location.

[0006] In one possible implementation of the first aspect of this application, the first device and the second device can generate a service identifier in real time, and record log information of distributed services through the service identifier. The service identifier can be used to identify distributed services. When recording log information through the service identifier, it is easy to distinguish the log information of different distributed services, and it is easy to filter the log information, thereby quickly finding the required log information.

[0007] In one possible implementation of the first aspect of this application, the real-time generation of a service identifier by the first device and the second device includes: the first device and the second device generating a service identifier based on a device identifier, a processor identifier, and a timestamp, wherein the timestamp is updated at a preset time period, and the timestamps updated within the preset time period are not repeated. In this implementation, the service identifier is generated from the device identifier, the processor identifier, and the timestamp. The generation rule is simple, requires no additional resources, and is applicable to the vast majority of devices, reducing device limitations and improving the coverage of fault location for devices.

[0008] In one possible implementation of the first aspect of this application, when a first device performs distributed services, the first device generates associated cache information, wherein the associated cache information is used to record information about devices that jointly perform distributed services with the first device; the first device can query the associated cache information and designate the queried device in the associated cache information as a second device. In this implementation, recording the second device through associated cache information can avoid the problem of device information loss due to the second device going offline, ensure that the first device can notify every second device, and improve the integrity of log information and the accuracy of fault location.

[0009] In one possible implementation of the first aspect of this application, when the first device fails to query the aforementioned associated cache information, the first device obtains the devices connected to it and designates these connected devices as the second device. In this implementation, the devices maintaining a connection with the first device are those that collaborate with the first device to execute the current distributed service. By designating the currently connected devices as the second devices, the first device can accurately notify the devices involved in the distributed service, avoiding resource occupation and waste caused by notifying devices unrelated to the current distributed service.

[0010] In one possible implementation of the first aspect of this application, after receiving a notification message, the second device determines the second log information related to the fault event based on the service identifier in the notification message, including: after receiving the notification message, the second device obtains the service identifier in the notification message; then, the second device parses the timestamp in the service identifier; the second device determines an associated time period based on the timestamp, and uses the log information within the associated time period as the second log information related to the fault event. In this implementation, the second device can determine an associated time period based on the timestamp in the service identifier, and filter out the log information within the associated time period as the second log information. The timestamp in the service identifier is a point in time, and the associated time period is a time period related to that point in time. Filtering log information through this time period can avoid information omission and ensure the integrity of the filtered second log information.

[0011] In one possible implementation of the first aspect of this application, the first device collecting first log information of a fault event upon detecting a fault event includes: recording the occurrence time of the fault event when the first device detects the fault event; and then, the first device collecting the first log information from the recorded log information based on the occurrence time of the fault event. In this implementation, the first device does not need to parse the service identifier in the fault event to obtain its timestamp; it can collect the first log information through the recorded occurrence time of the fault event, which is faster and can improve the collection speed.

[0012] In one possible implementation of the first aspect of this application, the sending of a notification message from the first device to the second device includes: the first device detecting whether the connection type of the second device meets preset requirements; if the connection type of the second device meets the preset requirements, the first device sending the notification message to the second device. In this implementation, the first device detects the connection type of the second device before sending the notification message, thereby only sending the notification message to the second device that meets the preset requirements, ensuring the effectiveness of the notification.

[0013] In one possible implementation of the first aspect of this application, if the first device detects that the connection type of the second device does not meet the aforementioned preset requirements, the first device synchronizes the log information on the second device; then, the first device collects second log information related to the aforementioned fault event from the synchronized log information; and the first device reports the second log information to the cloud server. In this implementation, the first device can determine the connection type of the second device, thereby determining the reporting method of the second log information based on the connection type of the second device. This is applicable to devices with different connection types, avoiding limitations on the devices. Furthermore, when the connection type of the second device does not meet the preset requirements, the first device can synchronize the log information on the second device, thus the first device is responsible for collecting the second log information, ensuring the integrity of the log information and improving the success rate of fault location.

[0014] In one possible implementation of the first aspect of this application, the first device determines whether a target notification message indicating a notification failure exists. When the first device sends a notification message to the second device, and the second device disconnects from the first device, the notification message is considered a target notification message indicating a notification failure. When a target notification message indicating a notification failure exists, the first device stores the target notification message so that it can be resent to the second device when the second device reconnects with the first device. In this implementation, when a notification failure occurs due to the second device going offline, the first device can record the target notification message indicating a notification failure and then send a notification when the second device comes back online. This reduces the problem of notification failures, ensures that notification messages are successfully sent to each second device, and improves the probability of the second device reporting log information.

[0015] Secondly, this application provides an electronic device including a memory and one or more processors. The memory stores one or more computer programs, each including instructions that, when executed by the processor, cause the electronic device to perform the methods described in the first aspect and any of its possible implementations.

[0016] Thirdly, this application provides an electronic device including a memory and one or more processors. The memory stores one or more computer programs, each including instructions. When executed by the processor, the electronic device performs the following steps: a first device collects first log information of a fault event upon detection of a fault event and reports the first log information to a cloud server; the first device determines the service identifier of the faulty distributed service from the fault event and generates a notification message based on the service identifier; the first device sends the notification message to a second device, wherein the second device and the first device collaboratively execute the distributed service; upon receiving the notification message, the second device determines second log information related to the fault event based on the service identifier in the notification message and reports the second log information to the cloud server; the cloud server merges the first log information and the second log information to locate the faulty distributed service. The first device and the second device are one or more of the aforementioned electronic devices.

[0017] In one possible implementation of the third aspect of this application, when the instruction is executed by the processor, the electronic device performs the following steps: the first device and the second device generate a service identifier in real time, and record log information of the distributed service through the service identifier.

[0018] In one possible implementation of the third aspect of this application, when the instruction is executed by the processor, the electronic device performs the following steps: the first device and the second device generate the service identifier based on the device identifier, the processor identifier and the timestamp, wherein the timestamp is updated at a preset time period and the timestamps updated within the preset time period are not repeated.

[0019] In one possible implementation of the third aspect of this application, when the instruction is executed by the processor, the electronic device performs the following steps: when the first device performs a distributed service, the first device generates associated cache information, wherein the associated cache information is used to record information of devices that jointly perform the distributed service with the first device; the first device queries the associated cache information and uses the device queried from the associated cache information as the second device.

[0020] In one possible implementation of the third aspect of this application, when the instruction is executed by the processor, the electronic device performs the following steps: when the first device fails to query the aforementioned associated cache information, the first device obtains the device connected to the first device and uses the device connected to the first device as the second device.

[0021] In one possible implementation of the third aspect of this application, when the instruction is executed by the processor, the electronic device performs the following steps: after receiving the notification message, the second device obtains the service identifier in the notification message; the second device parses the timestamp in the service identifier; the second device determines the associated time period based on the timestamp, and uses the log information within the associated time period as the second log information related to the above-mentioned fault event.

[0022] In one possible implementation of the third aspect of this application, when the instruction is executed by the processor, the electronic device performs the following steps: when the first device detects the above-mentioned fault event, it records the time of occurrence of the fault event; the first device collects first log information from the recorded log information based on the time of occurrence of the fault event.

[0023] In one possible implementation of the third aspect of this application, when the instruction is executed by the processor, the electronic device performs the following steps: the first device detects whether the connection type of the second device meets the preset requirements; if the connection type of the second device meets the preset requirements, the first device sends a notification message to the second device.

[0024] In one possible implementation of the third aspect of this application, when the instruction is executed by the processor, the electronic device performs the following steps: if the first device detects that the connection type of the second device does not meet the preset requirements, the first device synchronizes the log information on the second device; the first device collects second log information related to the fault event from the synchronized log information; and the first device reports the second log information to the cloud server.

[0025] In one possible implementation of the third aspect of this application, when the instruction is executed by the processor, the electronic device performs the following steps: the first device determines whether there is a target notification message that failed to notify; when the first device sends a notification message to the second device, the second device disconnects from the first device, and the notification message is a target notification message that failed to notify; when there is a target notification message that failed to notify, the first device stores the target notification message so that when the second device re-establishes a connection with the first device, it can resend the target notification message to the second device.

[0026] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect and any possible implementation thereof.

[0027] Fifthly, this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method described in the first aspect and any possible implementation.

[0028] It is understood that the beneficial effects achieved by the electronic devices described in the second aspect, the third aspect, and any possible embodiments thereof, the computer-readable storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can be referred to the beneficial effects in the first aspect and any possible design, which will not be repeated here. Attached Figure Description

[0029] Figure 1 A schematic diagram illustrating an application scenario of a fault location method based on multi-device interconnection provided in this application embodiment;

[0030] Figure 2 A schematic diagram illustrating another application scenario of a fault location method based on multi-device interconnection provided in this application embodiment;

[0031] Figure 3 A schematic diagram illustrating another application scenario of a fault location method based on multi-device interconnection provided in this application embodiment;

[0032] Figure 4 A schematic diagram of a system framework for a fault location method based on multi-device interconnection provided in an embodiment of this application;

[0033] Figure 5 A functional module interaction diagram of a fault location method based on multi-device interconnection provided in an embodiment of this application;

[0034] Figure 6 A schematic diagram of an interactive process for a fault location method based on multi-device interconnection provided in an embodiment of this application;

[0035] Figure 7 A schematic diagram of the structure of an electronic device applied to the above-mentioned fault location method based on multi-device interconnection, provided as an embodiment of this application;

[0036] Figure 8 This is a schematic diagram of the structure of a server applied to the above-mentioned fault location method based on multi-device interconnection, as provided in an embodiment of this application. Detailed Implementation

[0037] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0038] In a distributed system with interconnected multiple devices, a distributed service can be completed collaboratively by multiple devices. If a distributed service fails, the device that detected the failure will report the fault, allowing the system to pinpoint the cause of the failure based on the reported fault information.

[0039] However, in a distributed system, not every device can detect the failure of distributed service execution. Devices that cannot detect the failure will not report the fault. For example, when a mobile phone fails to connect to a smart speaker, the mobile phone can detect the connection failure and report the fault, while the speaker cannot detect the connection failure and will not report the fault.

[0040] The server can collect log information from devices that report faults, helping developers locate the problem. However, it cannot collect information from devices that do not report faults. If the true cause of the fault lies with an unreported device, developers will find it difficult to pinpoint the cause. In this situation, developers would need to check all interconnected devices one by one to find the faulty one, which is time-consuming and inefficient.

[0041] Based on this, embodiments of this application provide a fault location method and electronic device based on multi-device interconnection, which can improve the difficulty of fault location in multi-device interconnection scenarios and improve the accuracy of fault location.

[0042] In this embodiment, when the first device detects a fault event, it can send the first log information corresponding to the fault event to the cloud server. At the same time, the first device can send a notification message to the interconnected second device, notifying the second device to also send the second log information associated with the fault event to the cloud server. The cloud server locates the fault based on the first log information sent by the first device and the second log information sent by the second device. The information used for fault location is more comprehensive, which can improve the accuracy of fault location.

[0043] Furthermore, in existing technologies, information in devices is not permanently stored. For devices that have not detected a fault, fault-related information can easily be overwritten or lost. Compared to existing technologies, in the fault location method of this embodiment, the first device notifies the second device when it detects a fault event, enabling the second device to promptly report relevant information to the cloud server. This avoids the problem of faults not being located due to information being overwritten or lost on the second device.

[0044] The implementation of this embodiment will now be described in detail with reference to the accompanying drawings.

[0045] For example, the fault location method provided in this application embodiment can be applied to electronic devices such as mobile phones, in-vehicle devices (also known as vehicle-mounted systems), tablet computers, laptops, ultra-mobile personal computers (UMPCs), handheld computers, netbooks, personal digital assistants (PDAs), wearable electronic devices, virtual reality devices, and smart home devices. This application does not limit the scope of the application.

[0046] Figure 1 The diagram schematically illustrates a system architecture of an application environment for the fault location method of this embodiment. For example... Figure 1 As shown, system architecture 100 may include one or more electronic devices (e.g., computer 101, mobile phone 102, watch 103, television 105, and smart speaker 106), and cloud server 104. The electronic devices may be any of the types described above.

[0047] Electronic devices and cloud server 104 can be interconnected via wired or wireless networks. For example, the aforementioned wired or wireless networks can be implemented using any known network communication protocol, such as Ethernet, Universal Serial Bus (USB), FireWire, Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), Bluetooth, Wireless Fidelity (Wi-Fi), NFC, Voice over Internet Protocol (VoIP), communication protocols supporting network slicing architecture, or any other suitable communication protocol.

[0048] Electronic devices can interact with the cloud server 104 via the aforementioned wired or wireless network. For example, electronic devices can receive messages sent by the cloud server 104, and electronic devices can also send messages to the cloud server 104. For instance, multiple electronic devices can each act as a node in a distributed system to jointly execute a distributed service, such as data synchronization or data collection.

[0049] Furthermore, electronic devices can communicate with each other in various ways. For example, one electronic device can communicate wirelessly with another electronic device via wireless local area networks (WLANs) (such as Wireless Fidelity (Wi-Fi) networks), Bluetooth (BT), near field communication (NFC), or other wireless communication technologies. For example, one electronic device can communicate wiredly with another electronic device via an interface, which may include a universal serial bus (USB) interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface, etc. This implementation is not limited to these methods.

[0050] Cloud server 104 can provide computing services to electronic devices and respond to their service requests. For example, cloud server 104 can receive service requests from computer 101, analyze and process the requests, and then return the results to computer 101.

[0051] It should be understood that Figure 1 The number of electronic devices, networks, and cloud servers in the diagram is illustrative. Depending on the implementation requirements, the number of electronic devices, networks, and cloud servers can be arbitrary. For example, cloud server 104 can be a server cluster consisting of multiple cloud servers.

[0052] In some embodiments, when an electronic device (e.g., mobile phone 102) malfunctions, mobile phone 102 can send a notification to its corresponding cloud server 104. After receiving the notification sent by mobile phone 102, cloud server 104 can locate the malfunction that occurred on mobile phone 102 and feed back the location result to mobile phone 102.

[0053] When multiple electronic devices collaboratively perform a distributed service, any one or more of them can be designated as the first device, and one or more electronic devices connected to the first device can be designated as the second device. For example, when mobile phone 102 is connected to smartwatch 103 and smart speaker 106 to collaboratively perform a distributed service, mobile phone 102 can be designated as the first device, and smartwatch 103 and smart speaker 106 connected to mobile phone 102 can be designated as the second devices. The first device can be one or more of the aforementioned electronic devices (e.g., computer 101, mobile phone 102, smartwatch 103, television 105, smart speaker 106), and the second device can also be one or more of the aforementioned electronic devices. Furthermore, the first device and the second device can be the same type of electronic device, for example, both the first device and the second device can be mobile phone 102; or different types of electronic devices, for example, the first device is mobile phone 102 and the second device is smart speaker 103; this embodiment does not impose any limitations on this.

[0054] like Figure 2 As shown, the fault location method in this embodiment may include the following steps: When a first device (e.g., first device 201) is executing a distributed service, if a fault event (e.g., fault event A) is detected, it can collect first log information related to fault event A and report the collected first log information to a cloud server; simultaneously, the first device 201 can determine the service identifier of the distributed service that has failed from fault event A, and the first device 201 can generate a notification message based on the service identifier and send the notification message to a second device (e.g., second device 202) that is interconnected with it; after receiving the notification message sent by the first device 201, the second device 202 can determine the second log information related to fault event A based on the service identifier in the notification message; then, the second device 202 can upload the second log information to a cloud server; the cloud server can locate the fault based on the received first log information and second log information.

[0055] According to the above embodiment, when the first device 201 experiences a fault event A, the first device 201 can send the first log information corresponding to the fault event A to the cloud server; at the same time, the first device 201 will also notify other devices connected to it, namely the second device 202, so that the second device 202 can also send the second log information associated with the fault event A to the cloud server.

[0056] In this way, the cloud server can combine the first log information sent by the first device 201 and the second log information sent by the second device 202 to locate fault event A. Compared with existing technologies, the cloud server uses more comprehensive information for fault location, which improves the accuracy of fault location. Furthermore, for the device (second device 202) that did not detect fault event A, the first device 201 will notify the second device 202 when it detects a fault, enabling the second device 202 to promptly report relevant information to the cloud server. This avoids the problem of information on the second device 202 being overwritten or lost, which could lead to the inability to locate the fault.

[0057] The aforementioned fault event A can be triggered by distributed services in either the first device 201 or the second device 202. These distributed services can include various applications such as multi-screen collaboration applications and distributed gallery applications, which can be executed between interconnected devices. Examples include screen sharing between a mobile phone and a large-screen display, data sharing between a mobile phone and a personal computer, and data sharing between a mobile phone and a vehicle-mounted system. This embodiment does not impose any limitations on these examples.

[0058] In some implementations, when the first device 201 detects a fault event A, the first device 201 can record the time of occurrence of fault event A. Then, based on the time of occurrence of fault event A, the first device 201 can obtain log information within a preset time range at that time of occurrence from the stored log information, i.e., the first log information, and then send the first log information to the cloud server.

[0059] In some implementations, when the first device 201 detects a fault event A, the first device 201 can obtain a service identifier for a distributed service from the fault event A. This service identifier identifies the specific distributed service that triggered the fault event A. Then, the first device 201 can use this service identifier to filter out first log information from stored log information. The service identifier may include a timestamp, which reflects the time when fault event A occurred. When the first device 201 obtains the service identifier, it can parse the service identifier to obtain the timestamp contained within it. Similarly, similar to the method described above, the first device 201 can use this timestamp to collect log information within a preset event range of that timestamp from the stored log information, as the first log information.

[0060] For example, the first device 201 and the second device 202 can trigger various types of events during operation. These include power-on events, user behavior events (such as click events, swipe events, etc.), statistical events (such as events tracking memory usage, events tracking data usage, etc.), and fault events. When an event (e.g., event A) occurs, the object that caused event A (e.g., application 1) can notify all event subscribers that have subscribed to event A. The first device 201 itself or applications on the first device 201 (e.g., call, browser, multimedia player, etc.) can be pre-set as event subscribers, and the events that each subscriber is responsible for subscribing to can be configured.

[0061] In this embodiment, the event subscriber that subscribes to fault events can be a fault subscriber. The fault subscriber can be the device's operating system itself, or any application within the operating system. Technicians can pre-configure the device or applications within the device as fault subscribers and subscribe to corresponding fault events for those subscribers.

[0062] For example, the first device 201 or the module on the first device 201 responsible for executing the fault location method of this embodiment can be pre-configured as a fault subscriber. For example, the first device 201 is a mobile phone. As a fault subscriber, the mobile phone can subscribe to various types of fault events. For example, a fault event is an application startup failure. Once an application (e.g., application A) on the mobile phone fails to start, the mobile phone can receive the event and the object that sent the event, i.e., application A. The mobile phone can treat the event triggered by application A as a fault event.

[0063] Technicians can predefine one or more failure events for the application. For example, an event where the application fails to start can be considered as a failure event, and an event where files cannot be shared with other applications can be considered as another failure event. Those skilled in the art can use any event as a failure event according to implementation requirements; this implementation is not limited in this regard. When a failure event defined in the application occurs, the application can notify all its failure subscribers.

[0064] For example, a fault event may include a description of the event, the event type, the time when the event occurred, and may also include the service identifier of the distributed service that triggered the fault event.

[0065] When the first device 201 detects fault event A, it can obtain the service identifier of the distributed service executing fault event A. The application (e.g., application A) on the first device 201 responsible for executing the distributed service of fault event A can act as an event issuer. When the first device 201 is running application A, if fault event A occurs in application A, application A, as the event issuer, needs to notify the fault subscriber of fault event A. The fault subscriber can be the first device 201 or another application on the first device 201, such as application B. In some embodiments, a cloud server can also act as a fault subscriber for fault event A. When fault event A occurs on the first device 201, the first device 201 can report fault event A to the cloud server.

[0066] Each electronic device executing distributed services (such as the first device 201 and the second device 202) can generate a service identifier. In some exemplary embodiments, the first device 201 or the second device 202 can generate a service identifier based on its own device identity and timestamp. For example, a mobile phone can concatenate its device identity and timestamp to generate a service identifier. The device identity can be used to uniquely identify an electronic device; the timestamp is a credential issued by the electronic device when authenticating the time of data generation, proving the authenticity of the data before the time the timestamp was requested.

[0067] The aforementioned device identifier can be generated in various ways. For example, the first device 201 can obtain a Universally Unique Identifier (UUID) or a MAC (Media Access Control Address) address as its device identifier; the first device 201 can also generate a random number as its own device identifier; or, the first device 201 can combine the UUID, MAC address, and random number, and use the result as its device identifier; this embodiment does not limit this. Similarly, the second device 202 can also determine its own device identifier.

[0068] The first device 201 and the second device 202 can update the timestamps in real time, ensuring that each updated timestamp is unique or does not repeat within a preset time period. For example, the first device 201 and the second device 202 can update a timestamp every microsecond for 8 hours, guaranteeing that the timestamps generated within these 8 hours are unique. The preset time period can be set according to implementation requirements, such as 10 hours, 12 hours, 24 hours, etc., and this embodiment does not impose any restrictions on it.

[0069] In some exemplary embodiments, the first device 201 or the second device 202 can generate a service identifier using the aforementioned device identifier, timestamp, and CPU Identity (CPUID). For example, the first device 201 can combine the device identifier, processor identity, and timestamp to form a service identifier.

[0070] For example, when the first device 201 executes a certain distributed service, it can obtain the current time as a timestamp and concatenate this timestamp with its device identifier and processor identifier to obtain the service identifier for the distributed service. For example, service identifier B might be "abc", where 'a' represents the device identifier, 'b' represents the processor identifier, and 'c' represents the current timestamp. When a fault event (e.g., fault event A) occurs during the execution of this distributed service, the application that experienced fault event A can identify it using the service identifier (e.g., service identifier B). The first device 201 and the cloud server, as subscribers to fault event A, can receive fault event A sent by the application. Fault event A carries the aforementioned service identifier B. For example, fault event A might be: "abc file transfer failed". The first device 201 can identify the issuer of fault event A, i.e., the aforementioned application, using the service identifier B.

[0071] When the first device 201 obtains the service identifier B of the distributed service that caused the aforementioned fault event A, the first device 201 can parse the read service identifier B. According to the pre-agreed generation rules for the service identifier, the first device 201 can parse the timestamp contained in the service identifier B. For example, if the pre-agreed generation rule for the service identifier is to generate it by concatenating a 20-bit Device Identity, a 4-bit CPU Identity, and a 35-bit timestamp, the first device 201 can divide the obtained service identifier into three fields according to this generation rule, with the value of the last field being the timestamp. After parsing the timestamp from the service identifier B of fault event A, the first device 201 can query the stored log information for logs within a preset range of timestamps, and use the queried log information as the first log information.

[0072] The first device 201 and the second device 202 can record log information based on the aforementioned service identifier. This log information can include multiple entries and the time each entry was generated. Each entry in the log information can record different execution states of the distributed task. For example, the log information can include the start time, completion time, execution result, and information about the distributed service being executed. By configuring the code of the distributed task, any necessary information can be generated during its execution; the generated information and its corresponding time will be stored in the log information.

[0073] When the first device 201 determines the timestamp in the service identifier of fault event A, it can determine the associated time period of that timestamp. A timestamp is a point in time, while the associated time period can refer to a time interval containing that timestamp, such as within one minute before the timestamp, or within one minute before and after the timestamp. Based on this associated time period, the first device 201 can filter the stored log information. The first device 201 can query the timestamp of each piece of information in the logs, filter out information whose timestamps fall within the associated time period, and send the filtered information as the first log information to the cloud server.

[0074] In some implementations, when the cloud server receives a fault event A, it can determine the service identifier (e.g., service identifier B) that caused the fault based on the fault event A. Parsing service identifier B yields a timestamp, and the corresponding associated time period is determined based on this timestamp. The cloud server can then send a request to the first device 201 based on the determined associated time period to request the acquisition of the first device 201's first log information. After receiving the request from the cloud server, the first device 201 can filter out the log information within the aforementioned associated time period and send the filtered log information as the first log information to the cloud server.

[0075] When executing distributed services, the first device 201 needs to be connected to other electronic devices (i.e., the second device 202) to jointly realize the distributed services. Continuing with... Figure 2 For example, when a fault event A occurs while the first device 201 is performing distributed services, the first device 201 can generate a notification message based on the fault event A, and then send the notification message to the second device 202 connected to it. This notification message is used to notify the second device 202 to report second log information. This second log information is the log information related to the aforementioned fault event A stored on the second device 202.

[0076] For example, the first device 201 may carry the service identifier in the notification message and then send the notification message to the second device 202 connected to it.

[0077] The first device 201 can be connected to multiple second devices. Taking a mobile phone as an example, the mobile phone can connect to a smart speaker and a large-screen display via a local area network, and can also connect to a smartwatch via Bluetooth. In this example, the smart speaker, large-screen display, and smartwatch are all second devices. In some exemplary embodiments, when a fault event occurs, all devices connected to the first device 201 can act as second devices 202. The first device 201 can obtain information about the second devices 202 connected to it, such as device identification number, MAC address, IP address, etc. Based on the information of the second devices 202, the first device 201 can send a notification message containing a service identifier to the corresponding second device 202.

[0078] During the execution of distributed services, the first device 201 needs to coordinate with the second device 202. When the first device 201 establishes a connection with the second device 202, the first device 201 can generate associated cache information. This associated cache information can be used to record the call relationships of distributed services on the first device 201, for example, application 1 on the first device 201 calling application 2 on the second device 202. Specifically, this associated cache information may include information about the second device 202 connected to the first device 201, such as the device name and device identity, as well as information about the jointly executed distributed services, such as the service identifier, service name, and execution time of the distributed services.

[0079] The aforementioned associated cache information can be understood as a historical record of distributed services executed on the first device 201. By querying the associated cache information, the first device 201 can obtain the historical records of devices that collaboratively execute distributed services. In other words, the associated cache information can record all devices that have been connected to the first device 201 within a certain period. By recording the information of connected devices in the associated cache information, the problem of the first device 201 being unable to identify connected devices when a device disconnects can be avoided.

[0080] When the first device 201 experiences a fault event A, based on the service identifier of fault event A (e.g., service identifier B), the first device 201 can read the device executing the distributed service corresponding to service identifier B from the aforementioned associated cache information. This read device is designated as the second device 202. Furthermore, based on the device information stored in the associated cache information (e.g., device identifier, device IP address, etc.), a notification message is sent to the corresponding second device 202. Determining the second device from the associated cache information ensures that even if the second device (e.g., second device 202) disconnects from the first device 201 during fault event A, its information is already recorded in the associated cache information. Therefore, when determining the second device from the associated cache information, the first device 201 can also obtain the information of the second device 202, thus avoiding the problem of missed device notifications.

[0081] In some scenarios, the first device 201 can connect to multiple devices simultaneously to perform different distributed services. Taking a mobile phone as the first device 201 as an example, it can connect to a smart TV for multimedia playback, connect to a smartwatch for data sharing, or connect to a smart speaker for voice recognition, etc.

[0082] For different distributed services, the mobile phone can correspond to different second devices. Based on the distributed service where fault event A occurred, the mobile phone can determine the second device that needs to be notified. Specifically, based on the distributed service where fault event A occurred, the mobile phone can query the aforementioned associated cache information and read the information of the distributed service executed by each connected device, such as the service name of the distributed service. Furthermore, based on the read service name of the distributed service, the mobile phone can determine the device currently executing the same distributed service as the distributed service where fault event A occurred, and designate that device as the second device 202.

[0083] In other embodiments, when the first device 201 fails to query the associated cache information, the first device 201 can obtain all online devices currently connected to it as the second device 202, and then send a notification message to the second device 202. For example, if the first device 201 does not find the associated cache information, or the associated cache information found by the first device 201 is empty, the first device 201 can determine that the query for the associated cache information has failed. For instance, if the associated cache information is stored in file A, and the first device 201 queries file A and the result is that file A does not exist, or the result is that file A contains no data, the first device 201 can confirm that the query for the associated cache information has failed. In this case, the devices connected to the first device 201 can serve as the second device 202. For example, the first device 201 can query the devices connected to its own connection port; for example, if the device connected to the Bluetooth port is a smart speaker and the device connected to the Wi-Fi port is a smartwatch, then the smart speaker and the smartwatch can serve as the second device 202.

[0084] The first device 201 needs to send a corresponding notification message to the second device 202 to notify the second device 202 to upload relevant log information. In some implementations, before sending the notification message to the second device 202, the first device 201 can deduplicate the notification message to ensure that a fault event is only notified once, avoiding the problem of the second device 202 repeatedly uploading log information due to repeated notifications. For example, multiple fault events can occur on the first device 201, such as fault event A and fault event B. The first device 201 needs to send a notification message to the second device corresponding to each fault event, and the second device corresponding to each fault event can be different. For example, the second devices corresponding to fault event A are Device1 and Device2, and the second devices corresponding to fault event B are Device1, Device3, and Device4, etc. After each notification message is sent, the first device 201 can generate a history record to record the information of the sent notification messages (e.g., notification message 1). For example, the first device 201 can record the service identifier and the second device corresponding to the sent notification message 1. Before each notification message is sent, the first device 201 can use the history record to deduplicate the notification messages to be sent. If the notification message to be sent (e.g., notification message 2) has the same service identifier as the notification message already sent in the history record, and the corresponding second device is also the same, then the first device 201 can discard the notification message 2 to be sent.

[0085] For example, after the first device 201 sends the first notification message (e.g., notification message 1), it can generate a history record for notification message 1. This history record shows the second device to which notification message 1 was sent and the service identifier corresponding to that notification message. For example, history record 1 could include a service identifier of "traceid" and a second device identifier of "deviceid". When the first device 201 sends a second notification message, it can check the history record to see if the same notification message has already been sent to the same second device. For example, if the second notification message has the same service identifier and the same second device as a previously sent notification message (e.g., the service identifier is "traceid" and the second device is "deviceid"), which is the same as in history record 1, it means the first device 201 has already sent the same notification message to the same second device, and the first device can discard the second notification message.

[0086] In some implementations, if the second device 202 goes offline when the first device 201 sends a notification message to the second device 202 (i.e., the connection between the first device 201 and the second device 202 is broken), the notification fails; if the first device 201 successfully sends the notification message to the second device 202, the notification succeeds. The first device 201 can mark the notification message that failed, and the marked notification message can be used as a target notification message. The first device 201 can store the target notification message so that it can notify the second device that failed again. For example, the first device 201 can store the notification message that failed and the corresponding second device locally. When the second device that failed to notify re-establish a connection with the first device 201, the first device 201 can send the target notification message to the second device again until the target notification message is successfully sent to the corresponding second device, and then delete the stored target notification message.

[0087] When the second device 202 receives a notification message from the first device 201, it can obtain a service identifier (e.g., service identifier B) contained in the notification message. The second device 202 parses the service identifier B to extract a timestamp. The second device 202 can then determine an associated time period based on the parsed timestamp. This associated time period is a period within a preset time range of the timestamp. For example, if the parsed timestamp is 8:00:05 and the preset time range is within 10 minutes prior to the timestamp, the second device 202 can determine the associated time period as 7:50:05 to 8:00:05. Based on this associated time period, the second device 202 can filter locally stored log information, extracting information with timestamps within this associated time period as second log information, and then sending this second log information to the cloud server.

[0088] In some implementations, when the first device 201 sends a notification message to the second device 202, the second device may receive the same notification message repeatedly due to congestion, packet loss, or other factors. When filtering locally stored log information based on the notification message, the second device 202 can first perform deduplication to avoid repeatedly collecting the same second log information. Specifically, when collecting second log information, the second device 202 can determine whether the service identifier in the notification message is duplicated. If the service identifier in the notification message is the same as the service identifier in a previously received notification message, the second device 202 can discard the notification message or add it to the processed queue.

[0089] In other implementations, some devices may lack data transmission capabilities or have weak data transmission capabilities. For example, devices like Bluetooth speakers can only connect at close range. When the second device 202 lacks the ability to transmit data to a cloud server, the first device 201 can first synchronize the log information on the second device 202. After synchronization, the first device 201 can filter the log information on the second device using the method described above, filtering out the second log information. Then, the first device 201 can upload both the first and second log information to the cloud server.

[0090] In other words, when the first device 201 malfunctions, it can retrieve the first log information from its locally stored logs. Simultaneously, it can synchronize the log information from the connected second device 202 to its local storage, and then retrieve the second log information from the second device 202's logs. The first device 201 can then upload both the first and second log information to the cloud server.

[0091] In some implementations, when the first device 201 connects to the second device 202, the first device 201 can confirm the connection type of the second device 202, and then determine whether the second device 202 should report relevant log information to the cloud server based on the connection type of the second device 202. If the connection type of the second device 202 meets the preset requirements, the first device 201 can confirm that the second device 202 should report the log information; if the connection type of the second device 202 does not meet the preset requirements, the first device 201 can synchronize the log information on the second device 202, and then the first device 201 can report the second log information itself.

[0092] For example, when the second device 202 uses a connection type that supports short-range data transmission, such as Bluetooth or NFC, the first device 201 can determine that the connection type of the second device 202 does not meet the preset requirements. In this case, the first device 201 can determine to synchronize the log information of the second device 202. When the second device 202 uses a connection type that supports long-range data transmission, such as Wi-Fi or broadband, the first device 201 can determine that the second device 202 meets the preset requirements. In this case, the second device 202 can upload log information on its own.

[0093] For example, when establishing a connection with the second device 202, the first device 201 can generate connection cache information and record the connection type of the second device 202 through the connection cache information. When the connection type of the second device 202 meets the preset requirements, the first device 201 can record the connection type as "1" in the connection cache information; if the second device 202 does not meet the preset requirements, the first device 201 can record the connection type as "0" in the connection cache information. It is understood that the first device 201 can also record other information of the second device 202 in the connection cache information, such as the device name, device identification number, connection time, disconnection time, etc., and this embodiment does not limit this. When a fault event occurs in the first device 201, the first device 201 confirms whether the second device 202 should upload the second log information related to the fault event by reading the above-mentioned connection cache information. If the first device 201 obtains that the connection type of the second device 202 is "1", the first device 201 can send a notification message to the second device 202 with connection type "1" so that the second device 202 can report the second log information after receiving the notification message. If the first device 201 obtains that the connection type of the second device 202 is "0" from the above connection cache information, the first device 201 can synchronize the log information on the second device 202 with connection type "0".

[0094] like Figure 3As shown, when the first device (e.g., first device 301) executes a distributed service (e.g., a distributed image library), it needs to collaborate with the second device (e.g., second device 302). When the first device 301 establishes a connection with the second device 302, the first device 301 can record relevant information about this connection in the connection cache information. For example, it can record the device identifier, device name, connection type, and connection time of the second device 302 in the connection cache information. Furthermore, the first device 301 can also record relevant information about the current execution of the distributed service in the association cache information. For example, the first device 301 can record information about the collaborating second device 302 (such as the device identifier and device type of the second device 302) and information about the collaboratively executed distributed image library (such as the business identifier and start execution time of the distributed image library) in the association cache information.

[0095] When the first device 301 detects a fault event A, it can query the associated cache information based on the service identifier B of fault event A, and then retrieve the second device 302 corresponding to service identifier B from the associated cache information. After determining the second device 302 corresponding to fault event A, the first device 301 queries the connection cache information for the connection type of the second device 302. If the connection type of the second device 302 does not meet the preset requirements, the first device 301 can synchronize the log information generated on the second device 302.

[0096] First device 301 synchronizes the log information on second device 302 to its local machine. Then, first device 301 can obtain the service identifier B of the fault event A, parse the timestamp from the service identifier B, and use the timestamp to determine a time period. It can then retrieve the first log information and the second log information within that time period from the locally stored log information and the log information synchronized from the second device. Both the retrieved first and second log information can be uploaded by first device 301 to the cloud server.

[0097] After obtaining the first and second log information, the cloud server can use them to locate the fault event A. Locating the fault event A means determining the cause of its occurrence. This cause can include the application or function that caused the fault event A, or it can include the specific file that caused the fault event A and its storage path. This implementation does not impose any limitations on this. Obtaining more comprehensive log information facilitates more accurate fault location.

[0098] The first device 301 and the second device 302 can upload their own log information (i.e., the aforementioned first log information and second log information) through service identifier B. For example, when the first device 301 uploads the first log information to the cloud server, it can upload both the service identifier B and the first log information to the cloud server. The service identifier B is used to identify the first log information. When the cloud server receives the first log information and the second log information, it can parse the service identifier B to obtain the timestamp. Based on this timestamp, the cloud server can retrieve the information corresponding to that timestamp from the first and second log information. This retrieved information can be the log information of various modules on the first device 301 or the second device 302.

[0099] The cloud server can automatically locate the fault using the first and second log information to obtain the location result. Alternatively, developers can retrieve log information related to fault event A (i.e., the first and second log information) from the cloud server using business identifier B, and then use this information to locate the fault event A to obtain the location result.

[0100] For example, developers can determine the operational status of each module on the first device 301 and the second device 302 at the time corresponding to the timestamp based on the retrieved information. This includes checking whether interface function calls are normal, device discovery is normal, and device connection is normal. By investigating each module on the first device 301 and the second device 302, developers can pinpoint the cause of fault event A. For instance, if fault event A is a device connection error, and the first and second log information show that the application on the first device 301 changed its bound device at the time corresponding to the timestamp of fault event A, then developers can determine that the location of fault event A is: the application changed its bound device.

[0101] In an exemplary embodiment, after obtaining the location result, the cloud server can send the location result back to the first device 301 or the second device 302. The first device 301 or the second device 302 can then display the location result to prompt the user to repair the fault. After the fault is repaired, the first device 301 or the second device 302 can re-execute the distributed service to fulfill the user's needs.

[0102] For example, the cloud server can identify the faulty device based on the location results and then send the location results back to the corresponding device. If the faulty device is a first device, the cloud server can send the location results back to the first device; if the faulty device is a second device, the cloud server can send the location results back to the second device. For instance, if fault event A is a data transmission failure and the location result is that the second device has disconnected, the cloud server can send this location result back to the second device.

[0103] It is understandable that the cloud server can also determine a primary device from the first device and the second device, and designate the other devices as secondary devices. For example, the first device can be designated as the primary device and the second device as the secondary device, and then the cloud server can only send the location results back to the primary device. Alternatively, the primary device can further forward the location results to each secondary device. In addition, the primary device can be a personal computer, mobile phone, tablet computer, etc., and the secondary devices can be wearable devices (such as smartwatches, AI (Artificial Intelligence) glasses), smart home devices, etc. This embodiment does not impose any restrictions on this.

[0104] For example, the cloud server can simultaneously send the location results back to both the first and second devices.

[0105] In some embodiments, corresponding functional modules may be set in the first device or the second device to execute the fault location method provided in the above embodiments.

[0106] Taking a mobile phone as an example, either the first or second device, the aforementioned functional modules can be pre-installed in the phone's application framework layer. Applications in the mobile phone's application layer can execute various distributed services (such as multi-screen collaboration, distributed image libraries, etc.). When a failure event occurs in an application while executing a distributed service, the mobile phone can call the aforementioned functional modules to implement the fault location method provided in the above embodiments.

[0107] For example, such as Figure 4 As shown, the application framework layer 400 of the mobile phone may include a trigger module (Engine) 401, a detection module (RemoteDetector) 402, and a distributed communication module (DistributedCommnicator) 403.

[0108] The trigger module 401 can communicate with applications in the mobile application layer (such as gallery, multimedia player, etc.) and receive messages sent by the application, such as fault events sent by the application. The trigger module 401 can also report first log information to the cloud server when a fault event is received. For example, the trigger module 401 can parse the business identifier corresponding to the fault event, parse out the timestamp contained in the business identifier, and then collect the first log information based on the timestamp.

[0109] The detection module 402 can generate a notification message upon receiving a fault event and send the notification message to the corresponding second device, thereby notifying the second device to upload second log information. Specifically, the detection module 402 may include a fault subscription module 4021, a relationship caching module 4022, and a device online / offline caching module 4023.

[0110] The fault subscription module 4021 can be configured to subscribe to various fault events. When a fault event configured in the fault subscription module 4021 occurs in an application on the mobile phone, the triggering module 401 can communicate with the application on the mobile phone to obtain the fault event sent by the application. Furthermore, the fault subscription module 4021 can also be used to generate corresponding notification messages based on the fault event.

[0111] The relationship caching module 4022 can be used to generate associated cache information, which records the call relationships of distributed services. Specifically, this associated cache information can record information about the second device called by the mobile phone, such as the device identifier, and information about the executed distributed service, such as the service identifier. For example, when application A on the mobile phone calls application B on the second device, the relationship caching module 4022 can record the service identifier of application A and the device identifier of the second device as associated cache information. When a fault event occurs on the mobile phone, the mobile phone can read the information of the second device called by the mobile phone from the relationship caching module 4022 to send a notification message to the second device. The relationship caching module 4022 can also record the target notification message for notification failures, so that the second device can be re-notified when it comes back online.

[0112] The device connection / disconnection caching module 4023 can be used to record information about a second device connected to the mobile phone, as well as information about a second device disconnected from the mobile phone. For example, the device connection / disconnection caching module 4023 can record information such as the device identifier, device type, connection time, and connection duration of the second device connected to the mobile phone; when the second device disconnects from the mobile phone, it can record the device identifier and disconnection time of the second device disconnected from the mobile phone; this embodiment does not limit this.

[0113] The distributed communication module 403 can be used for cross-device communication. That is, the mobile phone can communicate with other devices (such as a second device) through this distributed communication module 403, thereby sending notification messages to the second device. Specifically, the distributed communication module 403 can be configured with a communication adaptation layer. Through this communication adaptation layer, the mobile phone can adapt to the communication protocols of other devices, thereby establishing connections with other devices. For example, the mobile phone can connect to the second device via Bluetooth (BT), or it can connect to the second device via a local area network (Wi-Fi), etc.

[0114] In addition, the above-mentioned functional modules can also implement other functions. For example, the distributed communication module 403 can filter the notification message before sending it to the second device, keeping only one of the same notification messages from the same second device. Similarly, the triggering module 401 can filter the first log information when reporting the first log information, keeping only one of the same first log information. This embodiment is not limited to these.

[0115] When a mobile phone is performing a distributed service, a second device (such as a smart speaker) that is also cooperating in performing the distributed service also needs to have the aforementioned functional modules pre-installed. For example... Figure 5 As shown, when mobile phone 510 and smart speaker 520 are connected to jointly perform distributed services, mobile phone 510 can record relevant information about this distributed service execution in associated cache information for storage. The trigger module 5101 in mobile phone 510 can communicate with various applications on mobile phone 510. When a fault event A occurs during the execution of distributed services on mobile phone 510, both the fault subscriber trigger module 5101 and the cloud server 530 can detect fault event A. The trigger module 5101 can collect the first log information from the cache of mobile phone 510 based on the moment fault event A is detected, and upload the first log information to the cloud server 530.

[0116] Meanwhile, when the triggering module 5101 obtains fault event A, the detection module 5102 in the mobile phone 510 can determine the corresponding second device from the associated cache based on the service identifier B of fault event A. When the determined second device is the smart speaker 520, the detection module 5102 can use the service identifier B to generate a notification message and send the notification message to the smart speaker 520. The distributed communication module 5103 in the mobile phone 510 can communicate across devices with the distributed communication module 5203 in the smart speaker 520 via Bluetooth (BT), local area network (Wi-Fi), etc., so that the mobile phone 510 can send the notification message to the corresponding smart speaker 520.

[0117] The distributed communication module 5203 in the smart speaker 520 can receive notification messages sent by the mobile phone 510. When the distributed communication module 5203 receives the notification message, the detection module 5202 in the smart speaker 520 can read the service identifier B in the notification message and parse the service identifier B to extract the timestamp. Then, the detection module 5202 can collect second log information from the log information stored on the smart speaker 520 based on the timestamp. The trigger module 5201 in the smart speaker 520 can identify the second log information using the service identifier B and is responsible for uploading the identified second log information to the cloud server 530. When the cloud server 530 receives the identified first and second log information, it can merge the first and second log information according to the service identifier B, thereby using the first and second log information together to locate the fault event A.

[0118] When the smart speaker 520 lacks data transmission capabilities, the trigger module 5101 in the mobile phone 510 can synchronize all log information on the smart speaker 520 to the mobile phone 510 upon receiving fault event A. Specifically, as follows... Figure 6 As shown, the process of synchronizing log information between mobile phone 510 and smart speaker 520 includes the following steps:

[0119] S601: The trigger module 5101 in mobile phone 510 detected fault event A.

[0120] S602: The detection module 5102 detects whether the smart speaker 520 has transmission capability. Specifically, the detection module 5102 can read the connection cache information stored on the mobile phone 510, query the connection type of the smart speaker 520 in the connection cache information, and then the detection module 5102 can determine whether the connection type of the smart speaker 520 meets the preset requirements. When the connection type of the smart speaker 520 does not meet the preset requirements, the smart speaker 520 does not have transmission capability.

[0121] S603: The distributed communication module 5103 requests the smart speaker 520 to synchronize log information. Specifically, the mobile phone 510 can generate a request, which may include information such as the file name and storage path of the file containing the log information to be synchronized. Then, the mobile phone 510 can send this request to the smart speaker 520 through the distributed communication module 5103 to request all the log information on the smart speaker 520.

[0122] S604: The distributed communication module 5203 in the smart speaker 520 returns log information to the mobile phone 510. Specifically, the distributed communication module 5203 in the smart speaker 520 can receive a request from the mobile phone to synchronize log information. Then, the smart speaker 520 can read the file storing the log information from memory and return that file to the mobile phone 510 through the distributed communication module 5203. In this way, the mobile phone 510 can obtain all the log information on the smart speaker 520.

[0123] Then, the trigger module 5101 in the mobile phone 510 can parse the corresponding timestamp based on the service identifier B of fault event A, and use this timestamp to collect the first log information in the log information stored in the mobile phone, and the second log information in the log information synchronized on the smart speaker 520. Furthermore, the trigger module 5101 can use the service identifier B as the identifier for the collected first and second log information, and upload the identified first and second log information to the cloud server 530.

[0124] The cloud server 530 can merge the received first log information with the second log information to form the complete log information for fault event A, and then use this complete log information to automatically locate the fault. Furthermore, when developers need to locate the fault, they can obtain the complete log information for fault event A through the cloud server 530, and then use this complete log information to locate the fault in fault event A.

[0125] In some implementations, the mobile phone can also connect to multiple second devices (such as smart speakers and televisions) to jointly execute a distributed task. In this scenario, when the mobile phone detects a fault event A in the distributed task, similar to the embodiments described above, the mobile phone can generate a notification message for fault event A and send the notification message to the smart speaker and television respectively. Simultaneously, the mobile phone can also send its stored first log information to a cloud server. When the smart speaker receives the notification message, it can send its second log information to the cloud server; when the television receives the notification message, it can also send its second log information to the cloud server. The cloud server, by obtaining the first log information from the mobile phone, the second log information from the smart speaker, and the second log information from the television, can automatically locate the fault event A, or provide the obtained log information to developers when they are troubleshooting. In other words, when three or more electronic devices are executing a distributed service, using the method described above, when a fault event occurs in the distributed service, the cloud server can obtain the corresponding log information from each electronic device executing the distributed service to facilitate fault event localization.

[0126] In the above embodiments, when a malfunction occurs in the mobile phone (i.e., the first device), the cloud server of the mobile phone can obtain log information from the mobile phone and the smart speaker connected to the mobile phone (i.e., the second device) to locate the fault. Thus, in scenarios involving distributed business operations, fault location can be based not only on the log information on the first device but also on the log information from the second device that collaborates with the first device, making fault location more comprehensive and accurate. Furthermore, important log information related to the fault on the second device can be uploaded to the cloud server in a timely manner, avoiding the problem of information being overwritten and preventing fault location, thereby improving the effectiveness of fault location.

[0127] This application provides an electronic device, which can be any of the electronic devices (e.g., the first device 201 or the second device 202) used to perform distributed services in the system architecture 100 described above. The electronic device may include a processor, as well as a memory and a communication module connected to the processor.

[0128] For example, such as Figure 7 As shown, the electronic device provided in this application embodiment may include: one or more processors 701; a memory 702; a communication module 703; one or more application programs (not shown); and one or more computer programs 704. These devices can be connected via one or more communication buses 705. The one or more computer programs 704 are stored in the memory 702 and configured to be executed by the one or more processors 701. The one or more computer programs 704 include instructions that can be used to execute various steps performed by the electronic device in the above embodiment. Furthermore, the electronic device may also include other devices such as a display screen, camera, and sensors; this embodiment is not limited to these.

[0129] This application embodiment provides a server, which can be the cloud server 104 in the system architecture 100 described above. For example... Figure 8 As shown, the server provided in this embodiment may include: one or more processors 801; a memory 802; a communication module 803; and one or more computer programs 804. These devices can be connected via one or more communication buses 805. The one or more computer programs 804 are stored in the memory 802 and configured to be executed by the one or more processors 801. The one or more computer programs 804 include instructions that can be used to execute various steps performed by the cloud server 104 in the above embodiment.

[0130] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0131] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0132] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0133] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.

Claims

1. A fault location method based on multi-device interconnection, applied to a distributed system composed of multiple interconnected physical devices, the system including a first physical device and at least one second physical device, wherein the second physical device and the first physical device collaboratively execute distributed services, characterized in that, include: When the first physical device detects a fault event during the collaborative execution of the distributed service, it collects the first log information of the fault event and reports the first log information to the cloud server. The first physical device determines the service identifier of the distributed service that failed from the fault event, and generates a notification message based on the service identifier; wherein, the service identifier is generated when the distributed service is executed, and includes the device identifier of the first physical device, the timestamp when the fault event occurred, and the processor identifier of the first physical device; the timestamp is updated at a preset time period, and the timestamps updated within the preset time period are not repeated. Based on the associated cache information generated when the first physical device executes the distributed service, a second physical device that collaborates with the first physical device to execute the distributed service is determined; wherein, the associated cache information is used to record information about the physical devices that jointly execute the distributed service; The first physical device sends the notification message to the second physical device; In response to receiving the notification message, the second physical device retrieves and determines the second log information related to the fault event in its local log based on the service identifier in the notification message, and reports the second log information to the cloud server. The cloud server performs correlation and merging analysis on the first log information and the second log information based on the service identifier in order to locate the fault of the distributed service in the system.

2. The method according to claim 1, characterized in that, The method further includes: The first physical device and the second physical device generate service identifiers in real time, and record log information of distributed services through the service identifiers.

3. The method according to claim 1, characterized in that, The method further includes: When the first physical device fails to query the associated cache information, the first physical device obtains the physical device connected to the first physical device and uses the device connected to the first physical device as the second physical device.

4. The method according to claim 1, characterized in that, After receiving the notification message, the second physical device retrieves and determines the second log information related to the fault event in its local log based on the service identifier in the notification message, including: After receiving the notification message, the second physical device obtains the service identifier in the notification message; The second physical device parses the timestamp from the service identifier; The second physical device determines the associated time period based on the timestamp and uses the log information within the associated time period as the second log information related to the fault event.

5. The method according to claim 1, characterized in that, When the first physical device detects a fault event during the collaborative execution of the distributed service, the first log information of the fault event collected includes: When the first physical device detects a fault event, the time of occurrence of the fault event is recorded; The first physical device collects the first log information from the recorded log information based on the time of occurrence of the fault event.

6. The method according to claim 1, characterized in that, The notification message sent from the first physical device to the second physical device includes: The first physical device detects whether the connection type of the second physical device meets the preset requirements. If the connection type of the second physical device meets the preset requirements, the first physical device sends the notification message to the second physical device.

7. The method according to claim 6, characterized in that, The method further includes: If the first physical device detects that the connection type of the second physical device does not meet the preset requirements, the first physical device synchronizes the log information on the second physical device. The first physical device collects second log information related to the fault event from the synchronized log information; The first physical device reports the second log information to the cloud server.

8. The method according to claim 1, characterized in that, After the first physical device sends the notification message to the second physical device, the method further includes: The first physical device determines whether there is a target notification message that failed to notify. When the first physical device sends the notification message to the second physical device, the second physical device disconnects from the first physical device. Then the notification message is a target notification message that failed to notify. When a target notification message fails to be sent, the first physical device stores the target notification message so that when the second physical device establishes a connection with the first physical device, it can resend the target notification message to the second physical device.

9. An electronic device, characterized in that, include: One or more processors; Memory; The memory stores one or more computer programs, the one or more computer programs including instructions that, when executed by the electronic device, cause the electronic device to perform a fault location method based on multi-device interconnection as described in any one of claims 1-8.

10. A computer-readable storage medium storing instructions, characterized in that, When the instruction is executed on the electronic device, the electronic device performs a fault location method based on multi-device interconnection as described in any one of claims 1-8.

11. A computer program product, characterized in that, When the computer program product is run on an electronic device, the electronic device performs a fault location method based on multi-device interconnection as described in any one of claims 1-8.

Images