Plug-in running state monitoring method, computer cluster system and electronic device

Abstract

The application discloses a plug-in running state monitoring method, a computer cluster system, an electronic device, a computer readable storage medium and a computer program product. The plug-in running state monitoring method comprises the following steps: scanning file paths of each plug-in in a cloud server according to a first period, and obtaining a timestamp file. The timestamp file stores a timestamp refreshed according to a second period. The first period is greater than the second period. The timestamp in the timestamp file is read, and the latest update time of a target plug-in is determined according to the timestamp. The running state of the target plug-in at the current time is determined according to the latest update time of the target plug-in. Compared with calling a plug-in interface, reading the timestamp file has smaller computational resource consumption of the cloud server, supports higher frequency reporting, solves the problem that the running state monitoring capability of the installed plug-in in the cloud server is weak, and improves the running state reporting frequency of the installed plug-in in the cloud server.

Description

Technical Field

[0001] This application relates to the field of cloud computing, and more specifically, to a method for monitoring the runtime status of a plug-in, a computer cluster system, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] In cloud servers, plugins can be installed to achieve corresponding functions. In practical applications, users need to check the plugin's running status. To achieve this, in cloud servers, relevant tools are typically used to periodically call the plugin's interface to obtain its running status. However, interface calls consume cloud server computing resources, putting pressure on the server. To reduce this pressure, the frequency of plugin running status reporting is usually limited; however, limiting the reporting frequency cannot meet the requirement of reporting plugin running status at a higher frequency.

[0004] Currently, no effective solution has been proposed to address the issue of weak monitoring capabilities for the operational status of plugins installed on cloud servers in related technologies. Summary of the Invention

[0005] This application provides a method for monitoring the runtime status of plugins, a computer cluster system, an electronic device, a computer-readable storage medium, and a computer program product to address the problem of weak monitoring capabilities for the runtime status of plugins installed on cloud servers in related technologies.

[0006] According to one aspect of the embodiments of this application, a method for monitoring the runtime status of a plugin is provided, including: According to the first cycle, the file paths of each plugin in the cloud server are scanned to obtain the timestamp file, wherein the timestamp file stores timestamps refreshed according to the second cycle, and the first cycle is longer than the second cycle; Read the timestamps from the timestamp file and determine the most recent update time of the target plugin based on the timestamps; Based on the latest update time of the target plugin, determine the running status of the target plugin at the current moment; Send the current running status of the target plugin to the cloud management system.

[0007] In some embodiments, determining the current running state of the target plugin based on its most recent update time includes: Determine the first time difference between the most recent update time of the target plugin and the current time; The first time difference is compared with the preset update cycle of the target plugin, and the result of the comparison determines whether the target plugin is running at the current moment.

[0008] In some embodiments, the current running status of the target plugin is sent to the cloud management system, including: Retrieve the saved running state of the target plugin at the previous moment; If the target plugin's running state is inconsistent between the current moment and the previous moment, the determined running state at the current moment is sent to the cloud management system, and the determined running state at the current moment is saved.

[0009] In some embodiments, the method further includes: The preset interfaces of each plugin in the cloud server are called according to the third cycle to obtain the running status of each plugin at the current moment, wherein the first cycle is shorter than the third cycle; The current running status of each plugin is sent to the cloud management system.

[0010] In some embodiments, the current running status of each plugin is sent to the cloud management system, including: If the timestamp file is obtained through scanning, the current running status of the plugin, determined by the timestamp file, is sent to the cloud management system. If the timestamp file cannot be found, the current running status of the plugin, obtained by calling the preset interface, will be sent to the cloud management system.

[0011] In some embodiments, the cloud management system sends records of the plugin's running status according to a fourth cycle, and the method further includes: Determine the time when the running status of the target plugin was last sent; Determine the second time difference between the most recent running status sending time of the target plugin and the preset query time; The second time difference is compared with the preset running status sending cycle of the target plugin, and the running status of the target plugin being sent is determined based on the comparison result.

[0012] According to another aspect of the embodiments of this application, a computer cluster system is provided, including: a cloud server and a cloud management system. The cloud server is equipped with a plug-in management module, which is capable of executing the above-described plug-in running status monitoring method to monitor the running status of plug-ins installed in the cloud server and sending the monitoring results to the cloud management system.

[0013] According to another aspect of the embodiments of this application, an electronic device is provided, including: a processor; and a memory storing a program, the program including instructions that, when executed by the processor, cause the processor to perform the steps of the above-described plug-in running status monitoring method.

[0014] According to another aspect of the embodiments of this application, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause the computer to perform the steps of the above-described plug-in running status monitoring method.

[0015] According to another aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, which, when executed by a processor, implements the steps of the above-described plug-in running status monitoring method.

[0016] The plugin runtime status monitoring method, computer cluster system, electronic device, computer-readable storage medium, and computer program product provided in this application embodiment include: scanning the file paths of each plugin in the cloud server according to a first cycle to obtain a timestamp file, wherein the timestamp file stores timestamps refreshed according to a second cycle, and the first cycle is greater than the second cycle; reading the timestamps in the timestamp file and determining the most recent update time of the target plugin based on the timestamps; and determining the runtime status of the target plugin at the current moment based on the most recent update time of the target plugin. Compared with calling the plugin interface, reading the timestamp file incurs less computational resource overhead on the cloud server, supports higher reporting frequency, solves the problem of weak runtime status monitoring capability of plugins installed on the cloud server, and improves the reporting frequency of runtime status of plugins installed on the cloud server while ensuring the stable operation of the cloud server. Attached Figure Description

[0017] Further details, features, and advantages of this disclosure are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 This is a schematic diagram of the architecture of a computer cluster system in one embodiment; Figure 2 This is a flowchart of a plugin runtime status monitoring method in one embodiment; Figure 3This is a flowchart of a plugin runtime status monitoring method in another embodiment; Figure 4 This is a flowchart of a plugin runtime status monitoring method in another embodiment; Figure 5 This is a structural block diagram of an electronic device in one embodiment. Detailed Implementation

[0018] 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.

[0019] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0020] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first", "second", etc., used in this disclosure are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0021] 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".

[0022] 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.

[0023] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0024] In one embodiment, a computer cluster system is provided. Figure 1 This is a schematic diagram of the architecture of the computer cluster system in this embodiment. The computer cluster system can also be referred to as a cloud platform, such as... Figure 1 As shown, the cloud platform includes a cloud server and a cloud management system. The cloud server is equipped with a plugin management module, which can execute a plugin running status monitoring method to monitor the running status of the plugins installed on the cloud server and send the monitoring results to the cloud management system.

[0025] A cloud server provides cloud computing services and can include functional components such as instances, images, block storage, security groups, snapshots, and networks. An instance is essentially a virtual server, containing basic computing components such as vCPU, memory, operating system, network configuration, and disk. An image is like a "installation disk," providing the instance with an operating system and pre-installed software. Block storage is a distributed data storage device used for data storage and allows random read / write access. A security group is a virtual firewall that divides security isolation zones and implements network access control. A snapshot is a real-time copy of a cloud disk at a specific point in time, which can be used for data backup, recovery, application disaster recovery, and image creation. A network can be a Virtual Private Cloud (VPC), a logically completely isolated private network in the cloud.

[0026] The cloud management system is used to manage cloud servers. It utilizes QEMU's virtio-port mechanism to enable communication between the host machine and the cloud server, thereby completing the installation of the plugin management module. QEMU's virtio-port mechanism: When a cloud server is created, a character device is generated inside the cloud server, and a corresponding socket file is also generated on the host machine. The installation of the plugin management module is executed through this mechanism.

[0027] The plugin management module is an automated operation and maintenance tool that can be installed on cloud servers. It enables batch operation and maintenance, command execution (Shell, PowerShell, and Bat), and file transfer within cloud server instances without requiring passwords, logins, or jump servers. Use cases include: installing and uninstalling software, starting or stopping services, distributing configuration files, and executing general commands (or scripts).

[0028] Plugins encapsulate commonly used scripts and tools for cloud server operations and maintenance, enabling complex configuration operations to be completed with simple commands, thus improving operational efficiency. Plugins include resident plugins, which can run as persistent processes within the cloud server instance to enhance plugin availability.

[0029] In practical applications, to monitor the runtime status of plugins installed on cloud servers, a plugin management module can periodically call the plugin's interface to obtain its runtime status and send it to the cloud management system. However, interface calls consume cloud server computing resources, putting pressure on the server. To reduce this pressure, the reporting frequency of plugin runtime status is usually limited. However, limiting the reporting frequency cannot meet the requirement of reporting plugin runtime status at a higher frequency.

[0030] To address the aforementioned issues, this embodiment provides a method for monitoring the runtime status of a plugin. Figure 2 This is a flowchart of the plugin runtime status monitoring method in this embodiment. The method runs in... Figure 1 The process, executed on a cloud server and managed by the plugin management module, includes the following steps: Step S201: Scan the file paths of each plugin in the cloud server according to the first cycle to obtain the timestamp file. The timestamp file stores timestamps refreshed according to the second cycle, where the first cycle is greater than the second cycle.

[0031] A timestamp file is used to maintain timestamps and can be refreshed in seconds. Timestamps include, but are not limited to, UTC (Universal Time Coordinated), GMT (Greenwich Mean Time), Unix (Unix timestamp, the number of seconds elapsed since January 1, 1970 (midnight UTC / GMT), and CET (Central European Time). A first cycle greater than a second cycle indicates that the timestamp refresh frequency is higher than the plugin's scanning frequency, thus meeting the scanning requirements. For plugins with high requirements for runtime status reporting frequency, a timestamp file can be created in the plugin's file path (i.e., the plugin directory) to maintain a single timestamp. The timestamps in the timestamp file are refreshed according to a custom first cycle. The plugin management module periodically scans the file paths in each plugin directory to obtain the timestamp file.

[0032] Step S202: Read the timestamps from the timestamp file and determine the most recent update time of the target plugin based on the timestamps.

[0033] Step S203: Determine the running status of the target plugin at the current moment based on the latest update time of the target plugin.

[0034] After the plugin management module scans and obtains the timestamps from the timestamp file, it determines the first time difference between the target plugin's most recent update time and the current time. This first time difference is compared with the target plugin's preset update cycle. Based on the comparison result, it determines whether the target plugin is currently running. If the first time difference is greater than the target plugin's preset update cycle, the target plugin is determined to be in a stagnant state at the current time; otherwise, if the first time difference is not greater than the target plugin's preset update cycle, the target plugin is determined to be running at the current time. Step S204: Send the current running status of the target plugin to the cloud management system.

[0035] In this embodiment, if the plugin's running status is obtained by calling the plugin interface and then sent to the cloud management system, the computational resource overhead of the plugin interface call on the cloud server is relatively large. To balance the execution of the cloud server's own services and the reporting of the plugin's running status, a relatively generous reporting cycle is set, such as reporting the plugin's running status every 15 minutes. However, obtaining the plugin's running status by reading a timestamp file and then sending it to the cloud management system incurs less computational resource overhead on the cloud server compared to calling the plugin interface, allowing for a shorter reporting cycle, such as reporting the plugin's running status every 5 minutes. Through these steps, the problem of weak monitoring capability of the running status of plugins installed on the cloud server is solved, and the frequency of reporting the running status of plugins installed on the cloud server is increased while ensuring the stable operation of the cloud server.

[0036] In one embodiment, sending the current running status of the target plugin to the cloud management system can be achieved through the following method: The system retrieves the saved running status of the target plugin at the previous moment. If the running status of the target plugin at the current moment is inconsistent with that at the previous moment, the determined running status at the current moment is sent to the cloud management system and saved. Optionally, if the running status of the target plugin at the current moment is consistent with that at the previous moment, the determined running status at the current moment is not reported. In this embodiment, the plugin management module saves the running status of each plugin obtained last time, compares the running status of the plugin obtained this time with that obtained last time, and only reports the running status when the running status of the plugin obtained in the two times is inconsistent. This setting realizes lazy reporting of plugin running status to save communication traffic resources between the cloud server and the cloud management system.

[0037] In one embodiment, another method for monitoring the runtime status of a plugin is provided. Figure 3 This is a flowchart of the plugin runtime status monitoring method in this embodiment, as follows: Figure 3 As shown, the process includes the following steps: Step S301: Scan the file paths of each plugin in the cloud server according to the first cycle to obtain the timestamp file. The timestamp file stores timestamps refreshed according to the second cycle, where the first cycle is greater than the second cycle. Step S302: Read the timestamps from the timestamp file and determine the latest update time of the target plugin based on the timestamps; Step S303: Determine the running status of the target plugin at the current moment based on the latest update time of the target plugin; Step S304: Send the current running status of the target plugin to the cloud management system; Step S305: Call the preset interfaces of each plugin in the cloud server according to the third cycle to obtain the running status of each plugin at the current moment. The first cycle is shorter than the third cycle. Step S306: Send the current running status of each plugin to the cloud management system.

[0038] In this embodiment, the plugin management module reports the plugin's running status in two ways, steps S301 and S305. These steps are executed in parallel, with no fixed order. Steps S301 to S304 are the preferred method, i.e., reporting by reading a timestamp file as provided in the previous embodiment. Steps S305 to S306 are the fallback method, i.e., reporting by calling the plugin interface. These two methods are executed in parallel without a fixed order. The preferred method will not be elaborated upon in this embodiment. For the fallback method, for example, the plugin management module periodically calls the Status interface defined as Status in the plugin and determines the plugin's running status based on its exit code. The relationship between the exit code and the plugin's running status is: 0 - PERSIST_RUNNING, 1 - PERSIST_FAIL. Here, PERSIST_RUNNING represents that the plugin is running, and PERSIST_FAIL represents that the plugin is stalled. Considering that each batch call to the plugin interface will start a process and consume system performance, the period for this method is set to a relatively long time (e.g., 15 minutes) as a fallback method for reporting the plugin's running status.

[0039] In one embodiment, sending the current running status of each plugin to the cloud management system includes: if a timestamp file is obtained by scanning, sending the current running status of the plugin determined by the timestamp file to the cloud management system; if no timestamp file is found, sending the current running status of the plugin obtained by calling a preset interface to the cloud management system. In this embodiment, the preferred method has a higher priority than the fallback method. For example, Figure 4 This is a flowchart of the plugin runtime status monitoring method in this embodiment, as follows: Figure 4 As shown, the process includes the following steps: Step S401: Scan the file paths of each plugin in the cloud server according to the first cycle. Step S402: Determine whether a timestamp file has been obtained by scanning; if yes, proceed to step S403; if no, proceed to step S408. Step S403: Obtain a timestamp file, wherein the timestamp file stores timestamps refreshed according to the second cycle, and the first cycle is greater than the second cycle; Step S404: Read the timestamps from the timestamp file and determine the most recent update time of the target plugin based on the timestamps; Step S405: Determine the running status of the target plugin at the current moment based on the latest update time of the target plugin; Step S406: Send the current running status of the target plugin to the cloud management system; Step S407: Call the preset interfaces of each plugin in the cloud server according to the third cycle to obtain the running status of each plugin at the current moment. The first cycle is shorter than the third cycle. Step S408: Send the current running status of each plugin to the cloud management system.

[0040] In this embodiment, steps S401 and S407 are not sequential and are executed in parallel. Since the plugin management module's 15-minute plugin status reporting cannot meet the relevant requirements, in addition to the method of obtaining the plugin's running status by calling the plugin interface and then reporting it, a method of reading the plugin's timestamp file to determine the plugin's running status before reporting is added. The plugin management module calls the plugin interface to obtain the plugin's running status and reports it to the cloud management system every 15 minutes as a fallback method; the plugin management module reads the timestamp file to obtain the plugin's running status and reports it to the cloud management system every 5 minutes as a preferred method to meet the needs of some plugins that require high-frequency status updates. If the plugin has created a timestamp file in its own file path, the plugin's running status will be reported in the preferred method, i.e., the plugin management module reads the timestamp file to obtain the plugin's running status and reports it. If the plugin's file path does not have the timestamp file, the plugin's running status will only be reported in the fallback method, i.e., the plugin management module calls the plugin interface to obtain the plugin's running status and reports it. Prioritize ensuring cloud server performance. Adjust the frequency of the plugin management module scanning timestamp files or calling plugin APIs to obtain plugin running status in real time based on cloud server performance. The plugin management module's call to the plugin API serves as a fallback mechanism. Reading timestamp files has less overhead than calling plugin APIs, so it can be initially set to report every 5 minutes, and then gradually adjusted based on the pressure on the cloud server.

[0041] In one embodiment, if the plugin management module fails to send a request to the cloud management system, it can retry, for example, 3 times. If the current reporting request fails, it can continue to report next time, regardless of whether the plugin's running status changes.

[0042] The two reporting methods described above operate in parallel. The fallback method reports the status of all plugins, while the preferred method only reports the status of resident plugins with timestamped files in the specified file path. Both reporting methods call the same cloud management system interface, and the data format is consistent. The reporting period for each method is independently controlled by two fields returned by the cloud management system. Simultaneous reporting by both methods is avoided. If they happen to overlap, the second method will be staggered from the first method by a certain time interval (1 minute). The plugin file path refers to the file path containing the plugin's config file. After a plugin is uninstalled, the plugin management module will explicitly report the uninstallation status (REMOVED) to the cloud server management system upon the next scan if it detects that the plugin has been uninstalled.

[0043] In one embodiment, the cloud management system queries the plugin's running status sending record according to the fourth cycle. The plugin management module will also determine the time when the target plugin's running status was last sent; determine the second time difference between the target plugin's most recent running status sending time and the preset query time; compare the second time difference with the target plugin's preset running status sending cycle, and determine whether the sent target plugin's running status is true based on the comparison result.

[0044] Optionally, if the second time difference is greater than the preset running status transmission period of the target plugin, the transmitted running status of the target plugin is determined to be false, and the running status of the plugin at the current moment is determined based on the previously reported data. If the second time difference is not greater than the preset running status transmission period of the target plugin, the transmitted running status of the target plugin is determined to be true, that is, the running status of the plugin at the current moment is determined based on the currently reported data. The comparison result between the second time difference and the preset running status transmission period is allowed to have a certain time error, for example, a deviation of 60 seconds.

[0045] In this embodiment, the plugin running status reported by the plugin management module is combined with the processing logic of the cloud management system to form the final state of the plugin. The processing logic of the cloud management system will be described below.

[0046] If there are no reported records, it means the cloud server has not installed the specified plugin, and the plugin's running status is NotInstalled. If the time difference between the current query time and the plugin management module's most recent report of the plugin's running status is <= (plugin management module's periodic reporting frequency + 60-second error), it means the plugin management module is reporting normally, and the result reported by the plugin management module will be used as the plugin's final status: for example, Stopped, Running, Removed, or Installed (one-time plugin installed). If the time difference between the current query time and the plugin management module's most recent report of the plugin's running status is > (plugin management module's periodic reporting frequency + 60-second error): if the previous reported status was Removed, then this time it will still be Removed; if the previous reported status was Stopped, then this time it will still be Stopped; if the previous reported status was Installed, then this time instance diagnosis will be performed. Instance diagnostics include: instance release, plugin running status is Removed; instance not running, plugin running status is Stopped; instance booted within 1 minute, plugin running status is Stopped; instance is normal but plugin management module is abnormal, plugin running status is Unknown.

[0047] Exemplary embodiments of this disclosure also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform a plug-in operation status monitoring method according to embodiments of this disclosure.

[0048] Exemplary embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a plug-in operation status monitoring method according to embodiments of this disclosure.

[0049] Exemplary embodiments of this disclosure also provide a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a plug-in runtime status monitoring method according to embodiments of this disclosure.

[0050] refer to Figure 5 The present invention describes a structural block diagram of an electronic device 500 that can serve as a server or client of the present disclosure, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0051] like Figure 5 As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0052] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, output unit 507, storage unit 508, and communication unit 509. Input unit 506 can be any type of device capable of inputting information to electronic device 500. Input unit 506 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 507 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 508 may include, but is not limited to, disk and optical disk. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0053] The computing unit 501 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, CPUs, graphics processing units (GPUs), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above. For example, in some embodiments, the aforementioned cloud desktop encoding method, cloud desktop reconstruction method, or cloud desktop display method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. In some embodiments, the computing unit 501 can be configured to perform the cloud desktop encoding method, cloud desktop reconstruction method, or cloud desktop display method by any other suitable means (e.g., by means of firmware).

[0054] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0055] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, 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 devices, magnetic storage devices, or any suitable combination of the foregoing.

[0056] As used in this disclosure, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0057] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0058] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0059] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0060] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for monitoring the running status of a plug-in, characterized in that, The method includes: According to the first cycle, the file paths of each plugin in the cloud server are scanned to obtain the timestamp file, wherein the timestamp file stores timestamps refreshed according to the second cycle, and the first cycle is longer than the second cycle; Read the timestamps from the timestamp file and determine the most recent update time of the target plugin based on the timestamps; Based on the latest update time of the target plugin, determine the running status of the target plugin at the current moment; Send the current running status of the target plugin to the cloud management system; Based on the target plugin's most recent update time, determine the target plugin's current running status, including: Determine the first time difference between the most recent update time of the target plugin and the current time; The first time difference is compared with the preset update cycle of the target plugin, and the result of the comparison determines whether the target plugin is running at the current moment.

2. The plug-in running status monitoring method according to claim 1, characterized in that, Sending the current running status of the target plugin to the cloud management system, including: Retrieve the saved running state of the target plugin at the previous moment; If the target plugin's running state is inconsistent between the current moment and the previous moment, the determined running state at the current moment is sent to the cloud management system, and the determined running state at the current moment is saved.

3. The plug-in running status monitoring method according to claim 1, characterized in that, The method further includes: The preset interfaces of each plugin in the cloud server are called according to the third cycle to obtain the running status of each plugin at the current moment, wherein the first cycle is shorter than the third cycle; The current running status of each plugin is sent to the cloud management system.

4. The plug-in running status monitoring method according to claim 3, characterized in that, Sending the current running status of each plugin to the cloud management system, including: If the timestamp file is obtained through scanning, the current running status of the plugin, determined by the timestamp file, is sent to the cloud management system. If the timestamp file cannot be found, the current running status of the plugin, obtained by calling the preset interface, will be sent to the cloud management system.

5. The plug-in running status monitoring method according to claim 1, characterized in that, The cloud management system sends records according to the fourth cycle query of the plugin's running status, and the method further includes: Determine the time when the running status of the target plugin was last sent; Determine the second time difference between the most recent running status sending time of the target plugin and the preset query time; The second time difference is compared with the preset running status sending cycle of the target plugin, and the running status of the target plugin being sent is determined based on the comparison result.

6. A computer cluster system, characterized in that, include: A cloud server and a cloud management system, wherein the cloud server is equipped with a plug-in management module, the plug-in management module is capable of executing the plug-in running status monitoring method according to any one of claims 1 to 5, monitoring the running status of the plug-ins installed in the cloud server, and sending the monitoring results to the cloud management system.

7. An electronic device, comprising: processor; And a memory for storing a program, characterized in that the program includes instructions that, when executed by the processor, cause the processor to perform the steps of the plug-in running status monitoring method according to any one of claims 1 to 5.

8. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the steps of the plug-in running status monitoring method according to any one of claims 1 to 5.

9. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the plug-in running status monitoring method according to any one of claims 1 to 5.

Images