System monitoring and upgrading method, electronic device and computer readable storage medium

Abstract

The application discloses a system monitoring and upgrading method, an electronic device and a computer readable storage medium. The method comprises the following steps: obtaining a starting instruction, executing the starting instruction to start a monitoring process of a system, starting each sub-service in the system by using the monitoring process, and performing health monitoring on each sub-service to obtain at least one round of health monitoring result; in response to the health monitoring result of a first preset round being abnormal, restarting the system; in response to an upper application of the system calling an application program interface, obtaining an upgrade package of the system by using the application program interface, backing up a current installation package of the system to obtain a backup version, loading the upgrade package by using a timing task of the system to upgrade the system, restarting the system after the upgrade is completed, and returning to the step of obtaining the starting instruction; and in response to the health monitoring result of a second preset round being abnormal, rolling back the system to the backup version, wherein the second preset round is after the system is upgraded. The above scheme can improve the convenience and stability of the system.

Description

Technical Field

[0001] This application relates to the field of system management technology, and in particular to a system monitoring and upgrade method, electronic device, and computer-readable storage medium. Background Technology

[0002] As systems become increasingly powerful, the importance of system health monitoring and upgrades after feature updates is growing. Current technologies typically require system developers to periodically monitor the system, obtaining data to determine its health. Furthermore, upgrades require developers to access the server-side support and specify upgrade packages, making health monitoring and upgrades inconvenient. Additionally, there's a lack of necessary methods to verify upgrade package compatibility, potentially leading to unusable upgraded systems and compromised stability. Therefore, improving system usability and stability has become a pressing issue. Summary of the Invention

[0003] The main technical problem addressed by this application is to provide a system monitoring and upgrade method, electronic device, and computer-readable storage medium that can improve the ease of use and stability of the system.

[0004] To address the aforementioned technical problems, this application provides a system monitoring and upgrade method, comprising: obtaining a startup command; executing the startup command to start a system monitoring process; using the monitoring process to start various sub-services in the system and performing health monitoring on each sub-service to obtain at least one round of health monitoring results; in response to an abnormal health monitoring result in a first preset round, restarting the system; in response to an upper-layer application of the system calling an application programming interface (API), using the API to obtain an upgrade package for the system, backing up the current installation package of the system to obtain a backup version, using a scheduled task of the system to load the upgrade package to upgrade the system, restarting the system after the upgrade is completed, and returning to the step of obtaining the startup command; in response to an abnormal health monitoring result in a second preset round, rolling back the system to the backup version, wherein the second preset round occurs after the system upgrade.

[0005] To address the aforementioned technical problems, a second aspect of this application provides an electronic device comprising: a memory and a processor coupled to each other, wherein the memory stores program data, and the processor invokes the program data to execute the method described in the first aspect.

[0006] To solve the above-mentioned technical problems, a third aspect of this application provides a computer storage medium storing program data thereon, wherein the program data, when executed by a processor, implements the method described in the first aspect.

[0007] The above scheme, upon receiving the startup command, executes the command to initiate the system's monitoring process. This monitoring process then starts each sub-service of the system and performs health monitoring on each sub-service. This allows for immediate health monitoring after system startup, obtaining at least one round of health monitoring results using only the monitoring process, thus improving the convenience of system health monitoring. If the first preset round of health monitoring results is abnormal, the system is restarted to attempt to restore system functionality, improving system stability. When the upper-layer application calls the application programming interface (API), the API is used to obtain the system's upgrade package, enabling users to independently obtain the upgrade package, improving the convenience of obtaining the upgrade package. Simultaneously, the current system installation package is backed up, obtaining a backup version. The system's scheduled task then loads the upgrade package to upgrade the system. The scheduled task ensures accurate acquisition of the system upgrade package for system upgrades. After the upgrade is complete, the system is restarted to continue health monitoring. If the second preset round of health monitoring results obtained after the system upgrade is abnormal, the system is rolled back to the backup version to ensure continued system usability, thereby improving the convenience and stability of system use. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:

[0009] Figure 1 This is a flowchart illustrating one implementation method of the system monitoring and upgrade method of this application;

[0010] Figure 2 This is a flowchart illustrating another implementation of the system monitoring and upgrade method of this application;

[0011] Figure 3 This is a flowchart illustrating yet another implementation of the system monitoring and upgrade method of this application;

[0012] Figure 4 This is a schematic diagram of the structure of one embodiment of the electronic device of this application;

[0013] Figure 5 This is a schematic diagram illustrating an application scenario of one implementation method of the system monitoring and upgrade method of this application;

[0014] Figure 6 This is a schematic diagram of one embodiment of the computer-readable storage medium of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0016] In this paper, the terms "system" and "network" are often used interchangeably. The term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this paper means two or more.

[0017] The system monitoring and upgrade method provided in this application is used to perform health monitoring and system upgrades on the user's system. The execution entity corresponding to the system monitoring and upgrade method is the processor or processing module of the user's system.

[0018] Please see Figure 1 , Figure 1 This is a flowchart illustrating one implementation method of the system monitoring and upgrade method of this application. The method includes:

[0019] S101: Obtain the startup command, execute the startup command to start the system's monitoring process, use the monitoring process to start each sub-service in the system, and perform health monitoring on each sub-service to obtain at least one round of health monitoring results.

[0020] Specifically, when a startup command is received, the startup command is executed to start the system's monitoring process. The monitoring process is then used to start various sub-services in the system and to perform health monitoring on each sub-service. This allows for immediate health monitoring of the system after startup, and the health monitoring results can be obtained using only the monitoring process, thus improving the convenience of health monitoring of the system.

[0021] Furthermore, when the monitoring process completes a health monitoring of all sub-services in the system, it is considered to have completed one round of health monitoring and obtained one round of health monitoring results.

[0022] In one application mode, after the startup command is triggered, the startup command is obtained and executed. Based on the startup command, the system's monitoring process is started. The monitoring process is used to start various sub-services in the system. Each sub-service sends a lifecycle signal to the monitoring process. The monitoring process monitors the lifecycle signals of each sub-service. Based on the lifecycle signals of each sub-service, health monitoring is performed on each sub-service, thereby obtaining at least one round of health monitoring results.

[0023] In another application, after the startup command is triggered, the startup command is obtained and executed. Based on the startup command, the system's monitoring process is started. The monitoring process is used to start various sub-services in the system. Each sub-service sends a communication request to the monitoring process. The monitoring process monitors the communication requests of each sub-service and performs health monitoring on each sub-service based on the communication requests, thereby obtaining at least one round of health monitoring results.

[0024] In one application scenario, the system is built on Docker containers. The sub-services in the system correspond to sub-service modules. The monitoring process is the system's entry script. When the startup command is received, the system is started immediately by executing the startup command. The monitoring process then starts the sub-service modules corresponding to each sub-service in sequence. The sub-service modules send lifecycle signals or communication requests to the monitoring process. The monitoring process monitors the lifecycle signals or communication requests of each sub-service and performs health monitoring on each sub-service based on the lifecycle signals or communication requests, thereby obtaining at least one round of health monitoring results.

[0025] S102: Responding to the abnormal result of the first preset round of health monitoring, the system is restarted.

[0026] Specifically, when the health monitoring result of the first preset round is abnormal, the system is restarted in order to attempt to restore the system's functionality and improve the system's stability.

[0027] In one application scenario, the first preset round includes other rounds besides the first round. When the health monitoring results of other rounds that are different from the first round are abnormal, the system is directly restarted to restart the system as soon as possible in an attempt to restore the system's functionality.

[0028] In another application scenario, the first preset round includes any round. When the health monitoring result of the first round is abnormal, the system waits for the communication request returned by the sub-service until the waiting time exceeds the time threshold, and then restarts the system. When the health monitoring results of other rounds different from the first round are abnormal, the system is restarted directly to reduce the impact of delayed communication request return during the startup phase when the system is just started.

[0029] S103: In response to the upper-layer application calling the application programming interface (API), the system upgrade package is obtained using the API. The current system installation package is backed up to obtain the backup version. The system's scheduled task is used to load the upgrade package to upgrade the system. After the upgrade is completed, the system is restarted and the process of obtaining the startup command is returned.

[0030] Specifically, when the upper-layer application of the system calls the application programming interface (API), it uses the API to obtain the system upgrade package so that the user can obtain the upgrade package independently, improving the convenience of obtaining the upgrade package. At the same time, it backs up the current installation package of the system to obtain a backup version of the installation package.

[0031] In one application mode, the upgrade package has a corresponding downloadable link address. When the upper-layer application of the system calls the application programming interface (API), it uses the API to obtain the link address and download the upgrade package, backs up the current version of the system's installation package, and obtains the backup version.

[0032] In another application method, the upgrade package corresponds to a shared installation file. When the upper layer of the system calls the application interface, it uses the application interface to copy the installation file of the upgrade package to obtain the upgrade package, backs up the current version of the installation package of the system, and obtains the backup version.

[0033] Furthermore, the system upgrades itself by using a scheduled task to load the upgrade package. The scheduled task loads the upgrade package after a preset time interval to prevent the system from receiving the original installation package. The scheduled task ensures that the system upgrade package is accurately obtained and the system is upgraded. After the upgrade is completed, the system is restarted and returns to step S101 to continue health monitoring of the system.

[0034] In one application scenario, the upgrade package has a corresponding name. After obtaining the backup version, the system is restarted, and the system's scheduled task loads the upgrade package corresponding to the name after the system restarts, so as to accurately obtain the upgrade package to upgrade the system. After the upgrade is completed, the system is restarted to continue to monitor the system's health.

[0035] In another application scenario, the upgrade package corresponds to a version number. After obtaining the backup version, the system is restarted, and the system's scheduled task loads the upgrade package corresponding to the version number after the system restarts, so as to accurately obtain the upgrade package to upgrade the system. After the upgrade is completed, the system is restarted to continue to monitor the system's health.

[0036] S104: In response to the abnormal health monitoring result of the second preset round, the system is rolled back to the backup version, wherein the second preset round is after the system upgrade.

[0037] Specifically, when the health monitoring result of the second preset round after the system upgrade is abnormal, the installation package of the backup version is obtained, and the system is rolled back to the backup version to ensure that the system can continue to be used, thereby improving the ease of use and stability of the system.

[0038] In one application scenario, the second preset round is the first round after the system upgrade. When the health monitoring result of the first round is abnormal, the installation package of the backup version is obtained, and the system is rolled back to the backup version.

[0039] In another application scenario, the second preset round includes rounds within a preset time period after the system upgrade. When the health monitoring result corresponding to the round within the preset time period is abnormal, the installation package of the backup version is obtained, and the system is rolled back to the backup version.

[0040] Optionally, the system includes an upgrade record upon initial startup after an upgrade. If the health monitoring result of the first round is normal when the second preset round is the same as the first round, the upgrade record will be deleted. Alternatively, if the health monitoring result is still normal after the preset time period when the second preset round is the same as the first round, the upgrade record will be deleted.

[0041] The above scheme, upon receiving the startup command, executes the command to initiate the system's monitoring process. This monitoring process then starts each sub-service of the system and performs health monitoring on each sub-service. This allows for immediate health monitoring after system startup, obtaining at least one round of health monitoring results using only the monitoring process, thus improving the convenience of system health monitoring. If the first preset round of health monitoring results is abnormal, the system is restarted to attempt to restore system functionality, improving system stability. When the upper-layer application calls the application programming interface (API), the API is used to obtain the system's upgrade package, enabling users to independently obtain the upgrade package, improving the convenience of obtaining the upgrade package. Simultaneously, the current system installation package is backed up, obtaining a backup version. The system's scheduled task then loads the upgrade package to upgrade the system. The scheduled task ensures accurate acquisition of the system upgrade package for system upgrades. After the upgrade is complete, the system is restarted to continue health monitoring. If the second preset round of health monitoring results obtained after the system upgrade is abnormal, the system is rolled back to the backup version to ensure continued system usability, thereby improving the convenience and stability of system use.

[0042] Please see Figure 2 , Figure 2 This is a flowchart illustrating another implementation of the system monitoring and upgrade method of this application, wherein the system is built based on containers and container management tools, and the system runs on containers, and the monitoring process is bound to the system's containers.

[0043] Specifically, the system is built on containers (Docker) and the container management tool (Docker Compose). Each system corresponds to one or more containers; that is, the system has at least one container and runs on it, thus providing services within the container. The monitoring process, as the entry script for the system's container, is bound to the container. When the system starts, the monitoring process starts immediately; when the monitoring process exits, the bound system container also exits, ensuring a timely system restart when abnormal health monitoring results are detected.

[0044] Furthermore, container management tools manage containers through configuration files, which allow for customized settings, increasing the flexibility of container management. These configuration files enable the stopping and restarting of applications, services within the application, and containers of all dependent services.

[0045] Specifically, the system monitoring and upgrade method includes the following steps:

[0046] S201: Obtain the startup command, use the container management tool to execute the startup command, and start the corresponding container and its bound monitoring process.

[0047] Specifically, the startup command is obtained, and the startup command is executed using the container management tool with the specified configuration file. Based on the startup command, the corresponding container of the system and the monitoring process bound to the container are started.

[0048] In one application scenario, Docker Compose is used to specify a particular yml configuration file to execute startup instructions. When the system starts, that is, when the Docker container on which the system resides starts, the monitoring process is executed as the entry script of Docker.

[0049] S202: Use the monitoring process to call the startup commands of each sub-service to start each sub-service in the system.

[0050] Specifically, when the monitoring process starts, it first calls the startup commands of each sub-service in sequence to attempt to start the sub-service. Once the sub-service responds to the startup command, the sub-service in the system starts.

[0051] S203: Receive communication requests from each sub-service, determine the health monitoring results for the current round based on the communication requests for the current round, and obtain at least one round of health monitoring results.

[0052] Specifically, each sub-service sends a communication request to the monitoring process after startup. Upon receiving the communication requests from each sub-service, the health monitoring result for the current round can be determined based on the communication requests of the current round. If all sub-services return a communication request in the current round and the return value is correct, then the health monitoring result for the current round is normal. If any sub-service fails to return a communication request or returns an incorrect value, then the health monitoring result for the current round is abnormal.

[0053] Furthermore, different sub-services may be built on different programming languages. By using the monitoring process to obtain the communication requests of the sub-services, health monitoring of the sub-services can be performed without the need for targeted development for sub-services in different programming languages. This reduces the resource consumption for health monitoring of the system and improves the ease of use of the system.

[0054] In one application scenario, a sub-service sends an HTTP request containing health status information to the monitoring process. The monitoring process polls and calls the HTTP requests containing health status information provided by each sub-service. If the HTTP request from one of the sub-services returns an incorrect value or does not return an HTTP request, the monitoring process retryes 3 times consecutively at 5-second intervals. If the return value is still incorrect or no HTTP request is returned, the sub-service is determined to be abnormal. This is done by repeatedly calling the service to reduce the impact of discrete values ​​and improve the stability of the system.

[0055] Understandably, when the monitoring process fails to start any sub-service, the first round of health monitoring after system startup will result in an anomaly. Similarly, when the monitoring process receives an anomaly in the communication request for the current round, the health monitoring result for the current round will also be anomaly. Specifically, when the monitoring process fails to start any sub-service, it cannot obtain the corresponding sub-service's communication request, thus resulting in an anomaly for the first round of health monitoring.

[0056] S204: In response to the upper-layer application calling the application programming interface (API), the system upgrade package is obtained using the API. The current installation package of the system is backed up, the backup version is obtained, the upgrade package is loaded using the system's scheduled task to upgrade the system, and the system is restarted after the upgrade is completed.

[0057] Specifically, when the upper-layer application of the system calls the application programming interface (API), it uses the API to obtain the system upgrade package so that the user can obtain the upgrade package independently, improving the convenience of obtaining the upgrade package. At the same time, it backs up the current installation package of the system to obtain a backup version of the installation package.

[0058] Furthermore, the system uses a scheduled task to load the upgrade package to upgrade the system, and after the upgrade is completed, the system is restarted and the process returns to step S201.

[0059] It should be noted that the entry condition for step S204 is that the upper-layer application of the system calls the application programming interface. If the upper-layer application of the system does not call the application programming interface, the system will directly enter step S205 from step S203. When the health monitoring result of the system is normal, the system can respond to the upper-layer application calling the application programming interface at any time and perform the system upgrade process. Therefore, step S204 is not limited to the time between steps S203 and S205.

[0060] S205: Determine whether the current round of health monitoring results are abnormal.

[0061] Specifically, determine whether the health monitoring results of the current round are abnormal. If they are normal, proceed to step S206; if they are abnormal, proceed to step S207.

[0062] S206: In response to the current round of health monitoring results being normal, proceed to the next round of health monitoring.

[0063] Specifically, if the monitoring result of the current round is normal, the next round of health monitoring process will begin, returning to step S203, thereby ensuring continuous health monitoring of each sub-service in the system and timely execution of corresponding operations when abnormal health monitoring results occur, thus improving the stability of the system.

[0064] S207: Determine whether the current round is the first preset round.

[0065] Specifically, determine whether the current round is the first preset round. If so, proceed to step S208; otherwise, proceed to step S210.

[0066] S208: In response to the current round being the first preset round and the health monitoring result being abnormal, exit the monitoring process to cause the container bound to the monitoring process to exit, and return the first error code.

[0067] Specifically, the first preset round refers to any round other than the first round, and the first error code is abnormally related to the communication request of the first preset round. In other words, the first preset round is any round other than the first round after system startup. The first error code is abnormally related to the communication request of the first preset round. If the current round is the first preset round and the health monitoring result is abnormal, the monitoring process exits, causing the container bound to the monitoring process to exit. This allows the system to restart as soon as possible and return the first error code. The first error code is used to feedback the health monitoring result, so that the processing terminal can perform corresponding operations based on the first error code.

[0068] S209: In response to receiving the first error code, restart the corresponding container and its associated monitoring process using the container management tool.

[0069] Specifically, when the first error code is obtained, the container management tool is used to specify the configuration file again to execute the startup command, and the corresponding container and the monitoring process bound to the container are started based on the startup command.

[0070] S210: In response to the current round being the second preset round and the health monitoring result being abnormal, exit the monitoring process to cause the container bound to the monitoring process to exit, and return the second error code.

[0071] Specifically, the second preset round is the first round after the system upgrade, and the second error code is related to an anomaly in the communication request of the second preset round. In other words, the second preset round is the first round of health monitoring when the system restarts after an upgrade. The second error code is related to an anomaly in the communication request of the second preset round or the failure of the sub-service to start in the first round. If the current round is the second preset round and the health monitoring result is abnormal, the monitoring process exits, causing the container bound to the monitoring process to exit, enabling the system to restart as soon as possible and return the second error code. The health monitoring result is fed back through the second error code, allowing the processing terminal to perform corresponding operations based on the second error code.

[0072] S211: In response to receiving the second error code, load the backup version of the installation package using the system's scheduled task and roll back the system to the backup version.

[0073] Specifically, when the second error code is obtained, the system's scheduled task loads the backup version of the installation package. At this time, the scheduled task loads the installation package after a preset time interval and uses the backup version of the installation package to roll back the system to the backup version, thereby ensuring that the system can continue to be used.

[0074] It should be noted that since the second preset round corresponds to the first round after the system is upgraded and restarted, the health monitoring result of the first round after the system starts is usually abnormal, which corresponds to the scenario that the upgrade package is incompatible with the system or that the upgrade package has vulnerabilities. Therefore, when the health monitoring result of the second preset round is abnormal and returns the second error code, the system needs to be rolled back to the backup version.

[0075] In this embodiment, the monitoring process is bound to the system's container. Health monitoring can be performed using the monitoring process, and the system is continuously monitored during operation. When the health monitoring result of the first preset round is abnormal, the first error code is returned, and the system is restarted based on the first error code. When the health monitoring result of the second preset round is abnormal, the second error code is returned. At this time, for the upgraded system, the backup installation package is obtained and the system is rolled back to the backup version, thereby ensuring that the system can be used stably.

[0076] Please see Figure 3 , Figure 3This is a flowchart illustrating another implementation of the system monitoring and upgrade method of this application. The system is built based on containers and container management tools, and runs on containers. The monitoring process is bound to the system's container. For details, please refer to the previous embodiment; further elaboration is omitted here.

[0077] Furthermore, the upgrade package and the installation package are generated based on the container image, and the upgrade package and the installation package correspond to the image name that matches the image. The upgrade package has a downloadable link address on the system's storage platform.

[0078] Specifically, a container image contains a packaged application, its dependencies, and process information for when the application starts. Images can be integrated through layering; we can build various application images based on a base image, thus increasing the flexibility in creating upgrade and installation packages. Furthermore, upgrade and installation packages correspond to image names that match the image itself, and upgrade packages have downloadable links on the system's storage platform, enabling sharing of upgrade packages across multiple systems. These download links can also be obtained through the application programming interface (API).

[0079] Specifically, the system monitoring and upgrade method includes the following steps:

[0080] S301: Obtain the startup command, execute the startup command to start the system's monitoring process, use the monitoring process to start each sub-service in the system, and perform health monitoring on each sub-service to obtain at least one round of health monitoring results.

[0081] S302: Responding to the abnormal result of the first preset round of health monitoring, the system is restarted.

[0082] Specifically, the steps S301-S302 described above can be referred to as steps S101-S102 in the first embodiment or steps S201-S209 in the second embodiment, and will not be repeated here.

[0083] S303: In response to a call to the application programming interface (API) from an upper-layer application, the upgrade package is downloaded from the link address using the API.

[0084] Specifically, when the upper-layer application of the system calls the application programming interface (API), it uses the API to obtain the link address, and then downloads the upgrade package from the link address.

[0085] S304: Change the first name of the current installation package to the second name, back up the second name of the current installation package, and obtain the backup version of the current installation package.

[0086] Specifically, the image name corresponding to the current system installation package is the first name. The image name corresponding to the system's running installation package is modified to the second name, and the second name is recorded to obtain the backup version corresponding to the current system installation package.

[0087] In one application method, the image name includes the image name and the image tag, such as A:B, where A represents the image name and B represents the image tag. When modifying the image name corresponding to the current installation package, either the image name or the image tag, or both, can be modified to make the second name different from the first name, and then the modified image name is backed up as the second name.

[0088] In one application scenario, after multiple upgrades, there are multiple versions of the installation package. When backing up different versions of the installation package, you can choose to change the name to something different. That is, the second name of the installation package is not exactly the same. It is just called the second name in the execution steps to distinguish it from the first name. In this way, different versions of the installation package can be backed up so that you can roll back to the specified version of the installation package based on different needs and application scenarios.

[0089] In another application scenario, after multiple upgrades, there are multiple versions of the installation package. When backing up different versions of the installation package, you can choose to change them to the same second name. Whenever a new installation package is backed up, it will overwrite the previous backup. Thus, when rolling back, you only need to roll back one version and roll the system back to the version corresponding to the last running installation package, so as to reduce the probability of system rollback errors.

[0090] S305: Change the image name corresponding to the upgrade package to the first name, where the first name is the same as the image name corresponding to the system's initial installation package.

[0091] Specifically, the image name corresponding to the upgrade package is changed to the first name, which is the same as the image name of the system's initial installation package. In other words, the image name of the modified upgrade package is the same as the image name of the installation package that the system loads for the first time, so as to match the rules defined in the subsequent configuration files.

[0092] S306: Utilize the system's scheduled task to invoke the container management tool after a preset time interval. The container management tool then specifies a configuration file, which defines rules for retrieving images based on the first name.

[0093] Specifically, a normal system restart corresponds to a container restart. When a container restarts, it starts the system by reading the image ID corresponding to the installation package image. Before reading the upgrade package, the image ID within the container is still the image ID corresponding to the original installation package image. When the system needs to be upgraded, if the conventional restart method is used, the installation package corresponding to the original image ID will still be read, leading to upgrade failure. Therefore, a scheduled task is used to call the container management tool after a preset time interval. The container management tool specifies a configuration file, where the rule defined in the configuration file is to retrieve the image corresponding to the upgrade package based on its first name, thus distinguishing it from the restart process and facilitating system upgrades.

[0094] In one application scenario, the scheduled task is implemented based on the crontab provided by the Linux system. crontab is used to set the instructions to be executed periodically, so as to call the container management tool Docker Compose after a preset time interval. The preset time interval can be one minute, and it can also be customized to other durations in other application scenarios. This application does not impose specific restrictions on this.

[0095] S307: Based on the rules defined in the configuration file, load the image corresponding to the upgrade package according to the first name, upgrade the system, restart the system after the upgrade is completed, and return to the steps of obtaining the boot command.

[0096] Specifically, based on the rules defined in the configuration file, the image corresponding to the upgrade package is loaded by the image name of the upgrade package. That is, the image corresponding to the upgrade package is obtained based on the first name, so as to ensure that the upgrade package is obtained instead of the previous installation package, thereby completing the system upgrade. After the upgrade is completed, the system is restarted and returns to step S301 to continuously monitor the system health.

[0097] S308: In response to the abnormal result of the second preset round of health monitoring, the system is rolled back to the backup version.

[0098] Specifically, the second preset round is usually the first round of the first startup after the system upgrade. When the health monitoring result of the second preset round is abnormal, the system is rolled back to the backup version.

[0099] In one application scenario, rolling back the system to a backup version includes: determining the backup version corresponding to the installation package based on the second name of the installation package; clearing the upgrade record corresponding to the upgrade package and changing the second name of the installation package to the first name; wherein, the upgrade record includes the image name of the upgrade package; using the system's scheduled task to call the container management tool after a preset time interval, and using the container management tool to specify the configuration file; based on the rules defined in the configuration file, loading the image corresponding to the installation package according to the first name, and rolling back the system.

[0100] Specifically, the backup version corresponding to the installation package is determined based on the second name that has already been backed up. The upgrade record corresponding to the upgrade package in the last upgrade process is cleared to prepare for system rollback. The upgrade record includes the image name corresponding to the upgrade package, thus freeing up the first name.

[0101] Understandably, based on the same modification rules, the image name corresponding to the installation package is changed to the first name to match the rules in the configuration file. Then, the system's scheduled task is used to call the container management tool after a preset time interval. The container management tool specifies the configuration file and loads the image corresponding to the installation package by the first name based on the rules defined in the configuration file. This ensures that the backed-up installation package is obtained instead of the upgrade package that caused the system to malfunction after the upgrade, thereby completing the system rollback and ensuring that the system can be used stably.

[0102] In this example, the upgrade package and installation package are generated based on container images. During the upgrade or rollback process, the system's scheduled tasks call the container management tool after a preset time interval. The container management tool specifies a configuration file, which defines rules for retrieving images based on the first name. During the upgrade, the first name corresponding to the current installation package is changed to the second name and the second name is backed up. Based on the rules defined in the configuration file, the image corresponding to the upgrade package is loaded according to the first name, and the system is upgraded. During the rollback, the image name of the installation package is changed from the second name to the first name. Based on the rules defined in the configuration file, the image corresponding to the installation package is loaded according to the first name, and the system is rolled back. This ensures the accuracy of upgrades and rollbacks and improves the stability of system operation.

[0103] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an embodiment of the electronic device of this application. The electronic device 40 includes a memory 401 and a processor 402 coupled to each other. The memory 401 stores program data (not shown in the figure), and the processor 402 calls the program data to implement the method in any of the above embodiments. For the description of the relevant content, please refer to the detailed description of the above method embodiments, which will not be repeated here.

[0104] In one application scenario, please refer to Figure 5 , Figure 5 This is a schematic diagram of an application scenario for one implementation of the system monitoring and upgrade method of this application. The entire system needs to be deployed on a Linux environment based on Docker and Docker Compose.

[0105] Specifically, the system is started by Docker Compose executing startup instructions using a specific yml configuration file. When the system starts, i.e., when the Docker container hosting the system starts, a monitoring process is executed as the Docker entry script. If this process exits, the system will exit. The main functions of the monitoring process are to start each sub-service sequentially, perform system rollback, and poll to monitor the health status of each sub-service. Polling involves calling HTTP requests containing health status information from each sub-service. If an HTTP request from a sub-service returns an error, and this error is repeated three times at 5-second intervals, the sub-service is considered abnormal, the monitoring process exits, and the Docker system exits with a specific error code, including the first and second error codes described in the above embodiment. Docker Compose then restarts the Docker system based on the error code, either rebooting the system or rolling it back to a backup version.

[0106] Furthermore, the system provides an Application Programming Interface (API) that can be called by upper-layer applications. This API supports uploading system upgrade packages, which are created from Docker images and contain new system programs and corresponding configuration files. When the system receives this API request, it first modifies and records the currently used image tag for rollback in case of upgrade failure. Then, it connects to the Docker service on the host machine within the system's Docker container, loading the image from the upgrade package. Here, the image name of the upgrade package is consistent with the image name of the original installer. Next, a scheduled task is added to the host machine's cron job to call Docker Compose once every minute to retrieve the upgrade package image based on its image name, thus using the new image to start the system. After the system restarts, the monitoring process starts each sub-service sequentially. If any sub-service is found to be abnormal during the first round of health monitoring after startup, and an upgrade record exists, it indicates that an error occurred during the upgrade process and a rollback is required. At this point, the monitoring process sends a rollback signal to the system. When the system receives the rollback signal, it first parses the recorded image tags that were able to run normally before the last upgrade, and modifies the image name on the host machine to a specific image name. At the same time, it cleans up the upgrade records. Then, it adds a scheduled task to the host machine's cron job to call Docker Compose once every minute to start the system using the last image, thus rolling back the system.

[0107] Please see Figure 6 , Figure 6 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present application. The computer-readable storage medium 60 stores program data 600. When the program data 600 is executed by a processor, it implements the method in any of the above embodiments. For a detailed description of the relevant content, please refer to the detailed description of the above method embodiments, which will not be repeated here.

[0108] It should be noted that the units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

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

[0111] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A system monitoring and upgrade method, characterized in that, The method includes: Obtain a startup command, execute the startup command to start the system's monitoring process, use the monitoring process to start each sub-service in the system, perform health monitoring on each sub-service, and obtain at least one round of health monitoring results; If the health monitoring result of the first preset round is abnormal, the system will be restarted. In response to the upper-layer application of the system calling the application programming interface, the system upgrade package is obtained using the application programming interface, the current installation package of the system is backed up to obtain the backup version, the system upgrades the system by loading the upgrade package using the system's scheduled task, and after the upgrade is completed, the system is restarted and the process returns to the step of obtaining the startup command. In response to an abnormal health monitoring result in the second preset round, the system is rolled back to the backup version; wherein, the second preset round occurs after the system upgrade; The system is built on containers and container management tools, and runs on containers. The monitoring process is bound to the system's container, serving as the container's entry script. The upgrade package and the installation package are generated based on container images, and each corresponds to an image name that matches the image. The container management tool is used to execute the startup command, thereby starting the system's corresponding container and its bound monitoring process. The monitoring process is used to obtain communication requests from the sub-services to perform health monitoring on the sub-services.

2. The system monitoring and upgrade method according to claim 1, characterized in that, The process of obtaining a startup command, executing the startup command to start the system's monitoring process, using the monitoring process to start various sub-services in the system, and performing health monitoring on each sub-service to obtain at least one round of health monitoring results includes: Obtain the startup command, execute the startup command using the container management tool, and start the container corresponding to the system and its bound monitoring process; The monitoring process invokes the startup commands of each of the sub-services to start each of the sub-services in the system; Receive communication requests from each of the sub-services, determine the health monitoring result of the current round based on the communication request of the current round, and obtain at least one round of health monitoring results; In response to the current round of health monitoring results being normal, proceed to the next round of health monitoring, return to the step of receiving communication requests from each of the sub-services, and determine the current round of health monitoring results based on the current round of communication requests.

3. The system monitoring and upgrade method according to claim 2, characterized in that, If the monitoring process fails to start any of the sub-services, the health monitoring result of the first round after the system starts will be abnormal. When the monitoring process receives an abnormal communication request for the current round, the health monitoring result for the current round is abnormal. After receiving communication requests from each of the sub-services, determining the health monitoring result for the current round based on the communication requests, and obtaining at least one round of health monitoring results, the process further includes: In response to the current round being the first preset round and the health monitoring result being abnormal, the monitoring process exits, causing the container bound to the monitoring process to exit, and a first error code is returned; wherein, the first preset round is a round different from the first round, and the first error code is related to an abnormality in the communication request of the first preset round; or... In response to the current round being the second preset round and the health monitoring result being abnormal, the monitoring process is exited to cause the container bound to the monitoring process to exit, and a second error code is returned; wherein, the second preset round is the first round and after the system upgrade, the second error code is related to an abnormality in the communication request of the second preset round.

4. The system monitoring and upgrade method according to claim 3, characterized in that, The response to an abnormal health monitoring result in the first preset round, restarting the system, includes: In response to obtaining the first error code, the container corresponding to the system and its bound monitoring process are restarted using the container management tool; The response to an abnormal health monitoring result in the second preset round, rolling back the system to the backup version, includes: In response to obtaining the second error code, the system loads the installation package of the backup version using a scheduled task, and rolls the system back to the backup version.

5. The system monitoring and upgrade method according to claim 1, characterized in that, The upgrade package has a corresponding downloadable link on the system's storage platform.

6. The system monitoring and upgrade method according to claim 5, characterized in that, The image name corresponding to the current installation package of the system is the first name. The process involves responding to the upper-layer application of the system calling the application programming interface (API), obtaining the upgrade package of the system using the API, backing up the current installation package of the system to obtain the backup version, and using the system's scheduled task to load the upgrade package to upgrade the system, including: In response to a call to the application programming interface by an upper-layer application of the system, the upgrade package is downloaded from the link address using the application programming interface. Change the first name corresponding to the current installation package of the system to the second name, back up the second name corresponding to the current installation package, and obtain the backup version corresponding to the current installation package of the system; The image name corresponding to the upgrade package is modified to the first name; wherein, the first name is the same as the image name corresponding to the initial installation package of the system; The system uses a scheduled task to invoke the container management tool after a preset time interval, and uses the container management tool to specify a configuration file; wherein, the configuration file defines rules for obtaining an image based on the first name; Based on the rules defined in the configuration file, the image corresponding to the upgrade package is loaded according to the first name, and the system is upgraded.

7. The system monitoring and upgrade method according to claim 6, characterized in that, Rolling the system back to the backup version includes: Based on the second name corresponding to the installation package, determine the backup version corresponding to the installation package; Clear the upgrade record corresponding to the upgrade package, and change the second name of the installation package to the first name; wherein, the upgrade record includes the image name of the upgrade package; The system uses a scheduled task to invoke the container management tool after a preset time interval, and uses the container management tool to specify the configuration file. Based on the rules defined in the configuration file, the image corresponding to the installation package is loaded according to the first name, and the system is rolled back.

8. An electronic device, characterized in that, include: A memory and a processor are coupled to each other, wherein the memory stores program data, and the processor invokes the program data to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium storing program data thereon, characterized in that, When the program data is executed by the processor, the method as described in any one of claims 1-7 is implemented.

Images