Distributed operation monitoring method and device, electronic equipment and computer readable medium

Abstract

Embodiments of the present disclosure disclose a distributed operation monitoring method, device, electronic equipment and computer readable medium. A specific embodiment of the method comprises: in response to determining to establish a communication connection, decrypting at least one received state encryption information to obtain at least one current node operation state; for each current node operation state, performing a processing step of: performing module state analysis on the current node operation state; determining a device monitoring node; updating the display state of each operation module, and generating operation alarm information; sending the operation alarm information to the device monitoring node; in response to determining that there is an operation exception and no abnormal maintenance is performed, sending the operation alarm information to a module operation and maintenance terminal to perform abnormal maintenance. The embodiment can timely monitor the real-time operation state of each service device node through a target device state monitoring platform, so as to timely and efficiently perform module-level abnormal maintenance according to the abnormal operation state.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of computer technology, and more specifically to distributed operation monitoring methods, apparatus, electronic devices, and computer-readable media. Background Technology

[0002] Currently, distributed systems typically consist of a large number of device nodes. An abnormal operation of a single device node can lead to service degradation or even complete system failure. Status detection can identify abnormal device nodes in real time, triggering automatic recovery (such as restarting the service or switching between primary and backup nodes) or alerting for manual intervention, minimizing downtime. The typical approach to detecting the operational status of service device nodes is as follows: First, the relevant monitoring platform periodically sends operational status query requests to each service device node to obtain its operational status at various points in time. Then, based on the operational status, corresponding technical personnel are dispatched for manual maintenance.

[0003] However, when using the above method, the following technical problems often arise:

[0004] When service device nodes malfunction, monitoring platforms often fail to detect the anomalies in a timely manner, and information leaks may occur during status queries. This results in faulty device nodes not receiving effective, granular module-level maintenance, leading to service degradation or even complete system failure.

[0005] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0007] Some embodiments of this disclosure provide distributed operation monitoring methods, apparatuses, electronic devices, and computer-readable media to address one or more of the technical problems mentioned in the background section above.

[0008] In a first aspect, some embodiments of this disclosure provide a distributed operation monitoring method, comprising: in response to determining that a distributed set of service device nodes establishes a communication connection with a target device status monitoring platform, receiving at least one state encrypted information representing the node operation status corresponding to at least one target service device node in the set of service device nodes; decrypting each state encrypted information in the at least one state encrypted information to obtain at least one current node operation status; and for each current node operation status in the at least one current node operation status, performing the following processing steps: performing module status parsing on the current node operation status to obtain a current module status set for each operating module in the node; determining the current node operation status corresponding to... The target service device node is designated as the device monitoring node. Based on the current module status set, the display status of each running module in the module status display interface corresponding to the device monitoring node is updated, and at least one running alarm message corresponding to the target running module is generated. The at least one target running module is a running module in the device monitoring node that indicates an abnormal operation. The running alarm message is sent to the device monitoring node in an encrypted manner to determine the abnormality of the at least one target running module. In response to determining that the at least one target running module has an abnormal operation and has not been abnormally maintained, the running alarm message is sent to the module operation and maintenance terminal to perform abnormal maintenance on the at least one target running module.

[0009] Secondly, some embodiments of this disclosure provide a distributed operation monitoring device, including: a receiving unit configured to, in response to determining that a distributed set of service device nodes establishes a communication connection with a target device status monitoring platform, receive at least one encrypted status information representing the node operation status corresponding to at least one target service device node in the set of service device nodes; a decryption unit configured to decrypt each of the at least one encrypted status information to obtain at least one current node operation status; and an execution unit configured to, for each of the at least one current node operation statuses, perform the following processing steps: perform module status parsing on the current node operation status to obtain a set of current module statuses for each operating module in the node; and confirm... The target service device node corresponding to the current node's operating status is designated as the device monitoring node. Based on the current module status set, the display status of each operating module in the module status display interface corresponding to the device monitoring node is updated, and at least one operating alarm message corresponding to a target operating module is generated. This target operating module is a running module in the device monitoring node that indicates an abnormal operation. The operating alarm message is sent to the device monitoring node in an encrypted manner to determine the abnormality of the at least one target operating module. In response to determining that the at least one target operating module has an abnormal operation and has not undergone abnormal maintenance, the operating alarm message is sent to the module maintenance terminal to perform abnormal maintenance on the at least one target operating module.

[0010] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, such that when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any implementation of the first aspect.

[0011] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0012] The above embodiments of this disclosure have the following beneficial effects: Through the distributed operation monitoring method of some embodiments of this disclosure, the real-time operation status of each service device node can be monitored in a timely manner by the target device status monitoring platform, so as to perform timely and efficient module-level anomaly maintenance based on abnormal operation status. Specifically, the reason why anomaly maintenance is not timely and efficient when related service device nodes experience module anomalies is that when a service device node malfunctions, the monitoring platform often cannot obtain the anomaly information in a timely manner, and information leakage may occur during the status query process. This results in the malfunctioning device node not receiving effective, more granular module anomaly maintenance, leading to service degradation or overall paralysis. Based on this, the distributed operation monitoring method of some embodiments of this disclosure firstly, in response to determining that the distributed service device node set establishes a communication connection with the target device status monitoring platform, receives at least one encrypted status information representing the node operation status corresponding to at least one target service device node in the aforementioned service device node set. Here, based on the established communication connection between the target device status monitoring platform and the service device node set, by receiving encrypted status information from at least one target service device node in the service device node set that needs to convey its node operating status in real time, it can not only promptly understand the status communication needs of each service device node, but also prevent the leakage of node operating status information through encryption, ensuring the efficiency and confidentiality of real-time communication of node operating status. Then, each of the above-mentioned encrypted status information is decrypted to obtain at least one current node operating status, so that the target device status monitoring platform can understand the real-time node operating status of at least one target service device node. Furthermore, for each of the above-mentioned at least one current node operating status, the following processing steps are performed: First, the current node operating status is parsed to obtain the current module status set for each operating module in the node, so as to accurately obtain the module operating status corresponding to each operating module in the current node operating status, which can be used for subsequent module-level operation and maintenance. Second, the target service device node corresponding to the above-mentioned current node operating status is determined as the device monitoring node. The third step involves updating the display status of each operating module in the module status display interface corresponding to the aforementioned device monitoring nodes based on the current module status set. It also involves generating operational alarm information for at least one target operating module, where each target module is a module in the aforementioned device monitoring nodes that indicates an operational anomaly. Here, the module status display interface is used to show each operating module, allowing the operation and maintenance objects corresponding to the device node set to promptly understand the anomaly status of each operating module in each service device node at the current time. Furthermore, generating operational alarm information enables timely alerts for operating modules exhibiting operational anomalies.The fourth step involves sending the aforementioned operational alarm information in encrypted form to the aforementioned device monitoring nodes to determine the anomaly of at least one target operational module. This verifies whether the at least one target operational module is indeed experiencing an anomaly at that time and whether the anomaly has been resolved in a timely manner. The fifth step, in response to the determination that at least one target operational module is experiencing an operational anomaly and has not undergone anomaly maintenance, involves sending the aforementioned operational alarm information to the module maintenance terminal for accurate and efficient anomaly maintenance of the at least one target operational module. In summary, the target device status monitoring platform can monitor the real-time operational status of each service device node in a timely manner, enabling timely and efficient module-level anomaly maintenance based on abnormal operational status, thus preventing service degradation or overall system failure. Attached Figure Description

[0013] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0014] Figure 1 These are flowcharts of some embodiments of the distributed operation monitoring method according to this disclosure;

[0015] Figure 2 These are schematic diagrams illustrating the structure of some embodiments of the distributed operation monitoring device according to this disclosure;

[0016] Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0017] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0018] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0019] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0020] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0021] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0022] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] refer to Figure 1 The diagram illustrates a flow 100 of some embodiments of a distributed operation monitoring method according to the present disclosure. This distributed operation monitoring method includes the following steps:

[0024] Step 101: In response to establishing a communication connection between the distributed service device node set and the target device status monitoring platform, receive at least one encrypted status information representing the node operating status corresponding to at least one target service device node in the aforementioned service device node set.

[0025] In some embodiments, in response to establishing a communication connection between a distributed set of service device nodes and a target device status monitoring platform, the executing entity of the distributed operation monitoring method (e.g., the target device status monitoring platform) can receive at least one encrypted status information representing the node operation status corresponding to at least one target service device node in the service device node set via a wired or wireless connection. The service device nodes in the service device node set can be deployed in a distributed manner. Each service device node can be a device node providing related services. For example, the related services could be image recognition services, intelligent product recommendation services, or intelligent dialogue services. In practice, a service device node can be a server. The target device status monitoring platform can be a platform that monitors or registers node-related information corresponding to the service device node set. In practice, the target device status monitoring platform can be hardware or software. The target device status monitoring platform has a device status monitoring plane to display and provide early warnings for the status of each service device node. In practice, node-related information can include, but is not limited to, at least one of the following: node name, node location, node resource configuration, node status, node communication information, and node update time. The target service device node can be a service device node that sends the real-time operating status of the device at the current time. In other words, the target device status monitoring platform supports each service device node to provide status feedback at any time based on its own status, allowing the platform to understand the operational status of the service device nodes in a timely manner. The node's operational status can be the current operational status of the service device node. For example, the node's operational status can be, but is not limited to, one of the following: normal node operation, node failure, or node alarm status. There is a one-to-one correspondence between at least one target service device node and at least one encrypted status information. The encrypted status information can be the result of encrypting the node's operational status corresponding to the target service device node. In practice, the node's operational status can be encrypted using relevant encryption algorithms. For example, encryption algorithms can be symmetric encryption, asymmetric encryption, hash algorithms, and key exchange algorithms. Symmetric encryption, such as AES, is fast and suitable for encrypting large amounts of data, but key distribution is a problem. Asymmetric encryption, such as RSA, solves the key distribution problem, but is slow. Hash algorithms are used for integrity verification, such as SHA-256. Key exchange algorithms, such as DH, are used for securely sharing keys.

[0026] It should be noted that the service device nodes in the service device node cluster communicate via a local area network, and the service device nodes are primarily detectors. The service device node cluster will proactively initiate VPN connections (with pre-assigned and configured accounts and passwords) to establish an internet communication channel with the target device status monitoring platform.

[0027] In some optional implementations of certain embodiments, the aforementioned set of service device nodes includes at least one master service device node. The master service device node is responsible for coordinating the work of the entire distributed system. For example, when multiple service device nodes exist, a central node (i.e., the master service device node) is needed to allocate tasks and avoid confusion. For example, the NameNode in HDFS manages the file system's namespace and the location of data blocks, while DataNodes store the actual data. The role of the master node here is to maintain metadata, process client requests, and guide DataNodes in their operations. The master service device node also supports task scheduling and allocation. The master node might be like the JobTracker in MapReduce, responsible for decomposing tasks and allocating them to different worker nodes (TaskTrackers), and then monitoring their execution. In this case, the master node needs to know the status of each slave node, allocate tasks appropriately, and handle failover. In addition, the master service device node also supports, but is not limited to, at least one of the following: permission and security management, data consistency and synchronization, and system status monitoring and processing. Each master service device node has at least one managed slave service device node.

[0028] Optionally, at least one of the aforementioned state encryption information is generated through the following steps:

[0029] First, for each of the at least one primary service device node mentioned above, perform the following determination steps:

[0030] Sub-step 1 involves determining the pre-registered set of slave service device nodes corresponding to the aforementioned master service device node. Each master service device node and its corresponding set of slave service device nodes can be obtained by querying the relevant master-slave registration table.

[0031] Sub-step 2 involves periodically sending node status acquisition information to the aforementioned set of service device nodes. The corresponding periodic sending interval can be preset. The node status acquisition information can be a request to obtain the real-time node status of the service device nodes at the current time.

[0032] Sub-step 3 involves receiving the real-time status set sent from the aforementioned set of service device nodes. There is a correspondence between the slave service device nodes in the set of service device nodes and the real-time statuses in the real-time status set. The real-time status can be the operating status of the slave service device node at the current time.

[0033] Sub-step 4: Remove the slave service device nodes that indicate no abnormalities in their real-time status from the above set of slave service device nodes to obtain the set of slave service device nodes after removal.

[0034] Sub-step 5 generates status acquisition logs for the service device node set after removal. These status acquisition logs characterize how it was determined that each service device node in the removed service device node set exhibits real-time status anomalies.

[0035] The second step is to encrypt the real-time status subset corresponding to the service device node set after the above removal and the status acquisition log to obtain the status encryption information.

[0036] In some optional implementations of certain embodiments, the target device status monitoring platform maintains a set of node codes corresponding to the service device node set in real time. Each service device node has a unique corresponding node code. The node code can represent the identity information corresponding to the service device node. In practice, the node code can be a node code identifier. The target device status monitoring platform can periodically maintain and update the node codes. There is a one-to-one correspondence between the primary service device node and the device region in at least one device region. Each primary service device node has a corresponding service management device region. Within this device region, there are deployed primary service device nodes and at least one secondary service device node to provide adaptive services to various objects within the region.

[0037] The aforementioned target device status monitoring platform maintains at least one region code corresponding to at least one device region in real time. Each device region has a unique corresponding region code. The region code can represent the identity information corresponding to the device region. In practice, the region code can be a region code identifier. The target device status monitoring platform can periodically maintain and update the region codes. The aforementioned target device status monitoring platform also maintains module codes corresponding to each operating module in real time. Each operating module has a unique corresponding module code. The module code can represent the identity information of the operating module. The specific maintenance content is synchronized with the node codes. The aforementioned target device status monitoring platform also maintains various operating status codes corresponding to each operating module. The operating status codes can represent the corresponding operating status. Different operating status codes correspond to different operating statuses. For example, the various operating statuses include: normal operating status, abnormal operating status, resource request status, request status, submission status, cancellation status, completion status, and waiting status. The corresponding operating status codes can include: the code corresponding to the normal operating status, the code corresponding to the abnormal operating status, the code corresponding to the resource request status, the code corresponding to the request status, the code corresponding to the submission status, the code corresponding to the cancellation status, the code corresponding to the completion status, and the code corresponding to the waiting status.

[0038] The aforementioned target device status monitoring platform contains node behavior adjustment codes for each service device node. These node behavior adjustment codes can be codes used to adjust the relevant behaviors of the service device nodes. For example, node behavior adjustment codes can be, but are not limited to, at least one of the following: adding a behavior code, modifying a behavior code, deleting a behavior code, querying a behavior code, revoking a behavior code, uploading a behavior code, and downloading a behavior code.

[0039] In some optional implementations of certain embodiments, the target device status monitoring platform also supports the scheduling of computing resources for each service device node in the aforementioned service device node set. Computational resource scheduling can be the scheduling of online and offline resources. For service device nodes providing services related to neural network models, each service device node needs to call upon significant computing resources to provide computing power and ensure the normal execution of the service. The resource emergency usage status display page corresponding to the target device status monitoring platform displays the real-time resource emergency situation for each service device node. The resource emergency usage status display page can be a page displaying the resource emergency usage status. In practice, the resource emergency usage status can characterize the resource emergency usage situation of a service device node at the current time. In practice, the resource emergency usage status can include: a first emergency usage status, a second emergency usage status, and a third emergency usage status. The resource urgency level corresponding to the first emergency usage status is higher than that corresponding to the second emergency usage status. The resource urgency level corresponding to the second emergency usage status is higher than that corresponding to the third emergency usage status.

[0040] Optionally, the service device nodes in the service device node cluster are scheduled using the following steps:

[0041] The first step, in response to determining that at least one resource-critical node is experiencing a resource emergency, is to obtain at least one resource-critical demand information corresponding to that node. This resource-critical demand information represents the urgent resources required by service device nodes within a target future time period. A resource-critical node can be a service device node currently experiencing a resource shortage. Each resource-critical node has a unique corresponding resource-critical demand information. This resource demand information represents the resource requirements of the resource-critical node within the target future time period.

[0042] The second step is to obtain the node distribution map corresponding to the above-mentioned service device node set. The node distribution map represents the location distribution of each service device node in the service device node set.

[0043] Third, for each of the at least one resource emergency node mentioned above, a subset of service device nodes whose distance from the resource emergency node is less than a target distance is selected from the node distribution map. The node distance can be the distance between two service device nodes. The target distance can be a pre-set value.

[0044] The fourth step is to perform deduplication on each service device node in the obtained at least one subset of service device nodes to obtain the target subset of service device nodes.

[0045] Fifth, for each target service device node in the above subset of target service device nodes, perform the following generation steps:

[0046] Sub-step 1: Identify the resource emergency node group corresponding to the target service device node that has a proximity relationship. The proximity relationship can be a distance proximity relationship where the node's location distance is less than the target distance.

[0047] Sub-step 2 generates node proximity binding information groups between the aforementioned target service device node and the aforementioned resource emergency node group. Each node proximity binding information group represents the binding information between the target service device node and the resource emergency node.

[0048] Sub-step 3: Obtain the historical resource usage sequence corresponding to the target service device node. The historical resource usage sequence can be the resource usage sequence of the target service device node within the target historical time period. Each historical time point has a corresponding historical resource usage.

[0049] Sub-step 4: Based on the aforementioned historical resource usage sequence, generate the future resource usage sequence for the target future time period. Within the target future time period, each future time corresponds to a specific future resource usage.

[0050] As an example, the aforementioned entity can first preprocess historical resource usage sequences to generate preprocessed data sequences. Then, the preprocessed data sequences are input into a pre-trained resource usage prediction model based on a temporal neural network model (e.g., a recurrent neural network model and a long short-term memory neural network model) to generate future resource usage sequences.

[0051] The sixth step involves generating device node resource scheduling information for the aforementioned service device node set based on the obtained set of node proximity binding information, the obtained set of future resource usage sequences, and at least one of the aforementioned urgent resource demand information. This device node resource scheduling information can be a scheduling scheme for the computing resources of each service device node in the service device node set.

[0052] Step 7: Perform regional parsing on the aforementioned device node resource scheduling information to generate at least one device node resource scheduling sub-information corresponding to at least one primary service device node. Each primary service device node has corresponding device node resource scheduling sub-information. This sub-information represents the resource scheduling scheme required for each service device node within the region corresponding to the primary service device node.

[0053] Step 8: For each of the above at least one device node resource scheduling sub-information, send the encrypted resource scheduling information corresponding to the above device node resource scheduling sub-information to the corresponding master service device node, so that the master service device node can perform resource scheduling on the corresponding at least one slave service device node.

[0054] In some optional implementations of certain embodiments, after step eight, the steps further include:

[0055] The first step is to acquire, in real time, resource usage anomaly information corresponding to at least one slave service device node sent by at least one master service device node. This resource usage anomaly information may include information about resource scheduling anomalies on the slave service device node. In practice, resource usage anomaly information may include: the cause of the resource anomaly, the solution to the resource anomaly, and the severity of the resource anomaly.

[0056] The second step is to display the abnormal resource usage information for each service device node on the aforementioned resource emergency usage status display page.

[0057] The third step involves generating next-device node resource scheduling information for the aforementioned service device node set based on the updated node proximity binding information set at the current real-time, the updated future resource usage sequence set at the current real-time, and at least one resource emergency demand information. This next-device node resource scheduling information can be a scheduling scheme for computing resources of each service device node in the service device node set at the next possible time.

[0058] The fourth step is to perform regional parsing on the above-mentioned next device node resource scheduling information to generate at least one next device node resource scheduling sub-information corresponding to the above-mentioned at least one main service device node.

[0059] Fifth, for each of the above at least one next device node resource scheduling sub-information, send the resource scheduling encryption information corresponding to the above next device node resource scheduling sub-information to the corresponding master service device node, so that the master service device node can perform resource scheduling on the corresponding at least one slave service device node.

[0060] In some optional implementations of certain embodiments, the execution entity may generate device node resource scheduling information for the service device node set based on the obtained set of node proximity binding information, the obtained set of future resource usage sequences, and at least one resource emergency demand information, including the following steps:

[0061] The first step involves generating a first generation instruction to generate device node resource scheduling information based on the aforementioned set of node proximity binding information, the aforementioned set of future resource usage sequences, and at least one set of urgent resource demand information. This first generation instruction may be a prompt instruction for generating device node resource retrieval information.

[0062] The second step, generating a representation, follows from the initial generation instruction. Since the first generation instruction failed to generate device node resource scheduling information, a second generation instruction is then used to generate the second device node resource scheduling information based on at least one loss constraint and the aforementioned first generation instruction. Here, it means that since the first generation instruction cannot accurately generate device node resource scheduling information, the optimal device node resource scheduling information for the current time is obtained by leveraging the benefits of partial resource demand. In practice, at least one loss constraint can be a constraint that sacrifices some resource demand benefits (i.e., reduces some resource requirements). For example, at least one loss constraint could include: a loss constraint supporting the selection of node locations with a distance greater than the target distance and less than the maximum distance; or a loss constraint supporting the sequential fulfillment of resource needs by at least one resource-urgent node.

[0063] The third step is to input the first and second generation instructions into a pre-trained large language model to generate device node resource scheduling information.

[0064] It should be noted that the aforementioned "optional content," as one of the inventive points of this disclosure, solves the problem of "insufficiently precise and effective resource scheduling among service device nodes in a centralized service device node system, leading to untimely resource provision." Based on this, this application, by judging the distance between node locations and the future usage of resources based on the node distribution map, can achieve effective resource scheduling and rational resource allocation. Furthermore, based on the application of instructions and utilizing a large language model, efficient and accurate generation of device node resource scheduling information can be achieved.

[0065] Step 102: Decrypt each of the state encryption messages in the above-mentioned at least one state encryption message to obtain at least one current node running state.

[0066] In some embodiments, the execution entity may decrypt each of the at least one state encryption information to obtain at least one current node running state. Each state encryption information corresponds to a current node running state. The current node running state may be the running status of the target service device node at the current time.

[0067] As an example, the aforementioned execution entity can decrypt each state encryption information in the above-mentioned at least one state encryption information according to the decryption method corresponding to the encryption algorithm, and obtain at least one current node running state.

[0068] Step 103: For each of the above-mentioned at least one current node running states, perform the following processing steps:

[0069] Step 1031: Perform module state parsing on the current node running state to obtain the current module state set for each running module in the node.

[0070] In some embodiments, the aforementioned execution entity can perform module state parsing on the current node's running state to obtain a set of current module states for each running module within the node. Module state parsing can involve determining the running state of each running module. Each running module can be a module within the target service device node, divided according to its function and running content. In practice, each module can include, but is not limited to, at least one of the following: database, graphics processor, central processing unit, and various application service modules. The current module state can characterize the running status of the module at the current time. In practice, the current module state can be, but is not limited to, at least one of the following: abnormal state, resource emergency state, and normal state.

[0071] As an example, the aforementioned execution entity can use module state parsing regular expressions to parse the current node's running state and obtain the current module state set for each running module in the node.

[0072] Step 1032: Determine the target service device node corresponding to the current node's operating status as the device monitoring node.

[0073] In some embodiments, the aforementioned execution entity can determine the target service device node corresponding to the current node's running status through node query, and use it as a device monitoring node.

[0074] Step 1033: Based on the current module status set, update the display status of each running module in the module status display interface corresponding to the above-mentioned device monitoring node, and generate at least one running alarm information corresponding to the target running module.

[0075] In some embodiments, the execution entity can update the display status of each running module in the module status display interface corresponding to the device monitoring node based on the current module status set, and generate at least one running alarm information corresponding to a target running module. The module status display interface can be an interface displaying the running status of each module corresponding to the device monitoring node. The module status display interface can also be an interface popped up by a relevant click command in the target device status monitoring platform. The running alarm information can be information determining whether at least one target running module has an abnormal state, and information for timely maintenance through alarms when an abnormal state is determined. The at least one target running module is a running module in the device monitoring node that indicates an abnormal operation. In practice, running modules with abnormal operations can be displayed in the module status display interface by highlighting them. For example, the highlighting method can be to display them using a target color and target brightness.

[0076] Step 1034: The above-mentioned operation alarm information is sent to the above-mentioned device monitoring node in an encrypted manner to determine the anomaly of at least one of the above-mentioned target operation modules.

[0077] In some embodiments, the execution entity may send the aforementioned operational alarm information to the aforementioned device monitoring node in an encrypted manner to determine the anomaly of at least one target operating module. The encryption method may utilize a relevant encryption algorithm. Here, anomaly determination is used to determine whether the target operating module is operating abnormally at the current time and whether the anomaly has been resolved.

[0078] Step 1035: In response to determining that at least one of the target operating modules has an operational anomaly and has not been abnormally maintained, the above-mentioned operational alarm information is sent to the module operation and maintenance terminal to perform abnormal maintenance on the at least one target operating module.

[0079] In some embodiments, in response to determining that at least one target operating module is experiencing an operational anomaly and has not undergone abnormal maintenance, the executing entity may send the operational alarm information to the module maintenance terminal to perform abnormal maintenance on the at least one target operating module. The lack of abnormal maintenance may mean that no proactive maintenance has been performed by relevant technical personnel or intelligent machines. The module maintenance terminal may be a terminal that displays and processes module operation and maintenance. For example, the module maintenance terminal may be a handheld communication terminal corresponding to relevant technical personnel, or it may be a terminal for real-time communication between intelligent machines and the target device status monitoring platform.

[0080] In some optional implementations of certain embodiments, after step 1035, the steps further include:

[0081] The first step, in response to determining that at least one of the aforementioned target operating modules does not have any operational abnormalities, is to generate confirmation information for the aforementioned alarm information. This confirmation information may instruct the device inspection node to confirm whether at least one target operating module currently does not have any operational abnormalities.

[0082] The second step involves sending the aforementioned confirmation information to the primary service device node corresponding to the aforementioned device monitoring node. This allows the primary service device node and the aforementioned device monitoring node to confirm the malfunctioning operating module. The primary service device node corresponding to the device monitoring node can be the primary service device node responsible for task management within the region to which the device monitoring node belongs. The confirmation of the malfunctioning operating module between the primary service device node and the aforementioned device monitoring node can be achieved by the primary service device node sending an anomaly confirmation command to the device monitoring node to determine whether at least one target operating module is still malfunctioning.

[0083] Third, in response to the confirmation information indicating that the operation abnormality does not exist, the display status of at least one target operating module in the module status display interface corresponding to the above-mentioned device monitoring node is updated to the normal operating status, and the operation alarm corresponding to at least one target operating module is cancelled.

[0084] Fourth step: In response to determining that at least one target operating module has an operational anomaly and receiving that abnormal maintenance is in progress, receive at least one maintenance personnel code for performing abnormal maintenance on the at least one target operating module. The maintenance personnel code can represent the identity information of the maintenance personnel. At least one maintenance personnel can be any individual currently maintaining at least one target operating module.

[0085] The fifth step is to generate a maintenance progress update upload instruction for at least one maintenance personnel code and at least one target operating module. This maintenance progress update upload instruction can be an instruction message instructing at least one maintenance personnel to upload maintenance progress in real time and to upload maintenance information.

[0086] Step 6: Send the maintenance progress update upload instruction to at least one handheld terminal corresponding to at least one maintenance personnel code. Each maintenance personnel code has a corresponding handheld terminal. The handheld terminal can be the handheld terminal used by the maintenance personnel.

[0087] Step 7: In response to the maintenance progress information sent by the target personnel's handheld terminal indicating that the abnormal maintenance for the target operating module has been completed, update the display status of the target operating module in the module status display interface corresponding to the above-mentioned equipment monitoring node to update it to normal operating status, and cancel the operating alarm corresponding to the target operating module.

[0088] In some optional implementations of certain embodiments, the module maintenance terminal performs the following abnormal maintenance operations on at least one target running module:

[0089] The first step is to parse the operation alarm information to obtain operation anomaly information.

[0090] As an example, the aforementioned executing entity can use a pre-set content parsing script to parse the running alarm information and obtain running exception information.

[0091] The second step involves using a pre-deployed large language model learned through domain knowledge to generate processing information corresponding to the runtime anomaly information. The large language model can be a pre-trained model based on conventional knowledge relevant to the scenario described in this disclosure.

[0092] The third step involves controlling the maintenance equipment to perform automatic anomaly maintenance on the at least one target operating module. This maintenance equipment can be a device that automatically performs anomaly maintenance based on processed information.

[0093] The above embodiments of this disclosure have the following beneficial effects: Through the distributed operation monitoring method of some embodiments of this disclosure, the real-time operation status of each service device node can be monitored in a timely manner by the target device status monitoring platform, so as to perform timely and efficient module-level anomaly maintenance based on abnormal operation status. Specifically, the reason why anomaly maintenance is not timely and efficient when related service device nodes experience module anomalies is that when a service device node malfunctions, the monitoring platform often cannot obtain the anomaly information in a timely manner, and information leakage may occur during the status query process. This results in the malfunctioning device node not receiving effective, more granular module anomaly maintenance, leading to service degradation or overall paralysis. Based on this, the distributed operation monitoring method of some embodiments of this disclosure firstly, in response to determining that the distributed service device node set establishes a communication connection with the target device status monitoring platform, receives at least one encrypted status information representing the node operation status corresponding to at least one target service device node in the aforementioned service device node set. Here, based on the established communication connection between the target device status monitoring platform and the service device node set, by receiving encrypted status information from at least one target service device node in the service device node set that needs to convey its node operating status in real time, it can not only promptly understand the status communication needs of each service device node, but also prevent the leakage of node operating status information through encryption, ensuring the efficiency and confidentiality of real-time communication of node operating status. Then, each of the above-mentioned encrypted status information is decrypted to obtain at least one current node operating status, so that the target device status monitoring platform can understand the real-time node operating status of at least one target service device node. Furthermore, for each of the above-mentioned at least one current node operating status, the following processing steps are performed: First, the current node operating status is parsed to obtain the current module status set for each operating module in the node, so as to accurately obtain the module operating status corresponding to each operating module in the current node operating status, which can be used for subsequent module-level operation and maintenance. Second, the target service device node corresponding to the above-mentioned current node operating status is determined as the device monitoring node. The third step involves updating the display status of each operating module in the module status display interface corresponding to the aforementioned device monitoring nodes based on the current module status set. It also involves generating operational alarm information for at least one target operating module, where each target module is a module in the aforementioned device monitoring nodes that indicates an operational anomaly. Here, the module status display interface is used to show each operating module, allowing the operation and maintenance objects corresponding to the device node set to promptly understand the anomaly status of each operating module in each service device node at the current time. Furthermore, generating operational alarm information enables timely alerts for operating modules exhibiting operational anomalies.The fourth step involves sending the aforementioned operational alarm information in encrypted form to the aforementioned device monitoring nodes to determine the anomaly of at least one target operational module. This verifies whether the at least one target operational module is indeed experiencing an anomaly at that time and whether the anomaly has been resolved in a timely manner. The fifth step, in response to the determination that at least one target operational module is experiencing an operational anomaly and has not undergone anomaly maintenance, involves sending the aforementioned operational alarm information to the module maintenance terminal for accurate and efficient anomaly maintenance of the at least one target operational module. In summary, the target device status monitoring platform can monitor the real-time operational status of each service device node in a timely manner, enabling timely and efficient module-level anomaly maintenance based on abnormal operational status, thus preventing service degradation or overall system failure.

[0094] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a distributed operation monitoring device, which are similar to... Figure 1 Corresponding to the method embodiments shown, this distributed operation monitoring device can be specifically applied to various electronic devices.

[0095] like Figure 2As shown, a distributed operation monitoring device 200 includes a receiving unit 201, a decryption unit 202, and an execution unit 203. The receiving unit 201 is configured to, in response to establishing a communication connection between a distributed set of service device nodes and a target device status monitoring platform, receive at least one encrypted status information representing the node operation status corresponding to at least one target service device node in the service device node set. The decryption unit 202 is configured to decrypt each of the at least one encrypted status information to obtain at least one current node operation status. The execution unit 203 is configured to, for each of the at least one current node operation statuses, perform the following processing steps: perform module status parsing on the current node operation status to obtain a set of current module statuses for each operating module in the node; determine the current node operation status... The target service device node corresponding to the current module status is designated as the device monitoring node. Based on the current module status set, the display status of each running module in the module status display interface corresponding to the device monitoring node is updated, and at least one running alarm message corresponding to a target running module is generated. The at least one target running module is a running module in the device monitoring node that indicates an abnormal operation. The running alarm message is sent to the device monitoring node in an encrypted manner to determine the abnormality of the at least one target running module. In response to determining that the at least one target running module has an abnormal operation and has not been abnormally maintained, the running alarm message is sent to the module operation and maintenance terminal to perform abnormal maintenance on the at least one target running module.

[0096] It is understandable that the units described in the distributed operation monitoring device 200 are related to the reference. Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the distributed operation monitoring device 200 and the units contained therein, and will not be repeated here.

[0097] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device (e.g., an electronic device) 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0098] like Figure 3As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0099] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0100] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0101] It should be noted that, in some embodiments of this disclosure, the computer-readable medium described above may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0102] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0103] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: in response to determining that a distributed set of service device nodes establishes a communication connection with a target device status monitoring platform, receive at least one encrypted status information representing the node operating status corresponding to at least one target service device node in the aforementioned service device node set; decrypt each of the at least one encrypted status information to obtain at least one current node operating status; for each of the at least one current node operating statuses, perform the following processing steps: perform module status parsing on the current node operating status to obtain a current module status set for each operating module in the node; determine the current node operating status set; and determine the current node operating status set for each operating module in the node. The target service device node corresponding to the running status of the previous node serves as the device monitoring node. Based on the current module status set, the display status of each running module in the module status display interface corresponding to the device monitoring node is updated, and at least one running alarm message corresponding to a target running module is generated. The at least one target running module is a running module in the device monitoring node that indicates an abnormal operation. The running alarm message is sent to the device monitoring node in an encrypted manner to determine the abnormality of the at least one target running module. In response to determining that the at least one target running module has an abnormal operation and has not been abnormally maintained, the running alarm message is sent to the module operation and maintenance terminal to perform abnormal maintenance on the at least one target running module.

[0104] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0105] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0106] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a receiving unit, a decryption unit, and an execution unit. The names of these units do not necessarily limit the unit itself; for example, a decryption unit may be described as "a unit that decrypts each of the state encryption messages in the at least one state encryption message to obtain at least one current node running state."

[0107] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0108] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A distributed operation monitoring method, comprising: in response to determining that a distributed set of service device nodes establishes a communication connection with a target device state monitoring platform, receiving at least one state encryption information representing a node operation state of at least one target service device node in the set of service device nodes; decrypting each state encryption information in the at least one state encryption information to obtain at least one current node operation state; for each current node operation state in the at least one current node operation state, performing the following processing steps: performing module state analysis on the current node operation state to obtain a current module state set for each running module in the node, the module state analysis being used to determine the running state of each running module; determining the target service device node corresponding to the current node operation state as a device monitoring node; updating the display state of each running module in a module state display interface corresponding to the device monitoring node according to the current module state set, and generating running alarm information corresponding to at least one target running module, wherein the at least one target running module is a running module in the device monitoring node that represents an existence of a running exception; sending the running alarm information to the device monitoring node in an encrypted manner to determine an exception of the at least one target running module, the exception determination being used to determine whether the target running module exists an abnormal running at a current time and whether the abnormality has been resolved; in response to determining that the at least one target running module exists an abnormal running and has not been maintained abnormally, sending the running alarm information to a module operation and maintenance terminal to maintain the at least one target running module abnormally.

2. The method of claim 1, wherein, The set of service device nodes includes at least one master service device node; and The at least one state encryption information is generated by the following steps: for each master service device node in the at least one master service device node, performing the following determination steps: determining a set of pre-registered slave service device nodes corresponding to the master service device node; sending node state acquisition information to the set of slave service device nodes periodically; receiving a set of real-time states sent by the set of slave service device nodes; removing slave service device nodes representing an absence of an abnormal real-time state from the set of slave service device nodes to obtain a removed set of slave service device nodes; generating a state acquisition log corresponding to the removed set of slave service device nodes; encrypting a subset of real-time states corresponding to the removed set of slave service device nodes and the state acquisition log to obtain state encryption information.

3. The method of claim 2, wherein, After the step of sending the running alarm information to the module operation and maintenance terminal to maintain the at least one target running module abnormally in response to determining that the at least one target running module exists an abnormal running and has not been maintained abnormally, the method further comprises: in response to determining that the at least one target running module does not exist an abnormal running, generating confirmation information for the alarm information; sending the confirmation information to a master service device node corresponding to the device monitoring node, so that the master service device node and the device monitoring node confirm the running module with the operation exception; in response to determining that the reply information corresponding to the confirmation information represents that the operation exception does not exist, updating the display state of at least one target running module in the module state display interface corresponding to the device monitoring node to update to a normal operation state, and canceling the running alarm corresponding to the at least one target running module; in response to determining that the at least one target running module has an operation exception and receiving that the abnormal maintenance is in progress, receiving at least one maintenance personnel code for performing abnormal maintenance on the at least one target running module; generating a maintenance progress update upload instruction for the at least one maintenance personnel code and the at least one target running module; sending the maintenance progress update upload instruction to at least one target personnel handheld terminal corresponding to the at least one maintenance personnel code; in response to the maintenance progress information sent by the target personnel handheld terminal representing that the abnormal maintenance for the target running module has been completed, updating the display state of the target running module in the module state display interface corresponding to the device monitoring node to update to a normal operation state, and canceling the running alarm corresponding to the target running module.

4. The method of claim 2, wherein, The target device state monitoring platform has a set of node codes corresponding to the set of service device nodes being maintained in real time, a master service device node in the at least one master service device node has a one-to-one correspondence with a device area in at least one device area, the target device state monitoring platform has at least one area code corresponding to the at least one device area being maintained in real time, the target device state monitoring platform has a plurality of module codes corresponding to a plurality of running modules being maintained in real time, the target device state monitoring platform has a plurality of running state codes corresponding to a plurality of running modules, and the target device state monitoring platform has a node behavior adjustment code corresponding to each service device node.

5. The method of claim 1, wherein, The module operation and maintenance terminal performs the following abnormal maintenance operations on at least one target running module: performing content analysis on the running alarm information to obtain running exception information; using a pre-deployed large language model learned through domain knowledge to generate processing information corresponding to the running exception information; controlling the maintenance machine device to automatically maintain the at least one target running module.

6. A distributed running monitoring device, comprising: a receiving unit configured to receive at least one state encryption information representing a node running state corresponding to at least one target service device node in a set of distributed service device nodes in response to determining that the set of service device nodes establish a communication connection with a target device state monitoring platform; a decryption unit configured to decrypt each state encryption information in the at least one state encryption information to obtain at least one current node running state; The execution unit is configured to perform the following processing steps for each of the at least one current node running state: performing module state analysis on the current node running state to obtain a current module state set for each running module in the node, the module state analysis being used to determine the running state of each of the running modules; determining a target service device node corresponding to the current node running state as a device monitoring node; According to the current module state set, updating the display state of each running module in the module state display interface corresponding to the device monitoring node, and generating running alarm information corresponding to at least one target running module, wherein the at least one target running module is a running module in the device monitoring node that represents an existing running exception; sending the running alarm information to the device monitoring node in an encrypted manner to determine the exception of the at least one target running module, the exception determination being used to determine whether the target running module exists an abnormal running at the current time and whether the abnormality has been solved; in response to determining that the at least one target running module exists an abnormal running and has not been maintained, sending the running alarm information to a module operation and maintenance terminal to maintain the at least one target running module. 7.An electronic device, comprising: one or more processors; a memory device having stored thereon one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the method of any one of claims 1-5.

8. A computer readable medium having stored thereon a computer program, wherein, The program is executed by the processor to implement the method of any one of claims 1-5.

Images