A software status automatic monitoring method and system

Abstract

The present invention discloses a method and system for automatically supervising software status, which relates to the technical field of software status management. The method solves the technical problem that existing solutions are inaccurate in monitoring abnormalities of database services and cannot provide processing plans to promptly process database services, resulting in the database being unable to operate continuously and stably. The present invention establishes a message queue between a main process and a child process through shared memory, and executes a processing plan based on the number of heartbeat writes of the child process and the updated heartbeat number read by the main process; not only can the abnormalities of the database service be accurately monitored in real time, but the corresponding processing plan can also be executed to promptly process the database abnormalities, thereby ensuring the continuous and stable operation of the database; the processing plans built into the monitoring platform of the present invention can be added and deleted in real time, and when adding or deleting processing plans, only the configuration of the monitoring platform needs to be changed, which is simple and convenient to operate and can ensure the operating efficiency of the database service.

Description

Technical Field

[0001] The present invention belongs to the technical field of software status management, and relates to a method and system for automatic monitoring of software status. Background Art

[0002] A database system usually consists of software, database and data administrator. Its software includes operating system, host language, utility program and database management system. The database is managed by database management system, and data insertion, modification and retrieval must be performed through database management system. Database administrator is responsible for creating, monitoring and maintaining the entire database.

[0003] Database systems may experience failures during operation, mainly including transaction failures, system failures, media failures, and computer virus failures. These failures can lead to transaction interruptions, memory information loss, and external storage data loss, which have a significant impact on database operations. Therefore, there is an urgent need for an automated supervision method that can monitor the database operation status in real time and automatically handle failures when the database is abnormal. Summary of the Invention

[0004] The purpose of the present invention is to solve the problems in the prior art and provide a method and system for automatic supervision of software status, aiming to solve the technical problem of the lack of an automated supervision method in the prior art that can monitor the database operation status in real time and automatically handle faults when the database is abnormal.

[0005] In order to achieve the above object, the present invention adopts the following technical solutions:

[0006] The present invention proposes a method for automatically monitoring software status, comprising the following steps:

[0007] The main process of the monitoring platform reads the configuration of the initialization file and creates a sub-process of the monitoring platform according to the configuration of the initialization file;

[0008] A message queue is established through shared memory between the main process of the monitoring platform and the sub-process of the monitoring platform. The heartbeat number is written to the message queue. The main process of the monitoring platform reads the heartbeat number from the message queue and regularly decrements the read heartbeat number.

[0009] A processing plan is established and executed according to the written heartbeat number and the decremented heartbeat number to realize automatic supervision of the software status; wherein, the processing plan is built into the monitoring platform.

[0010] Preferably, the processing plan detects the running status of the running database service through the software status automatic supervision method and the corresponding monitoring platform.

[0011] Preferably, when adding or deleting a treatment plan, only the configuration of the monitoring platform needs to be changed;

[0012] The monitoring platform can mount multiple processing plans, which are isolated from each other; one processing plan corresponds to one sub-process.

[0013] Preferably, the handling plan includes an overall restart plan and a separate restart plan;

[0014] The individual restart plan is used to restart an individual sub-process; the overall restart plan is used to restart the monitoring platform.

[0015] Preferably, when the child process cannot update the heartbeat count, and the main process reads the decremented heartbeat count as 0, a separate restart plan is executed to restart the corresponding child process, thereby achieving full-process monitoring and processing.

[0016] Preferably, after the sub-process is developed, the sub-process is mounted to the main process in real time through the initialization file.

[0017] Preferably, the sub-processes in the initialization file are added or deleted in real time; when a sub-process is added, the corresponding dynamic link library is loaded in real time; when a sub-process is deleted, the corresponding sub-process that has been running is terminated in real time.

[0018] Preferably, the monitoring platform is deployed on a Windows side or a Linux side.

[0019] Preferably, the monitoring platform is capable of detecting and deleting expired processing plans in real time.

[0020] The present invention proposes a software status automatic monitoring system, comprising:

[0021] A sub-process acquisition module is used to read the configuration of the initialization file through the main process of the monitoring platform and create a sub-process of the monitoring platform according to the configuration of the initialization file;

[0022] A heartbeat number acquisition module is used to establish a message queue through shared memory between the main process of the monitoring platform and the sub-process of the monitoring platform, write the heartbeat number in the message queue, and the main process of the monitoring platform reads the heartbeat number from the message queue and regularly decrements the read heartbeat number;

[0023] The data processing module is used to establish a processing plan, execute the processing plan according to the written heartbeat number and the decremented heartbeat number, and realize the automatic supervision of the software status; wherein the processing plan is built into the monitoring platform.

[0024] Compared with the prior art, the present invention has the following beneficial effects:

[0025] The present invention proposes a method for automatically supervising software status, which is used to solve the technical problem that existing solutions cannot accurately monitor database service anomalies and cannot provide a processing plan to promptly handle database services, resulting in the database being unable to operate continuously and stably. The present invention solves the above-mentioned problem by setting a message queue between the main process and the child process to evaluate the operating status of the child process, and at the same time using a built-in processing plan to handle abnormal child processes. The present invention establishes a message queue between the main process and the child process through shared memory, writes the heartbeat number into the message queue, and the main process reads the heartbeat number from the message queue, and periodically decrements the read heartbeat number, and executes the processing plan based on the written heartbeat number and the decremented heartbeat number; the present invention can not only accurately monitor database service anomalies in real time, but also execute the corresponding processing plan to promptly handle database anomalies, thereby ensuring the continuous and stable operation of the database.

[0026] Furthermore, the built-in processing plans of the monitoring platform can be added and deleted in real time, and when adding or deleting processing plans, it is only necessary to change the configuration of the monitoring platform. The operation is simple and convenient, and can ensure the operating efficiency of the database service.

[0027] Furthermore, after the sub-process is developed, it is mounted to the main process through the initialization file. Any two sub-processes are independent of each other, and the corresponding functions are completely isolated. Operating a sub-process will not affect the operation of the main process and other sub-processes.

[0028] The present invention proposes an automatic software status monitoring system, which divides the system into a sub-process acquisition module, a heartbeat acquisition module and a data processing module, and adopts a modular concept to make each module independent of each other, thereby facilitating unified management of each module. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0030] Figure 1 Schematic diagram of the workflow of the method for automatic monitoring of software status of the present invention.

[0031] Figure 2 Schematic diagram of the system architecture for automated software status monitoring according to the present invention.

[0032] Figure 3 This is a diagram of the software status automatic monitoring system of the present invention. DETAILED DESCRIPTION

[0033] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings herein can be arranged and designed in various different configurations.

[0034] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention as claimed, but rather merely represents selected embodiments of the present invention. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without creative effort shall fall within the scope of protection of the present invention.

[0035] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings.

[0036] In the description of the embodiments of the present invention, it should be noted that if the terms "upper," "lower," "horizontal," "inner," etc. appear, the orientation or positional relationship indicated is based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship in which the inventive product is typically placed when in use. These terms are merely for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or component referred to must have a specific orientation, be constructed, or operate in a specific orientation. Therefore, they should not be construed as limitations on the present invention. In addition, the terms "first," "second," etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0037] In addition, if the term "horizontal" appears, it does not mean that the component must be absolutely horizontal, but can be slightly tilted. For example, "horizontal" only means that its direction is more horizontal than "vertical", and does not mean that the structure must be completely horizontal, but can be slightly tilted.

[0038] In the description of the embodiments of the present invention, it should be noted that, unless otherwise expressly specified or limited, the terms "disposed," "installed," "connected," and "connected" should be understood in a broad sense. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to internal connections between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on specific circumstances.

[0039] The present invention is described in further detail below with reference to the accompanying drawings:

[0040] Unexpected problems encountered in various operating systems are as follows:

[0041] 1) When the operating system encounters a hardware problem, such as a disk or memory anomaly;

[0042] 2) When the operating system encounters a software problem, such as an abnormality in some concurrently running services;

[0043] 3) When the operating system encounters network overload, such as a large number of concurrent upstream connections in a certain period of time.

[0044] To address the above issues, existing monitoring service solutions use a method of scanning the memory for the existence of the service executable file for monitoring. If it is detected that the service executable file does not exist, the specified executable file is re-run using a script or other means, and the completion of the execution is regarded as a successful start-up judgment. The drawbacks of this method are:

[0045] 1) The executable file of the database service exists in memory, but it is unknown whether it can provide services to the client;

[0046] 2) The database service executable file exists in memory, but it is unknown whether the database service startup process has completed. If the startup time is long, it is unknown what state the database service is in.

[0047] 3) The executable files of some database services do not exist in the memory, so all services can only be restarted

[0048] 4) The status detection of various database services is too simple;

[0049] 5) The database system cannot be changed as it evolves, or upgrading the monitoring system requires reconfiguration, restarting, and other operations, which affects the normal operation of the database system;

[0050] 6) Most of them only support a single operating system platform, or the usage methods of each platform are different.

[0051] To address the aforementioned issues and the shortcomings of existing solutions, the present invention proposes an automated software status monitoring method, including a monitoring platform. The monitoring platform in the present invention is an arbitrarily scalable emergency plan processing platform that provides long-term, stable, and real-time monitoring of various database services, ensuring the long-term stable operation of the database.

[0052] The present invention proposes a method for automatically supervising software status. Figure 1 As shown, the following steps are included:

[0053] The main process of the monitoring platform reads the configuration of the initialization file and creates a sub-process of the monitoring platform according to the configuration of the initialization file;

[0054] A message queue is established through shared memory between the main process of the monitoring platform and the sub-process of the monitoring platform. The heartbeat number is written to the message queue. The main process of the monitoring platform reads the heartbeat number from the message queue and regularly decrements the read heartbeat number.

[0055] A processing plan is established and executed according to the written heartbeat number and the decremented heartbeat number to realize automatic supervision of the software status; wherein, the processing plan is built into the monitoring platform.

[0056] The processing plan in the present invention is a preset processing flow developed for various services of the current database. The processing plan is designed in detail for monitoring each database service from startup to runtime. The processing plan interacts with the database service in real time during runtime. When an abnormal database service status is captured at any time, the logic in the processor plan is immediately adopted for processing; the running status of the running database service is detected through the software status automation supervision method and the corresponding monitoring platform. The monitoring platform adopts a resident memory service mode, which can be started after the various database services are started and terminated before the various database services are terminated. It can also be set as a startup item in the operating system and started before the various database services are started, and all database services are started by the monitoring platform.

[0057] The monitoring platform itself is a mounting platform that can host any number of response plans (the specific number is configurable in the initialization file). Each response plan is isolated from each other. Each response plan corresponds to a child process. While the monitoring platform is running, it automatically monitors the execution of the response plans. This means that the monitoring platform uses the response plans to resolve database issues while also monitoring their execution. If a response plan encounters a deadlock or other issue, the platform automatically restarts the response plan, preventing database service anomalies at another level. The monitoring platform is deployed on Windows or Linux.

[0058] The processing plans mounted on the monitoring platform can be dynamically configured and loaded or unloaded in real time without affecting other running processing plans. Any processing plan is isolated from each other, that is, the failure of one processing plan will not affect the detection and maintenance functions provided by other processing plans. The operation or suspension of any processing plan can be configured in real time and is isolated from each other.

[0059] In this embodiment, the monitoring platform is marked as rtdbwatcher, the initialization file is marked as ini file, and the dynamic link library is marked as dll.

[0060] The rtdbwatcher main process reads the configuration in the configuration ini file, dynamically creates the rtdbwatcher child process and loads the specified dll. In the present invention, the user can add or delete child processes (sub-functions) in real time. When adding a child process (sub-function), rtdbwatcher loads the dll in real time. When deleting a child process (sub-function), rtdbwatcher terminates the running child process (sub-function) in real time.

[0061] After a subprocess is developed, it is attached to the main process in real time through an initialization file. Any two subprocesses are independent of each other, and their corresponding functions are completely isolated. Subprocesses in the initialization file can be added or deleted in real time; when a subprocess is added, the corresponding dynamic link library is loaded in real time; when a subprocess is deleted, the corresponding subprocess that is already running is terminated in real time.

[0062] Specifically, the implementation method of detecting the function of the database service through the present invention is as follows:

[0063] like Figure 2 As shown, after the main process obtains the initialization file configuration and loads the dynamic link library of the corresponding child process, a message queue between the main process and the child process is established through shared memory, the child process writes the heartbeat number to the message queue, and the main process reads the heartbeat number from the message queue, and the heartbeat number read by the main process will be updated periodically; when the child process cannot update the heartbeat number, and the updated heartbeat number read by the main process is 0, it is determined that the operation of the child process is abnormal, and the abnormal child process is restarted through a separate restart plan to achieve full-process monitoring and processing; the separate restart plan is used to restart a separate child process, and the overall restart plan is used to restart the monitoring platform.

[0064] The timing in this embodiment is a period set manually, which may be per second or per minute. In other preferred embodiments, the timing may be a period randomly generated by the system within a given range.

[0065] The present invention provides a method for automatically supervising software status and a monitoring platform that carries the method. The monitoring platform can also detect and delete expired processing plans in real time, which can be done in two ways: 1) manual evaluation and 2) automatic evaluation.

[0066] 1) Manual evaluation

[0067] The operator checks the processing plans preset on the monitoring platform. When a processing plan has not been used for a long time or is replaced by a new version of the processing plan, the corresponding processing plan is manually deleted.

[0068] 2) Automatic evaluation

[0069] Automatically detect the number of times a treatment plan is called; the number of times the treatment plan is called within three months or other time limits can be detected;

[0070] When the number of calls is less than the call number threshold, the corresponding processing plan is determined to be inapplicable, and the processing plan is automatically deleted; wherein the call number threshold is a number greater than 0; or

[0071] When the last call time of the processing plan is three months or before the set time, the processing plan is determined to be inapplicable and is automatically deleted.

[0072] The operating environment of the software status automatic supervision method and the corresponding monitoring platform of this embodiment includes Windows and Linux.

[0073] On Windows, it exists as a background service. You can perform the following operations through a console with administrator privileges:

[0074] Register service: rtdbwatcher64.exe-service

[0075] Delete the service: rtdbwatcher64.exe -unregserver

[0076] Start the service: net start rtdbwatcher

[0077] Stop the service: net stop rtdbwatcher

[0078] Starting and stopping services can also be done through the operating system's service manager.

[0079] Unless the user stops the service manually on the Windows side, the operating system will automatically restart the rtdbwatcher service immediately after it crashes or is terminated using taskkill (taskkill / f / im rtdbwatcher64.exe, process termination command).

[0080] On the Linux side, execute the startup command gstart through the console to start rtdbwatcher.

[0081] Next, three functions of the present invention are introduced in detail: 1) monitoring service function, 2) access test service and socket deadlock function, and 3) automatic overall restart function.

[0082] 1) Monitoring service function

[0083] The purpose of the monitoring service function is to monitor whether the specified monitored service is running. If it is not running, it will attempt to start it. This function will only start / stop services that do not exist in the specified monitoring services at the same time (when the system needs to be restarted as a whole, you should consider using the automatic overall restart function). The specified monitored services are specified through the initialization file ini.

[0084] Windows:

[0085] The monitoring service function will regularly check whether the monitored service is running according to the cycle specified in the configuration file.

[0086] Each existing service creates a unique global mutex upon startup. The service monitoring function verifies whether the monitored service is running by checking the existence of the global mutex. The service monitoring function does not determine whether the service startup has completed (i.e., whether the service is in the running state). It is possible that a service startup has created the global mutex, but the startup process is long and remains in the startup pending state. In this case, the service monitoring function will still consider the service to be running normally.

[0087] If the check fails, the monitoring service function attempts to open the service through the Windows service API.

[0088] The monitoring service function does not guarantee that the monitored service will be started successfully. If the startup fails, the monitoring service function will repeat the above behavior in the next detection cycle.

[0089] If multiple monitored services are specified in the configuration file, each service will be detected sequentially. The next monitored service will not be detected until a service is detected / started.

[0090] The monitoring service re-reads the configuration file at the beginning of each cycle. This means that any changes to the configuration file will be applied during that cycle. This feature allows you to specify whether to enable the monitoring service in real time. For specific parameters, refer to the configuration file description.

[0091] A potential problem with monitoring services is that they don't guarantee successful service startup. If a service gets stuck during the load process or doesn't return for a long time, the monitoring function won't be able to handle this situation and will still assume the service has started. One solution is to create another service to check for the completion of the startup process. If it doesn't complete within a given timeframe, it can generate an alert or restart the service, but this can result in data loss.

[0092] Linux:

[0093] The Linux function is the same as that of the Windows side, but the Linux side lacks the service management application program interface API, so the Linux side first detects whether the startup command gstart exists. If not, it scans whether the service executable file name exists in the memory, that is, pidof -s service name.

[0094] 2) Access test service and socket deadlock function

[0095] The purpose of the access test service function is to test in real time whether the rtdbserver can still provide normal access functions.

[0096] Windows:

[0097] The access test service function will regularly check whether the rtdbserver can still provide access functions according to the period specified in the configuration file.

[0098] The access test service function calls the Windows service API to detect whether the rtdbserver service is running. If the rtdbserver service is not running, no further processing is performed. The rtdbserver is also considered not running if it is in the startup pending state.

[0099] The access test service function tests whether the rtdbserver is in a normal access state by calling the go_connect / go_login (connection / login) provided in the real-time database program interface rtdbapi.

[0100] If the access test fails, potential issues include:

[0101] If the rtdbserver service is running but cannot provide access for some reason, the access test service will attempt to stop the service by calling the Windows system API (Application Programming Interface) to terminate the rtdbserver process. The access test function does not restart the rtdbserver service, but instead waits for the monitoring service function to start. Whether to terminate the rtdbserver process is configurable in the configuration file. If not, the function will simply log a message notifying the user of the rtdbserver access failure.

[0102] The configured username and password are incorrect, prompting the user to modify the configuration file.

[0103] The rtdbserver service is in active-active synchronization state, and this situation has not yet been handled.

[0104] The access test service function may be unable to return for a long time due to a pseudo-death of the rtdbserver. If the rtdbserver service cannot be restarted, the access test service function will not return, resulting in a deadlock. The rtdbwatcher service will also be unable to exit normally. When the user shuts down the rtdbwatcher service, the code will have to force exit, which may generate a dump file (memory image). In this case, you need to monitor whether the access test service is deadlocked to further resolve the issue.

[0105] The access test service re-reads the configuration file at the beginning of each cycle. This means that any changes to the configuration file will be applied during that cycle. This feature allows users to specify whether to enable the access test feature in real time. For specific parameters, refer to the configuration file description.

[0106] Linux:

[0107] The functions are the same as those on Windows.

[0108] The access test service function may be in a state where it has connected to the rtdbserver, but because the rtdbserver is in a suspended state, the access test service cannot return due to a timeout or connection failure, resulting in a deadlock. The access test service deadlock monitoring function determines whether to proceed further based on the timeout.

[0109] Windows:

[0110] The function of monitoring whether the access test service is deadlocked is in a stateless waiting stage after startup.

[0111] The function of monitoring whether the access test service is deadlocked will be activated before the access test service performs go_connect / go_login (connection / login).

[0112] Each time the function of monitoring whether the access test service is deadlocked is activated, the configuration file will be read and the configuration parameters will be updated.

[0113] After the deadlock monitoring function of the access test service is activated, it starts waiting for the connection timeout time set by the parameter login_timeout in the configuration file.

[0114] If the access test service function returns a connection success / failure, it will notify the monitoring access test service to exit the waiting state and return to the stateless waiting stage.

[0115] If the access test service connection enters a deadlock state, the deadlock monitoring function will decide whether to restart the rtdbserver based on the configuration file after a timeout. If the rtdbserver is restarted, the deadlock monitoring function will continue to wait; however, if the rtdbserver is not restarted, it will degenerate to writing an access test service deadlock alarm to the log.

[0116] If the rtdbserver service is restarted, the access test service function returns due to a socket disconnect, exiting the deadlock state. At this point, the monitoring function for access test service deadlock is notified to exit the detection state and return to the stateless waiting phase. If the access test service function does not return due to a socket disconnect after the restart, the monitoring function for access test service deadlock will remain in the deadlock monitoring state and wait for a timeout. At this point, the monitoring function will wait for the main process to restart itself.

[0117] Linux

[0118] The functions are the same as those on Windows.

[0119] 3) Automatic overall restart function

[0120] The purpose of the automatic overall restart function is to simulate the behavior of Rose restarting services. That is, when it detects that any service does not exist, it first stops all services as a whole and then starts all services as a whole.

[0121] Windows:

[0122] The automatic overall restart function periodically checks whether any services are not running.

[0123] When it is detected that any service is not running, all services are stopped first, and then it is checked in the subsequent cycle whether the services have been stopped. If there are still services that have not been stopped within the specified number of retries, Kill (execute the termination command) will terminate the service directly.

[0124] When it is detected that all services are not running, all services are started first, and then all services are checked in subsequent cycles to see if they are started. If there are still services that are not started within the specified number of retries, all started services are killed (executed as terminated) and all services are started again after the next cycle.

[0125] If all services are detected to be running, the function does nothing.

[0126] Linux:

[0127] The function is the same as that of the Window side.

[0128] Working principle of the present invention:

[0129] The main process of the monitoring platform reads the configuration of the initialization file, dynamically creates a child process and loads the dynamic link library corresponding to the child process; a message queue is established between the main process and the child process through shared memory, the child process writes the heartbeat number to the message queue, the main process reads the heartbeat number from the message queue, and the main process periodically decreases the read heartbeat number; the processing plan is executed according to the heartbeat number written by the child process and the updated heartbeat number read by the main process.

[0130] The present invention proposes a software status automatic monitoring system, such as Figure 3 As shown, including:

[0131] A sub-process acquisition module is used to read the configuration of the initialization file through the main process of the monitoring platform and create a sub-process of the monitoring platform according to the configuration of the initialization file;

[0132] A heartbeat number acquisition module is used to establish a message queue through shared memory between the main process of the monitoring platform and the sub-process of the monitoring platform, write the heartbeat number in the message queue, and the main process of the monitoring platform reads the heartbeat number from the message queue and regularly decrements the read heartbeat number;

[0133] The data processing module is used to establish a processing plan, execute the processing plan according to the written heartbeat number and the decremented heartbeat number, and realize the automatic supervision of the software status; wherein the processing plan is built into the monitoring platform.

[0134] The present invention proposes a method and system for automated software status monitoring, which is used to address the technical problems of existing solutions, such as inaccurate monitoring of database service anomalies and the inability to provide a response plan to promptly handle database services, resulting in the database being unable to operate continuously and stably. The present invention solves the above-mentioned problems by setting a message queue between the main process and the child process to evaluate the operating status of the child process, while simultaneously using a built-in response plan to handle abnormal child processes. The present invention establishes a message queue between the main process and the child process through shared memory. The child process writes the heartbeat count to the message queue, and the main process reads the heartbeat count from the message queue and periodically decrements the read heartbeat count. The response plan is executed based on the written heartbeat count of the child process and the updated heartbeat count read by the main process. This method not only accurately monitors database service anomalies in real time, but also executes the corresponding response plan to promptly handle database anomalies, ensuring the continuous and stable operation of the database. The response plans built into the monitoring platform of the present invention can be added and deleted in real time. When adding or deleting a response plan, only the configuration of the monitoring platform needs to be changed. The operation is simple and convenient, and the operation efficiency of the database service can be guaranteed. After the subprocesses are developed, they are attached to the main process via initialization files. Any two subprocesses are independent of each other, and their corresponding functions are completely isolated. Operating a subprocess will not affect the main process or other subprocesses. The present invention and monitoring platform can run on both Windows and Linux platforms.

[0135] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A method for automatic monitoring of software status, characterized in that: The steps include: The main process of the monitoring platform reads the configuration of the initialization file and creates a sub-process of the monitoring platform according to the configuration of the initialization file; A message queue is established by sharing memory between the main process of the monitoring platform and the sub-process of the monitoring platform. The sub-process writes the heartbeat number to the message queue, and the main process of the monitoring platform reads the heartbeat number from the message queue and regularly decrements the read heartbeat number. Establish a processing plan and execute it based on the written heartbeat number and the decremented heartbeat number to achieve automated monitoring of the software status. The processing plan is built into the monitoring platform. When the child process cannot update the heartbeat count, and the main process reads the decremented heartbeat count as 0, a separate restart plan is executed to restart the corresponding child process, thereby achieving full-process monitoring and processing.

2. The software status automatic monitoring method according to claim 1, characterized in that: The processing plan detects the operating status of the running database service through the software status automatic supervision method and the corresponding monitoring platform.

3. The software status automatic monitoring method according to claim 1, characterized in that: When adding or deleting a treatment plan, only the configuration of the monitoring platform needs to be changed; The monitoring platform can mount multiple processing plans, which are isolated from each other; one processing plan corresponds to one sub-process.

4. The software status automatic monitoring method according to claim 1, characterized in that: The response plan includes an overall restart plan and a separate restart plan; The individual restart plan is used to restart an individual sub-process; the overall restart plan is used to restart the monitoring platform.

5. The software status automatic monitoring method according to claim 1, characterized in that: After the sub-process is developed, it is mounted to the main process in real time through the initialization file.

6. The method for automatic monitoring of software status according to claim 5, characterized in that: The sub-processes in the initialization file are added or deleted in real time; when a sub-process is added, the corresponding dynamic link library is loaded in real time; when a sub-process is deleted, the corresponding sub-process that is already running is terminated in real time.

7. The software status automatic monitoring method according to claim 1, characterized in that: The monitoring platform is deployed on a Windows or Linux terminal.

8. The method for automatic monitoring of software status according to claim 1, characterized in that: The monitoring platform can detect and delete expired processing plans in real time.

9. A software status automatic monitoring system, characterized in that: include: A sub-process acquisition module is used to read the configuration of the initialization file through the main process of the monitoring platform and create a sub-process of the monitoring platform according to the configuration of the initialization file; A heartbeat number acquisition module is used to establish a message queue through shared memory between the main process of the monitoring platform and the sub-process of the monitoring platform. The sub-process writes the heartbeat number to the message queue, and the main process of the monitoring platform reads the heartbeat number from the message queue and regularly decrements the read heartbeat number; A data processing module, which is used to establish a processing plan and execute the processing plan according to the written heartbeat number and the decremented heartbeat number to achieve automated monitoring of the software status; wherein the processing plan is built into the monitoring platform; When the child process cannot update the heartbeat count, and the main process reads the decremented heartbeat count as 0, a separate restart plan is executed to restart the corresponding child process, thereby achieving full-process monitoring and processing.

Images