CN114924850A - Software monitoring recovery method, electronic equipment and storage medium - Google Patents

Software monitoring recovery method, electronic equipment and storage medium Download PDF

Info

Publication number
CN114924850A
CN114924850A CN202210483649.8A CN202210483649A CN114924850A CN 114924850 A CN114924850 A CN 114924850A CN 202210483649 A CN202210483649 A CN 202210483649A CN 114924850 A CN114924850 A CN 114924850A
Authority
CN
China
Prior art keywords
monitoring
functional
thread
state quantity
thread state
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210483649.8A
Other languages
Chinese (zh)
Inventor
郑腾龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wangsu Science and Technology Co Ltd
Original Assignee
Wangsu Science and Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wangsu Science and Technology Co Ltd filed Critical Wangsu Science and Technology Co Ltd
Priority to CN202210483649.8A priority Critical patent/CN114924850A/en
Publication of CN114924850A publication Critical patent/CN114924850A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The embodiment of the invention relates to the field of computer processing, and discloses a software monitoring recovery method, electronic equipment and a storage medium. In the invention, a monitoring process acquires monitoring parameters and initiates a state query request to a first function process according to a query mode in the monitoring parameters; the first functional process feeds back the thread state quantity corresponding to the state query request to the monitoring process; the thread state quantity is provided for the functional thread corresponding to the first functional process and is used for reflecting the running state of the functional thread; and the monitoring process determines a processing mode of the first function process according to the thread state quantity and the monitoring threshold value in the monitoring parameters. The running state of the software is monitored and judged according to the thread state quantity of the functional thread, the query granularity is finer, and the accuracy of obtaining the running state of the software can be ensured; meanwhile, the monitoring parameters do not need to be developed in advance and correspondingly debugged in the monitoring process, and the manpower and material resource investment in the development and test stages is reduced.

Description

Software monitoring recovery method, electronic equipment and storage medium
Technical Field
The embodiments of the present invention relate to computer processing, and in particular, to a method for monitoring and recovering software, an electronic device, and a storage medium.
Background
With the development of technology, the use of multi-process software is increasingly widespread. For software consisting of a plurality of processes, because a plurality of processes need to be called in operation, some processes are prone to be trapped in errors due to problems of system environment, time sequence, calling interfaces and the like, including but not limited to deadlock, dead loop deadlock and the like, and the software cannot work normally. For this reason, the multiprocess software needs to be monitored to ensure that the process can be executed normally.
Currently, most of monitoring measures taken for multi-process software are to acquire the running state of a process so as to judge whether recovery operations such as restarting are needed or not.
Disclosure of Invention
The embodiment of the invention aims to provide a software monitoring and recovering method, electronic equipment and a storage medium, which are used for managing multi-process software, ensuring the running state of the multi-process software and improving user experience.
In order to solve the above technical problem, an embodiment of the present invention provides a method for monitoring and recovering software, which is applied to a monitoring process, a first functional process, and a functional thread corresponding to the first functional process, and includes the following steps: the monitoring process acquires the monitoring parameters and initiates a state query request to the first function process according to a query mode in the monitoring parameters; the first functional process feeds back the thread state quantity corresponding to the state query request to the monitoring process; the thread state quantity is provided for the functional thread corresponding to the first functional process and is used for reflecting the running state of the functional thread; and the monitoring process determines a processing mode of the first function process according to the thread state quantity and the monitoring threshold value in the monitoring parameter.
An embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively coupled to the at least one processor; the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the software monitoring recovery method.
The embodiment of the invention also provides a computer readable storage medium, which stores a computer program, and is characterized in that the computer program is executed by a processor to realize the monitoring and recovering method of the software.
In the embodiment of the application, the thread state quantity of the functional thread corresponding to the first functional process to be monitored is obtained, and the thread state quantity is used for representing the running state of the functional thread, so that the running state of the first functional process is represented through the running state of the functional thread. Compared with a mode of directly observing the operation result of the first function process to judge the operation state of the first function process, the method and the device for monitoring the first function process have the advantages that the granularity of monitoring the first function process is finer, and the judgment on the operation state of the first function process is more accurate. Meanwhile, monitoring parameters for monitoring the first function process do not need to be fixedly set in the monitoring process, flexible acquisition is supported when the monitoring process needs to monitor the first function process, the complexity of development and test of the monitoring process is reduced, the project cycle is shortened, and the user experience is improved.
Drawings
One or more embodiments are illustrated by way of example in the accompanying drawings, which correspond to the figures in which like reference numerals refer to similar elements and which are not to scale unless otherwise specified.
FIG. 1 is a flow chart of a proposed method for monitoring recovery of software according to one embodiment of the present application;
FIG. 2 is a first schematic diagram of a monitoring recovery method for software according to an embodiment of the present application;
FIG. 3 is a second schematic diagram of a monitoring recovery method for software according to an embodiment of the present application;
fig. 4 is a schematic diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention more apparent, embodiments of the present invention will be described in detail below with reference to the accompanying drawings. However, it will be appreciated by those of ordinary skill in the art that numerous technical details are set forth in order to provide a better understanding of the present application in various embodiments of the present invention. However, the technical solution claimed in the present application can be implemented without these technical details and various changes and modifications based on the following embodiments. The following embodiments are divided for convenience of description, and should not constitute any limitation to the specific implementation manner of the present invention, and the embodiments may be mutually incorporated and referred to without contradiction.
The terms "first" and "second" in the embodiments of the present application are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present application, the terms "comprise" and "have", as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a system, product or apparatus that comprises a list of elements or components is not limited to only those elements or components but may alternatively include other elements or components not expressly listed or inherent to such product or apparatus. In the description of the present application, "plurality" means at least two, e.g., two, three, etc., unless explicitly specifically limited otherwise.
One embodiment of the invention relates to a software monitoring and recovering method, which is applied to a monitoring process, a first functional process and a functional thread corresponding to the first functional process. The specific flow is shown in figure 1.
Step 101, a monitoring process acquires a monitoring parameter and initiates a state query request to a first function process according to a query mode in the monitoring parameter.
102, the first function process feeds back a thread state quantity corresponding to the state query request to the monitoring process; the thread state quantity is provided for the functional thread corresponding to the first functional process and is used for reflecting the running state of the functional thread.
And 103, the monitoring process determines a processing mode of the first function process according to the thread state quantity and the monitoring threshold value in the monitoring parameter.
In this embodiment, a thread state quantity of a functional thread corresponding to a first functional process to be monitored is obtained, where the thread state quantity is used to represent a running state of the functional thread, and further represents the running state of the first functional process through the running state of the functional thread. Compared with a mode of directly observing the operation result of the first function process to judge the operation state of the first function process, the method and the device for monitoring the first function process have the advantages that the granularity of monitoring the first function process is finer, and the judgment on the operation state of the first function process is more accurate. Meanwhile, monitoring parameters for monitoring the first function process do not need to be fixedly set in the monitoring process, flexible acquisition is supported when the monitoring process needs to monitor the first function process, the complexity of development and test of the monitoring process is reduced, the project cycle is shortened, and the user experience is improved.
The following describes implementation details of the monitoring and recovering method for software according to this embodiment in detail, and the following description is only provided for facilitating understanding of the implementation details and is not necessary for implementing this embodiment.
In step 101, the monitoring process obtains the monitoring parameters, and initiates a status query request to the first functional process according to the query mode in the monitoring parameters.
The monitoring process is used for monitoring the functional process and ensuring the stable operation of the functional process. One monitoring process can monitor a plurality of functional processes, the first functional process is one of the functional processes or one type of functional process, and the number of the functional processes monitored by the monitoring process is not limited in this embodiment. The monitoring process runs stably, has the capability of autonomously recovering from the abnormity, and can ensure the stability of the monitoring function process. The functional process is a process for providing software functions in the software running process, is a running activity of a program with certain independent functions on a certain data set, and is an independent unit for resource allocation and scheduling of the system.
Specifically, for each function process including the first function process, the monitoring process may store the monitoring parameters corresponding to each function process, including the query mode, or may not fix the monitoring parameters corresponding to each built-in function process. Optionally, data related to the query mode corresponding to each functional process is carried in the monitoring parameter, and the monitoring parameter is stored in the device supporting communication transmission with the monitoring process. In the actual operation process of this embodiment, the monitoring parameter is obtained first, and a status query request is initiated to the first functional process according to the query mode in the monitoring parameter. Because fixed monitoring parameters corresponding to the first function process do not need to be preset, the storage and acquisition of the monitoring parameters are more flexible, namely, the monitoring process and each function process including the first function process do not have necessary binding relationship; therefore, under the condition that the corresponding query mode is not built in the monitoring process, the monitoring parameters including the query mode do not need to be considered for research, development and debugging of the monitoring process, and only a data interface for receiving the monitoring parameters is provided, so that the working complexity of research and development personnel can be reduced, the error probability in actual operation is reduced, and the project cycle is shortened. Meanwhile, the function process which is required to be monitored by the monitoring process can be changed by changing the monitoring parameters according to actual needs, or the process for monitoring the first function process is changed, so that the relation between the monitoring process and the function process can be adjusted more conveniently.
In one example, the monitoring process obtains monitoring parameters, including: and the monitoring process acquires the monitoring parameters according to the configuration file and the first function process. Specifically, the monitoring parameter may be stored in a configuration file and a first function process, and is used to provide a query mode for the monitoring process. The monitoring parameters can be stored in the configuration file and the first function process in a complete or block mode, and the specific storage position can be adaptively changed according to actual needs (such as test research and development difficulty, user requirements and the like). Optionally, control parameters related to all the functional processes are stored in a configuration file, so that the monitoring process can be called quickly; and storing the individualized control parameters of the first functional process in the first functional process, so that the first functional process can be conveniently and specifically debugged.
In one example, the monitoring process obtains the monitoring parameters according to the configuration file, including: the monitoring process acquires a monitoring threshold value in the monitoring parameters and the influence range of each functional process through the configuration file; the scope of influence includes all functional processes affected by the fault condition of the first functional process.
The monitoring threshold is the number of times that the thread state quantity of the functional thread is allowed to be unchanged. The influence range includes: after the first functional process fails, all functional processes that need to be adjusted, the specific manner of adjustment includes but is not limited to restart. One functional process may correspond to a plurality of functional threads, which are one or more entities of the functional process, and are the basic unit of CPU scheduling and dispatch, which is a smaller unit capable of independent operation than the functional process.
Specifically, the monitoring threshold and the influence range of the monitoring process on the first function process are prestored in the configuration file. After the monitoring process acquires the thread state quantity for multiple times, when the number of times that the thread state quantity remains unchanged exceeds a monitoring threshold value, judging a functional thread fault corresponding to the thread state quantity, namely a first functional process fault; or after the first functional process is judged to be failed, all functional processes within the influence range of the first functional process are adjusted.
In some practical applications, the operating state of the software is determined by intuitive software function implementation of the functional process, for example, the operating state of the software is determined by directly observing whether the operating result of the functional process meets the expectation. However, if the expectation of the functional process is a suspended or suspended state, there are two cases, namely a current suspended state obtained by normal operation of the functional process or a suspended state obtained by abnormal conditions such as deadlock in the functional process; the former is the case that the function process operates normally, and the latter is the case that the function process operates in failure, and cannot be distinguished and processed effectively. If the fault is not handled, the operation fault affects the functional process related to the functional process, and further, if the user does not perceive that the software has a fault in operation, the software is broken down and the like, which seriously affects the use. In this embodiment, whether the running of the functional process fails or not is embodied according to the running state of the functional thread, and compared with a mode of determining the running state of the software by directly observing the software function implementation condition of the functional process, the method monitors the software implementation with finer granularity, can ensure the monitoring efficiency of the running state of the software, and improves the user experience.
In one example, the monitoring process obtains the monitoring parameters according to the configuration file, and further includes: the monitoring process acquires the monitoring type in the monitoring parameters through the configuration file; the monitoring type is an evaluation rule for the thread state quantity, and the evaluation rule comprises the following steps: whether the thread state quantity exists, whether the thread state quantity changes or not, or whether the change value of the thread state quantity is within a preset range.
Specifically, the configuration file may further pre-store a monitoring type, where the monitoring type is an evaluation rule of the monitoring process on the thread state quantity of the functional thread corresponding to the first functional process. The evaluation rule may include whether the thread state quantity exists, whether the thread state quantity changes, or whether a change value of the thread state quantity is within a preset range. For example, if the thread state quantity exists, the functional thread is normal; if the thread state quantity changes, the functional thread is normal; or the change value of the thread state quantity is within a preset range, the thread state quantity is normal. It is to be understood that the above evaluation rules support free combination according to actual requirements, and the evaluation rules are not limited to the above examples, and it is sufficient if the operating state of the functional thread or the functional process is normal or faulty based on the thread state quantity.
In addition, the monitoring parameters in the configuration file may further include a time interval for the monitoring process to initiate a status query request to the first functional process. The time interval enables the monitoring process to regularly acquire the thread state quantity, and is convenient for acquiring the running state of the functional thread in time.
In one example, the acquiring, by the monitoring process, the monitoring parameter according to the first functional process includes: the monitoring process acquires a query mode of the first function process in the monitoring parameters according to the first function process; the query mode in the monitoring process is obtained by receiving a first message sent by the first functional process to the monitoring process.
The query mode of the first functional process comprises the thread name, the thread ID and the thread state quantity of each functional thread corresponding to the first functional process. The thread name supports a user or a developer to carry out adaptive modification according to use habits, the thread ID is the unique identification of the functional thread, and the thread state quantity can be a preset independent variable or a specific parameter in the functional thread is taken as the thread state quantity. The query mode is carried in a first message sent by the first functional process to the monitoring process, and the first message can be sent to the monitoring process by the first functional process when the monitoring process is identified to exist; or after the monitoring process sends the monitoring instruction to the first functional process, the first functional process feeds back the first message to the monitoring process according to the monitoring instruction.
Specifically, the query mode includes relevant information of the functional thread corresponding to the first functional process, so that the state query request can accurately query the operating state of the functional thread corresponding to the first functional process, and the relevant information of the functional thread in the query mode can be prestored in the first functional process. It can be understood that, in the query mode that the monitoring process needs to acquire, all the functional threads corresponding to the first functional process are allowed to be excluded, and only the functional threads capable of reflecting the operating state of the first functional process are required to be included.
In addition, the monitoring type may also be pre-stored in the first functional process, and the monitoring process obtains the monitoring type through feedback of the first functional process.
In step 102, the first functional process feeds back a thread state quantity corresponding to the state query request to the monitoring process; the thread state quantity is provided for the functional thread corresponding to the first functional process and is used for reflecting the running state of the functional thread. Specifically, the thread state quantity is used for embodying the running state of the functional thread, and the running state of the first functional process can be inferred through the running state of the functional thread, so that the monitoring process can judge the running state of the first functional process by acquiring the thread state quantity of the functional thread corresponding to the first functional process. The first functional process feeds back the process of the thread state quantity to the monitoring process, for example, the first functional process may query the thread state quantity of the functional thread in real time according to the state query request and feed it back to the monitoring process.
In one example, the feeding back, by the first functional process, the thread state quantity corresponding to the state query request to the monitoring process includes: the first functional process acquires the thread state quantity corresponding to the state query request from the thread state quantity periodically fed back by the functional thread cached locally according to the state query request; and feeding back the thread state quantity corresponding to the state query request to the monitoring process.
Specifically, the process of feeding back the thread state quantity to the first function process by the function thread may be performed periodically, that is, the function thread has a preset feedback time interval, and the function thread feeds back the thread state quantity to the first function process according to the feedback time interval. The function thread does not need to respond to the real-time query of the first function process, and only needs to feed back the thread state quantity according to the preset feedback time interval, so that the function thread does not need to research, develop and debug the real-time query function of the feedback first function process, the real-time query of the first function process does not need to be additionally received and fed back in the running process, the running process is more stable, and the fault rate of the function thread can be reduced.
After the functional thread feeds back the thread state quantity to the first functional process according to the preset feedback time interval, the first functional process can store the thread state quantity to the local, and after receiving a state query request of the monitoring process, the thread state quantity corresponding to the state query request is fed back to the monitoring process.
In one example, the thread state quantity is used for embodying the running state of the functional thread, and comprises the following steps: the thread state quantity is determined by a circulation module in the running process of the functional thread, and under the condition that the circulation module runs, the thread state quantity is updated.
Specifically, the present embodiment reflects the operating state of the functional thread by the thread state quantity. The thread state quantity is an independent variable in a circulation module in the running process of the functional thread or an independent variable determined by the running state of the circulation module; in the case where the loop module is operating normally, the argument as the thread state quantity can be updated normally.
In one example, the thread state quantities include: a timestamp or a preset argument. For example, in the case of a functional thread running normally, the time stamp in the loop module is self-increasing; or identifying the independent variable increase of the running times of the loop module under the condition that the functional thread runs normally. The specific thread state quantity can be set according to actual requirements.
In addition, different functional threads corresponding to the same first functional process may have different thread state quantities, and different functional processes are allowed to correspond to different monitoring types.
In step 103, the monitoring process determines a processing manner for the first functional process according to the thread state quantity and the monitoring threshold in the monitoring parameter. Specifically, after the first functional process is judged to have a fault according to the thread state quantity and the monitoring threshold, a preset recovery mode may be adopted.
In one example, under the condition that the monitoring process acquires the monitoring type in the monitoring parameter through the configuration file, the monitoring process judges the running state of the functional thread according to the thread state quantity, the monitoring threshold value and the monitoring type in the monitoring parameter; and determining the processing mode of each functional process in the influence range corresponding to the first functional process according to the running state of the functional thread.
Specifically, the monitoring process obtains the thread state quantity of the functional thread through the feedback of the first functional process to the state query request, and obtains the monitoring type through the configuration file. And under the condition that the times that the thread state quantity is kept unchanged does not exceed the monitoring threshold, judging whether the thread state quantity is normal according to the monitoring type, and further judging whether the first function process is normal. The judgment of the thread state quantity through the monitoring type has more pertinence and meets the requirements of users.
In one example, when the monitoring process obtains the monitoring threshold and the influence range of each function process in the monitoring parameter through the configuration file, the monitoring process determines, according to the thread state quantity and the monitoring threshold in the monitoring parameter, a processing manner for each function process within the influence range corresponding to the first function process.
Specifically, the influence scope includes each functional process that may be influenced after the failure of the first functional process, and therefore, after it is determined that the first functional process fails, recovery measures need to be taken on all functional processes within the influence scope, for example, parameters related to the first functional process in each functional process are changed, program running related to the first functional process is suspended, and the like. The recovery mode can be preset according to actual conditions, and the recovery mode can also be preset in the first function process or the configuration file and is obtained when the monitoring process obtains the monitoring parameters.
For the sake of understanding, the above solution is described below with a specific implementation process, and the structures between the monitoring process, the functional process and the functional thread are shown in fig. 2.
Before monitoring is performed, a function for updating the thread state quantity needs to be written into a code of a thread corresponding to a functional process, and is generally added in a loop of the thread, so that the thread which normally runs can always update the thread state quantity, and the thread state quantity refers to a value which can be changed constantly along with the running of the thread, and can be a timestamp, an argument or the like. Assuming that the thread state quantity uses the timestamp, the first functional process to be monitored is a functional process a, the functional process a needs a monitored function a1, and assuming that there are two flows F1 and F2 in the main loop of the functional thread a1, the function U for updating the thread state quantity is added thereto, so that there are three flows U, F1 and F2 in the main loop of the functional thread a 1. Thus, during the running of functional thread a1, U can always be executed, thereby updating the timestamp, i.e., updating the thread state quantity. If functional thread A1 runs and finds that it is not running to U, then the thread should be in some exception state.
The functional process needs to record all thread names, thread IDs, monitoring types (optional) and monitoring thresholds (optional) which need to be monitored. The monitoring type is a judgment standard for the thread state quantity, such as whether the thread state quantity changes or whether the thread exists. The monitoring threshold refers to the number of times the thread state quantity is allowed to be constant. The monitoring process uses the default configuration or reads the configuration file to determine: monitoring type, monitoring threshold, time interval for initiating state query and influence range of function process. The influence scope refers to whether the functional process influences the normal operation of other functional processes. The monitoring process initiates state inquiry to the function process at regular time, and the function process transmits information such as the thread name, the thread ID, the thread state quantity and the like which are recorded by the function process and need to be monitored to the monitoring process.
In the specific execution process, the functional process a initiates interaction with the monitoring process, and feeds back the query method through the first message. The flow is shown in fig. 3.
And all information can be recorded by the monitoring process when the information fed back by the functional thread A according to the state query request is acquired for the first time. If the monitoring type is whether the thread state quantity exists, the monitoring process determines whether the functional process A fails according to whether the thread state quantity exists, and further determines whether all the functional processes within the influence range of the functional process A are restarted according to the influence range of the functional process A. For example: the monitoring process is S, a function process A and a function process B are monitored, the A has a function thread A1, whether the monitoring type of the thread state quantity in A1 exists or not is judged, and the influence range of the A is all the function processes; s receives the record information of A for the first time, and does not find the thread state quantity of A1, then S restarts all functional processes according to the influence range of A.
And subsequently acquiring information fed back by the functional thread A, if the monitoring type is that whether the thread state quantity changes, comparing the current thread state quantity with the last thread state quantity by the monitoring process, if the current thread state quantity is the same as the last thread state quantity, updating the times that the thread state quantity is not changed by the monitoring process, if the updated times is greater than a monitoring threshold value, judging that the functional thread A1 has a fault, and determining the functional process needing to be restarted according to the influence range of the functional thread A. For example: the monitoring process is S, the functional process A and the functional process B are monitored, the A has a functional thread A1, the monitoring type of the thread state quantity of the A1 is whether the thread state quantity changes, the monitoring threshold value of the A1 is N, and the influence range of the A is A per se; at the N +1 th time of S, it is found that the thread state quantity of a1 is still unchanged, and then S restarts the functional process a according to the influence range of a.
After the functional thread is restarted, the monitoring process is executed again.
In this embodiment, the monitoring process obtains a thread state quantity of a functional thread corresponding to the functional process, and evaluates the thread state quantity through the monitoring parameter to determine a processing mode of the functional process, such as restart; the software availability is monitored and judged according to the state of the functional thread, the query granularity is finer, and the accuracy of acquiring the software running state can be ensured. The thread state quantity can be a timestamp of a functional thread, and the timestamp is compared before and after for many times to determine the thread activity state, so that whether the process is restarted or not is determined, and the software can realize self-recovery. In addition, the monitoring parameters are acquired from the outside for the monitoring process, the corresponding monitoring parameters can be provided according to actual requirements when the monitoring function is needed, the monitoring parameters can be in a packaging form, the monitoring parameters do not need to be developed in advance in the monitoring process and correspondingly debugged, and the manpower and material resources investment in the development and testing stage is reduced.
The steps of the above methods are divided for clarity, and the implementation may be combined into one step or split some steps, and the steps are divided into multiple steps, so long as the same logical relationship is included, which are within the scope of the present patent; it is within the scope of the patent to add insignificant modifications to the algorithms or processes or to introduce insignificant design changes to the core design without changing the algorithms or processes.
One embodiment of the invention relates to an electronic device, as shown in fig. 4, comprising at least one processor 301; and a memory 302 communicatively coupled to the at least one processor 301; the memory 302 stores instructions executable by the at least one processor 301, and the instructions are executed by the at least one processor 301, so that the at least one processor 301 can perform the monitoring recovery method of the software.
Where the memory and processor are connected by a bus, the bus may comprise any number of interconnected buses and bridges, the buses connecting together one or more of the various circuits of the processor and the memory. The bus may also connect various other circuits such as peripherals, voltage regulators, power management circuits, etc., which are well known in the art, and therefore, will not be described any further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver may be one element or a plurality of elements, such as a plurality of receivers and transmitters, providing a means for communicating with various other apparatus over a transmission medium. The data processed by the processor is transmitted over a wireless medium via an antenna, which further receives the data and transmits the data to the processor.
The processor is responsible for managing the bus and general processing and may also provide various functions including timing, peripheral interfaces, voltage regulation, power management, and other control functions. And the memory may be used to store data used by the processor in performing operations.
One embodiment of the present invention relates to a computer-readable storage medium storing a computer program. The computer program realizes the above-described method embodiments when executed by a processor.
That is, as can be understood by those skilled in the art, all or part of the steps in the method for implementing the embodiments described above may be implemented by a program instructing related hardware, where the program is stored in a storage medium and includes several instructions to enable a device (which may be a single chip, a chip, or the like) or a processor (processor) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
It will be understood by those of ordinary skill in the art that the foregoing embodiments are specific examples of practicing the invention, and that various changes in form and detail may be made therein without departing from the spirit and scope of the invention in practice.

Claims (10)

1. A monitoring recovery method of software is applied to a monitoring process, a first functional process and a functional thread corresponding to the first functional process, and the method comprises the following steps:
the monitoring process acquires monitoring parameters and initiates a state query request to the first function process according to a query mode in the monitoring parameters;
the first functional process feeds back the thread state quantity corresponding to the state query request to the monitoring process; the thread state quantity is provided for a functional thread corresponding to the first functional process and is used for reflecting the running state of the functional thread;
and the monitoring process determines a processing mode of the first functional process according to the thread state quantity and the monitoring threshold value in the monitoring parameter.
2. The method for monitoring and recovering software according to claim 1, wherein the first functional process feeds back a thread state quantity corresponding to the state query request to the monitoring process; the thread state quantity is provided for the functional thread corresponding to the first functional process, and comprises the following steps:
the first functional process acquires the thread state quantity corresponding to the state query request from the thread state quantity periodically fed back by the functional thread cached locally according to the state query request;
and feeding back the thread state quantity corresponding to the state query request to the monitoring process.
3. The method for monitoring and recovering software according to claim 1, wherein the thread state quantity is used for representing the running state of the functional thread, and includes:
the thread state quantity is determined by a circulation module in the running process of the functional thread, and the thread state quantity is updated under the condition that the circulation module runs.
4. The method for monitoring and recovering software according to claim 1, wherein the monitoring process obtains monitoring parameters, including:
and the monitoring process acquires the monitoring parameters according to the configuration file and the first functional process.
5. The method for monitoring and recovering software according to claim 4, wherein the step of acquiring the monitoring parameters by the monitoring process according to the configuration file comprises:
the monitoring process obtains a monitoring threshold value in the monitoring parameters and the influence range of each functional process through the configuration file; the scope of influence includes all functional processes affected by a fault condition of the first functional process;
the monitoring process determines a processing mode of the first function process according to the thread state quantity and the monitoring threshold value in the monitoring parameter, and the processing mode comprises the following steps:
and the monitoring process determines the processing mode of each functional process in the influence range corresponding to the first functional process according to the thread state quantity and the monitoring threshold value in the monitoring parameter.
6. The method for monitoring and recovering software according to claim 4, wherein the acquiring, by the monitoring process, the monitoring parameter according to the first functional process includes:
the monitoring process acquires the query mode of the first function process in the monitoring parameters according to the first function process; and the query mode in the monitoring process is acquired by receiving a first message sent by the first functional process to the monitoring process.
7. The method for monitoring and recovering software according to claim 5, wherein the monitoring process obtains the monitoring parameters according to a configuration file, and further comprising:
the monitoring process acquires the monitoring type in the monitoring parameters through the configuration file; the monitoring type is an evaluation rule for the thread state quantity, and the evaluation rule comprises the following steps: whether the thread state quantity exists, whether the thread state quantity changes or not, or whether the change value of the thread state quantity is within a preset range;
the monitoring process determines, according to the thread state quantity and the monitoring threshold in the monitoring parameter, a processing manner for each functional process within an influence range corresponding to the first functional process, including:
the monitoring process judges the running state of the functional thread according to the thread state quantity, the monitoring threshold value in the monitoring parameter and the monitoring type;
and determining a processing mode of each functional process in the influence range corresponding to the first functional process according to the running state of the functional thread.
8. The method for monitoring and recovering software according to any one of claims 1 to 7, wherein the thread state quantity comprises: a timestamp or a preset argument.
9. An electronic device, comprising:
at least one processor; and (c) a second step of,
a memory communicatively coupled to the at least one processor; wherein, the first and the second end of the pipe are connected with each other,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a method of monitoring recovery of software according to any of claims 1 to 8.
10. A computer-readable storage medium, storing a computer program, wherein the computer program, when executed by a processor, implements a monitoring recovery method for software according to any one of claims 1 to 8.
CN202210483649.8A 2022-05-05 2022-05-05 Software monitoring recovery method, electronic equipment and storage medium Pending CN114924850A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210483649.8A CN114924850A (en) 2022-05-05 2022-05-05 Software monitoring recovery method, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210483649.8A CN114924850A (en) 2022-05-05 2022-05-05 Software monitoring recovery method, electronic equipment and storage medium

Publications (1)

Publication Number Publication Date
CN114924850A true CN114924850A (en) 2022-08-19

Family

ID=82806096

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210483649.8A Pending CN114924850A (en) 2022-05-05 2022-05-05 Software monitoring recovery method, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN114924850A (en)

Similar Documents

Publication Publication Date Title
US7082555B2 (en) Computer system dynamically adding and deleting software modules
US9983924B2 (en) Analytics platform for automated diagnosis, remediation, and proactive supportability
EP3591485B1 (en) Method and device for monitoring for equipment failure
US20030051188A1 (en) Automated software testing management system
CN111416821A (en) Internet of things equipment information acquisition method, system and device
CN104423981A (en) BMC (Baseboard Management Controller) firmware automatic update system and method
CN110502366B (en) Case execution method, device, equipment and computer readable storage medium
CN110895488B (en) Task scheduling method and device
US20040205167A1 (en) Automatic configuration of performance management tools
CN111026735B (en) Data transmission method, device, equipment and medium
CN110109741B (en) Method and device for managing circular tasks, electronic equipment and storage medium
CN107729213B (en) Background task monitoring method and device
CN112948189B (en) Margin test method, margin test system and related device
JP2003173272A (en) Information processing system, information processor and maintenance center
CN114924850A (en) Software monitoring recovery method, electronic equipment and storage medium
US11314670B2 (en) Method, apparatus, and device for transmitting file based on BMC, and medium
US20210337011A1 (en) Method, apparatus, and device for transmitting file based on bmc, and medium
CN109324834A (en) A kind of system and method that distributed storage server is restarted automatically
CN115098138A (en) Function upgrading method and device of battery management system, electronic equipment and medium
US20090083747A1 (en) Method for managing application programs by utilizing redundancy and load balance
CN114791900A (en) Operator-based Redis operation and maintenance method, device, system and storage medium
CN110188008B (en) Job scheduling master-slave switching method and device, computer equipment and storage medium
CN111506422B (en) Event analysis method and system
CN109144788B (en) Method, device and system for reconstructing OSD
CN113553243A (en) Remote error detection method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination