CN115718689A

CN115718689A - Method and device for monitoring service state

Info

Publication number: CN115718689A
Application number: CN202211496110.2A
Authority: CN
Inventors: 宋利冬; 纪光闪
Original assignee: Qichacha Technology Co ltd
Current assignee: Qichacha Technology Co ltd
Priority date: 2022-11-25
Filing date: 2022-11-25
Publication date: 2023-02-28

Abstract

The present application relates to the field of data processing technologies, and in particular, to a method and an apparatus for monitoring a service status. The method comprises the following steps: if the service monitoring requirement exists, determining a thread call log of a service thread corresponding to the service to be monitored; determining a task to be monitored according to the subtask execution state recorded by the thread calling log; the subtasks are tasks corresponding to each service processing flow of the service to be monitored; calling a service thread, and executing a task to be monitored; and updating the thread call log according to the execution result of the task to be monitored. According to the method and the device, the execution state of each task in the service to be monitored can be accurately recorded in the thread calling log, the integrity of the thread calling log is guaranteed, the related information can be quickly acquired when the related information of the service to be monitored is acquired subsequently, and workers can conveniently know the service to be monitored.

Description

Method and device for monitoring service state

Technical Field

The present application relates to the field of data processing technologies, and in particular, to a method and an apparatus for monitoring a service status.

Background

With the continuous development of computer technology, the system performance is also continuously improved, and further, the service volume processed by the system is also increased day by day; therefore, the system can be helped to acquire the processing state of the related task and monitor the system performance by monitoring the processing result of the service.

In the prior art, only the processing result of the service can be monitored, and when the service execution fails, the task which fails to be executed in the service cannot be positioned according to the monitoring result; when the execution of the service fails, the service needs to be executed repeatedly as a whole, so that all tasks in the service are guaranteed to be executed successfully.

Disclosure of Invention

In view of the above, it is necessary to provide a service status monitoring method and a device thereof capable of monitoring a service execution status.

In a first aspect, the present application provides a method for monitoring a service status. The method comprises the following steps:

if the service monitoring requirement exists, determining a thread calling log of a service thread corresponding to the service to be monitored;

determining a task to be monitored according to the subtask execution state recorded by the thread calling log; the subtasks are tasks corresponding to all service processing flows of the services to be monitored;

calling a service thread and executing a task to be monitored;

and updating the thread call log according to the execution result of the task to be monitored.

In one embodiment, determining a task to be monitored according to a subtask execution state of a thread call log includes:

and calling the subtasks with the execution states of failure and/or waiting to be executed in the log by the threads as the tasks to be monitored.

In one embodiment, invoking a business thread and executing a task to be monitored includes:

determining a processing method of a task to be monitored according to the processing logic of the service to be monitored;

and calling a service processing thread, and executing the task to be monitored based on the processing method of the task to be monitored.

In one embodiment, after updating the thread call log, the method further includes:

according to the updated thread, calling a subtask execution state recorded in a log, and determining whether a task to be monitored still exists;

and if the task exists, returning to execute the calling service thread based on the task to be monitored, and executing the operation of the task to be monitored until the task to be monitored does not exist.

In one embodiment, the method further comprises:

responding to a pause instruction of the task to be monitored, and determining the task to be paused from subtasks of the service to be monitored;

and adjusting the execution state of the subtask corresponding to the task to be suspended in the thread call log of the service thread.

In one embodiment, the thread call log further includes: at least one of thread creation information, thread invocation information, and business process parameters.

In a second aspect, the present application further provides a device for monitoring a service status. The device includes:

the first determining module is used for determining a thread call log of a service thread corresponding to a service to be monitored if a service monitoring requirement exists;

the second determining module is used for determining the tasks to be monitored according to the subtask execution state recorded by the thread calling log; the subtasks are tasks corresponding to all service processing flows of the services to be monitored;

the execution module is used for calling the service thread and executing the task to be monitored;

and the updating module is used for updating the thread call log according to the execution result of the task to be monitored.

In a third aspect, the present application also provides a computer device. The computer device comprises a memory and a processor, the memory stores a computer program, and the processor implements the method for monitoring the traffic status as described in any one of the embodiments of the first aspect when executing the computer program.

In a fourth aspect, the present application further provides a computer-readable storage medium. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, implements the method for monitoring traffic status as defined in any one of the embodiments of the first aspect above.

In a fifth aspect, the present application further provides a computer program product. Computer program product comprising a computer program which, when executed by a processor, implements the method of monitoring traffic status as in any one of the embodiments of the first aspect above.

According to the technical scheme, the log is called by determining the thread of the service to be monitored, so that the relevant information of the service to be monitored is recorded, the relevant information can be quickly acquired when the relevant information of the service to be monitored needs to be acquired subsequently, and workers can conveniently know the service to be monitored; by determining the task to be monitored and executing the task to be monitored, the repeated execution of the task to be monitored in an abnormal state in the service to be monitored is ensured, the task to be monitored is accurately positioned, and the efficiency of the determined task to be monitored is improved; by updating the thread call log, the execution state of each task in the service to be monitored can be accurately recorded in the thread call log, and the integrity of the thread call log is ensured.

Drawings

Fig. 1 is an application environment diagram of a method for monitoring a service status according to an embodiment of the present application;

fig. 2 is a flowchart of a method for monitoring a service status according to an embodiment of the present application;

FIG. 3 is a flowchart illustrating steps for executing a task to be monitored according to an embodiment of the present disclosure;

fig. 4 is a flowchart illustrating steps of another method for monitoring a service status according to an embodiment of the present application;

fig. 5 is a flowchart illustrating steps of a method for monitoring a service status according to an embodiment of the present application;

fig. 6 is a flowchart of a method for monitoring a service status according to another embodiment of the present application;

fig. 7 is a structural block diagram of monitoring a first service status according to an embodiment of the present application;

fig. 8 is a structural block diagram of monitoring a second service status according to an embodiment of the present application;

fig. 9 is a block diagram of a third example of monitoring a service status according to an embodiment of the present disclosure;

FIG. 10 is a diagram showing an internal structure of a computer device according to an embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

It should be understood that the specific embodiments described herein are merely illustrative of and not restrictive on the broad application. In the description of the present application, reference to the description of the terms "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The method for monitoring the service state provided by the embodiment of the application can be applied to the application environment shown in fig. 1. In one embodiment, a computer device is provided, which may be a server, the internal structure of which may be as shown in fig. 1. The computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing the acquired data of the monitoring of the service state. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a method of monitoring a traffic state.

The application discloses a method and a device for monitoring a service state. The method comprises the steps that computer equipment of a worker judges whether a service monitoring requirement exists or not, and if the service monitoring requirement exists, a thread calling log is determined; determining a task to be monitored based on the thread call log, and executing the task to be monitored to obtain an execution result; and updating the thread calling log according to the execution result.

In an embodiment, as shown in fig. 2, fig. 2 is a flowchart of a method for monitoring a service state provided in this application, and provides a method for monitoring a service state, where the method for monitoring a service state executed by the computer device in fig. 1 may include the following steps:

step 201, if there is a service monitoring requirement, determining a thread call log of a service thread corresponding to a service to be monitored.

The thread call log may include, but is not limited to: at least one of thread creation information, thread invocation information, and business process parameters. Further, the thread creation information may include: generating thread start time, creators, etc.; the thread invocation information may include: and the execution state of the subtask in the service to be monitored, and the like.

It should be noted that the service to be monitored is written by the staff according to the abstract class packaged in advance, and the abstract class may be used to create the service to be monitored and at least one subtask in the service to be monitored. Therefore, the service to be monitored and at least one subtask in the service to be monitored inherit the pre-packaged abstract class. Further, when the service to be monitored needs to be executed, a blank log corresponding to the service to be monitored can be created, the thread creation information, the thread calling information and the service processing parameters corresponding to the service to be monitored are stored in the blank log, so that a thread calling log is obtained, and the thread calling log is stored in the database, wherein the thread calling log is provided with the identity corresponding to the service to be monitored.

In an embodiment of the application, when a service monitoring requirement exists and a thread call log needs to be acquired, an identity corresponding to a service to be monitored can be determined, log query is performed in a database according to the identity, whether the thread call log with the identity exists in the database is queried, and therefore the thread call log of the service thread corresponding to the service to be monitored is determined.

Step 202, determining the task to be monitored according to the sub-task execution state recorded by the thread call log.

And the subtasks are tasks corresponding to all service processing flows of the services to be monitored.

It should be noted that, the target subtask execution state may be preset, and the task to be monitored in the service to be monitored is determined by determining whether the subtask execution state recorded by the thread call log is the same as the target task execution state.

Further to illustration, the subtask execution state may include, but is not limited to: successful execution, failed execution, wait for execution, suspend execution, and the like. The target task execution state may be any one or more of the subtask execution states.

In an embodiment of the application, assuming that a service to be monitored contains three subtasks in total, the three subtasks are a subtask a, a subtask B and a subtask C, respectively, if a target task execution state is an execution failure, when the task to be monitored needs to be determined, task execution states corresponding to the three subtasks respectively can be determined according to a thread call log, where the subtask a task execution state is an execution success, the subtask B task execution state is an execution success, and the subtask C task execution state is an execution failure; the task execution state of the subtask C may be determined to be the same as the target task execution state, and thus, the task execution state may be determined to be the task to be monitored.

In an embodiment of the present application, it is assumed that a service to be monitored includes three subtasks in total, where the three subtasks are a subtask a, a subtask B, and a subtask C, and if an execution state of a target task is to be executed, when it is required to determine a task to be monitored, it may be determined that task execution states corresponding to the three subtasks are all to be executed according to a thread call log, and then it may be determined that the task execution states of the three subtasks are the same as the execution state of the target task, and therefore, all the three subtasks are tasks to be monitored.

Step 203, calling a service thread and executing the task to be monitored.

It should be noted that, when a service thread needs to be called to execute a task to be monitored, a task processing method corresponding to the task to be monitored can be determined according to a service processing method corresponding to the service to be monitored, so that the service thread is called to execute the task to be monitored according to the task processing method.

And step 204, updating the thread call log according to the execution result of the task to be monitored.

It should be noted that, when the thread call log is updated, the execution state of the subtask corresponding to each task to be monitored in the thread call log may be adjusted according to the execution result, and further, it is further described that the execution state of the subtask of the task to be monitored in the thread call log after updating needs to be consistent with the execution result of the task to be monitored.

In one embodiment of the application, if two tasks to be monitored are included, the two tasks to be monitored are the task Q to be monitored and the task P to be monitored respectively, and when the execution state of the subtask before the execution of the two tasks to be monitored is waiting for execution, the execution state of the subtask after the execution of the task P to be monitored is determined as successful execution according to the execution result; and the execution state of the subtask after the monitoring task Q is executed is execution failure. Updating the subtask execution state of the task Q to be monitored from waiting for execution to failure when the thread calls the log element for updating; and updating the subtask execution state of the task P to be monitored from waiting for execution to successful execution.

It should be noted that, when the thread call log is updated, the time for completing execution corresponding to each task to be monitored can be added to the thread call log according to the execution result. Further, the execution completion time corresponding to the task to be monitored in the updated thread call log needs to be consistent with the execution result of the task to be monitored.

In an embodiment of the application, if two tasks to be monitored are included, the two tasks to be monitored are the task Q to be monitored and the task P to be monitored respectively, and when the two tasks to be monitored respectively correspond to the time for completing execution, the time is a and the time b; adding the time a to a thread calling log of the task Q to be monitored when updating the thread calling log component; and adding the time b into a thread call log of the task P to be monitored.

According to the monitoring method of the service state, the log is called by determining the thread of the service to be monitored, so that the relevant information of the service to be monitored is recorded, the relevant information can be quickly acquired when the relevant information of the service to be monitored needs to be acquired subsequently, and workers can conveniently know the service to be monitored; by determining the task to be monitored and executing the task to be monitored, the repeated execution of the task to be monitored in an abnormal state in the service to be monitored is ensured, the task to be monitored is accurately positioned, and the efficiency of the determined task to be monitored is improved; by updating the thread call log, the execution state of each task in the service to be monitored can be accurately recorded in the thread call log, and the integrity of the thread call log is ensured.

It should be noted that, when determining the task to be monitored, different subtask execution states may be selected according to actual requirements, and used as a judgment basis for determining the task to be monitored.

In an embodiment of the present application, a sub-task whose execution state is failure and/or waiting to be executed in a thread call log may be used as a task to be monitored according to an actual requirement.

As an example, when the actual demand is that, a subtask that fails to be executed is positioned from the executed service to be monitored, and the subtask is re-executed; the sub-task whose execution state is failure in the thread call log can be used as the task to be monitored.

As another example, when the actual requirement is that the service to be monitored, which is not started to be executed, starts to be executed, the thread may call a subtask whose execution state is waiting to be executed in the log as the task to be monitored.

As another example, when the actual requirement is that the execution of the business to be monitored is started, the sub-task which fails to be executed is positioned from the executed business to be monitored, and the sub-task which fails to be executed is re-executed; the thread may call the subtask whose execution status is failure and waiting to be executed in the log as the task to be monitored.

According to the monitoring method of the service state, the task to be monitored which meets the actual requirement is determined in the service to be monitored, so that follow-up processing of the task to be monitored can be guaranteed, the task to be monitored can be accurately positioned, and the efficiency of the determined task to be monitored is improved.

It should be noted that the task to be monitored can be executed by determining the processing method of the task to be monitored. Optionally, as shown in fig. 3, fig. 3 is a flowchart of a step of executing a task to be monitored according to an embodiment of the present application. Specifically, executing the task to be monitored may include the following steps:

step 301, determining a processing method of the task to be monitored according to the processing logic of the service to be monitored.

It should be noted that, because the processing logic refers to a processing flow corresponding to each sub-task in the service to be monitored, the processing method of the task to be monitored can be determined through the processing logic of the service to be monitored. Further, the processing methods of different tasks to be monitored may be the same or different.

In an embodiment of the present application, when a processing method of a task to be monitored needs to be determined, a position of the task to be monitored relative to a service to be monitored can be determined, so as to position a processing logic corresponding to the task to be monitored in a processing logic of the service to be monitored according to the position, where the processing logic corresponding to the task to be monitored is the processing method of the task to be monitored.

Step 302, a service processing thread is called, and the task to be monitored is executed based on the processing method of the task to be monitored.

It should be noted that, when it is required to determine to process the task to be monitored, the service processing thread may be invoked, and the task to be monitored is executed according to the processing method of the task to be monitored.

In an embodiment of the present application, if the execution state of the subtask of the task to be monitored is execution failure and the actual requirement is to repeatedly execute the task to be monitored until the task to be monitored is successfully executed, when the service processing thread is called, the task to be monitored is executed based on the processing method of the task to be monitored, which specifically includes: and executing the task to be monitored according to a preset repeated execution time threshold value according to the processing method of the task to be monitored, if the execution processing is still successful, executing the task to be monitored according to the processing method of the task to be monitored again, and if the repeated execution time is greater than or equal to the time threshold value, determining that the task to be monitored cannot be executed successfully according to the processing method of the task to be monitored.

According to the monitoring method of the service state, the processing method corresponding to the task to be monitored is determined through the processing logic, the follow-up task to be monitored can be executed, the follow-up process can be smoothly carried out, and the task to be monitored can be executed according to the execution state of the subtasks.

It should be noted that after the thread call log is updated, whether the task to be monitored needs to be executed again may be determined according to whether the task to be monitored still exists. Optionally, as shown in fig. 4, fig. 4 is a flowchart of steps of another service status monitoring method provided in this embodiment of the present application. Specifically, the method for monitoring the service status may further include the following steps:

step 401, if there is a service monitoring requirement, determining a thread call log of a service thread corresponding to a service to be monitored.

Step 402, determining the task to be monitored according to the subtask execution state recorded by the thread call log.

And step 403, calling a service thread and executing the task to be monitored.

And step 404, updating the thread call log according to the execution result of the task to be monitored.

Step 405, according to the sub-task execution state recorded in the updated thread call log, determining whether the task to be monitored still exists; if yes, returning to the step 403 based on the task to be monitored; and if not, stopping executing the task to be monitored.

In an embodiment of the application, if a subtask with an execution state waiting for execution in a thread call log is preset, the subtask is used as a task to be monitored; determining the subtask execution state of each subtask in the updated thread call log; and judging whether the subtask execution state is a to-be-monitored task waiting to be executed.

In an embodiment of the application, if a subtask with a failure execution state in a thread call log is preset, the subtask is used as a task to be monitored; determining the subtask execution state of each subtask in the updated thread call log; and judging whether the subtask to be monitored exists in the state of being executed in failure.

In one embodiment of the application, subtasks with execution states of failure and waiting to be executed in the thread call logs are used as tasks to be monitored; determining the subtask execution state of each subtask in the updated thread call log; and judging whether the subtask to be monitored exists, wherein the execution state of the subtask is failure and the task to be monitored is waiting to be executed.

The subtask waiting to be executed is used as a task to be monitored; and if the subtask execution state exists in the service to be monitored, namely the task to be monitored which is waiting to be executed, re-executing the processing method for determining the task to be monitored, calling the service processing thread, and executing the operation of the task to be monitored based on the processing method for the task to be monitored until the subtask execution state does not exist in the service to be monitored, namely the task to be monitored which is waiting to be executed.

In an embodiment of the application, if a subtask with a failure execution state in a thread call log is preset, the subtask is used as a task to be monitored; and if the to-be-monitored task with the sub-task execution state of failed execution exists in the to-be-monitored service, re-executing the processing method for determining the to-be-monitored task, calling the service processing thread, and executing the operation of the to-be-monitored task based on the processing method for the to-be-monitored task until the to-be-monitored task with the sub-task execution state of failed execution does not exist in the to-be-monitored service.

In one embodiment of the application, if a subtask with a failure execution state and waiting to be executed in a thread calling log is preset, the subtask is used as a task to be monitored; and if the subtask execution state in the service to be monitored is the failure and the task to be monitored waiting to be executed exists, re-executing the processing method for determining the task to be monitored, calling the service processing thread, and executing the operation of the task to be monitored based on the processing method of the task to be monitored until the subtask execution state in the service to be monitored does not exist as the failure and the task to be monitored waiting to be executed.

According to the monitoring method of the service state, whether the task to be monitored exists or not is judged according to the sub-task execution state recorded in the thread calling log, and the purpose that the task to be monitored in the service to be monitored is determined according to the thread calling log is achieved; and the operation of the task to be monitored is executed by repeatedly executing the calling service thread, so that the task to be monitored can be processed.

It should be noted that, in response to the pause instruction of the task to be monitored, the execution state of the subtask is adjusted. Optionally, as shown in fig. 5, fig. 5 is a flowchart of steps of a further method for monitoring a service state provided in the embodiment of the present application. Specifically, the method for monitoring the service status may further include the following steps:

step 501, responding to a suspension instruction of a task to be monitored, and determining the task to be suspended from subtasks of a service to be monitored.

It should be noted that the suspension instruction of the task to be monitored at least includes the identity of the task to be monitored that needs to be suspended, and the task to be suspended is determined from the subtasks of the service to be monitored according to the identity of the task to be monitored that needs to be suspended.

Further, the pause instruction of the task to be monitored may further include, but is not limited to, a pause duration of the task to be paused, a time for resuming execution of the task to be paused, and the like.

Step 502, adjusting the execution state of the subtask corresponding to the task to be suspended in the thread call log of the service thread.

It should be noted that, when the execution state of the sub-task corresponding to the to-be-suspended task needs to be adjusted, the execution state of the sub-task of the suspended task may be adjusted to the execution state of the sub-task of the target execution state according to the preset target execution state. The target execution state may be defined according to historical experience of the worker or actual requirements, and the target execution state is not specifically defined herein.

In an embodiment of the application, when the execution state of the subtask corresponding to the suspended task is preset to be adjusted to be the execution failure, the to-be-suspended task in the subtask of the service to be monitored is determined according to the identity of the to-be-monitored task needing to be suspended, which is included in the suspension instruction of the to-be-monitored task, and the execution state of the subtask corresponding to the suspended task in the thread call log is adjusted to be the execution failure.

In an embodiment of the application, when the execution state of the subtask corresponding to the suspended task is preset to be adjusted to be execution suspended, the to-be-suspended task in the subtask of the service to be monitored is determined according to the identity of the to-be-monitored task needing to be suspended, which is included in the suspension instruction of the to-be-monitored task, and the execution state of the subtask corresponding to the suspended task in the thread call log is adjusted to be execution suspended.

According to the monitoring method for the service state, the task to be suspended which needs to be suspended is determined according to the suspension instruction by determining the task to be suspended, the execution state of the subtask of the task to be suspended is adjusted, and the execution state of the subtask of the task to be suspended can be distinguished in the thread call log.

In an embodiment of the present application, as shown in fig. 6, fig. 6 is a flowchart of a further method for monitoring a service state provided in the embodiment of the present application, where when monitoring the service state:

step 601, if there is a service monitoring requirement, determining a thread call log of a service thread corresponding to a service to be monitored.

It should be noted that the thread call log further includes: at least one of thread creation information, thread invocation information, and business process parameters.

Step 602, determining a task to be monitored according to the sub-task execution state recorded by the thread call log.

The subtasks are tasks corresponding to all service processing flows of the services to be monitored; and calling the subtasks with the execution states of failure and/or waiting to be executed in the log by the threads as the tasks to be monitored.

Step 603, determining a processing method of the task to be monitored according to the processing logic of the service to be monitored.

Step 604, calling the service processing thread, and executing the task to be monitored based on the processing method of the task to be monitored.

Step 605, updating the thread call log according to the execution result of the task to be monitored.

Step 606, according to the sub-task execution state recorded in the updated thread call log, determining whether the task to be monitored still exists; if yes, returning to execute the step 604 based on the task to be monitored; and if not, stopping executing the task to be monitored.

In one embodiment of the application, in response to a suspension instruction of a task to be monitored, determining the task to be suspended from subtasks of a service to be monitored; and adjusting the execution state of the subtask corresponding to the task to be suspended in the thread call log of the service thread.

It should be understood that, although the steps in the flowcharts related to the embodiments are shown in sequence as indicated by the arrows, the steps are not necessarily executed in sequence as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least a part of the steps in the flowcharts related to the above embodiments may include multiple steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of performing the steps or stages is not necessarily sequential, but may be performed alternately or alternately with other steps or at least a part of the steps or stages in other steps.

Based on the same inventive concept, the embodiment of the present application further provides a service state monitoring device for implementing the service state monitoring method. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so that specific limitations in one or more embodiments of the monitoring device for the service state provided below can be referred to the limitations of the above monitoring method for the service state, and details are not described here.

In an embodiment, as shown in fig. 7, fig. 7 is a structural block diagram of monitoring a first service state provided in an embodiment of the present application, and provides a service state monitoring apparatus, including: a first determination module 10, a second determination module 20, an execution module 30, and an update module 40, wherein:

the first determining module 10 is configured to determine a thread call log of a service thread corresponding to a service to be monitored if a service monitoring requirement exists.

And a second determining module 20, configured to determine the task to be monitored according to the sub-task execution state recorded by the thread call log.

It should be noted that the thread calls the subtask whose execution state is failure and/or waiting to be executed in the log as the task to be monitored. And the subtasks are tasks corresponding to all service processing flows of the services to be monitored.

And the execution module 30 is configured to invoke a service thread and execute a task to be monitored.

And the updating module 40 is used for updating the thread call log according to the execution result of the task to be monitored.

According to the monitoring device for the service state, the log is called by determining the thread of the service to be monitored, so that the relevant information of the service to be monitored is recorded, the relevant information can be quickly acquired when the relevant information of the service to be monitored needs to be acquired subsequently, and workers can conveniently know the service to be monitored; by determining the task to be monitored and executing the task to be monitored, the task to be monitored in an abnormal state in the service to be monitored is ensured to be repeatedly executed, the task to be monitored is accurately positioned, and the efficiency of the determined task to be monitored is improved; by updating the thread call log, the execution state of each task in the service to be monitored can be accurately recorded in the thread call log, and the integrity of the thread call log is ensured.

In an embodiment, as shown in fig. 8, fig. 8 is a block diagram of a second service status monitoring structure provided in an embodiment of the present application, and provides a service status monitoring apparatus, where an execution module 30 in the service status monitoring apparatus includes: a determination unit 31 and an execution unit 32, wherein:

the determining unit 31 is configured to determine a processing method of the task to be monitored according to the processing logic of the service to be monitored.

And the execution unit 32 is configured to invoke a service processing thread, and execute the task to be monitored based on the processing method of the task to be monitored.

According to the monitoring device for the service state, the processing method corresponding to the task to be monitored is determined through the processing logic, the follow-up task to be monitored can be executed, the follow-up process can be smoothly carried out, and the task to be monitored can be executed according to the execution state of the subtasks.

In an embodiment, as shown in fig. 9, fig. 9 is a block diagram of a third service state monitoring structure provided in the embodiment of the present application, and provides a service state monitoring apparatus, where the service state monitoring apparatus further includes: a third determination module 50 and a return module 60, wherein:

a third determining module 50, configured to determine whether a task to be monitored still exists according to the sub-task execution state recorded in the updated thread call log;

and a returning module 60, configured to, if the task to be monitored exists, return to the executing module 30 to execute the call service thread based on the task to be monitored, and execute the operation of the task to be monitored until the task to be monitored does not exist.

According to the monitoring device for the service state, whether the task to be monitored exists or not is judged according to the sub-task execution state recorded in the thread calling log, and the purpose that the task to be monitored in the service to be monitored is determined according to the thread calling log is achieved; and the operation of the task to be monitored is executed by repeatedly executing the calling service thread, so that the task to be monitored can be processed.

All or part of each module in the monitoring device for the service state can be realized by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent of a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as shown in fig. 10. The computer apparatus includes a processor, a memory, an input/output interface, a communication interface, a display unit, and an input device. The processor, the memory and the input/output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input/output interface. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program to run on the non-volatile storage medium. The input/output interface of the computer device is used for exchanging information between the processor and an external device. The communication interface of the computer device is used for carrying out wired or wireless communication with an external terminal, and the wireless communication can be realized through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. The computer program is executed by a processor to implement a method of monitoring a traffic state. The display unit of the computer device is used for forming a visual picture and can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on the shell of the computer equipment, an external keyboard, a touch pad or a mouse and the like.

It will be appreciated by those skilled in the art that the configuration shown in fig. 10 is a block diagram of only a portion of the configuration associated with the present application, and is not intended to limit the computing device to which the present application may be applied, and that a particular computing device may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, a computer device is provided, comprising a memory having a computer program stored therein and a processor that when executing the computer program performs the steps of:

calling a service thread and executing a task to be monitored;

In one embodiment, the processor, when executing the computer program, further performs the steps of:

In one embodiment, the processor when executing the computer program further performs the steps of:

according to the updated thread, calling the subtask execution state recorded in the log, and determining whether the task to be monitored still exists;

if the task to be monitored does not exist, returning to execute the calling service thread based on the task to be monitored, and executing the operation of the task to be monitored until the task to be monitored does not exist.

the thread call log also comprises: at least one of thread creation information, thread invocation information, and business process parameters.

In one embodiment, a computer-readable storage medium is provided, having a computer program stored thereon, which when executed by a processor, performs the steps of:

determining a task to be monitored according to a subtask execution state recorded by a thread call log; the subtasks are tasks corresponding to each service processing flow of the service to be monitored;

calling a service thread and executing a task to be monitored;

In one embodiment, the computer program when executed by the processor further performs the steps of:

In one embodiment, a computer program product is provided, comprising a computer program which, when executed by a processor, performs the steps of:

calling a service thread and executing a task to be monitored;

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) referred to in the present application are information and data authorized by the user or sufficiently authorized by each party, and the collection, use and processing of the related data need to comply with the relevant laws and regulations and standards of the relevant country and region.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware related to instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, database, or other medium used in the embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include a Read-Only Memory (ROM), a magnetic tape, a floppy disk, a flash Memory, an optical Memory, a high-density embedded nonvolatile Memory, a resistive Random Access Memory (ReRAM), a Magnetic Random Access Memory (MRAM), a Ferroelectric Random Access Memory (FRAM), a Phase Change Memory (PCM), a graphene Memory, and the like. Volatile Memory can include Random Access Memory (RAM), external cache Memory, and the like. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM), for example. The databases referred to in various embodiments provided herein may include at least one of relational and non-relational databases. The non-relational database may include, but is not limited to, a block chain based distributed database, and the like. The processors referred to in the embodiments provided herein may be general purpose processors, central processing units, graphics processors, digital signal processors, programmable logic devices, quantum computing based data processing logic devices, etc., without limitation.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above examples only express several embodiments of the present application, and the description thereof is more specific and detailed, but not to be construed as limiting the scope of the present application. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, and these are all within the scope of protection of the present application. Therefore, the protection scope of the present application shall be subject to the appended claims.

Claims

1. A method for monitoring a traffic state, the method comprising:

if the service monitoring requirement exists, determining a thread call log of a service thread corresponding to the service to be monitored;

determining a task to be monitored according to the subtask execution state recorded by the thread calling log; the subtasks are tasks corresponding to each service processing flow of the service to be monitored;

calling the service thread and executing the task to be monitored;

2. The method of claim 1, wherein determining the task to be monitored according to the subtask execution state of the thread call log comprises:

and taking the subtasks with the execution states of failure and/or waiting to be executed in the thread call logs as the tasks to be monitored.

3. The method of claim 1, wherein invoking the business thread to execute the task to be monitored comprises:

determining a processing method of the task to be monitored according to the processing logic of the service to be monitored;

and calling the service processing thread, and executing the task to be monitored based on the processing method of the task to be monitored.

4. The method of claim 1, wherein after updating the thread call log, further comprising:

if the task to be monitored exists, based on the task to be monitored, returning to execute and calling the service thread, and executing the operation of the task to be monitored until the task to be monitored does not exist.

5. The method of claim 1, further comprising:

responding to the pause instruction of the task to be monitored, and determining the task to be paused from the subtasks of the service to be monitored;

6. The method according to any one of claims 1 to 5, wherein the thread call log further comprises: at least one of thread creation information, thread invocation information, and business process parameters.

7. An apparatus for monitoring traffic conditions, the apparatus comprising:

the second determining module is used for determining the task to be monitored according to the subtask execution state recorded by the thread calling log; the subtasks are tasks corresponding to each service processing flow of the service to be monitored;

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor realizes the steps of the method of any one of claims 1 to 6 when executing the computer program.

9. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that the computer program realizes the steps of the method of any one of claims 1 to 6 when executed by a processor.