A hedging system backend module operation monitoring system

Abstract

The present invention provides a monitoring system for the operation of the backend module of a hedging system, which belongs to the technical field of monitoring systems. The monitoring system includes a monitoring client, a monitoring server, and a database; the monitoring client and the monitoring server complete data interaction through the database. The monitoring system of the present invention no longer uses the operation and maintenance method of scripts, and the user only needs to perform simple configuration on the monitoring client; and the log information and module status information of each module can be stored in the database. When the log information is deleted by mistake, the log information can be viewed through the database; and the monitoring system of the present invention operates independently of the hedging system, and the operation of the monitoring system will not affect the operation of the hedging system, and the system reliability is higher.

Description

Technical Field

[0001] The present invention relates to the technical field of monitoring systems, and in particular to a hedging system backend module operation monitoring system. Background Art

[0002] With the continuous increase in business types and the continuous improvement of various functions, the background components of the hedging system are also increasing. When there are only a few basic components and no primary and backup services are configured, simple control and management can be performed by writing operation and maintenance scripts. The occupancy of system resources in the Windows operating system can be obtained through the built-in resource manager, and the Linux system can be viewed through commands.

[0003] However, the number of backend components in the hedging system has generally increased several times, and different business scenarios require different components to be configured, and the master-slave mode must also be configured. At this time, the original method of writing operation and maintenance scripts is no longer applicable, and not all customer operation and maintenance personnel can write operation and maintenance scripts. Therefore, the hedging system urgently needs to be equipped with a monitoring system with complete functions and simple operation. Summary of the invention

[0004] In order to at least solve the technical problems existing in the above-mentioned background technology, the present invention provides a hedging system backend module operation monitoring system.

[0005] A hedging system backend module operation monitoring system, the hedging system comprising a plurality of target servers;

[0006] The monitoring system includes a monitoring client, a monitoring server, and a database; the monitoring client and the monitoring server complete data interaction through the database;

[0007] The monitoring server is used to provide a reporting monitoring function to each of the target servers, and the reporting monitoring function is used to enable the target server to collect status data and generate log data for each backend module of the hedging system; and receive the status data and log data sent by the target server through the UDP connection; and is also used to store the status data and log data in the database, and push important status data and log data to the monitoring client;

[0008] The monitoring client is used to receive the configuration operation of the customer, generate the reporting monitoring function based on the configuration operation and send it to the monitoring server; and support the customer to query and analyze the status data and the log data, and implement control over each of the background modules.

[0009] Furthermore, there are multiple monitoring servers, and the monitoring servers correspond to the target servers one by one;

[0010] One of the plurality of monitoring servers is configured as a master monitoring server, and the other monitoring servers are configured as slave monitoring servers;

[0011] And, the slave monitoring server sends the server data and background module data of the target server to the master monitoring server.

[0012] Furthermore, the monitoring server is configured to implement a monitoring daemon service, specifically including:

[0013] 1) Provide independent operation and maintenance functions for each of the background modules, including starting and stopping a single background module, and one-key start, one-key stop, and one-key restart and recovery functions for all the background modules;

[0014] 2) Monitor the survival status of all started background modules, and report abnormal process information in a timely manner. If there is any abnormality, automatically maintain the corresponding background module to ensure its normal operation;

[0015] 3) Monitor the CPU load, memory usage and other operating information of all the background module processes, and report to the monitoring client at regular intervals;

[0016] 4) Monitor the target server's CPU load, memory usage, hard disk usage and other system information, and report to the monitoring client at regular intervals;

[0017] 5) The monitoring target server automatically detects the devices that have been started in the environment when it is started, and continues to monitor.

[0018] Furthermore, the monitoring server is also configured to implement module operation and maintenance control, specifically including:

[0019] 11) A monitoring daemon thread is set for each of the background modules, and the monitoring message table is continuously updated by the monitoring daemon thread to monitor the module control request (module start, stop, restart) sent by the monitoring client.

[0020] 12) A module process is uniquely identified by the two attributes of group number and device number;

[0021] 13) If the module process is started by the monitoring client sending a command, the monitoring daemon thread determines the group number and device number of the corresponding background module according to the command; after the process is successfully started, the new process monitoring information is saved to the process monitoring strategy queue of the monitoring daemon thread for querying and monitoring the module operation status;

[0022] 14) When stopping the module process, first check whether the process exists. If it exists, clear the process and report the process exit status (whether it exits normally) message to the monitoring client, and delete the corresponding monitoring process information in the monitoring thread queue.

[0023] Furthermore, the monitoring server is also configured to implement module operation status monitoring, specifically including:

[0024] 21) When the monitoring daemon service is initialized, a separate thread is started to monitor the module running status of the background module, and the module running status is regularly reported to the monitoring client so that the monitoring client updates the monitoring information;

[0025] 22) If the module is in an abnormal operating state, immediately report a warning message to the monitoring client; and / or, set a number of safety thresholds on the monitoring client, and if the status data is not within the safety threshold range, issue an alarm to prompt processing;

[0026] 23) Process monitoring strategy, queue for storing process monitoring information;

[0027] 24) After the module operation status monitoring is started, the startup control command issued by the monitoring client is obtained from the database (the command includes the module group number, device number, program name, path, command line parameters, whether automatic restart is required, etc.), and the corresponding background module is started and the corresponding module data is saved to the monitoring strategy (including the module group number, device number, pid, etc.) for use in information collection and reporting;

[0028] 25) When the monitoring client issues a stop command, the monitoring server reads the command from the database and stops the corresponding module and deletes it from the monitoring strategy. From then on, the module operation status monitoring thread no longer collects its status information;

[0029] 26) monitoring the running status of each of the background modules and detecting whether the process of each of the background modules is alive;

[0030] 27) Collecting the CPU load, memory usage, IO read and write and other operating information of each background module during the process running period and the system operating status information (CPU usage, memory usage, hard disk usage, etc.);

[0031] 28) After obtaining the process monitoring strategy, first determine whether each monitoring process in the strategy is initialized and started successfully, that is, determine whether the program exists based on the PID, and then start cyclically monitoring the running status of the module process.

[0032] Furthermore, the monitoring server is also used to implement automatic detection of the monitoring module, specifically including:

[0033] 31) The monitoring service automatically detects the service modules that have been started in the system deployment environment when it is started;

[0034] 32) Use bus mode or traversal process mode to monitor the recovery of strategy.

[0035] Furthermore, the monitoring server is also used to implement the recovery of the monitoring environment after the monitoring service is restarted, specifically including:

[0036] The primary monitoring server sends PID information to the restarted non-primary monitoring service to restore the monitoring policy of the non-primary monitoring service.

[0037] Furthermore, the monitoring system is also configured as follows:

[0038] 41) The monitoring server receiving thread receives the status data and the log data sent from each of the background modules through UDP communication, and the receiving thread is in UDP server-side working mode;

[0039] 42) The receiving thread puts the state data and the log data into the corresponding global message queue according to the message type.

[0040] Furthermore, the monitoring client is configured as follows:

[0041] 51) Used to maintain the operation of the entire system, including one-key start, one-key stop, and one-key restart of the entire monitoring system and the hedging system;

[0042] 52) Monitoring and operation support single or multiple modules start, restart, stop;

[0043] 53) The control action is performed by sending a control command to a corresponding server, and the monitoring server is responsible for executing the control command;

[0044] Among them, all operations (except stop) are mutually exclusive operations (interface control), and only one client is allowed to perform operations at the same time;

[0045] 54) Provide a module monitoring and operation interface, so that customers can directly observe the operating status, CPU, memory, etc. of each background module;

[0046] 55) Real-time monitoring of the operating status of each target server and each backend module of the hedging system, including the CPU, memory, and hard disk usage information of the target server and the backend module, as well as any warning and error information of the system operation;

[0047] 56) The client may perform fuzzy query to search the log data (eg, the log data of the day).

[0048] Further, the database is configured to include a database log table (ITS_LOG), a monitoring message table (ITS_MONITOR_MESSAGE), a monitoring module list (ITS_MONITOR_MODULES), and a module status monitoring table (ITS_MONITOR_MOUDLE_STATUS).

[0049] The solution of the present invention has the following beneficial effects:

[0050] 1) The monitoring system of the present invention has gotten rid of the previous operation and maintenance method through scripts. Users can configure the required business modules according to the business scenarios on the monitoring client, and then realize the monitoring, control and management of the entire system background modules. The operation is simple and the user's learning cost is effectively reduced.

[0051] 2) The monitoring system of the present invention can store the log information and module status information of each module in a database. When the log information is deleted by mistake, the log information can be viewed through the database. Moreover, the changes in the module status will also be recorded. When the time of the module status change is uncertain, analysis can be performed by checking the database.

[0052] 3) The monitoring system of the present invention operates independently of the hedging system, and the operation of the monitoring system will not affect the operation of the hedging system, so the system reliability is higher. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0054] Figure 1 It is a structural diagram of a backend module operation monitoring system of a hedging system disclosed in an embodiment of the present invention;

[0055] Figure 2 It is a timing diagram of the execution of action commands in the module operation and maintenance control disclosed in the embodiment of the present invention;

[0056] Figure 3 It is a timing relationship diagram of the execution of the monitoring process disclosed in the embodiment of the present invention;

[0057] Figure 4 It is a schematic diagram of two recovery monitoring strategies disclosed in an embodiment of the present invention;

[0058] Figure 5 is a flow chart of monitoring recovery disclosed in an embodiment of the present invention;

[0059] Figure 6 It is a schematic diagram of restoring the monitoring environment after the monitoring service disclosed in the embodiment of the present invention is restarted;

[0060] Figure 7 It is a schematic diagram of a process of restoring a monitoring environment disclosed in an embodiment of the present invention;

[0061] Figure 8 It is a schematic diagram of the log thread operation disclosed in the embodiment of the present invention;

[0062] Fig. 9 This is a diagram of a system start / stop maintenance interface of a monitoring client disclosed in an embodiment of the present invention;

[0063] Fig.10 It is a schematic diagram of an interface for monitoring the operation of a target server by a monitoring client disclosed in an embodiment of the present invention;

[0064] Fig.11 It is a schematic diagram of an interface for performing fuzzy query of logs using a monitoring client disclosed in an embodiment of the present invention. DETAILED DESCRIPTION

[0065] In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0066] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings, and "multiple" generally includes at least two.

[0067] It should be understood that the term "and / or" used in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0068] It should be understood that although the terms first, second, third, etc. may be used to describe ... in the embodiments of the present application, these ... should not be limited to these terms. These terms are only used to distinguish .... For example, without departing from the scope of the embodiments of the present application, the first ... may also be referred to as the second ..., and similarly, the second ... may also be referred to as the first ....

[0069] As used herein, the words "if" and "if" may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to determining" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)", depending on the context.

[0070] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a product or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such a product or system. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the product or system including the elements.

[0071] The preferred embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0072] See also Figure 1 , Figure 1 Schematic diagram of the structure of a backend module operation monitoring system of a hedging system disclosed in an embodiment of the present invention. Figure 1 As shown, a backend module operation monitoring system of a hedging system according to an embodiment of the present invention, the hedging system includes a plurality of target servers;

[0073] The monitoring system includes a monitoring client, a monitoring server, and a database; the monitoring client and the monitoring server complete data interaction through the database;

[0074] The monitoring server is used to provide a reporting monitoring function to each of the target servers, and the reporting monitoring function is used to enable the target server to collect status data and generate log data for each backend module of the hedging system; and receive the status data and log data sent by the target server through the UDP connection; and is also used to store the status data and log data in the database, and push important status data and log data to the monitoring client;

[0075] The monitoring client is used to receive the configuration operation of the customer, generate the reporting monitoring function based on the configuration operation and send it to the monitoring server; and support the customer to query and analyze the status data and the log data, and implement control over each of the background modules.

[0076] In the embodiment of the present invention, the present invention designs a monitoring system independent of the hedging system. The customer can perform configuration operations on the monitoring client according to the monitoring needs, send the generated corresponding reporting monitoring function to the monitoring server, and the monitoring server forwards it to each target server of the hedging system to trigger each target server to collect the status data of each background module and generate log data and send these data to the monitoring server; then, the monitoring server can actively push the important data to the monitoring client, and at the same time, the monitoring client can also actively obtain relevant data, thereby realizing the monitoring and control of the server resource occupancy of the hedging system. The monitoring system of the present invention gets rid of the previous operation and maintenance mode through scripts. The user can configure the required business module according to the business scenario on the monitoring client, thereby realizing the monitoring, control and management of the background module of the entire system, which is simple to operate and effectively reduces the learning cost of the user; the monitoring server also stores the status data and log data of each background module in the database. When the log information is deleted by mistake, the log information can be viewed through the database, and there will also be records of the changes in the module status. When the time of the module status change is uncertain, it can be analyzed by checking the database; and the monitoring system of the present invention operates independently of the hedging system, and the operation of the monitoring system will not affect the operation of the hedging system, and the system reliability is higher.

[0077] Among them, the customer can customize which type of data is important data in the monitoring client, and the monitoring client can also dynamically determine the importance value of various data based on preset rules and then execute push, and the present invention does not limit this.

[0078] Furthermore, there are multiple monitoring servers, and the monitoring servers correspond to the target servers one by one;

[0079] One of the plurality of monitoring servers is configured as a master monitoring server, and the other monitoring servers are configured as slave monitoring servers;

[0080] And, the slave monitoring server sends the server data and background module data of the target server to the master monitoring server.

[0081] In the embodiment of the present invention, a monitoring server can be deployed for each target server to monitor the current target server and the background module deployed thereon. At the same time, each monitoring server can also be divided into a master-slave division, and the slave monitoring server sends its own server data and background module data to the master monitoring server, and the master monitoring server then shares data with the monitoring client through the database, which can significantly improve the working efficiency of the monitoring system.

[0082] Furthermore, the monitoring server is configured to implement a monitoring daemon service, specifically including:

[0083] 1) Provide independent operation and maintenance functions for each of the background modules, including starting and stopping a single background module, and one-key start, one-key stop, and one-key restart and recovery functions for all the background modules;

[0084] 2) Monitor the survival status of all started background modules, and report abnormal process information in a timely manner. If there is any abnormality, automatically maintain the corresponding background module to ensure its normal operation;

[0085] 3) Monitor the CPU load, memory usage and other operating information of all the background module processes, and report to the monitoring client at regular intervals;

[0086] 4) Monitor the target server's CPU load, memory usage, hard disk usage and other system information, and report to the monitoring client at regular intervals;

[0087] 5) The monitoring target server automatically detects the devices that have been started in the environment when it is started, and continues to monitor.

[0088] In an embodiment of the present invention, the monitoring system of the present invention involves the above-mentioned monitoring guardian service, which can monitor the operating status of each background module of the hedging system and the operating status of each target server in real time, as well as the ability to automatically maintain the normal operation of the investment hedging system.

[0089] It should be noted that the function buttons involved in 1) also have mutually exclusive logic control on the monitoring client to ensure the orderly execution of the function commands.

[0090] Furthermore, the monitoring server is also configured to implement module operation and maintenance control, specifically including:

[0091] 11) A monitoring daemon thread is set for each of the background modules, and the monitoring message table is continuously updated by the monitoring daemon thread to monitor the module control request (module start, stop, restart) sent by the monitoring client.

[0092] Among them, since the monitoring client has mutually exclusive logic control, the orderly execution of functional commands is guaranteed, so the request and execution of commands are synchronized. In addition, after receiving the module control request from the monitoring client, the monitoring daemon thread delegates the execution of commands to different objects, thereby isolating the request and execution of commands, and only one monitoring client is allowed to perform control operations at the same time.

[0093] 12) A module process is uniquely identified by the two attributes of group number and device number;

[0094] 13) If the module process is started by the monitoring client sending a command, the monitoring daemon thread determines the group number and device number of the corresponding background module according to the command; after the process is successfully started, the new process monitoring information is saved to the process monitoring strategy queue of the monitoring daemon thread for querying and monitoring the module operation status;

[0095] Among them, in special circumstances, if the customer needs to manually start the module process, and the monitoring daemon thread does not know the group number and device number to which the module belongs, the daemon service supports starting with command line parameters. When starting the module manually, the group number and device number to which the module belongs are needed to start the monitoring module.

[0096] 14) When stopping the module process, first check whether the process exists. If it exists, clear the process and report the process exit status (whether it exits normally) message to the monitoring client, and delete the corresponding monitoring process information in the monitoring thread queue.

[0097] Among them, stopping the module only considers the way that the client sends a command to stop. The client manually stops the process without considering it. Because the monitoring service query finds that the module process does not exist, it will report an abnormal alarm message to the monitoring client and automatically start the module process to maintain the normal operation of the system.

[0098] In the embodiment of the present invention, the timing relationship diagram of the execution of each action command can be referred to Figure 2 shown.

[0099] Furthermore, the monitoring server is also configured to implement module operation status monitoring, specifically including:

[0100] 21) When the monitoring daemon service is initialized, a separate thread is started to monitor the module running status of the background module, and the module running status is regularly reported to the monitoring client so that the monitoring client updates the monitoring information;

[0101] 22) If the module is in an abnormal operating state, immediately report a warning message to the monitoring client; and / or, set a number of safety thresholds on the monitoring client, and if the status data is not within the safety threshold range, issue an alarm to prompt processing;

[0102] 23) Process monitoring strategy, queue for storing process monitoring information;

[0103] 24) After the module operation status monitoring is started, the startup control command issued by the monitoring client is obtained from the database (the command includes the module group number, device number, program name, path, command line parameters, whether automatic restart is required, etc.), and the corresponding background module is started and the corresponding module data is saved to the monitoring strategy (including the module group number, device number, PID, etc.) for use in information collection and reporting;

[0104] 25) When the monitoring client issues a stop command, the monitoring server reads the command from the database and stops the corresponding module and deletes it from the monitoring strategy. From then on, the module operation status monitoring thread no longer collects its status information;

[0105] 26) monitoring the running status of each of the background modules and detecting whether the process of each of the background modules is alive;

[0106] 27) Collecting the CPU load, memory usage, IO read and write and other operating information of each background module during the process running period and the system operating status information (CPU usage, memory usage, hard disk usage, etc.);

[0107] 28) After obtaining the process monitoring strategy, first determine whether each monitoring process in the strategy is initialized and started successfully, that is, determine whether the program exists based on the PID, and then start cyclically monitoring the running status of the module process.

[0108] In the embodiment of the present invention, the timing relationship diagram of monitoring process execution is referred to Figure 3 shown.

[0109] Furthermore, the monitoring server is also used to implement automatic detection of the monitoring module, specifically including:

[0110] 31) The monitoring service automatically detects the service modules that have been started in the system deployment environment when it is started

[0111] 32) Use bus mode or traversal process mode to monitor the recovery of strategy.

[0112] The difference between the above two methods is that the bus method is for modules that depend on the bus. The same service can be deployed multiple times in the entire deployment environment, so the bus needs to provide group numbers and device numbers for distinction and monitoring; while the traversal process method is for individual components, that is, only one such service needs to be deployed and run in the entire deployment environment.

[0113] Furthermore, the monitoring server is also used to implement the recovery of the monitoring environment after the monitoring service is restarted, specifically including:

[0114] The primary monitoring server sends PID information to the restarted non-primary monitoring service to restore the monitoring policy of the non-primary monitoring service.

[0115] In the embodiment of the present invention, since the deployment in the monitoring system is distributed, there will be multiple monitoring services running on different servers, and there is only one monitoring service that receives PID information, namely the main monitoring service (this is set in the bus configuration). Therefore, after the non-main monitoring service is restarted, the main monitoring service needs to send PID information to the restarted non-main monitoring service to restore the monitoring strategy of the non-main monitoring service. For specific strategies and interactive processes for restoring monitoring and restoring the monitoring environment, please refer to Figure 4-7 As shown. Among them, Figure 5 , 7 The commands in 2007 and 2009 are only used to restore the existing monitoring environment and will not disrupt the operation of existing monitoring strategies or environment components.

[0116] Furthermore, the monitoring system is also configured as follows:

[0117] 41) The monitoring server receiving thread receives the status data and the log data sent from each of the background modules through UDP communication, and the receiving thread is in UDP server-side working mode.

[0118] 42) The receiving thread puts the state data and the log data into the corresponding global message queue according to the message type.

[0119] In an embodiment of the present invention, the log thread may be configured as follows:

[0120] The log thread inherits from CThreadBase;

[0121] Init() completes the database connection;

[0122] UnInit() releases database connection resources;

[0123] Run() reads log storage and maintains message queue;

[0124] g_log_data_list performs log storage and maintenance.

[0125] For details about the working status of the log thread, please refer to Figure 8 shown.

[0126] Furthermore, the monitoring client is configured as follows:

[0127] 51) is used to maintain the operation of the entire system, including one-key start, one-key stop, and one-key restart of the entire monitoring system and the hedging system.

[0128] 52) Monitoring and operation support single or multiple modules start, restart, stop;

[0129] 53) The control action is performed by sending a control command to a corresponding server, and the monitoring server is responsible for executing the control command;

[0130] Among them, all operations (except stop) are mutually exclusive operations (interface control), and only one client is allowed to perform the operation at the same time.

[0131] 54) Provide a module monitoring and operation interface, so that customers can directly observe the operating status, CPU, memory, etc. of each background module.

[0132] 55) Real-time monitoring of the operating status of each target server and each backend module of the hedging system, including the CPU, memory, and hard disk usage information of the target server and the backend module, as well as any warning and error information of the system operation.

[0133] 56) The client may perform fuzzy query to search the log data (eg, the log data of the day).

[0134] In an embodiment of the present invention, Figure 9-11 It is one of the interfaces of the monitoring client of the present invention.

[0135] Further, the database is configured to include a database log table (ITS_LOG), a monitoring message table (ITS_MONITOR_MESSAGE), a monitoring module list (ITS_MONITOR_MODULES), and a module status monitoring table (ITS_MONITOR_MOUDLE_STATUS).

[0136] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present invention, all of which belong to the scope of protection of the present invention.

Claims

1. A hedging system backend module operation monitoring system, the operation monitoring system is set up independently of the hedging system, and the hedging system includes multiple target servers; characterized in that: The monitoring system includes a monitoring client, a monitoring server, and a database; the monitoring client and the monitoring server complete data interaction through the database; The monitoring server is used to provide a reporting monitoring function to each of the target servers, and the reporting monitoring function is used to enable the target server to collect status data and generate log data for each backend module of the hedging system; and receive the status data and log data sent by the target server through the UDP connection; and is also used to store the status data and log data in the database, and push important status data and log data to the monitoring client; The monitoring client is used to receive the configuration operation of the customer, generate the reporting monitoring function based on the configuration operation and send it to the monitoring server; and support the customer to query and analyze the status data and the log data, and implement control over each of the backend modules; There are multiple monitoring servers, and each monitoring server corresponds to each target server one by one; One of the plurality of monitoring servers is configured as a master monitoring server, and the other monitoring servers are configured as slave monitoring servers; And, the slave monitoring server sends the server data and the backend module data of the target server to the master monitoring server; The monitoring server is configured to implement monitoring daemon services, specifically including: 1) Provide independent operation and maintenance functions for each of the background modules, including starting and stopping a single background module, and one-key start, one-key stop, and one-key restart and recovery functions for all the background modules; 2) Monitor the survival status of all started background modules, and report abnormal process information in a timely manner. If there is any abnormality, automatically maintain the corresponding background module to ensure its normal operation; 3) Monitor the CPU load and memory usage of all the background module processes and report them to the monitoring client at regular intervals; 4) Monitor the CPU load, memory usage, and hard disk usage system information of the target server, and report to the monitoring client at regular intervals; 5) The monitoring target server automatically detects the devices that have been started in the environment when it is started, and continues to monitor; The monitoring server is also configured to implement module operation and maintenance control, specifically including: 11) Setting a monitoring daemon thread for each of the background modules, continuously updating the monitoring message table through the monitoring daemon thread, and monitoring the module control request sent by the monitoring client; 12) A module process is uniquely identified by the two attributes of group number and device number; 13) If the module process is started by the monitoring client sending a command, the monitoring daemon thread determines the group number and device number of the corresponding background module according to the command; after the process is successfully started, the new process monitoring information is saved to the process monitoring strategy queue of the monitoring daemon thread for querying and monitoring the module operation status; 14) When stopping a module process, first check whether the process exists, if so, clear the process, report the process exit status message to the monitoring client, and delete the corresponding monitoring process information in the monitoring thread queue; The monitoring server is also configured to implement module operation status monitoring, specifically including: 21) When the monitoring daemon service is initialized, a separate thread is started to monitor the module running status of the background module, and the module running status is regularly reported to the monitoring client so that the monitoring client updates the monitoring information; 22) If the module is in an abnormal operating state, immediately report a warning message to the monitoring client; and / or, set a number of safety thresholds on the monitoring client, and if the status data is not within the safety threshold range, issue an alarm to prompt processing; 23) Process monitoring strategy, queue for storing process monitoring information; 24) After the module operation status monitoring is started, the startup control command issued by the monitoring client is obtained from the database, and after the corresponding background module is started, the corresponding module data is saved to the monitoring strategy for use in information collection and reporting; 25) When the monitoring client issues a stop command, the monitoring server reads the command from the database and stops the corresponding module and deletes it from the monitoring strategy. From then on, the module operation status monitoring thread no longer collects its status information; 26) monitoring the running status of each of the background modules and detecting whether the process of each of the background modules is alive; 27) Collecting the CPU load, memory usage, IO read and write operation information and system operation status information of each background module during the process operation period; 28) After obtaining the process monitoring strategy, first determine whether each monitoring process in the strategy is successfully initialized, that is, determine whether the program exists according to the PID, and then start cyclically monitoring the running status of the module process; The monitoring server is also used to implement automatic detection of the monitoring module, specifically including: 31) The monitoring service automatically detects the service modules that have been started in the system deployment environment when it is started; 32) Use bus mode or traversal process mode to monitor the recovery of strategy; The monitoring server is also used to implement the recovery of the monitoring environment after the monitoring service is restarted, specifically including: The primary monitoring server sends PID information to the restarted non-primary monitoring service to restore the monitoring policy of the non-primary monitoring service; The monitoring system is also configured to: 41) The monitoring server receiving thread receives the status data and the log data sent from each of the background modules through UDP communication, and the receiving thread is in UDP server-side working mode; 42) The receiving thread puts the state data and the log data into the corresponding global message queue according to the message type; The monitoring client is configured as follows: 51) Used to maintain the operation of the entire system, including one-key start, one-key stop, and one-key restart of the entire monitoring system and the hedging system; 52) Monitoring and operation support single or multiple modules start, restart, stop; 53) The control action is performed by sending a control command to a corresponding server, and the monitoring server is responsible for executing the control command; Among them, all operations are mutually exclusive operations, and only one client is allowed to perform an operation at the same time; 54) Provide a module monitoring and operation interface, so that customers can directly observe the operating status, CPU, and memory of each background module; 55) Real-time monitoring of the operating status of each target server and each backend module of the hedging system, including the CPU, memory, and hard disk usage information of the target server and the backend module, as well as any warning and error information of the system operation; 56) Customers can use fuzzy query to search the log data; The database is configured to include a database log table, a monitoring message table, a monitoring module list, and a module status monitoring table.

Images