WO2022095848A1 - 基线监控方法、装置、可读介质及电子设备 - Google Patents

基线监控方法、装置、可读介质及电子设备 Download PDF

Info

Publication number
WO2022095848A1
WO2022095848A1 PCT/CN2021/128180 CN2021128180W WO2022095848A1 WO 2022095848 A1 WO2022095848 A1 WO 2022095848A1 CN 2021128180 W CN2021128180 W CN 2021128180W WO 2022095848 A1 WO2022095848 A1 WO 2022095848A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
monitored
instance
baseline
time
Prior art date
Application number
PCT/CN2021/128180
Other languages
English (en)
French (fr)
Inventor
胡雄华
沈阅
王珊珊
孟贺
丁桂涛
Original Assignee
北京字节跳动网络技术有限公司
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 北京字节跳动网络技术有限公司 filed Critical 北京字节跳动网络技术有限公司
Priority to JP2022572367A priority Critical patent/JP7406010B2/ja
Priority to EP21888545.7A priority patent/EP4141670A4/en
Publication of WO2022095848A1 publication Critical patent/WO2022095848A1/zh
Priority to US18/070,443 priority patent/US11853792B2/en

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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3428—Benchmarking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/48—Indexing scheme relating to G06F9/48
    • G06F2209/484—Precedence
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/508—Monitor

Definitions

  • the present disclosure relates to the field of computer technologies, and in particular, to a baseline monitoring method, apparatus, readable medium, and electronic device.
  • the present disclosure provides a baseline monitoring method, comprising: determining a plurality of tasks to be monitored in a baseline; determining whether there is a first to-be-monitored task having a cyclic dependency according to dependencies among the plurality of tasks to be monitored tasks, wherein the cyclic dependency refers to the mutual dependence between the first tasks to be monitored; determine the task instance to be checked for each task to be monitored, wherein, in the presence of the first tasks to be monitored that have a cyclic dependency
  • the first task to be monitored is determined according to the cyclic dependency relationship and the dependency relationship between the first task to be monitored and its downstream tasks to be monitored.
  • the first task to be monitored is determined according to the dependency between the second task to be monitored and its downstream tasks to be monitored. 2.
  • the task instance of the task to be monitored to be verified wherein the second task to be monitored is the task to be monitored except the first task to be monitored, and the guarantee task is the task added by the user to the baseline task; for each task to be monitored, the baseline is monitored according to the task instance to be verified for the task to be monitored.
  • the present disclosure provides a baseline monitoring apparatus, comprising: a task-to-be-monitored determination module configured to determine a plurality of tasks to be monitored in a baseline; a circular dependency determination module configured to The dependencies between the tasks to be monitored are determined to determine whether there is a first task to be monitored that has a cyclic dependency, where the cyclic dependency refers to the mutual dependencies between the first tasks to be monitored; the task instance determination module is configured is used to determine the task instance to be verified for each task to be monitored, wherein, in the case of the first task to be monitored that has a cyclic dependency, the first task to be monitored that is not a guaranteed task task, according to the cyclic dependency relationship and the dependency relationship between the first task to be monitored and its downstream tasks to be monitored, determine the task instance to be verified by the first task to be monitored, For the second task to be monitored of the guarantee task, the task instance to be checked for the second task to be monitored is determined according to the dependency between the second task to be monitored and its downstream tasks
  • the second task to be monitored is the task to be monitored except the first task to be monitored, and the guaranteed task is the task added to the baseline by the user;
  • the monitoring module is configured to be used for each task to be monitored for each task to be monitored , and monitor the baseline according to the task instance to be verified for the task to be monitored.
  • the present disclosure provides a computer-readable medium on which a computer program is stored, and when the computer program is executed by a processing apparatus, implements the steps of the method provided in the first aspect of the present disclosure.
  • the present disclosure provides an electronic device, including: a storage device on which a computer program is stored; and a processing device for executing the computer program in the storage device, so as to implement the computer program provided in the first aspect of the present disclosure. the steps of the method.
  • the present disclosure provides a computer program, comprising: instructions that, when executed by a processor, cause the processor to perform the steps of the baseline monitoring method provided in the first aspect of the present disclosure.
  • the present disclosure provides a computer program product comprising instructions that, when executed by a processor, cause the processor to perform the steps of the baseline monitoring method provided by the first aspect of the present disclosure.
  • Fig. 1 is a flow chart of a method for monitoring baselines according to an exemplary embodiment.
  • Fig. 2 is a schematic diagram showing a dependency relationship between tasks according to an exemplary embodiment.
  • Fig. 3 is a flow chart of a method for monitoring a baseline according to a task instance to be verified of a task to be monitored according to an exemplary embodiment.
  • Fig. 4 is a schematic diagram of a baseline monitoring apparatus according to an exemplary embodiment.
  • Fig. 5 is a schematic structural diagram of an electronic device according to an exemplary embodiment.
  • the term “including” and variations thereof are open-ended inclusions, ie, "including but not limited to”.
  • the term “based on” is “based at least in part on.”
  • the term “one embodiment” means “at least one embodiment”; the term “another embodiment” means “at least one additional embodiment”; the term “some embodiments” means “at least some embodiments”. Relevant definitions of other terms will be given in the description below.
  • the task to be verified for each task to be monitored is determined For instance, for the first to-be-monitored task that is not a guaranteed task, the task instance to be verified can be determined according to the cyclic dependency and its dependency with the downstream to-be-monitored task. After the task instance to be verified is determined, the cycle process between the first tasks to be monitored may not be performed, so as to avoid the cycle dependency relationship from entering the process of continuous cycle.
  • the task instance to be verified can be determined according to the dependency relationship between the second to-be-monitored task and the downstream to-be-monitored task.
  • the assurance task can be a task added to the baseline by the user, for the assurance task, the latest task instance can be determined as the task instance to be verified, and for the task to be monitored that is not a assurance task, the latest dependent task instance
  • the task instance of is determined as the task instance to be verified. In this way, only the task instance to be verified can be verified, and there is no need to repeatedly verify the earlier task instance to avoid repeated verification.
  • the running status of the task instance to be verified affects the overall status of the baseline. By verifying the task instance to be verified, the baseline can be effectively monitored, so that daily tasks can be effectively operated and maintained to ensure the normal operation of tasks and business operations. Normal output of data.
  • Fig. 1 is a flow chart of a method for monitoring baselines according to an exemplary embodiment.
  • the method can be applied to an electronic device with processing capability. As shown in Fig. 1 , the method can include S101-S104.
  • the baseline can be a full link of tasks based on dependencies.
  • Dependencies are the upstream and downstream dependencies between tasks, and downstream tasks depend on the execution of their upstream tasks, that is, downstream tasks need to wait for their upstream tasks to execute successfully before they can be executed.
  • the types of baselines may include daily baselines and hourly baselines, and the daily baselines are detected every day, and the hourly baselines are detected every hour.
  • the types of tasks may include daily tasks and hourly tasks.
  • Daily tasks are scheduled every day, for example, at 8 o'clock every day, and hourly tasks are scheduled every hour, such as at the 20th minute of every hour.
  • assurance tasks are tasks added to the baseline by the user.
  • assurance tasks can be added to the baseline according to the identification information of assurance tasks (such as task name, task ID, etc.).
  • the assurance task may be a task with a relatively high degree of importance, or may be a task that generates important information, and the number of assurance tasks added to the baseline by the user may be one or more, which is not specified in this disclosure. limit. It is worth noting that, for daily baselines, users can add day-period assurance tasks, and for hourly baselines, users can add hourly-period assurance tasks.
  • a plurality of tasks to be monitored in the baseline can be determined according to the assurance tasks added to the baseline by the user.
  • the upstream tasks are all tasks to be monitored.
  • Fig. 2 is a schematic diagram showing a dependency relationship between tasks according to an exemplary embodiment, wherein the direction pointed by the arrow is the dependent task.
  • the user adds task C and task D as support tasks to the baseline
  • the upstream tasks of task C include task A, task B and task E
  • the upstream tasks of task D include task B and task E
  • Task A, task B, task C, task D, and task E may all be determined as tasks to be monitored.
  • the assurance task added by the user to the daily baseline can be a daily task
  • the upstream tasks of the daily task can also have hourly tasks
  • the assurance task added by the user to the hourly baseline can be an hourly task
  • the upstream task of the hourly task can be an hourly task.
  • S102 it is determined whether there is a first to-be-monitored task having a cyclic dependency according to the dependencies among the multiple to-be-monitored tasks.
  • the circular dependency relationship refers to the mutual dependence between the first tasks to be monitored. As shown in Figure 2, according to the dependencies between multiple tasks to be monitored, task A to be monitored depends on task B to be monitored, and task B to be monitored also depends on task A to be monitored, that is, the two are mutually dependent. Then, it can be determined that there are the first task A to be monitored and the first task B to be monitored that have a cyclic dependency in the baseline.
  • the cyclic dependency may be that at least two tasks are mutually dependent, for example, three tasks or four tasks may be mutually dependent. In the schematic diagram shown in FIG. 2, only two tasks are mutually dependent. Relying on an example for description, it does not constitute a limitation to the embodiments of the present disclosure.
  • a task instance can include a task and business time.
  • the business time refers to the time required to generate the data required for the operation of the task to be monitored.
  • the running process of the task instance can also be regarded as the execution process of the task.
  • a task instance to be run the next day may be generated at a preset time every day. Among them, for hourly tasks, 24 task instances should be run every day, that is, including task instances from 0:00 to 23:00.
  • the task needs to process data during the execution process.
  • the data generated on which day is processed on the current day that is, the task instance of which day is run.
  • the task processed on July 26th is the data generated on July 25th, and these data were generated on July 25th, so the business time is July 25th, that is, on July 26th Run the July 25th task instance.
  • which hour is the data generated by the current hour operation, that is, the task instance of which hour is running, for example, for example, running at 15 o'clock processes the data generated at 14 o'clock, Then at 15 o'clock run the task instance of 14 o'clock.
  • the task instance to be verified refers to the task instance to be verified at the verification time point, and the baseline can be monitored by verifying the running status of the task instance.
  • the task instance to be verified of the task to be monitored may be determined according to the latest task instance of the task to be monitored, for example, the latest task instance of the task to be monitored may be determined.
  • the task instance is used as the task instance to be verified, because the earlier task instance has been verified before, and there is no need to repeat the verification.
  • the latest task instance may refer to the task instance with the latest business time. For daily tasks, the latest task instance is the task instance of the previous day. For example, on July 26, the latest task instance is the task of July 25. Instance; for hourly tasks, the latest task instance is the task instance of the previous hour, for example, at 15:00, the latest task instance is the task instance of 14:00.
  • the first to-be-monitored task and its downstream The dependencies between the monitoring tasks are determined, and the task instance to be verified for the first task to be monitored is determined. As shown in FIG. 2 , neither the first task A to be monitored nor the first task B to be monitored is a guarantee task.
  • the cyclic dependency relationship between the first task A to be monitored and the first task B to be monitored can be , and the dependency relationship between the first task A to be monitored and its downstream task C to be monitored, to determine the task instance to be verified for the first task A to be monitored.
  • the first to-be-monitored task B the first to-be-monitored task can be determined according to the cyclic dependency between it and the first to-be-monitored task A, and the dependency between the first to-be-monitored task B and its downstream to-be-monitored task D The task instance to be verified by task B.
  • the task instance to be verified for the second to-be-monitored task is determined according to the dependency between the second to-be-monitored task and its downstream to-be-monitored task, wherein the second to-be-monitored task is: Tasks to be monitored except the first task to be monitored.
  • tasks C, D and E to be monitored are second tasks to be monitored, wherein the tasks C and D to be monitored are safeguard tasks, and the second task to be monitored E is not a safeguard task.
  • the task instance to be verified can be determined according to the dependency relationship between the second task to be monitored and the downstream task to be monitored.
  • the baseline is monitored according to the task instance to be verified for the task to be monitored.
  • the task instance to be verified may be determined according to the dependency between tasks, the dependency between tasks affects the overall operation of each task on the baseline, and the operation of the task instance to be verified affects the overall status of the baseline , so the baseline can be monitored by verifying the operation of the task instance.
  • the task instance to be verified can be determined according to the cyclic dependency and the dependency between it and the downstream to-be-monitored task.
  • the cycle process between the first tasks to be monitored may not be performed, so as to avoid the cycle dependency relationship from entering the process of continuous cycle.
  • the task instance to be verified can be determined according to the dependency relationship between the second to-be-monitored task and the downstream to-be-monitored task.
  • the assurance task can be a task added to the baseline by the user, for the assurance task, the latest task instance can be determined as the task instance to be verified, and for the task to be monitored that is not a assurance task, the latest dependent task instance
  • the task instance of is determined as the task instance to be verified. In this way, only the task instance to be verified can be verified, and there is no need to repeatedly verify the earlier task instance to avoid repeated verification.
  • the running status of the task instance to be verified affects the overall status of the baseline. By verifying the task instance to be verified, the baseline can be effectively monitored, so that daily tasks can be effectively operated and maintained to ensure the normal operation of tasks and business operations. Normal output of data.
  • determining the task instance to be verified for the first task to be monitored according to the cyclic dependency and the dependency between the first task to be monitored and its downstream tasks to be monitored may include:
  • the first task instance of the upstream first to-be-monitored task on which the first to-be-monitored task depends and the dependency between the upstream first to-be-monitored task as the downstream of the first to-be-monitored task and the first to-be-monitored task
  • the shifted offset information to determine the second task instance on which the first task to be monitored depends according to the second task instance and the task instance on which the first task to be monitored is dependent on the downstream task to be monitored, determine the first task instance to be monitored
  • the latest task instance on which the task depends, and the latest task instance is determined as the task instance to be verified for the first to-be-monitored task.
  • Dependency offsets are first introduced.
  • Dependency offset means that a task to be monitored depends on the historical execution of another task to be monitored, and the offset information can be used to represent when the execution depends on the history of another task to be monitored.
  • the offset information of the dependency offset of task C to be monitored to task A to be monitored is 0, which can indicate that task C to be monitored depends on the execution of task A to be monitored on that day.
  • the offset information of the dependency offset of task A to be monitored to task B to be monitored is -1, which can represent the execution situation of task A to be monitored dependent on task B to be monitored one day before. Hourly tasks are similar.
  • task C to be monitored depends on the execution of task A to be monitored in the current hour, and task A to be monitored depends on the execution of task B to be monitored in the previous hour.
  • offset information can also be represented by discrete time points or time intervals, taking hourly tasks as an example, such as tasks to be monitored
  • the offset information of C dependent on task A to be monitored is [-3, 0], which can represent the execution of task C to be monitored dependent on task A to be monitored in the past four hours.
  • the daily task depends on the hourly task
  • the offset information is 2 o’clock and 4 o’clock, that is, the daily task depends on the execution of the hourly task at 2 o’clock and 4 o’clock.
  • the task to be monitored is taken as an example for explanation.
  • the current day is July 26, and task C to be monitored is used as a guarantee task.
  • the task instance to be verified is the latest task instance. , that is, the task instance on July 25.
  • the task D to be monitored is used as a guarantee task, and the task instance to be verified is the task instance on July 25.
  • the offset information of the dependency offset of the downstream task C to be monitored is 0, that is, the task instance to be verified on July 25 of the task C to be monitored depends on 7 of the task A to be monitored.
  • the offset information of the dependency offset of the upstream first task B to be monitored is ⁇ 1, that is, the first task instance of the upstream first to-be-monitored task B on which the task instance of the first to-be-monitored task A on July 25 depends is the task instance of the first to-be-monitored task B on July 24.
  • the offset information of the dependent offset between the first task A to be monitored upstream is 0, then according to the first task instance and the offset information , it can be determined that the second task instance on which the first task A to be monitored depends on the first task B to be monitored is the task instance of the first task A to be monitored on July 24.
  • the dependency of task C to be monitored is the task instance on July 25, and the dependency of the first task B to be monitored is the task instance on July 24, then the first task The latest task instance on which the task A to be monitored depends is the task instance on July 25, and the task instance on July 25 can be determined as the task instance to be verified for the first task A to be monitored. And, according to the cyclic dependency between the two, the task instance on July 24 that the first task A to be monitored determined at this time is dependent on the first task B to be monitored is not the latest task A to be monitored. Task instance, then the cycle process between the two can no longer be performed.
  • the cycle process between the two continues, it can be determined that the task instance of the first task A to be monitored on July 24 depends on the first task to be monitored B July The task instance on the 23rd, the task instance of the first task to be monitored on July 23rd depends on the task instance of the first task to be monitored on July 23rd, and the task instance on July 23rd is not the first task to be monitored A. The latest task instance, so the cycle between the two can no longer be continued.
  • the task instance of the first task A to be monitored on July 25 depends on the task instance of the first task B to be monitored on July 24.
  • the first task to be monitored When B is downstream, the first task instance of its upstream first task A to be monitored depends on its task instance on July 24, which is the task instance of the first task A to be monitored on July 24, and then the first task A to be monitored As the downstream, according to the first task instance and the offset information-1, it can be determined that the second task instance on which the first task B to be monitored depends is the task instance on July 23.
  • the offset information of the downstream task D to be monitored on its dependency offset is -2, that is, the task instance on July 25 to be verified by task D to be monitored depends on the task of task B to be monitored on July 23 instance.
  • the task instance on July 23 is earlier than the task instance on July 24, it can be determined that the latest task instance on which the first task B to be monitored is relied on is the task instance on July 24, and can no longer be performed. cycle between the two. If the cyclic process between the two is continued, the subsequently determined task instances on July 22, July 21, etc., on which the first task B to be monitored is relied upon, are not the latest task instances.
  • the latest task on which the first task to be monitored depends can be determined according to the cyclic dependency and the offset information of the dependency offset of the downstream task to be monitored. instance, and the latest task instance is determined as the task instance to be verified for the first task to be monitored. After the task instance to be verified is determined, the cycle between the first tasks to be monitored can no longer be performed, so as to avoid the cyclic dependency from entering the process of continuous looping, and then the task instance to be verified is verified to verify the baseline. monitor.
  • determining the task instance to be verified for the second task to be monitored according to the dependency between the second task to be monitored and its downstream tasks to be monitored may include:
  • the offset information of the dependency offset between the second to-be-monitored task and its downstream to-be-monitored task determine the latest task instance on which the second to-be-monitored task is dependent, and use the latest task instance as the second to-be-monitored task to be calibrated Examples of tasks to be tested.
  • the second task to be monitored does not have a cyclic dependency, so the task instance to be verified can be determined directly according to the dependency between the second task to be monitored and the downstream task to be monitored.
  • the offset information of the downstream task B to be monitored on its dependency offset is 0, so the task instance of task B to be monitored on July 24 depends on the second task to be monitored.
  • the task instance of task E on July 24 is the latest task instance of the second task E to be monitored, and the task instance of July 24 can be used as the task instance to be verified for the second task E to be monitored.
  • the task instance on July 24 can be used as the task instance to be verified by the second task E to be monitored. If there is another task F to be monitored (not shown in the figure), the second task instance The downstream of the task E to be monitored, and the offset information of the dependency offset of the second task E to be monitored is 0.
  • the task instance to be verified of the task F to be monitored is the task instance on July 25, then the task The instance depends on the task instance on July 25 of the second task E to be monitored, so it can be determined that the task instance on July 25 is the latest task instance on which the second task E to be monitored is dependent, and the task instance on July 25 can be determined.
  • the task instance of the day is determined as the task instance to be checked for the second task E to be monitored.
  • the latest task instance on which the second task to be monitored is dependent is determined, and the latest task instance is determined as the task instance to be monitored. Validated task instance. In this way, only the latest task instance needs to be verified, and there is no need to repeat the verification of earlier task instances to monitor the baseline.
  • the task to be monitored is an hourly task, as shown in Figure 2, for example, for example, the current time is 15 o'clock, and task C to be monitored is a guarantee task, and the task instance to be verified can be the latest task instance, that is, the task instance of 14 o'clock.
  • a task instance, the task D to be monitored is used as a guarantee task, and the task instance to be verified can be a 14-point task instance.
  • the latest task on which the first task A to be monitored depends can be determined according to the cyclic dependency relationship between it and the first task B to be monitored and the dependency relationship between the first task to be monitored and its downstream tasks to be monitored
  • the instance is a task instance at 14 o'clock, and the task instance at 14 o'clock can be used as the task instance to be verified for the first task A to be monitored.
  • the task instance at 13 o'clock can be used as the first task B to be monitored The task instance to be verified.
  • the task instance at 13 o'clock can be used as the task instance to be checked.
  • the process of determining the task instance to be verified is described in detail above.
  • the following describes the process of determining the verification time information corresponding to the task to be monitored, that is, when the task instance to be verified should be verified.
  • the baseline monitoring method provided by the present disclosure may further include: determining the verification time information corresponding to each to-be-monitored task according to the preset baseline commitment time and early warning margin, and the dependencies among multiple to-be-monitored tasks.
  • the baseline commitment time is the latest completion time of the baseline. All tasks to be monitored in the baseline need to be completed before the baseline commitment time. If they are not completed before the baseline commitment time, the baseline will break.
  • the baseline commitment time can be set according to the estimated completion time of the baseline, and the estimated completion time of the baseline can be the maximum time among the estimated completion times of all assurance tasks.
  • the early warning margin can be the set buffer time.
  • the baseline commitment time minus the early warning margin is the baseline early warning completion time. It is expected that all tasks to be monitored can be completed before the baseline early warning completion time. If they are not completed before the baseline early warning completion time, Baseline warning. For the baseline, the impact of the baseline breaking line is more serious than the baseline warning.
  • the verification time information corresponding to the task to be monitored may include the latest warning start time, the latest promised start time, the task warning completion time, and the task promised completion time.
  • the task commitment completion time minus the early warning margin is the task early warning completion time
  • the task commitment completion time minus the average running time of the task to be monitored is the latest committed start time
  • the committed latest start time minus the early warning margin is the early warning maximum.
  • Late start time the task alert completion time minus the average running time of the tasks to be monitored is the latest alert start time.
  • the average running duration of the task to be monitored may be determined according to the historical running duration other than the maximum duration and the minimum duration among multiple historical running durations of the task to be monitored.
  • the multiple historical running durations may be the running durations of the past 15 days.
  • the average of the remaining historical running durations may be used as the average running duration of the task to be monitored. Since the maximum duration and the minimum duration may be caused by the unstable running of the task to be monitored, the running duration is too long or too short. Therefore, the average running duration is determined according to the historical running duration except the maximum duration and the minimum duration, which can avoid the influence of extreme values. Makes the determined average running time more accurate.
  • the verification time information of each to-be-monitored task can be determined by starting from the downstream security task and traversing from bottom to top according to the dependencies between the tasks.
  • the task commitment completion time of task C to be monitored can be 10:00, and the task warning completion time is 9:00.
  • the average running time of task C to be monitored is 30min, then the latest warning start time is 8:30, promised The latest start time is 9:30.
  • the task commitment completion time of task A to be monitored can be the task C to be monitored
  • the task warning completion time of task A to be monitored can be the latest start time of the warning of task C to be monitored at 8:30.
  • the average running time of task A to be monitored is 1.5h
  • the latest promised start time of task A to be monitored is 8:00
  • the latest start time of warning is 7:00.
  • the promised completion time of the task can be 8 o'clock, and the completion time of the task warning is 7 o'clock.
  • the average running time of task D to be monitored is 20 minutes, then the latest warning start time is 6:40.
  • the latest start time is 7:40.
  • task A to be monitored and task D to be monitored both depend on the execution of task B to be monitored.
  • the task early warning completion time of task B to be monitored needs to be completed at 7:00; in order to enable task D to be monitored before the latest warning start time of 6:40 Execute, the task warning completion time of task B to be monitored needs to be 6:40.
  • the task warning completion time of task B to be monitored can be taken as the earliest time among the latest early warning start times of the downstream task to be monitored, that is, 6:40. For example, if the average running time of task B to be monitored is 40 minutes, the latest warning start time is 6:00, the latest promised start time is 7:00, and the task promised completion time is 7:40.
  • the promised completion time of the task can be 7:00, and the completion time of task warning can be 6:00.
  • the average running time of task E to be monitored is 30 minutes, then the latest warning start time is 5:30.
  • the latest start time is promised to be 6:30.
  • the verification time information corresponding to each task to be monitored can be determined according to the preset baseline commitment time and early warning margin, as well as the dependencies between tasks.
  • the exemplary implementation of monitoring the baseline according to the task instance to be verified of the task to be monitored in the above S104 may be as shown in FIG. 3 , including S301 and S302.
  • the running state of the to-be-verified task instance of the to-be-monitored task is verified.
  • the baseline state of the baseline is determined according to the verification result, so as to monitor the baseline.
  • task A to be monitored it can be checked whether the task instance on July 25 has started running at the latest warning start time of July 26 at 7:00 and the promised latest start time of 8:00.
  • the completion time of the early warning is 8:30 and the promised completion time of the task is 9:30.
  • the baseline status may include safety, early warning, broken line, and others, and the baseline status in other status may refer to the status of the baseline when the task to be monitored is not associated with the baseline or the task to be monitored is closed.
  • Determining the baseline state according to the verification result in S302 may include:
  • the verification result indicates that the task instance to be verified has started running before the latest warning start time, and has successfully run before the task warning completion time, it can indicate that the task instance is running normally, and the baseline state can be determined to be a safe state;
  • the baseline status can be determined to be the warning status
  • the baseline state is a broken line state.
  • the running status of the task instance to be verified is verified, and the entire baseline can be monitored through the running status of the task instance.
  • the baseline commitment time is, for example, the 55th minute of the hour, and the warning margin is 5 minutes.
  • the task promised completion time is the 55th minute
  • the warning completion time is the 50th minute. If its average running time is 10 minutes, its promised latest start time is the 45th minute, and the latest warning start time is the 40th minute.
  • the baseline state can be determined to be an early warning state.
  • the latest promised start time is 40min
  • the latest warning start time is 35min. For example, at 15:35, it can be checked whether the task instance at 14:00 of task A to be monitored has started running.
  • the verification time information of other tasks to be monitored please refer to the above-mentioned introduction to the day tasks.
  • alarm information can also be issued according to the verification results. If the baseline status is determined to be an early warning status, the baseline warning alarm information can be sent to the person in charge of the baseline. If the baseline status is determined to be a broken line, the baseline can be sent to the person in charge of the baseline. The alarm information of the broken line will prompt the person in charge of the baseline of the running status of the baseline in time.
  • the baseline monitoring method provided by the present disclosure may further include: for each task to be monitored, determining the real-time margin of the task to be monitored according to the current instance state of the task instance to be verified for the task to be monitored; The minimum value of the margin determines the real-time margin of the baseline; according to the real-time margin of the baseline, the baseline status of the baseline is determined.
  • the real-time margin can characterize the alertness of the baseline warning or breaking the line.
  • the current instance status of a task instance may include a waiting execution status, an execution status, and an execution failure status.
  • task instances in different instance states have different ways of determining the real-time margin of the corresponding tasks to be monitored, not all tasks to be monitored adopt the same real-time margin determination method, so that the determination method adopted is the same as the instance.
  • the state corresponds to the state, so as to ensure the accuracy of the determined real-time margin of the task to be monitored.
  • the real-time remaining time of the task to be monitored can be determined according to the current time and the task commitment completion time, expected scheduling time, and average running time of the task to be monitored. quantity.
  • the expected scheduling time may be when the task to be monitored is expected to be scheduled. Generally, due to the influence of other tasks, the actual running time of the task to be monitored will be later than or equal to the expected scheduling time.
  • the real-time margin T1 corresponding to the task to be monitored can be determined by the following formula:
  • T1 task commitment completion time - [max (expected scheduling time, current time) + average running time]
  • the real-time margin of the task to be monitored can be determined according to the current time and the task commitment completion time, actual start execution time, and average running time of the task to be monitored.
  • the real-time margin T2 corresponding to the task to be monitored can be determined by the following formula:
  • T2 task commitment completion time - [max (current time, actual start execution time + average running time)]
  • the real-time margin of the task to be monitored can be determined according to the current time and the task commitment completion time and average running time of the task to be monitored. For example, when the instance state of the task instance is the execution failure state, the real-time margin T3 corresponding to the task to be monitored can be determined by the following formula:
  • T3 task commitment completion time - (current time + average running time)
  • the minimum value of the real-time margin of each task to be monitored can be determined as the real-time margin of the baseline, and the baseline of the baseline can be determined according to the real-time margin of the baseline state. If the real-time margin of the baseline is positive and greater than the early warning margin, it can indicate that the baseline state is safe, and the larger the value of the real-time margin is, the safer it is; if the real-time margin of the baseline is less than the early warning margin, the baseline state can be represented as Early warning state; if the real-time margin of the baseline is negative, it can indicate that the baseline state is a broken line, and the smaller the value of the real-time margin is, the higher the degree of broken line.
  • task instances in different instance states have different ways of determining the real-time margin of the corresponding task to be monitored, so that the determination method adopted corresponds to the instance state, so as to ensure the determined real-time margin of the task to be monitored. to ensure the accuracy of the baseline state determined according to the real-time margin of the task to be monitored.
  • the baseline monitoring method provided by the present disclosure may further include: when the actual running time of the task to be monitored is greater than a preset ratio of the average running duration of the task to be monitored, determining that the task to be monitored is a slow-running task, wherein the average running time is Different durations correspond to different preset ratios.
  • the task to be monitored may fail to run during the running process. In this case, an error alarm can be issued for the task to be monitored, and the alarm information of the task running error can be sent to the task leader.
  • the running time may also become slower, that is, the actual running time of the task to be monitored is longer than the average running time.
  • the task to be monitored is not considered to be a slow-running task as long as the actual running duration of the task to be monitored is greater than the average running duration, but the task to be monitored is determined only when the actual running duration is greater than the preset ratio of the average running duration In order to run slow tasks, this can control the number of slow events to a certain extent and prevent unnecessary slow events from being recorded.
  • the corresponding preset ratios may be different for different average running durations, and the corresponding preset ratios may be set according to the average running durations.
  • the corresponding relationship between the average running time and the preset ratio may be as shown in Table 1 below:
  • the task to be monitored is determined to be a slow-running task only when the actual running duration of the task to be monitored is greater than the preset ratio of the average running duration, and the average running duration is different, and the corresponding preset ratio can be Different, this can control the number of slowdown events to a certain extent and prevent unnecessary slowdown events from being recorded.
  • FIG. 4 is a schematic diagram of a baseline monitoring apparatus according to an exemplary embodiment. As shown in FIG. 4 , the apparatus 400 may include:
  • a task-to-be-monitored determining module 401 configured to determine a plurality of tasks to be monitored in the baseline
  • the cyclic dependency determination module 402 is configured to determine whether there is a first to-be-monitored task with a cyclic dependency according to the dependencies among the plurality of tasks to be monitored, wherein the cyclic dependency refers to the first to-be-monitored task. 1.
  • the tasks to be monitored depend on each other;
  • the task instance determination module 403 is configured to determine the task instance to be verified for each of the tasks to be monitored, wherein, in the case of the first task to be monitored having a cyclic dependency, the The first task to be monitored of the task, according to the cyclic dependency relationship and the dependency relationship between the first task to be monitored and its downstream tasks to be monitored, determine the first task to be monitored to be verified.
  • Task instance for the second task to be monitored that is not the guarantee task, according to the dependency between the second task to be monitored and its downstream task to be monitored, determine the said second task to be monitored to be verified
  • a task instance wherein the second task to be monitored is a task to be monitored other than the first task to be monitored, and the safeguard task is a task added to the baseline by the user;
  • the monitoring module 404 is configured to, for each task to be monitored, monitor the baseline according to the task instance to be verified for the task to be monitored.
  • the task instance to be verified when determining the task instance to be verified for each task to be monitored , for the first task to be monitored that is not a guarantee task, the task instance to be verified can be determined according to the cyclic dependency and the dependency between the task and the downstream task to be monitored. After the task instance to be verified is determined, the cycle process between the first tasks to be monitored may not be performed, so as to avoid the cycle dependency relationship from entering the process of continuous cycle.
  • the task instance to be verified can be determined according to the dependency relationship between the second to-be-monitored task and the downstream to-be-monitored task.
  • the assurance task can be a task added to the baseline by the user, for the assurance task, the latest task instance can be determined as the task instance to be verified, and for the task to be monitored that is not a assurance task, the latest dependent task instance
  • the task instance of is determined as the task instance to be verified. In this way, only the task instance to be verified can be verified, and there is no need to repeatedly verify the earlier task instance to avoid repeated verification.
  • the running status of the task instance to be verified affects the overall status of the baseline. By verifying the task instance to be verified, the baseline can be effectively monitored, so that daily tasks can be effectively operated and maintained to ensure the normal operation of tasks and business operations. Normal output of data.
  • the task instance determining module 403 may include: a first determining sub-module configured to be configured according to the first task instance of the upstream first task to be monitored on which the first task to be monitored depends, and When the upstream first task to be monitored is downstream of the first task to be monitored and the offset information of the dependency offset between the first task to be monitored, determine the second task on which the first task to be monitored depends
  • the dependency offset refers to the historical execution situation of one task to be monitored depending on another task to be monitored
  • the second determination submodule is configured to be configured according to the second task instance and the first The task instance on which the monitoring task is dependent on the downstream task to be monitored is determined, the latest task instance on which the first task to be monitored is dependent is determined, and the latest task instance is determined as the all task instance to be verified by the first task to be monitored. Examples of tasks described.
  • the task instance determination module 403 may include: a third determination sub-module, configured to determine according to the offset information of the dependent offset between the second to-be-monitored task and its downstream to-be-monitored task, determine The latest task instance on which the second task to be monitored is dependent, and the latest task instance is used as the task instance to be verified for the second task to be monitored.
  • a third determination sub-module configured to determine according to the offset information of the dependent offset between the second to-be-monitored task and its downstream to-be-monitored task, determine The latest task instance on which the second task to be monitored is dependent, and the latest task instance is used as the task instance to be verified for the second task to be monitored.
  • the task instance determining module 403 may include: a fourth determining sub-module, configured to, for the task to be monitored as a guarantee task, determine the task instance according to the latest task instance of the task to be monitored. The task instance to be checked for the task to be monitored.
  • the apparatus 400 may further include: a verification time information determination module, configured to commit time and early warning margin according to a preset baseline, and the dependencies between the multiple tasks to be monitored relationship, to determine the verification time information corresponding to each task to be monitored;
  • the monitoring module 404 may include: a verification sub-module configured to be used for the verification time information corresponding to the task to be monitored At the indicated time, the running state of the task instance to be verified by the task to be monitored is verified; the fifth determination sub-module is configured to determine the baseline status of the baseline according to the verification result, so as to determine the baseline status of the baseline. The baseline is monitored.
  • the verification time information includes the latest warning start time, the latest promised start time, the task warning completion time, and the task promised completion time;
  • the fifth determination submodule includes: a security state determination submodule, which is is configured to determine that the baseline state is a safe state if the verification result indicates that the task instance has started to run before the latest warning start time and has successfully run before the task warning completion time;
  • An early warning state determination sub-module configured to be used for if the verification result indicates that the task instance has not started running at the latest warning start time, or the task instance has not successfully run at the task warning completion time , then it is determined that the baseline state is an early warning state;
  • the broken line state determination sub-module is configured to be used if the verification result indicates that the task instance has not started running at the promised latest start time, or, the If the task instance has not run successfully at the promised completion time of the task, it is determined that the baseline state is a broken line state.
  • the apparatus 400 may further include: a task real-time margin determination module configured to, for each task to be monitored, according to the current instance of the task instance to be checked for the task to be monitored state, to determine the real-time margin of the task to be monitored, wherein the task instances in different instance states have different ways of determining the real-time margin of the corresponding task to be monitored; the baseline real-time margin determination module is configured is used to determine the real-time margin of the baseline according to the minimum value of the real-time margin of each task to be monitored; the baseline state determination module is configured to determine the real-time margin of the baseline according to the real-time margin of the baseline. The baseline state of the baseline.
  • the instance state includes a waiting execution state, an executing state and an execution failure state
  • the task real-time margin determination module includes: a first real-time margin determination sub-module configured to be used in the task When the current instance state of the instance is the waiting execution state, determine the real-time margin of the to-be-monitored task according to the current time and the task commitment completion time, expected scheduling time, and average running time of the to-be-monitored task
  • the second real-time margin determination submodule is configured to be used in the case that the current state of the instance of the task instance is the state in execution, according to the current time and the description of the task to be monitored
  • the promised completion time of the task, the actual start execution time, and the average running duration determine the real-time margin of the task to be monitored
  • a third real-time margin determination submodule is configured to be used in the current task instance of the task instance.
  • the instance state is the execution failure state
  • the real-time margin of the task to be monitored is determined according to the current time, the
  • the apparatus 400 further includes: a slowing down task determining module, configured to be configured to, when the actual running duration of the to-be-monitored task is greater than a preset ratio of the average running duration of the to-be-monitored task, It is determined that the to-be-monitored task is a slow-running task, wherein the average running durations are different, and the corresponding preset ratios are different.
  • a slowing down task determining module configured to be configured to, when the actual running duration of the to-be-monitored task is greater than a preset ratio of the average running duration of the to-be-monitored task, It is determined that the to-be-monitored task is a slow-running task, wherein the average running durations are different, and the corresponding preset ratios are different.
  • Terminal devices in the embodiments of the present disclosure may include, but are not limited to, such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablets), PMPs (portable multimedia players), vehicle-mounted terminals (eg, mobile terminals such as in-vehicle navigation terminals), etc., and stationary terminals such as digital TVs, desktop computers, and the like.
  • the electronic device shown in FIG. 5 is only an example, and should not impose any limitation on the function and scope of use of the embodiments of the present disclosure.
  • an electronic device 500 may include a processing device (eg, a central processing unit, a graphics processor, etc.) 501 that may be loaded into random access according to a program stored in a read only memory (ROM) 502 or from a storage device 508 Various appropriate actions and processes are executed by the programs in the memory (RAM) 503 . In the RAM 503, various programs and data required for the operation of the electronic device 500 are also stored.
  • the processing device 501, the ROM 502, and the RAM 503 are connected to each other through a bus 504.
  • An input/output (I/O) interface 505 is also connected to bus 504 .
  • I/O interface 505 input devices 506 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; including, for example, a liquid crystal display (LCD), speakers, vibration
  • An output device 507 such as a computer
  • a storage device 508 including, for example, a magnetic tape, a hard disk, etc.
  • Communication means 509 may allow electronic device 500 to communicate wirelessly or by wire with other devices to exchange data. While FIG. 5 shows electronic device 500 having various means, it should be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided.
  • embodiments of the present disclosure include a computer program product comprising a computer program carried on a non-transitory computer readable medium, the computer program containing program code for performing the method illustrated in the flowchart.
  • the computer program may be downloaded and installed from the network via the communication device 509, or from the storage device 508, or from the ROM 502.
  • the processing apparatus 501 When the computer program is executed by the processing apparatus 501, the above-mentioned functions defined in the methods of the embodiments of the present disclosure are executed.
  • the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the above two.
  • the computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or a combination of any of the above. More specific examples of computer readable storage media may include, but are not limited to, electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable Programmable read only memory (EPROM or flash memory), fiber optics, portable compact disk read only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
  • a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
  • a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave with computer-readable program code embodied thereon. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.
  • a computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device .
  • Program code embodied on a computer readable medium may be transmitted using any suitable medium including, but not limited to, electrical wire, optical fiber cable, RF (radio frequency), etc., or any suitable combination of the foregoing.
  • the client and server can use any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol) to communicate, and can communicate with digital data in any form or medium Communication (eg, a communication network) interconnects.
  • HTTP HyperText Transfer Protocol
  • Examples of communication networks include local area networks (“LAN”), wide area networks (“WAN”), the Internet (eg, the Internet), and peer-to-peer networks (eg, ad hoc peer-to-peer networks), as well as any currently known or future development network of.
  • the above-mentioned computer-readable medium may be included in the above-mentioned electronic device; or may exist alone without being assembled into the electronic device.
  • the above-mentioned computer-readable medium carries one or more programs, and when the above-mentioned one or more programs are executed by the electronic device, the electronic device: determines a plurality of tasks to be monitored in the baseline; determine whether there is a first task to be monitored that has a cyclic dependency relationship, wherein the cyclic dependency relationship refers to the mutual dependence between the first tasks to be monitored; determine the task to be checked for each task to be monitored A task instance, wherein, in the case of the first to-be-monitored task having a cyclic dependency, for the first to-be-monitored task that is not a guaranteed task, according to the cyclic dependency and the first to-be-monitored task The dependency between the monitoring task and its downstream tasks to be monitored, determine the task instance to be verified for the first task to be monitored, and for the second task to be monitored that is not the guarantee task, according to the second task to be monitored The dependency between the monitoring task and its downstream task to be monitored, and determine the task instance to be verified by the
  • Computer program code for performing operations of the present disclosure may be written in one or more programming languages, including but not limited to object-oriented programming languages—such as Java, Smalltalk, C++, and This includes conventional procedural programming languages - such as the "C" language or similar programming languages.
  • the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server.
  • the remote computer may be connected to the user's computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (eg, using an Internet service provider to via Internet connection).
  • LAN local area network
  • WAN wide area network
  • each block in the flowchart or block diagrams may represent a module, segment, or portion of code that contains one or more logical functions for implementing the specified functions executable instructions.
  • the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
  • each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations can be implemented in dedicated hardware-based systems that perform the specified functions or operations , or can be implemented in a combination of dedicated hardware and computer instructions.
  • the modules involved in the embodiments of the present disclosure may be implemented in software or hardware. Wherein, the name of the module does not constitute a limitation of the module itself under certain circumstances, for example, the module for determining the task to be monitored can also be described as a "determination module”.
  • exemplary types of hardware logic components include: Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), Systems on Chips (SOCs), Complex Programmable Logical Devices (CPLDs) and more.
  • FPGAs Field Programmable Gate Arrays
  • ASICs Application Specific Integrated Circuits
  • ASSPs Application Specific Standard Products
  • SOCs Systems on Chips
  • CPLDs Complex Programmable Logical Devices
  • a machine-readable medium may be a tangible medium that may contain or store a program for use by or in connection with the instruction execution system, apparatus or device.
  • the machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium.
  • Machine-readable media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or devices, or any suitable combination of the foregoing.
  • machine-readable storage media would include one or more wire-based electrical connections, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), fiber optics, compact disk read only memory (CD-ROM), optical storage, magnetic storage, or any suitable combination of the foregoing.
  • RAM random access memory
  • ROM read only memory
  • EPROM or flash memory erasable programmable read only memory
  • CD-ROM compact disk read only memory
  • magnetic storage or any suitable combination of the foregoing.
  • Example 1 provides a baseline monitoring method, including: determining a plurality of tasks to be monitored in a baseline; The first task to be monitored with a cyclic dependency relationship, wherein the cyclic dependency relationship refers to the mutual dependence between the first tasks to be monitored; determine the task instance to be checked for each of the tasks to be monitored, wherein there is a cyclic dependency relationship.
  • the first to-be-monitored task with a dependency relationship for the first to-be-monitored task that is not a guarantee task, according to the cyclic dependency relationship and the relationship between the first to-be-monitored task and its downstream to-be-monitored task determine the task instance to be verified for the first task to be monitored, and for the second task to be monitored that is not the guarantee task, according to the relationship between the second task to be monitored and its downstream task to be monitored Dependency relationship, determine the task instance to be verified by the second task to be monitored, wherein the second task to be monitored is a task to be monitored except the first task to be monitored, and the guarantee task is The tasks added by the user to the baseline; for each task to be monitored, the baseline is monitored according to the task instance to be verified for the task to be monitored.
  • Example 2 provides the method of Example 1, wherein according to the cyclic dependency and the dependency between the first task to be monitored and its downstream tasks to be monitored, determine the The task instance to be verified for the first task to be monitored includes: according to the first task instance of the upstream first task to be monitored that the first task to be monitored depends on, and the upstream first task to be monitored as the first task instance to be monitored The offset information of the dependency offset between the downstream of the first task to be monitored and the first task to be monitored is determined, and the second task instance on which the first task to be monitored is dependent is determined, wherein the dependency offset refers to A task to be monitored depends on the historical execution of another task to be monitored; according to the second task instance and the task instance on which the first task to be monitored is dependent on the downstream task to be monitored, determine the first task to be monitored The latest task instance on which the task depends, and the latest task instance is determined as the task instance to be verified by the first to-be-monitored task.
  • Example 3 provides the method of Example 1, wherein the second task to be monitored is determined to be
  • the verified task instance includes: determining the latest task instance on which the second to-be-monitored task is dependent according to the offset information of the dependency offset between the second to-be-monitored task and its downstream to-be-monitored task, and The latest task instance is used as the task instance to be verified for the second task to be monitored.
  • Example 4 provides the method of Example 1, wherein the determining a task instance to be verified for each task to be monitored includes: for the task to be monitored that is a guarantee task, According to the latest task instance of the task to be monitored, the task instance to be checked for the task to be monitored is determined.
  • Example 5 provides the method of Example 1, the method further comprising: according to a preset baseline commitment time and an early warning margin, and all of the tasks to be monitored The dependency relationship is determined, and the verification time information corresponding to each task to be monitored is determined; the monitoring of the baseline according to the task instance to be verified of the task to be monitored includes: At the time indicated by the verification time information, the running status of the task instance to be verified by the task to be monitored is verified; according to the verification result, the baseline status of the baseline is determined to monitor the baseline .
  • Example 6 provides the method of Example 5, wherein the verification time information includes the latest warning start time, the latest promised start time, the task warning completion time, and the task promised completion time; Determining the baseline state of the baseline according to the verification result includes: if the verification result indicates that the task instance has started to run before the latest warning start time and is running before the task warning completion time If successful, it is determined that the baseline state is a safe state; if the verification result indicates that the task instance has not started running at the latest warning start time, or the task instance has not been running at the task warning completion time If successful, it is determined that the baseline state is an early warning state; if the verification result indicates that the task instance has not yet started to run at the promised latest start time, or, the task instance has not yet run at the promised completion time of the task If successful, it is determined that the baseline state is a broken line state.
  • Example 7 provides the method of Example 1, the method further comprising: for each task to be monitored, according to the current task instance to be checked of the task to be monitored determine the real-time margin of the task to be monitored, wherein the task instances in different instance states have different ways of determining the real-time margin of the corresponding task to be monitored; according to each of the task instances to be monitored The minimum value of the real-time margin of the task is used to determine the real-time margin of the baseline; and the baseline state of the baseline is determined according to the real-time margin of the baseline.
  • Example 8 provides the method of Example 7, where the instance state includes a state of waiting for execution, a state in execution, and a state of execution failure; the task to be verified according to the task to be monitored
  • the current instance status of the instance, and determining the real-time margin of the task to be monitored includes: in the case that the current instance status of the task instance is the waiting execution status, according to the current time and the status of the task to be monitored.
  • the task commitment completion time, expected scheduling time, and average running time are used to determine the real-time margin of the task to be monitored; when the current instance state of the task instance is the executing state, according to the current time and the task commitment completion time, actual start execution time, and the average running duration of the task to be monitored to determine the real-time margin of the task to be monitored; the current instance state of the task instance is the In the case of an execution failure state, the real-time margin of the task to be monitored is determined according to the current time, the task commitment completion time and the average running time of the task to be monitored.
  • Example 9 provides the method of Example 1, the method further comprising: when the actual running duration of the task to be monitored is greater than a preset ratio of the average running duration of the task to be monitored In the case of , it is determined that the to-be-monitored task is a slow-running task, wherein the average running durations are different, and the corresponding preset ratios are different.
  • Example 10 provides the method of Example 8 or Example 9, wherein the average running duration is based on a maximum duration other than a maximum duration and a minimum duration among multiple historical running durations of the task to be monitored The historical running time of .
  • Example 11 provides a baseline monitoring apparatus, comprising: a task-to-be-monitored determination module configured to determine a plurality of tasks to be monitored in the baseline; a circular dependency determination module, configured to is configured to determine whether there is a first to-be-monitored task with a cyclic dependency according to the dependencies between the plurality of to-be-monitored tasks, where the cyclic dependency refers to the mutual dependence between the first to-be-monitored tasks
  • the task instance determination module is configured to determine the task instance to be checked for each described task to be monitored, wherein, in the presence of the first task to be monitored with a cyclic dependency, for not being guaranteed
  • the first task to be monitored of the task according to the cyclic dependency relationship and the dependency relationship between the first task to be monitored and its downstream tasks to be monitored, determine the first task to be monitored to be verified.
  • Task instance for the second task to be monitored that is not the guarantee task, according to the dependency between the second task to be monitored and its downstream task to be monitored, determine the said second task to be monitored to be verified
  • the second task to be monitored is a task to be monitored except the first task to be monitored, and the safeguard task is a task added to the baseline by the user;
  • the monitoring module is configured to be used for For each task to be monitored, the baseline is monitored according to the task instance to be verified for the task to be monitored.
  • Example 12 provides a computer-readable medium having a computer program stored thereon, the program implementing the method of any one of Examples 1 to 10 when executed by a processing apparatus. step.
  • Example 13 provides an electronic device, comprising: a storage device on which a computer program is stored; and a processing device for executing the computer program in the storage device, to The steps of implementing the method of any one of Examples 1 to 10 are performed.
  • Example 14 provides a computer program comprising: instructions that, when executed by a processor, cause the processor to perform any one of Examples 1 to 10 steps of the method.
  • Example 15 provides for a computer program product comprising instructions that, when executed by a processor, cause the processor to perform any one of Examples 1 to 10. steps of the method described.

Landscapes

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

Abstract

本公开涉及一种基线监控方法、装置、可读介质及电子设备，该方法包括：确定基线中多个待监控任务；根据多个待监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务；确定每一待监控任务待校验的任务实例，针对不为保障任务的第一待监控任务，根据循环依赖关系、以及第一待监控任务与其下游待监控任务之间的依赖关系，确定第一待监控任务待校验的任务实例，针对不为保障任务的第二待监控任务，根据第二待监控任务与其下游待监控任务之间的依赖关系，确定第二待监控任务待校验的任务实例；针对每一待监控任务，根据该待监控任务待校验的任务实例，对基线进行监控。如此，在存在循环依赖关系的情况下，可对基线进行有效监控。

Description

基线监控方法、装置、可读介质及电子设备
本申请要求于2020年11月04日递交、申请号为202011218097.5、名称为“基线监控方法、装置、可读介质及电子设备”的中国专利申请的优先权，其全部内容通过引用并入本文。
技术领域
本公开涉及计算机技术领域，具体地，涉及一种基线监控方法、装置、可读介质及电子设备。
背景技术
在大数据开发场景中，运维管理的任务很多，为了有效运维日常任务，保证业务数据的正常产出，需要对任务的运行进行监控。
发明内容
提供该发明内容部分以便以简要的形式介绍构思，这些构思将在后面的具体实施方式部分被详细描述。该发明内容部分并不旨在标识要求保护的技术方案的关键特征或必要特征，也不旨在用于限制所要求的保护的技术方案的范围。
第一方面，本公开提供一种基线监控方法，包括：确定基线中多个待监控任务；根据所述多个待监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务，其中，循环依赖关系是指所述第一待监控任务之间互相依赖；确定每一所述待监控任务待校验的任务实例，其中，在存在具有循环依赖关系的所述第一待监控任务的情况下，针对不为保障任务的所述第一待监控任务，根据所述循环依赖关系、以及所述第一待监控任务与其下游待监控任务之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，针对不为所述保障任务的第二待监控任务，根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，其中，所述第二待监控任务为除所述第一待监控任务外的待监控任务，所述保障任务为用户添加到所述基线中的任务；针对每一所述待监控任务，根据该待监控任务待校验的所述任务实例，对所述基线进行监控。
第二方面，本公开提供一种基线监控装置，包括：待监控任务确定模块，被配置成用于确定基线中多个待监控任务；循环依赖关系确定模块，被配置成用于根据所述多个待 监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务，其中，循环依赖关系是指所述第一待监控任务之间互相依赖；任务实例确定模块，被配置成用于确定每一所述待监控任务待校验的任务实例，其中，在存在具有循环依赖关系的所述第一待监控任务的情况下，针对不为保障任务的所述第一待监控任务，根据所述循环依赖关系、以及所述第一待监控任务与其下游待监控任务之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，针对不为所述保障任务的第二待监控任务，根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，其中，所述第二待监控任务为除所述第一待监控任务外的待监控任务，所述保障任务为用户添加到所述基线中的任务；监控模块，被配置成用于针对每一所述待监控任务，根据该待监控任务待校验的所述任务实例，对所述基线进行监控。
第三方面，本公开提供一种计算机可读介质，其上存储有计算机程序，该计算机程序被处理装置执行时实现本公开第一方面提供的所述方法的步骤。
第四方面，本公开提供一种电子设备，包括：存储装置，其上存储有计算机程序；处理装置，用于执行所述存储装置中的所述计算机程序，以实现本公开第一方面提供的所述方法的步骤。
第五方面，本公开提供一种计算机程序，包括：指令，所述指令当由处理器执行时使所述处理器执行本公开第一方面提供的所述基线监控方法的步骤。
第六方面，本公开提供一种计算机程序产品，包括指令，所述指令当由处理器执行时使所述处理器执行本公开第一方面提供的所述基线监控方法的步骤。
附图说明
结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。在附图中：
图1是根据一示例性实施例示出的一种基线监控方法的流程图。
图2是根据一示例性实施例示出的一种任务之间依赖关系的示意图。
图3是根据一示例性实施例示出的一种根据待监控任务待校验的任务实例对基线进行监控的方法的流程图。
图4是根据一示例性实施例示出的一种基线监控装置的示意图。
图5是根据一示例性实施例示出的一种电子设备的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。
应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。
本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。
需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。
需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。
本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。
任务之间具有上下游依赖关系，通常情况下，任务数量较多，且依赖关系较为复杂，例如任务之间的循环依赖关系，循环依赖关系指的是任务之间互相依赖。对于具有复杂依赖关系的任务，如何进行有效监控是运维管理的重要问题。
通过本公开的技术方案，根据基线中多个待监控任务之间的依赖关系，在确定存在具有循环依赖关系的第一待监控任务的情况下，在确定每一待监控任务待校验的任务实例时，针对不为保障任务的第一待监控任务，可以根据循环依赖关系以及其与下游待监控任务之间的依赖关系，确定待校验的任务实例。在确定出待校验的任务实例后，可不再进行第一待监控任务之间的循环过程，避免循环依赖关系进入不断循环的过程。针对不为保障任务的第二待监控任务，可以根据其与下游待监控任务之间的依赖关系，确定待校验的任务实例。其中，保障任务可以是用户添加到基线中的任务，对于保障任务，可将最新的任务实例确定为待校验的任务实例，对于不为保障任务的待监控任务，可将其被依赖的最新的任务实例确定为待校验的任务实例。如此，仅对待校验的任务实例进行校验即可，无需 重复校验更早的任务实例，避免重复校验。并且，待校验的任务实例的运行情况影响基线的整体状态，通过对待校验的任务实例进行校验，可对基线进行有效监控，从而可以有效运维日常任务，保证任务的正常运行以及业务数据的正常产出。
本公开的其他特征和优点将在后面予以详细说明。
图1是根据一示例性实施例示出的一种基线监控方法的流程图，该方法可以应用于具有处理能力的电子设备中，如图1所示，该方法可包括S101～S104。
在S101中，确定基线中多个待监控任务。
基线可以是基于依赖关系的任务全链路，依赖关系即任务之间的上下游依赖关系，下游任务依赖其上游任务的执行，即下游任务需要等待其上游任务执行成功之后才能执行。其中，基线的类型可包括天基线和小时基线，对于天基线每天进行检测，对于小时基线每小时进行检测。
其中，根据调度频率不同，任务的类型可包括天任务和小时任务，对于天任务每天进行调度，例如在每天8点调度，对于小时任务每小时进行调度，例如在每小时的第20分钟调度。
用户可在基线中添加需要保障的任务，保障任务为用户添加到基线中的任务，例如可根据保障任务的标识信息(如任务名称、任务ID等)，将保障任务添加到基线中。示例地，保障任务可以是重要程度相对较高的任务，也可以是产出重要信息的任务，对于用户添加到基线中的保障任务的数量，可以是一个也可是多个，本公开不做具体限制。值得说明的是，对于天基线，用户可以添加天周期的保障任务，对于小时基线，用户可以添加小时周期的保障任务。
本公开中，可以根据用户添加到基线中的保障任务，确定该基线中多个待监控任务。任务之间有上下游依赖关系，下游任务能否顺利执行，依赖其上游任务是否执行成功，由于保障任务的顺利执行，依赖于保障任务所有上游任务的执行，因此可将保障任务以及保障任务所有上游任务均作为待监控任务。
图2是根据一示例性实施例示出的一种任务之间依赖关系的示意图，其中箭头所指的方向为被依赖的任务。如图2所示，例如用户将任务C和任务D作为保障任务添加到基线中，任务C的上游任务包括任务A、任务B和任务E，任务D的上游任务包括任务B和任务E，则可将任务A、任务B、任务C、任务D和任务E均确定为待监控任务。另外，用户添加到天基线中的保障任务可以是天任务，该天任务的上游任务中也可以有小时任务；用户添加到小时基线中的保障任务可以是小时任务，该小时任务的上游任务中也可以有天任务。
需要说明的是，本公开在以下介绍中，以图2所示的示意图为例进行解释说明，但并不构成对本公开实施方式的限制，在实际应用中，任务的数量以及任务之间的依赖关系等并不局限于此。
在S102中，根据多个待监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务。
其中，循环依赖关系是指第一待监控任务之间互相依赖。如图2所示，根据多个待监控任务之间的依赖关系可知，待监控任务A依赖于待监控任务B，待监控任务B也依赖于待监控任务A，即二者之间互相依赖，则可确定该基线中存在具有循环依赖关系的第一待监控任务A和第一待监控任务B。
值得说明的是，循环依赖关系可以是至少两个任务之间互相依赖，例如也可以是三个任务或四个任务之间互相依赖，图2所示的示意图中仅以两个任务之间互相依赖为例进行说明，但并不构成对本公开实施方式的限制。
在S103中，确定每一待监控任务待校验的任务实例。
首先对任务实例进行介绍。任务实例可包括任务和业务时间，业务时间是指产生待监控任务运行所需数据的时间，任务实例的运行过程也可看作是任务的执行过程。本公开中，例如可以在每天的预设时间生成第二天要运行的任务实例。其中对于小时任务来说，每天要运行24个任务实例，即包括0点～23点的任务实例。
其中，任务在执行过程中需要处理数据，对于天任务来说，当天运行处理的是哪一天产生的数据，即运行的是哪一天的任务实例。举例来说，例如任务在7月26日处理的是7月25日产生的数据，这些数据是在7月25日产生的，因此业务时间是7月25日，也即是在7月26日运行7月25日的任务实例。类似地，对于小时任务来说，当前小时运行处理的是哪一小时产生的数据，即运行的是哪一小时的任务实例，示例地，例如在15点运行处理的是14点产生的数据，则在15点运行14点的任务实例。
待校验的任务实例是指在校验时间点需校验的任务实例，通过校验该任务实例的运行情况可对基线进行监控。
本公开中，针对作为保障任务的待监控任务，为了保证保障任务目前的顺利执行，可以根据该待监控任务最新的任务实例，确定该待监控任务待校验的任务实例，例如可将该最新的任务实例作为其待校验的任务实例，因为更早的任务实例之前已经校验过了，无需重复校验。其中，最新的任务实例可以指的是业务时间最新的任务实例，对于天任务，最新的任务实例为前一天的任务实例，例如在7月26日，最新的任务实例为7月25日的任务实例；对于小时任务，最新的任务实例为上一小时的任务实例，例如在15点，最新 的任务实例为14点的任务实例。
本公开中，在S102中确定存在具有循环依赖关系的第一待监控任务的情况下，针对不为保障任务的第一待监控任务，可以根据循环依赖关系、以及第一待监控任务与其下游待监控任务之间的依赖关系，确定第一待监控任务待校验的任务实例。如图2所示，第一待监控任务A和第一待监控任务B均不为保障任务，例如对于第一待监控任务A，可以根据其与第一待监控任务B之间的循环依赖关系，以及该第一待监控任务A与其下游待监控任务C之间的依赖关系，确定第一待监控任务A待校验的任务实例。对于第一待监控任务B，可以根据其与第一待监控任务A之间的循环依赖关系，以及该第一待监控任务B与其下游待监控任务D之间的依赖关系，确定第一待监控任务B待校验的任务实例。
针对不为保障任务的第二待监控任务，根据第二待监控任务与其下游待监控任务之间的依赖关系，确定第二待监控任务待校验的任务实例，其中，第二待监控任务为除第一待监控任务外的待监控任务。如图2所示，待监控任务C、D和E为第二待监控任务，其中，第二待监控任务C和D为保障任务，第二待监控任务E不为保障任务。对于第二待监控任务E，可根据其与下游待监控任务之间的依赖关系确定待校验的任务实例。
在S104中，针对每一待监控任务，根据该待监控任务待校验的任务实例，对基线进行监控。
其中，待校验的任务实例可以是根据任务之间的依赖关系确定出的，任务之间的依赖关系影响基线上各任务的整体运行，待校验的任务实例的运行情况影响基线的整体状态，因此通过校验该任务实例的运行情况可对基线进行监控。
通过上述技术方案，根据基线中多个待监控任务之间的依赖关系，在确定存在具有循环依赖关系的第一待监控任务的情况下，在确定每一待监控任务待校验的任务实例时，针对不为保障任务的第一待监控任务，可以根据循环依赖关系以及其与下游待监控任务之间的依赖关系，确定待校验的任务实例。在确定出待校验的任务实例后，可不再进行第一待监控任务之间的循环过程，避免循环依赖关系进入不断循环的过程。针对不为保障任务的第二待监控任务，可以根据其与下游待监控任务之间的依赖关系，确定待校验的任务实例。其中，保障任务可以是用户添加到基线中的任务，对于保障任务，可将最新的任务实例确定为待校验的任务实例，对于不为保障任务的待监控任务，可将其被依赖的最新的任务实例确定为待校验的任务实例。如此，仅对待校验的任务实例进行校验即可，无需重复校验更早的任务实例，避免重复校验。并且，待校验的任务实例的运行情况影响基线的整体状态，通过对待校验的任务实例进行校验，可对基线进行有效监控，从而可以有效运维日常任务，保证任务的正常运行以及业务数据的正常产出。
本公开中，根据循环依赖关系、以及第一待监控任务与其下游待监控任务之间的依赖关系，确定第一待监控任务待校验的任务实例，可包括：
根据第一待监控任务依赖的其上游第一待监控任务的第一任务实例、以及该上游第一待监控任务作为该第一待监控任务的下游时与该第一待监控任务之间依赖偏移的偏移信息，确定该第一待监控任务被依赖的第二任务实例；根据该第二任务实例、以及第一待监控任务被其下游待监控任务依赖的任务实例，确定第一待监控任务被依赖的最新的任务实例，并将该最新的任务实例确定为第一待监控任务待校验的任务实例。
首先对依赖偏移进行介绍。依赖偏移是指一个待监控任务依赖于另一个待监控任务的历史执行情况，偏移信息可用于表征依赖于另一待监控任务历史何时的执行情况。如图2所示，以待监控任务为天任务为例，待监控任务C对待监控任务A的依赖偏移的偏移信息为0，可表征待监控任务C依赖待监控任务A当天的执行情况；待监控任务A对待监控任务B的依赖偏移的偏移信息为-1，可表征待监控任务A依赖待监控任务B前一天的执行情况。小时任务与之类似，以待监控任务为小时任务为例，根据偏移信息，待监控任务C依赖待监控任务A当前小时的执行情况，待监控任务A依赖待监控任务B上一小时的执行情况。此外需要说明的是，上述0和-1仅为偏移信息的一种示例性表示方式，偏移信息还可通过离散的时间点或时间区间来表示，以小时任务为例，例如待监控任务C依赖待监控任务A的偏移信息为[-3，0]，可表征待监控任务C依赖待监控任务A过去四个小时的执行情况。另外，天任务的上游也可有小时任务，例如天任务依赖于该小时任务，偏移信息为2点、4点，即该天任务依赖于该小时任务2点的执行情况和4点的执行情况。
下面对确定待校验的任务实例的过程进行介绍。如图2所示，首先以待监控任务为天任务为例进行解释说明，例如当天为7月26日，待监控任务C作为保障任务，可确定其待校验的任务实例为最新的任务实例，即7月25日的任务实例，同样，待监控任务D作为保障任务，其待校验的任务实例为7月25日的任务实例。
针对第一待监控任务A，其下游待监控任务C对其依赖偏移的偏移信息为0，即待监控任务C待校验的7月25日的任务实例依赖于待监控任务A的7月25日的任务实例。
第一待监控任务A和第一待监控任务B之间为循环依赖关系，当第一待监控任务A作为下游时，对其上游第一待监控任务B的依赖偏移的偏移信息为-1，即第一待监控任务A的7月25日的任务实例依赖的其上游第一待监控任务B的第一任务实例，为第一待监控任务B的7月24日的任务实例。由于二者之间互相依赖，当第一待监控任务B作为下游时，与其上游第一待监控任务A之间依赖偏移的偏移信息为0，那么根据第一任务实例以及该偏移信息，可确定第一待监控任务A被第一待监控任务B依赖的第二任务实例，为第 一待监控任务A的7月24日的任务实例。
对于第一待监控任务A来说，由于待监控任务C对其的依赖为7月25日的任务实例，第一待监控任务B对其的依赖为7月24日的任务实例，那么第一待监控任务A被依赖的最新的任务实例即为7月25日的任务实例，可将7月25日的任务实例确定为第一待监控任务A待校验的任务实例。并且，根据二者之间的循环依赖关系，此时确定出的第一待监控任务A被第一待监控任务B依赖的7月24日的任务实例，不为第一待监控任务A最新的任务实例，之后可不再进行二者之间的循环过程，如果继续进行二者之间的循环过程，那么可确定出第一待监控任务A7月24日的任务实例依赖第一待监控任务B7月23日的任务实例，第一待监控任务B7月23日的任务实例又依赖第一待监控任务A7月23日的任务实例，该7月23日的任务实例更不为第一待监控任务A最新的任务实例，因此可不再继续进行二者之间的循环过程。
针对第一待监控任务B，第一待监控任务A7月25日的任务实例依赖于第一待监控任务B7月24日的任务实例，根据二者之间的循环依赖关系，第一待监控任务B作为下游时，其7月24日的任务实例依赖的其上游第一待监控任务A的第一任务实例，为第一待监控任务A7月24日的任务实例，然后第一待监控任务A作为下游时，根据该第一任务实例以及偏移信息-1，可确定第一待监控任务B被依赖的第二任务实例为7月23日的任务实例。并且，其下游待监控任务D对其依赖偏移的偏移信息为-2，即待监控任务D待校验的7月25日的任务实例依赖于待监控任务B的7月23日的任务实例。如此，由于7月23日的任务实例早于7月24日的任务实例，此时可确定第一待监控任务B被依赖的最新的任务实例为7月24日的任务实例，并且可不再进行二者之间的循环过程。如果继续进行二者之间的循环过程，后续确定出的第一待监控任务B被依赖的7月22日、7月21日等的任务实例，更不为最新的任务实例。
通过上述技术方案，针对具有循环依赖关系的第一待监控任务，可根据循环依赖关系、以及下游待监控任务对其依赖偏移的偏移信息，确定第一待监控任务被依赖的最新的任务实例，并将该最新的任务实例确定为第一待监控任务待校验的任务实例。在确定出待校验的任务实例后，可不再进行第一待监控任务之间的循环，避免循环依赖关系进入不断循环的过程，之后通过对待校验的任务实例进行校验，以对基线进行监控。
本公开中，根据第二待监控任务与其下游待监控任务之间的依赖关系，确定第二待监控任务待校验的任务实例，可包括：
根据第二待监控任务与其下游待监控任务之间依赖偏移的偏移信息，确定第二待监控任务被依赖的最新的任务实例，并将该最新的任务实例作为第二待监控任务待校验的任 务实例。
其中，第二待监控任务不具有循环依赖关系，因此可直接根据其与下游待监控任务之间的依赖关系，确定待校验的任务实例。如图2所示，针对第二待监控任务E，其下游待监控任务B对其依赖偏移的偏移信息为0，因此待监控任务B的7月24日的任务实例依赖第二待监控任务E的7月24日的任务实例，为第二待监控任务E最新的任务实例，可将7月24日的任务实例作为第二待监控任务E待校验的任务实例。
如图2所示的依赖关系，可将7月24日的任务实例作为第二待监控任务E待校验的任务实例，如果还有一个待监控任务F(图中未示出)作为第二待监控任务E的下游，且对第二待监控任务E的依赖偏移的偏移信息为0，例如该待监控任务F待校验的任务实例为7月25日的任务实例，那么该任务实例依赖于第二待监控任务E的7月25日的任务实例，由此可确定7月25日的任务实例为第二待监控任务E被依赖的最新的任务实例，并可将7月25日的任务实例确定为第二待监控任务E待校验的任务实例。
通过上述技术方案，根据第二待监控任务与其下游待监控任务之间依赖偏移的偏移信息，确定第二待监控任务被依赖的最新的任务实例，并将该最新的任务实例确定为待校验的任务实例。如此，仅需对最新的任务实例进行校验，无需重复校验更早的任务实例，以对基线进行监控。
如果待监控任务为小时任务，如图2所示，示例地，例如当前时间为15点，待监控任务C作为保障任务，其待校验的任务实例可以是最新的任务实例，即14点的任务实例，待监控任务D作为保障任务，其待校验的任务实例可以为14点的任务实例。对于第一待监控任务A，根据其与第一待监控任务B之间的循环依赖关系、以及与其下游待监控任务之间的依赖关系，可确定第一待监控任务A被依赖的最新的任务实例为14点的任务实例，可将14点的任务实例作为第一待监控任务A待校验的任务实例。对于第一待监控任务B，根据其与第一待监控任务A之间的循环依赖关系、以及与其下游待监控任务之间的依赖关系，可将13点的任务实例作为第一待监控任务B待校验的任务实例。对于第二待监控任务E，可将13点的任务实例作为其待校验的任务实例。
上文详细阐述了确定待校验的任务实例的过程，下面介绍确定待监控任务对应的校验时间信息的过程，即应该在何时对待校验的任务实例进行校验。
本公开提供的基线监控方法还可包括：根据预设的基线承诺时间和预警余量、以及多个待监控任务之间的依赖关系，确定每一待监控任务对应的校验时间信息。
其中，用户在创建基线时，可将保障任务添加到基线中，还可设置基线承诺时间和预警余量。基线承诺时间即基线的最晚完成时间，基线中所有待监控任务需要在该基线承 诺时间之前完成，如果未在该基线承诺时间之前完成，则基线破线。基线承诺时间可以根据基线的预计完成时间来设置，基线的预计完成时间可以为全部保障任务的预计完成时间中的最大时间。预警余量可以是设置的缓冲时长，基线承诺时间减去预警余量为基线预警完成时间，期望所有待监控任务在基线预警完成时间之前即能够完成，如果未在该基线预警完成时间之前完成，则基线预警。对于基线来说，基线破线比基线预警带来的影响更严重。
待监控任务对应的校验时间信息可包括预警最晚开始时间、承诺最晚开始时间、任务预警完成时间、任务承诺完成时间。
其中，任务承诺完成时间减去预警余量为任务预警完成时间，任务承诺完成时间减去待监控任务的平均运行时长为承诺最晚开始时间，承诺最晚开始时间减去预警余量为预警最晚开始时间，任务预警完成时间减去待监控任务的平均运行时长为预警最晚开始时间。本公开中，待监控任务的平均运行时长可以是根据除待监控任务的多个历史运行时长中的最大时长和最小时长外的历史运行时长确定的。示例地，多个历史运行时长可以是过去15天的运行时长，去除多个历史运行时长中的最大时长和最小时长之后，可将剩余历史运行时长的平均值作为待监控任务的平均运行时长。由于最大时长和最小时长可能是由于待监控任务运行不稳定出现的运行时长过长或过短，因此根据除最大时长和最小时长外的历史运行时长确定平均运行时长，可避免极端值的影响，使得确定出的平均运行时长更准确。
如图2所示，以待监控任务为天任务为例，例如预设的基线承诺时间为10点，预警余量为1h。在确定校验时间信息时，可以从下游保障任务开始，根据任务之间的依赖关系由下往上遍历，以确定每一待监控任务的校验时间信息。
其中，待监控任务C的任务承诺完成时间可以为10点，任务预警完成时间为9点，例如待监控任务C的平均运行时长为30min，那么其预警最晚开始时间为8点30分，承诺最晚开始时间为9点30分。
对于待监控任务A，由于待监控任务C依赖于该待监控任务A，待监控任务A执行成功之后待监控任务C方可执行，因此待监控任务A的任务承诺完成时间可以是待监控任务C的承诺最晚开始时间9点30分，待监控任务A的任务预警完成时间可以是待监控任务C的预警最晚开始时间8点30分。例如待监控任务A的平均运行时长为1.5h，那么待监控任务A的承诺最晚开始时间为8点，预警最晚开始时间为7点。
对于待监控任务D，其任务承诺完成时间可以为8点，任务预警完成时间为7点，例如待监控任务D的平均运行时长为20min，那么其预警最晚开始时间为6点40分，承诺最晚开始时间为7点40分。
对于待监控任务B，待监控任务A和待监控任务D均依赖该待监控任务B的执行。为了使得待监控任务A能够在预警最晚开始时间7点前执行，待监控任务B的任务预警完成时间需要为7点；为了使得待监控任务D能够在预警最晚开始时间6点40分前执行，待监控任务B的任务预警完成时间需要为6点40。为了保证待监控任务A和待监控任务D均能顺利执行，待监控任务B的任务预警完成时间可以取其下游待监控任务的预警最晚开始时间中的最早时间，即6点40分。例如待监控任务B的平均运行时长为40min，那么其预警最晚开始时间为6点，承诺最晚开始时间为7点，任务承诺完成时间为7点40分。
针对待监控任务E，其任务承诺完成时间可以为7点，任务预警完成时间可以为6点，例如待监控任务E的平均运行时长为30min，那么其预警最晚开始时间为5点30分，承诺最晚开始时间为6点30分。
由此，从保障任务开始，由下往上遍历，根据预设的基线承诺时间和预警余量、以及任务之间的依赖关系，可确定出各个待监控任务对应的校验时间信息。相应地，上述S104中根据待监控任务待校验的任务实例对基线进行监控的示例性实施方式可如图3所示，包括S301和S302。
在S301中，在待监控任务对应的校验时间信息所指示的时间，校验待监控任务待校验的任务实例的运行状态。在S302中，根据校验结果，确定基线的基线状态，以对基线进行监控。
示例地，例如对于待监控任务A，可以在7月26日的预警最晚开始时间7点以及承诺最晚开始时间8点，校验其7月25日的任务实例是否已经开始运行，在任务预警完成时间8点30分以及任务承诺完成时间9点30分，校验其7月25日的任务实例是否已经运行成功。其他待监控任务的校验与之类似不再赘述。
其中，基线状态可包括安全、预警、破线和其他，基线处于其他状态可以指的是，基线中没有关联待监控任务或者待监控任务处于关闭状态时基线所处的状态。S302中根据校验结果确定基线状态可包括：
若校验结果表征待校验的任务实例在预警最晚开始时间之前已开始运行、且在任务预警完成时间之前运行成功，可表征该任务实例正常运行，则可确定基线状态为安全状态；
若校验结果表征待校验的任务实例在预警最晚开始时间尚未开始运行，或者，待校验的任务实例在任务预警完成时间尚未运行成功，则可确定基线状态为预警状态；
若校验结果表征待校验的任务实例在承诺最晚开始时间尚未开始运行，或者，待校验的任务实例在任务承诺完成时间尚未运行成功，则可确定基线状态为破线状态。
值得说明的是，待监控任务之间是有上下游依赖关系的，基线中每一待监控任务的 运行对整个基线的状态具有影响。示例地，在对待监控任务E进行校验时，如果校验结果表征待监控任务E未在预警最晚开始时间之前运行，那么由于该待监控任务E运行过晚，会同时影响其下游其他待监控任务的按时运行，导致其下游其他待监控任务无法按时开始运行，因此可确定基线状态为预警状态。
如此，在校验时间信息所指示的时间，对待校验的任务实例的运行状态进行校验，通过任务实例的运行状态，可对整个基线进行监控。
如图2所示，以待监控任务为小时任务为例，基线承诺时间例如为小时中的第55min，预警余量为5min。对于待监控任务C，例如其任务承诺完成时间为第55min，预警完成时间为第50min，如果其平均运行时长为10min，则其承诺最晚开始时间为第45min，预警最晚开始时间为第40min。沿用上述示例，可在15点40分，校验待监控任务C的14点的任务实例是否已经开始运行，如果尚未开始运行，那么可确定基线状态为预警状态。
对于待监控任务A，如果其平均运行时长为5min，那么其任务承诺完成时间为第45min，任务预警完成时间为第40min，承诺最晚开始时间为第40min，预警最晚开始时间为第35min，例如可在15点35分，校验待监控任务A的14点的任务实例是否已经开始运行。其他待监控任务的校验时间信息的确定，可参照上述对天任务的介绍。
另外，还可根据校验结果发出报警信息，如果确定基线状态为预警状态，可向该基线负责人发送基线预警的报警信息，如果确定基线状态为破线状态，可向该基线负责人发送基线破线的报警信息，以及时提示基线负责人该基线的运行情况。
本公开提供的基线监控方法还可包括：针对每一待监控任务，根据待监控任务待校验的任务实例当前的实例状态，确定待监控任务的实时余量；根据每一待监控任务的实时余量的最小值，确定基线的实时余量；根据基线的实时余量，确定基线的基线状态。
实时余量可表征基线预警或破线的警戒程度。任务实例当前的实例状态可包括等待执行状态、执行中状态和执行失败状态。本公开中，处于不同实例状态的任务实例，对应的待监控任务的实时余量的确定方式不同，而不是所有的待监控任务均采用相同的实时余量确定方式，使得采用的确定方式与实例状态相对应，从而保证确定出的待监控任务的实时余量的准确性。
其中，在待校验的任务实例当前的实例状态为等待执行状态的情况下，可以根据当前时间和待监控任务的任务承诺完成时间、预期调度时间、平均运行时长，确定待监控任务的实时余量。预期调度时间可以是预期的该待监控任务期望在何时被调度，一般情况下，由于其他任务的影响，待监控任务的实际运行时间会晚于或等于该预期调度时间。
示例地，在任务实例的实例状态为等待执行状态的情况下，可通过如下公式确定对 应待监控任务的实时余量T1：
T1＝任务承诺完成时间-[max(预期调度时间，当前时间)+平均运行时长]
在待校验的任务实例当前的实例状态为执行中状态的情况下，可以根据当前时间和待监控任务的任务承诺完成时间、实际开始执行时间、平均运行时长，确定待监控任务的实时余量。示例地，在任务实例的实例状态为执行中状态的情况下，可通过如下公式确定对应待监控任务的实时余量T2：
T2＝任务承诺完成时间-[max(当前时间，实际开始执行时间+平均运行时长)]
在待校验的任务实例当前的实例状态为执行失败状态的情况下，可以根据当前时间和待监控任务的任务承诺完成时间、平均运行时长，确定待监控任务的实时余量。示例地，在任务实例的实例状态为执行失败状态的情况下，可通过如下公式确定对应待监控任务的实时余量T3：
T3＝任务承诺完成时间-(当前时间+平均运行时长)
其中，由于基线的状态受到每一待监控任务的影响，可将每一待监控任务的实时余量的最小值，确定为基线的实时余量，并根据基线的实时余量，确定基线的基线状态。如果基线的实时余量为正数且大于预警余量，则可表征基线状态是安全的，且实时余量的数值越大越安全；如果基线的实时余量小于预警余量，可表征基线状态为预警状态；如果基线的实时余量为负数，则可表征基线状态为破线状态，且实时余量的数值越小破线程度越高。
在上述技术方案中，处于不同实例状态的任务实例，对应的待监控任务的实时余量的确定方式不同，使得采用的确定方式与实例状态相对应，保证确定出的待监控任务的实时余量的准确性，从而保证根据待监控任务的实时余量确定出的基线状态的准确性。
本公开提供的基线监控方法还可包括：在待监控任务的实际运行时长大于待监控任务的平均运行时长的预设比例的情况下，确定待监控任务为运行变慢的任务，其中，平均运行时长不同，对应的预设比例不同。
待监控任务在运行过程中，可能会运行失败，此时可针对该待监控任务进行出错报警，向任务负责人发送任务运行出错的报警信息。另外，待监控任务在运行过程中，还可能会出现运行变慢的情况，即待监控任务的实际运行时长大于平均运行时长。本公开中，并不是只要待监控任务的实际运行时长大于平均运行时长就认为是运行变慢的任务，而是在实际运行时长大于平均运行时长的预设比例的情况下，才确定待监控任务为运行变慢的任务，这样可以一定程度上控制变慢事件的数量，防止不必要的变慢事件的记录。
并且，在本公开中，平均运行时长不同，对应的预设比例可以不同，可以根据平均 运行时长设置对应的预设比例。在一实施例中，平均运行时长和预设比例的对应关系可如下表1所示：
表1
平均运行时长 预设比例
0min～10min 200％
11min～60min 160％
61min～120min 140％
121min～180min 130％
181min以上 120％
需要说明的是，表1所示的实施例进行示例性的，不构成对本公开实施方式的限制。示例地，例如待监控任务C的平均运行时长为30min，那么待监控任务C的实际运行时长大于或等于48min时，确定待监控任务C为运行变慢的任务。
通过上述技术方案，在待监控任务的实际运行时长大于平均运行时长的预设比例的情况下，才确定待监控任务为运行变慢的任务，并且，平均运行时长不同，对应的预设比例可以不同，这样可以一定程度上控制变慢事件的数量，防止不必要的变慢事件的记录。
基于同一发明构思，本公开还提供一种基线监控装置，图4是根据一示例性实施例示出的一种基线监控装置的示意图，如图4所示，该装置400可包括：
待监控任务确定模块401，被配置成用于确定基线中多个待监控任务；
循环依赖关系确定模块402，被配置成用于根据所述多个待监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务，其中，循环依赖关系是指所述第一待监控任务之间互相依赖；
任务实例确定模块403，被配置成用于确定每一所述待监控任务待校验的任务实例，其中，在存在具有循环依赖关系的所述第一待监控任务的情况下，针对不为保障任务的所述第一待监控任务，根据所述循环依赖关系、以及所述第一待监控任务与其下游待监控任务之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，针对不为所述保障任务的第二待监控任务，根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，其中，所述第二待监控任务为除所述第一待监控任务外的待监控任务，所述保障任务为用户添加到所述基线中的任务；
监控模块404，被配置成用于针对每一所述待监控任务，根据该待监控任务待校验的所述任务实例，对所述基线进行监控。
通过上述技术方案，根据基线中多个待监控任务之间的依赖关系，在确定存在具有循环依赖关系的第一待监控任务的情况下，在确定每一待监控任务待校验的任务实例时，针对不为保障任务的第一待监控任务，可以根据循环依赖关系以及其与下游待监控任务之间的依赖关系，确定待校验的任务实例。在确定出待校验的任务实例后，可不再进行第一待监控任务之间的循环过程，避免循环依赖关系进入不断循环的过程。针对不为保障任务的第二待监控任务，可以根据其与下游待监控任务之间的依赖关系，确定待校验的任务实例。其中，保障任务可以是用户添加到基线中的任务，对于保障任务，可将最新的任务实例确定为待校验的任务实例，对于不为保障任务的待监控任务，可将其被依赖的最新的任务实例确定为待校验的任务实例。如此，仅对待校验的任务实例进行校验即可，无需重复校验更早的任务实例，避免重复校验。并且，待校验的任务实例的运行情况影响基线的整体状态，通过对待校验的任务实例进行校验，可对基线进行有效监控，从而可以有效运维日常任务，保证任务的正常运行以及业务数据的正常产出。
可选地，所述任务实例确定模块403，可包括：第一确定子模块，被配置成用于根据所述第一待监控任务依赖的其上游第一待监控任务的第一任务实例、以及该上游第一待监控任务作为所述第一待监控任务的下游时与所述第一待监控任务之间依赖偏移的偏移信息，确定所述第一待监控任务被依赖的第二任务实例，其中，依赖偏移是指一个待监控任务依赖于另一个待监控任务的历史执行情况；第二确定子模块，被配置成用于根据所述第二任务实例、以及所述第一待监控任务被其下游待监控任务依赖的任务实例，确定所述第一待监控任务被依赖的最新的任务实例，并将该最新的任务实例确定为所述第一待监控任务待校验的所述任务实例。
可选地，所述任务实例确定模块403，可包括：第三确定子模块，被配置成用于根据所述第二待监控任务与其下游待监控任务之间依赖偏移的偏移信息，确定所述第二待监控任务被依赖的最新的任务实例，并将该最新的任务实例作为所述第二待监控任务待校验的所述任务实例。
可选地，所述任务实例确定模块403，可包括：第四确定子模块，被配置成用于针对作为保障任务的所述待监控任务，根据所述待监控任务最新的任务实例，确定所述待监控任务待校验的所述任务实例。
可选地，所述装置400还可包括：校验时间信息确定模块，被配置成用于根据预设的基线承诺时间和预警余量、以及所述多个待监控任务之间的所述依赖关系，确定每一所述待监控任务对应的校验时间信息；所述监控模块404，可包括：校验子模块，被配置成用于在所述待监控任务对应的所述校验时间信息所指示的时间，校验所述待监控任务待校 验的所述任务实例的运行状态；第五确定子模块，被配置成用于根据校验结果，确定所述基线的基线状态，以对所述基线进行监控。
可选地，所述校验时间信息包括预警最晚开始时间、承诺最晚开始时间、任务预警完成时间、任务承诺完成时间；所述第五确定子模块，包括：安全状态确定子模块，被配置成用于若所述校验结果表征所述任务实例在所述预警最晚开始时间之前已开始运行、且在所述任务预警完成时间之前运行成功，则确定所述基线状态为安全状态；预警状态确定子模块，被配置成用于若所述校验结果表征所述任务实例在所述预警最晚开始时间尚未开始运行，或者，所述任务实例在所述任务预警完成时间尚未运行成功，则确定所述基线状态为预警状态；破线状态确定子模块，被配置成用于若所述校验结果表征所述任务实例在所述承诺最晚开始时间尚未开始运行，或者，所述任务实例在所述任务承诺完成时间尚未运行成功，则确定所述基线状态为破线状态。
可选地，所述装置400还可包括：任务实时余量确定模块，被配置成用于针对每一所述待监控任务，根据所述待监控任务待校验的所述任务实例当前的实例状态，确定所述待监控任务的实时余量，其中，处于不同实例状态的所述任务实例，对应的所述待监控任务的实时余量的确定方式不同；基线实时余量确定模块，被配置成用于根据每一所述待监控任务的实时余量的最小值，确定所述基线的实时余量；基线状态确定模块，被配置成用于根据所述基线的实时余量，确定所述基线的基线状态。
可选地，所述实例状态包括等待执行状态、执行中状态和执行失败状态；所述任务实时余量确定模块，包括：第一实时余量确定子模块，被配置成用于在所述任务实例当前的所述实例状态为所述等待执行状态的情况下，根据当前时间和所述待监控任务的任务承诺完成时间、预期调度时间、平均运行时长，确定所述待监控任务的实时余量；第二实时余量确定子模块，被配置成用于在所述任务实例当前的所述实例状态为所述执行中状态的情况下，根据所述当前时间和所述待监控任务的所述任务承诺完成时间、实际开始执行时间、所述平均运行时长，确定所述待监控任务的实时余量；第三实时余量确定子模块，被配置成用于在所述任务实例当前的所述实例状态为所述执行失败状态的情况下，根据所述当前时间和所述待监控任务的所述任务承诺完成时间、所述平均运行时长，确定所述待监控任务的实时余量。
可选地，所述装置400还包括：变慢任务确定模块，被配置成用于在所述待监控任务的实际运行时长大于所述待监控任务的平均运行时长的预设比例的情况下，确定所述待监控任务为运行变慢的任务，其中，所述平均运行时长不同，对应的所述预设比例不同。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实 施例中进行了详细描述，此处将不做详细阐述说明。
下面参考图5，其示出了适于用来实现本公开实施例的电子设备500的结构示意图。本公开实施例中的终端设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图5示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
如图5所示，电子设备500可以包括处理装置(例如中央处理器、图形处理器等)501，其可以根据存储在只读存储器(ROM)502中的程序或者从存储装置508加载到随机访问存储器(RAM)503中的程序而执行各种适当的动作和处理。在RAM 503中，还存储有电子设备500操作所需的各种程序和数据。处理装置501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。
通常，以下装置可以连接至I/O接口505：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置506；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置507；包括例如磁带、硬盘等的存储装置508；以及通信装置509。通信装置509可以允许电子设备500与其他设备进行无线或有线通信以交换数据。虽然图5示出了具有各种装置的电子设备500，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。
特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置509从网络上被下载和安装，或者从存储装置508被安装，或者从ROM 502被安装。在该计算机程序被处理装置501执行时，执行本公开实施例的方法中限定的上述功能。
需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结 合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。
在一些实施方式中，客户端、服务器可以利用诸如HTTP(HyperText Transfer Protocol，超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)，广域网(“WAN”)，网际网(例如，互联网)以及端对端网络(例如，ad hoc端对端网络)，以及任何当前已知或未来研发的网络。
上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。
上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：确定基线中多个待监控任务；根据所述多个待监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务，其中，循环依赖关系是指所述第一待监控任务之间互相依赖；确定每一所述待监控任务待校验的任务实例，其中，在存在具有循环依赖关系的所述第一待监控任务的情况下，针对不为保障任务的所述第一待监控任务，根据所述循环依赖关系、以及所述第一待监控任务与其下游待监控任务之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，针对不为所述保障任务的第二待监控任务，根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，其中，所述第二待监控任务为除所述第一待监控任务外的待监控任务，所述保障任务为用户添加到所述基线中的任务；针对每一所述待监控任务，根据该待监控任务待校验的所述任务实例，对所述基线进行监控。
可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言——诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域 网(LAN)或广域网(WAN)——连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块的名称在某种情况下并不构成对该模块本身的限定，例如，待监控任务确定模块还可以被描述为“确定模块”。
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
根据本公开的一个或多个实施例，示例1提供了一种基线监控方法，包括：确定基线中多个待监控任务；根据所述多个待监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务，其中，循环依赖关系是指所述第一待监控任务之间互相依赖；确定每一所述待监控任务待校验的任务实例，其中，在存在具有循环依赖关系的所述第一待监控任务的情况下，针对不为保障任务的所述第一待监控任务，根据所述循环依赖关系、 以及所述第一待监控任务与其下游待监控任务之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，针对不为所述保障任务的第二待监控任务，根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，其中，所述第二待监控任务为除所述第一待监控任务外的待监控任务，所述保障任务为用户添加到所述基线中的任务；针对每一所述待监控任务，根据该待监控任务待校验的所述任务实例，对所述基线进行监控。
根据本公开的一个或多个实施例，示例2提供了示例1的方法，所述根据所述循环依赖关系、以及所述第一待监控任务与其下游待监控任务之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，包括：根据所述第一待监控任务依赖的其上游第一待监控任务的第一任务实例、以及该上游第一待监控任务作为所述第一待监控任务的下游时与所述第一待监控任务之间依赖偏移的偏移信息，确定所述第一待监控任务被依赖的第二任务实例，其中，依赖偏移是指一个待监控任务依赖于另一个待监控任务的历史执行情况；根据所述第二任务实例、以及所述第一待监控任务被其下游待监控任务依赖的任务实例，确定所述第一待监控任务被依赖的最新的任务实例，并将该最新的任务实例确定为所述第一待监控任务待校验的所述任务实例。
根据本公开的一个或多个实施例，示例3提供了示例1的方法，所述根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，包括：根据所述第二待监控任务与其下游待监控任务之间依赖偏移的偏移信息，确定所述第二待监控任务被依赖的最新的任务实例，并将该最新的任务实例作为所述第二待监控任务待校验的所述任务实例。
根据本公开的一个或多个实施例，示例4提供了示例1的方法，所述确定每一所述待监控任务待校验的任务实例，包括：针对作为保障任务的所述待监控任务，根据所述待监控任务最新的任务实例，确定所述待监控任务待校验的所述任务实例。
根据本公开的一个或多个实施例，示例5提供了示例1的方法，所述方法还包括：根据预设的基线承诺时间和预警余量、以及所述多个待监控任务之间的所述依赖关系，确定每一所述待监控任务对应的校验时间信息；所述根据该待监控任务待校验的任务实例，对所述基线进行监控，包括：在所述待监控任务对应的所述校验时间信息所指示的时间，校验所述待监控任务待校验的所述任务实例的运行状态；根据校验结果，确定所述基线的基线状态，以对所述基线进行监控。
根据本公开的一个或多个实施例，示例6提供了示例5的方法，所述校验时间信息包括预警最晚开始时间、承诺最晚开始时间、任务预警完成时间、任务承诺完成时间；所 述根据校验结果，确定所述基线的基线状态，包括：若所述校验结果表征所述任务实例在所述预警最晚开始时间之前已开始运行、且在所述任务预警完成时间之前运行成功，则确定所述基线状态为安全状态；若所述校验结果表征所述任务实例在所述预警最晚开始时间尚未开始运行，或者，所述任务实例在所述任务预警完成时间尚未运行成功，则确定所述基线状态为预警状态；若所述校验结果表征所述任务实例在所述承诺最晚开始时间尚未开始运行，或者，所述任务实例在所述任务承诺完成时间尚未运行成功，则确定所述基线状态为破线状态。
根据本公开的一个或多个实施例，示例7提供了示例1的方法，所述方法还包括：针对每一所述待监控任务，根据所述待监控任务待校验的所述任务实例当前的实例状态，确定所述待监控任务的实时余量，其中，处于不同实例状态的所述任务实例，对应的所述待监控任务的实时余量的确定方式不同；根据每一所述待监控任务的实时余量的最小值，确定所述基线的实时余量；根据所述基线的实时余量，确定所述基线的基线状态。
根据本公开的一个或多个实施例，示例8提供了示例7的方法，所述实例状态包括等待执行状态、执行中状态和执行失败状态；所述根据所述待监控任务待校验的任务实例当前的实例状态，确定所述待监控任务的实时余量，包括：在所述任务实例当前的所述实例状态为所述等待执行状态的情况下，根据当前时间和所述待监控任务的任务承诺完成时间、预期调度时间、平均运行时长，确定所述待监控任务的实时余量；在所述任务实例当前的所述实例状态为所述执行中状态的情况下，根据所述当前时间和所述待监控任务的所述任务承诺完成时间、实际开始执行时间、所述平均运行时长，确定所述待监控任务的实时余量；在所述任务实例当前的所述实例状态为所述执行失败状态的情况下，根据所述当前时间和所述待监控任务的所述任务承诺完成时间、所述平均运行时长，确定所述待监控任务的实时余量。
根据本公开的一个或多个实施例，示例9提供了示例1的方法，所述方法还包括：在所述待监控任务的实际运行时长大于所述待监控任务的平均运行时长的预设比例的情况下，确定所述待监控任务为运行变慢的任务，其中，所述平均运行时长不同，对应的所述预设比例不同。
根据本公开的一个或多个实施例，示例10提供了示例8或示例9的方法，所述平均运行时长是根据除所述待监控任务的多个历史运行时长中的最大时长和最小时长外的所述历史运行时长确定的。
根据本公开的一个或多个实施例，示例11提供了一种基线监控装置，包括：待监控任务确定模块，被配置成用于确定基线中多个待监控任务；循环依赖关系确定模块，被配 置成用于根据所述多个待监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务，其中，循环依赖关系是指所述第一待监控任务之间互相依赖；任务实例确定模块，被配置成用于确定每一所述待监控任务待校验的任务实例，其中，在存在具有循环依赖关系的所述第一待监控任务的情况下，针对不为保障任务的所述第一待监控任务，根据所述循环依赖关系、以及所述第一待监控任务与其下游待监控任务之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，针对不为所述保障任务的第二待监控任务，根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，其中，所述第二待监控任务为除所述第一待监控任务外的待监控任务，所述保障任务为用户添加到所述基线中的任务；监控模块，被配置成用于针对每一所述待监控任务，根据该待监控任务待校验的所述任务实例，对所述基线进行监控。
根据本公开的一个或多个实施例，示例12提供了一种计算机可读介质，其上存储有计算机程序，该程序被处理装置执行时实现示例1至示例10中任一项所述方法的步骤。
根据本公开的一个或多个实施例，示例13提供了一种电子设备，包括：存储装置，其上存储有计算机程序；处理装置，用于执行所述存储装置中的所述计算机程序，以实现示例1至示例10中任一项所述方法的步骤。
根据本公开的一个或多个实施例，示例14提供了一种计算机程序，包括：指令，所述指令当由处理器执行时使所述处理器执行示例1至示例10中任一项所述方法的步骤。
根据本公开的一个或多个实施例，示例15提供了供一种计算机程序产品，包括指令，所述指令当由处理器执行时使所述处理器执行示例1至示例10中任一项所述方法的步骤。
以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
此外，虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。
尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理 解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

Claims (15)

  1. 一种基线监控方法，包括：
    确定基线中多个待监控任务；
    根据所述多个待监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务，其中，循环依赖关系是指所述第一待监控任务之间互相依赖；
    确定每一所述待监控任务待校验的任务实例，其中，在存在具有循环依赖关系的所述第一待监控任务的情况下，针对不为保障任务的所述第一待监控任务，根据所述循环依赖关系、以及所述第一待监控任务与其下游待监控任务之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，针对不为所述保障任务的第二待监控任务，根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，其中，所述第二待监控任务为除所述第一待监控任务外的待监控任务，所述保障任务为用户添加到所述基线中的任务；
    针对每一所述待监控任务，根据该待监控任务待校验的所述任务实例，对所述基线进行监控。
  2. 根据权利要求1所述的基线监控方法，其中，所述根据所述循环依赖关系、以及所述第一待监控任务与其下游待监控任务之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，包括：
    根据所述第一待监控任务依赖的其上游第一待监控任务的第一任务实例、以及该上游第一待监控任务作为所述第一待监控任务的下游时与所述第一待监控任务之间依赖偏移的偏移信息，确定所述第一待监控任务被依赖的第二任务实例，其中，依赖偏移是指一个待监控任务依赖于另一个待监控任务的历史执行情况；
    根据所述第二任务实例、以及所述第一待监控任务被其下游待监控任务依赖的任务实例，确定所述第一待监控任务被依赖的最新的任务实例，并将该最新的任务实例确定为所述第一待监控任务待校验的所述任务实例。
  3. 根据权利要求1所述的基线监控方法，其中，所述根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，包括：
    根据所述第二待监控任务与其下游待监控任务之间依赖偏移的偏移信息，确定所述第二待监控任务被依赖的最新的任务实例，并将该最新的任务实例作为所述第二待监控任 务待校验的所述任务实例。
  4. 根据权利要求1所述的基线监控方法，其中，所述确定每一所述待监控任务待校验的任务实例，包括：
    针对作为保障任务的所述待监控任务，根据所述待监控任务最新的任务实例，确定所述待监控任务待校验的所述任务实例。
  5. 根据权利要求1所述的基线监控方法，还包括：
    根据预设的基线承诺时间和预警余量、以及所述多个待监控任务之间的所述依赖关系，确定每一所述待监控任务对应的校验时间信息；
    所述根据该待监控任务待校验的任务实例，对所述基线进行监控，包括：
    在所述待监控任务对应的所述校验时间信息所指示的时间，校验所述待监控任务待校验的所述任务实例的运行状态；
    根据校验结果，确定所述基线的基线状态，以对所述基线进行监控。
  6. 根据权利要求5所述的基线监控方法，其中，所述校验时间信息包括预警最晚开始时间、承诺最晚开始时间、任务预警完成时间、任务承诺完成时间；
    所述根据校验结果，确定所述基线的基线状态，包括：
    若所述校验结果表征所述任务实例在所述预警最晚开始时间之前已开始运行、且在所述任务预警完成时间之前运行成功，则确定所述基线状态为安全状态；
    若所述校验结果表征所述任务实例在所述预警最晚开始时间尚未开始运行，或者，所述任务实例在所述任务预警完成时间尚未运行成功，则确定所述基线状态为预警状态；
    若所述校验结果表征所述任务实例在所述承诺最晚开始时间尚未开始运行，或者，所述任务实例在所述任务承诺完成时间尚未运行成功，则确定所述基线状态为破线状态。
  7. 根据权利要求1所述的基线监控方法，还包括：
    针对每一所述待监控任务，根据所述待监控任务待校验的所述任务实例当前的实例状态，确定所述待监控任务的实时余量，其中，处于不同实例状态的所述任务实例，对应的所述待监控任务的实时余量的确定方式不同；
    根据每一所述待监控任务的实时余量的最小值，确定所述基线的实时余量；
    根据所述基线的实时余量，确定所述基线的基线状态。
  8. 根据权利要求7所述的基线监控方法，其中，所述实例状态包括等待执行状态、执行中状态和执行失败状态；
    所述根据所述待监控任务待校验的任务实例当前的实例状态，确定所述待监控任务的实时余量，包括：
    在所述任务实例当前的所述实例状态为所述等待执行状态的情况下，根据当前时间和所述待监控任务的任务承诺完成时间、预期调度时间、平均运行时长，确定所述待监控任务的实时余量；
    在所述任务实例当前的所述实例状态为所述执行中状态的情况下，根据所述当前时间和所述待监控任务的所述任务承诺完成时间、实际开始执行时间、所述平均运行时长，确定所述待监控任务的实时余量；
    在所述任务实例当前的所述实例状态为所述执行失败状态的情况下，根据所述当前时间和所述待监控任务的所述任务承诺完成时间、所述平均运行时长，确定所述待监控任务的实时余量。
  9. 根据权利要求1所述的基线监控方法，还包括：
    在所述待监控任务的实际运行时长大于所述待监控任务的平均运行时长的预设比例的情况下，确定所述待监控任务为运行变慢的任务，其中，所述平均运行时长不同，对应的所述预设比例不同。
  10. 根据权利要求8或9所述的基线监控方法，其中，所述平均运行时长是根据除所述待监控任务的多个历史运行时长中的最大时长和最小时长外的所述历史运行时长确定的。
  11. 一种基线监控装置，包括：
    待监控任务确定模块，被配置成用于确定基线中多个待监控任务；
    循环依赖关系确定模块，被配置成用于根据所述多个待监控任务之间的依赖关系，确定是否存在具有循环依赖关系的第一待监控任务，其中，循环依赖关系是指所述第一待监控任务之间互相依赖；
    任务实例确定模块，被配置成用于确定每一所述待监控任务待校验的任务实例，其中，在存在具有循环依赖关系的所述第一待监控任务的情况下，针对不为保障任务的所述第一待监控任务，根据所述循环依赖关系、以及所述第一待监控任务与其下游待监控任务 之间的依赖关系，确定所述第一待监控任务待校验的所述任务实例，针对不为所述保障任务的第二待监控任务，根据所述第二待监控任务与其下游待监控任务之间的依赖关系，确定所述第二待监控任务待校验的所述任务实例，其中，所述第二待监控任务为除所述第一待监控任务外的待监控任务，所述保障任务为用户添加到所述基线中的任务；
    监控模块，被配置成用于针对每一所述待监控任务，根据该待监控任务待校验的所述任务实例，对所述基线进行监控。
  12. 一种计算机可读介质，其上存储有计算机程序，该计算机程序被处理装置执行时实现权利要求1-10中任一项所述基线监控方法的步骤。
  13. 一种电子设备，包括：
    存储装置，其上存储有计算机程序；
    处理装置，用于执行所述存储装置中的所述计算机程序，以实现权利要求1-10中任一项所述基线监控方法的步骤。
  14. 一种计算机程序，包括：
    指令，所述指令当由处理器执行时使所述处理器执行根据权利要求1-10中任一项所述基线监控方法的步骤。
  15. 一种计算机程序产品，包括指令，所述指令当由处理器执行时使所述处理器执行根据权利要求1-10中任一项所述基线监控方法的步骤。
PCT/CN2021/128180 2020-11-04 2021-11-02 基线监控方法、装置、可读介质及电子设备 WO2022095848A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2022572367A JP7406010B2 (ja) 2020-11-04 2021-11-02 ベースライン監視方法、装置、読み取り可能な媒体、及び電子機器
EP21888545.7A EP4141670A4 (en) 2020-11-04 2021-11-02 BASELINE MONITORING METHOD AND APPARATUS, READABLE MEDIUM AND ELECTRONIC DEVICE
US18/070,443 US11853792B2 (en) 2020-11-04 2022-11-28 Baseline monitoring method and apparatus, readable medium, and electronic device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011218097.5 2020-11-04
CN202011218097.5A CN112328377B (zh) 2020-11-04 2020-11-04 基线监控方法、装置、可读介质及电子设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/070,443 Continuation US11853792B2 (en) 2020-11-04 2022-11-28 Baseline monitoring method and apparatus, readable medium, and electronic device

Publications (1)

Publication Number Publication Date
WO2022095848A1 true WO2022095848A1 (zh) 2022-05-12

Family

ID=74323640

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/128180 WO2022095848A1 (zh) 2020-11-04 2021-11-02 基线监控方法、装置、可读介质及电子设备

Country Status (5)

Country Link
US (1) US11853792B2 (zh)
EP (1) EP4141670A4 (zh)
JP (1) JP7406010B2 (zh)
CN (1) CN112328377B (zh)
WO (1) WO2022095848A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115134224A (zh) * 2022-08-31 2022-09-30 杭州玳数科技有限公司 Dag图的监控方法及系统

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112328377B (zh) * 2020-11-04 2022-04-19 北京字节跳动网络技术有限公司 基线监控方法、装置、可读介质及电子设备
CN112559161A (zh) * 2021-02-19 2021-03-26 北京搜狐新媒体信息技术有限公司 一种任务调度方法及系统
CN113220542B (zh) * 2021-04-01 2022-10-28 深圳市云网万店科技有限公司 一种计算任务的预警方法、装置、计算机设备及存储介质
CN114610473A (zh) * 2022-05-11 2022-06-10 恒生电子股份有限公司 任务的处理方法及装置、非易失性存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107526631A (zh) * 2017-09-01 2017-12-29 百度在线网络技术（北京）有限公司 一种任务监控方法、装置、设备和介质
CN109558292A (zh) * 2017-09-26 2019-04-02 阿里巴巴集团控股有限公司 一种监控方法及装置
CN109684229A (zh) * 2019-01-08 2019-04-26 杭州雅拓信息技术有限公司 有向无环图的链式依赖分析方法及系统
US20200104231A1 (en) * 2018-09-27 2020-04-02 International Business Machines Corporation Monitorning task output within a system
CN111736969A (zh) * 2020-06-16 2020-10-02 中国银行股份有限公司 分布式作业调度方法及装置
CN112328377A (zh) * 2020-11-04 2021-02-05 北京字节跳动网络技术有限公司 基线监控方法、装置、可读介质及电子设备

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7904369B1 (en) * 2000-02-11 2011-03-08 Kapow Aps User interface, system and method for performing a web-based transaction
JP2006268509A (ja) 2005-03-24 2006-10-05 Nomura Research Institute Ltd ジョブ設定装置およびジョブ設定方法
JP2011187874A (ja) 2010-03-11 2011-09-22 Canon Inc 半導体露光システム
US9286106B1 (en) * 2013-04-16 2016-03-15 Ca, Inc. Scheduling periodic tasks with dependencies and determining improper loop dependencies between tasks placed in a waiting tasks set and in a unfinished dependent tasks set
CN107241205A (zh) * 2016-03-28 2017-10-10 阿里巴巴集团控股有限公司 异常监控方法及装置
US10193762B2 (en) * 2016-08-11 2019-01-29 Rescale, Inc. Dynamic optimization of simulation resources
JP6104447B1 (ja) 2016-10-31 2017-03-29 株式会社ソリトンシステムズ プログラム動作監視制御装置、分散オブジェクト生成管理装置、プログラム、及びプログラム動作監視システム
US10747544B1 (en) * 2019-06-27 2020-08-18 Capital One Services, Llc Dependency analyzer in application dependency discovery, reporting, and management tool
CN110413483B (zh) * 2019-07-30 2023-04-07 中国工商银行股份有限公司 批量作业数据的监控方法、装置、电子设备及存储介质
CN110837457B (zh) * 2019-11-19 2022-05-13 支付宝(杭州)信息技术有限公司 任务管理方法、装置、电子设备及存储介质
CN111427748B (zh) * 2020-03-31 2023-06-23 携程计算机技术（上海）有限公司 任务告警方法、系统、设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107526631A (zh) * 2017-09-01 2017-12-29 百度在线网络技术（北京）有限公司 一种任务监控方法、装置、设备和介质
CN109558292A (zh) * 2017-09-26 2019-04-02 阿里巴巴集团控股有限公司 一种监控方法及装置
US20200104231A1 (en) * 2018-09-27 2020-04-02 International Business Machines Corporation Monitorning task output within a system
CN109684229A (zh) * 2019-01-08 2019-04-26 杭州雅拓信息技术有限公司 有向无环图的链式依赖分析方法及系统
CN111736969A (zh) * 2020-06-16 2020-10-02 中国银行股份有限公司 分布式作业调度方法及装置
CN112328377A (zh) * 2020-11-04 2021-02-05 北京字节跳动网络技术有限公司 基线监控方法、装置、可读介质及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4141670A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115134224A (zh) * 2022-08-31 2022-09-30 杭州玳数科技有限公司 Dag图的监控方法及系统

Also Published As

Publication number Publication date
US20230087168A1 (en) 2023-03-23
JP2023527195A (ja) 2023-06-27
US11853792B2 (en) 2023-12-26
EP4141670A1 (en) 2023-03-01
EP4141670A4 (en) 2023-10-18
CN112328377A (zh) 2021-02-05
CN112328377B (zh) 2022-04-19
JP7406010B2 (ja) 2023-12-26

Similar Documents

Publication Publication Date Title
WO2022095848A1 (zh) 基线监控方法、装置、可读介质及电子设备
CN111950988B (zh) 分布式工作流调度方法、装置、存储介质及电子设备
CN111597065B (zh) 用于采集设备信息的方法和装置
CN111274503B (zh) 数据处理的方法、装置、电子设备及计算机可读介质
WO2021175187A1 (zh) 数据保护方法、装置、电子设备及计算机可读存储介质
CN110928715A (zh) 一种提示错误描述信息的方法、装置、介质和电子设备
CN112954056B (zh) 监控数据处理方法、装置、电子设备及存储介质
WO2023206883A1 (zh) 电池数据动态存储方法、装置及相关设备
CN110727558A (zh) 信息提示方法、装置、存储介质及电子设备
WO2022188576A1 (zh) 性能问题定位方法、装置、电子设备和存储介质
CN111984496A (zh) 一种监控栈内存泄露的方法、装置、介质和电子设备
CN111538577A (zh) 程序执行控制的装置及方法、终端和存储介质
CN111092758A (zh) 降低告警及恢复误报的方法、装置及电子设备
CN110633566A (zh) 一种侵入检测方法、装置、终端设备及介质
CN110750242B (zh) 一种部署文件的方法、系统、介质和电子设备
CN111367555B (zh) 断言的方法、装置、电子设备及计算机可读介质
WO2022152162A1 (zh) 信息处理方法、装置、终端和存储介质
CN115827415B (zh) 系统进程性能测试方法、装置、设备和计算机介质
CN113138883B (zh) 消息处理方法、装置、存储介质及电子设备
CN116954957A (zh) 信息获取方法、装置、设备及存储介质
CN118113580A (zh) 程序运行时长处理方法、装置、设备及存储介质
CN116661956A (zh) 一种异常数据检测方法、装置、终端设备及介质
CN117493150A (zh) 代码质量检测方法、装置、设备、存储介质及程序
CN115408230A (zh) 应用程序管理装置、方法、车辆及存储介质
CN116028452A (zh) 应用程序的存储管理方法、设备、存储介质及产品

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21888545

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022572367

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021888545

Country of ref document: EP

Effective date: 20221125

NENP Non-entry into the national phase

Ref country code: DE