Task executor state determination method and device and electronic equipment

Abstract

The invention discloses a state determination method and device of a task executor and electronic equipment, and relates to the field of distributed technologies. The method comprises the following steps: after detecting that N application actuators successfully quote a target compressed file to connect a service cluster, registering service node information of each application actuator to a target node in the target compressed file through a monitoring program; determining whether each application executor is in an offline state according to the state information of each application executor recorded in the target node; and recording the offline time of the ith application executor, the container information corresponding to the ith application executor and the application information corresponding to the ith application executor in a database under the condition that the ith application executor is detected to be in the offline state. The technical problem that in the prior art, when the states of a large number of task executors are managed, the state determining efficiency is low is solved.

Description

Technical Field

[0001] The present application relates to the field of distributed technology, and in particular to a method, device, and electronic device for determining the state of a task executor. Background Art

[0002] In today's distributed computing environments, processing large numbers of concurrent tasks has become the norm, particularly in big data processing, cloud computing, and enterprise applications. To efficiently execute these tasks, a variety of distributed task scheduling and execution frameworks have been developed, such as Apache Hadoop, Apache Spark, and Airflow. These frameworks can decompose computing tasks and execute them in parallel across clusters consisting of multiple computing nodes.

[0003] However, with the explosive growth in the scale of batch tasks, managing the status of the large number of task executors that execute these tasks has become increasingly challenging. In existing technologies, teams typically use separate monitoring systems or custom solutions to monitor and maintain the health status of task executors. This approach not only leads to duplication of resources, but also, when the number of task executors is large, individually accessing the health check interface of each executor to confirm its status will cause significant delays. In addition, each executor needs to implement independent health monitoring logic, which not only increases the complexity of the code, but may also lead to technical problems such as untimely status monitoring between different executors and inefficient status determination.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0005] The embodiments of the present application provide a method, device, and electronic device for determining the status of a task executor, so as to at least solve the technical problem of low status determination efficiency in managing the status of a large number of task executors in the prior art.

[0006] According to one aspect of an embodiment of the present application, a method for determining the status of a task executor is provided, comprising: after detecting that N application executors successfully reference a target compressed file to connect to a service cluster, registering the service node information of each application executor to a target node in the target compressed file through a monitoring program, wherein N is an integer greater than 1, and the target node is used to detect the status information of each application executor that references the target compressed file, and each application executor is a virtual machine for executing application services; determining whether each application executor is in an offline state based on the status information of each application executor recorded in the target node; when it is detected that the i-th application executor is in an offline state, recording the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor in a database, wherein i is a positive integer less than or equal to N.

[0007] Optionally, the N application executors include at least one of the following types of application executors: a first type of application executor, used to execute a preceding dependent application task, wherein the preceding dependent application task represents an application task that needs to be completed before executing the current application task in the task execution sequence; a second type of application executor, used to execute a succeeding dependent application task, wherein the succeeding dependent application task represents an application task that needs to be started after the current application task is successfully executed in the task execution sequence.

[0008] Optionally, determining whether each application executor is in an offline state based on the status information of each application executor recorded in the target node includes: judging whether each application executor maintains a connection with the target node based on the status information of each application executor; when it is determined that the i-th application executor maintains a connection with the target node, determining that the i-th application executor is in an online state; when it is determined that the i-th application executor does not maintain a connection with the target node, sending a check message to all containers corresponding to the i-th application executor through the monitoring program, wherein any container corresponding to the i-th application executor returns a target feedback value to the monitoring program after receiving the check message; and determining whether the i-th application executor is in an offline state based on the reception result of the target feedback value by the monitoring program.

[0009] Optionally, based on the reception result of the monitoring program for the target feedback value, determining whether the i-th application executor is in an offline state includes: when it is detected that the monitoring program has not received the target feedback value, determining that the i-th application executor is in an offline state; when it is detected that the monitoring program has received the target feedback value, determining that the i-th application executor is in an online state.

[0010] Optionally, the method for determining the status of the task executor also includes: when it is detected that the number of target feedback values ​​received by the monitoring program is less than the number of containers corresponding to the i-th application executor, determining that the i-th application executor is disconnected from some containers; reading the container identifier in each target feedback value received by the monitoring program; and determining the target container disconnected from the i-th application executor based on the container identifier in each target feedback value received by the monitoring program.

[0011] Optionally, determining a target container to be disconnected from the i-th application executor based on a container identifier in each target feedback value received by the monitoring program includes: using a container corresponding to the container identifier in the target feedback value as a first container; and using a container other than the first container among all containers corresponding to the i-th application executor as a target container.

[0012] Optionally, the method for determining the status of a task executor further includes: when it is detected that the i-th application executor is in an online state, storing a data interaction record between the i-th application executor and the target node in a database.

[0013] According to another aspect of the present application, a task executor status determination system is also provided, including: a service cluster; N application executors, wherein N is an integer greater than 1, and each application executor is a virtual machine for executing application services; a monitoring program, for registering the service node information of each application executor to the target node in the target compressed file after detecting that the N application executors successfully reference the target compressed file to connect to the service cluster, wherein the target node is used to detect the status information of each application executor that references the target compressed file; the monitoring program is also used to determine whether each application executor is in an offline state based on the status information of each application executor recorded in the target node; when it is detected that the i-th application executor is in an offline state, the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor are recorded in a database, wherein i is a positive integer less than or equal to N.

[0014] According to another aspect of the present application, a task executor status determination device is also provided, including: a first processing unit, for registering the service node information of each application executor to the target node in the target compressed file through a monitoring program after detecting that N application executors successfully reference the target compressed file to connect to the service cluster, wherein N is an integer greater than 1, and the target node is used to detect the status information of each application executor that references the target compressed file, and each application executor is a virtual machine for executing application services; a second processing unit, for determining whether each application executor is in an offline state based on the status information of each application executor recorded in the target node; a third processing unit, for recording the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor in a database when detecting that the i-th application executor is in an offline state, wherein i is a positive integer less than or equal to N.

[0015] According to another aspect of the present application, a computer-readable storage medium is also provided, wherein the computer-readable storage medium includes a stored executable program, wherein when the executable program runs, the device where the computer-readable storage medium is located is controlled to execute the above-mentioned task executor state determination method.

[0016] According to another aspect of the present application, an electronic device is provided, which includes: a memory storing an executable program; and a processor for running the program, wherein the above-mentioned task executor state determination method is executed when the program is running.

[0017] According to another aspect of the present application, a computer program product is provided, comprising computer instructions, wherein the computer instructions implement the steps of the above-mentioned method for determining the state of a task executor when executed by a processor.

[0018] In the present application, after detecting that N application executors have successfully referenced a target compressed file to connect to a service cluster, the service node information of each application executor is registered with the target node in the target compressed file through a monitoring program, where N is an integer greater than 1. The target node is used to detect the status information of each application executor that references the target compressed file, and each application executor is a virtual machine used to execute application services. Then, based on the status information of each application executor recorded in the target node, it is determined whether each application executor is in an offline state. When it is detected that the i-th application executor is in an offline state, the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor are recorded in a database, where i is a positive integer less than or equal to N.

[0019] From the above content, it can be seen that this application designs a target compressed file (such as a jar package) to control N application executors to establish a connection with the service cluster. The target compressed file needs to be referenced, and then the monitoring program can register the service node information of each application executor to the target node of the target compressed file. In this way, the target node can uniformly record the status information of all application executors, and determine whether each application executor is offline based on the status information of the application executor.

[0020] It can be seen that the method of batch management of task executors provided in this application does not require human intervention. Regardless of the number of application executors, batch management can be easily implemented, which improves the efficiency of determining the status of task executors and solves the technical problem of low status determination efficiency in the existing technology when managing the status of large batches of task executors. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0022] Figure 1 A hardware structure block diagram of a computer terminal for implementing a method for determining the state of a task executor is shown;

[0023] Figure 2 is a flowchart of an optional method for determining the state of a task executor according to an embodiment of the present application;

[0024] Figure 3 is a schematic diagram of an optional task executor state determination process according to an embodiment of the present application;

[0025] Figure 4 is a schematic diagram of an optional device for determining the state of a task executor according to an embodiment of the present application;

[0026] Figure 5 This is a structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0029] It should also be noted that the collected information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions to provide users with corresponding operation portals for users to choose to agree or refuse the automated decision-making results; if the user chooses to refuse, the expert decision-making process will be entered.

[0030] According to an embodiment of the present application, an embodiment of a method for determining the state of a task executor is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0031] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal (or mobile device) for implementing the state determination method of a task executor is shown. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more (illustrated as 102a, 102b, ..., 102n in the figure) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0032] It should be noted that the one or more processors 102 and / or other data processing circuits mentioned above may generally be referred to herein as "data processing circuits". The data processing circuit may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be fully or partially integrated into any of the other components in the computer terminal 10 (or mobile device). As in the state determination method of the task executor involved in the embodiments of the present application, the data processing circuit serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0033] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the state determination method of the task executor in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, realizes the above-mentioned state determination method of the task executor. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0034] The transmission device 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of the computer terminal 10. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is configured to communicate with the Internet wirelessly.

[0035] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0036] Under the above operating environment, this application provides Figure 2 The state determination method of the task executor is shown. Figure 2 is a flowchart of an optional method for determining the state of a task executor according to an embodiment of the present application, such as Figure 2 As shown, the method includes the following steps:

[0037] Step S201 : After detecting that N application executors have successfully referenced the target compressed file to connect to the service cluster, the monitoring program is used to register the service node information of each application executor with the target node in the target compressed file.

[0038] In step S201 , N is an integer greater than 1, and the target node is used to detect status information of each application executor that references the target compressed file. Each application executor is a virtual machine for executing an application service.

[0039] In an optional embodiment, a task executor state determination system can serve as the execution subject of the task executor state determination method of the embodiment of the present application. It is understood that the task executor state determination method provided in the embodiment of the present application can also be executed by other systems or devices, and the embodiment of the present application does not specifically limit this.

[0040] Alternatively, the target compressed file can be interpreted as a specific node in the server cluster for storing and managing health status information about the application executor. The target node can serve as a registration point for detecting the status information of the application executor.

[0041] Optionally, when N application executors (N>1, N is an integer, each executor is a separate instance running on a virtual machine for executing a specific application service) successfully reference the target compressed file to connect to the service cluster (this can be understood as the application executor successfully loading and using the required resources or services, such as a specific compressed file or service endpoint), each executor registers its service node information (including executor ID, virtual machine IP address, service port, health check endpoint, etc.) to the target node through the client.

[0042] Optionally, the monitoring program will scan the target node periodically (for example, every 10 seconds) to check the registration information of each application executor. If the information of an application executor is found to have been registered, the monitoring program will check the health status of the executor.

[0043] Optionally, health checks can be performed by accessing the health check endpoint in the registration information. If a health check fails, the monitoring program will record the executor's unavailable status and update the database with relevant information (such as the time the container went offline, the container name, and application information). Simultaneously, the application's responsible person will be notified via email or SMS to trigger appropriate operations and maintenance.

[0044] Optionally, when the monitoring program finds that an application executor is not registered or the registration information disappears, it can be considered that the executor has gone offline or encountered a network problem. At this time, the monitoring program will also record this event and notify relevant personnel to intervene.

[0045] Step S202 : determining whether each application executor is in an offline state according to the state information of each application executor recorded in the target node.

[0046] Optionally, to further confirm the status of the application executor, the monitoring program can attempt to access the executor's health check endpoint. If the health check returns an unhealthy status or the endpoint is unreachable, the monitoring program determines that the application executor is offline. For any application executors identified as offline, the monitoring program records information such as the offline time, IP address, and executor ID, and updates this information to the database for subsequent fault analysis and resolution.

[0047] Optionally, when the monitoring program detects that an executor is offline, it triggers an alert mechanism, notifying the application manager via email or text message. Upon receiving the notification, the application manager can log in to the relevant virtual machine to verify whether the executor is offline due to insufficient resources, hardware failure, software anomalies, or network issues. Based on the cause of the offline, the application manager can take appropriate operational and maintenance measures, such as restarting the executor, fixing software anomalies, or increasing resource allocation, to restore normal operation of the executor.

[0048] In step S203, when it is detected that the i-th application executor is in an offline state, the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor are recorded in a database, where i is a positive integer less than or equal to N.

[0049] Optionally, when the monitoring program (i.e., the monitor of the distributed batch framework) detects in the target node that the status information of the i-th application executor fails to be updated within a preset time interval (for example, the heartbeat time is not refreshed for more than 30 seconds), or an abnormal result is returned when attempting a health check, the monitoring program will determine that the executor is offline.

[0050] Optionally, the monitoring program can also record the current time when the executor is detected to be offline as an offline time record. The monitoring program can also extract the container-related data of the i-th application executor from the registration information of the server cluster, including the container ID, the creation time of the container, the IP of the host where the container runs, etc. In addition, the monitoring program obtains the application identifier of the application executor, the team to which the application belongs, the application type (such as batch processing tasks, stream processing tasks, etc.) and any other relevant metadata from the registration information. For example, the monitoring program organizes the obtained offline time, container information and application information into structured data, and stores this information in a database table specifically used to manage the health status of the application executor through a communication interface with the database.

[0051] It's important to note that the monitoring program stores this information in a structured database, ensuring detailed records of offline events for easy analysis and auditing. Furthermore, the monitoring program notifies the application manager or operations team of offline events via email or text message, including the executor's offline time, container ID, and application information, enabling rapid response and troubleshooting.

[0052] By implementing the above steps, the system accurately detects and records when any application executor (i, i ≤ N, where N is the total number of currently running application executors) goes offline. This mechanism not only improves monitoring efficiency and accuracy, but also enables the system to promptly notify relevant personnel and take necessary operational measures, thereby reducing the impact of failures on business and enhancing the stability and reliability of the distributed batch task processing framework. Furthermore, database records provide valuable data support for failure analysis, helping to optimize future system design and operational strategies.

[0053] Based on the contents of steps S202 to S203, in this application, after detecting that N application executors have successfully referenced the target compressed file to connect to the service cluster, the service node information of each application executor is registered with the target node in the target compressed file through a monitoring program, where N is an integer greater than 1. The target node is used to detect the status information of each application executor that references the target compressed file, and each application executor is a virtual machine used to execute the application service. Then, based on the status information of each application executor recorded in the target node, it is determined whether each application executor is in an offline state. When it is detected that the i-th application executor is in an offline state, the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor are recorded in a database, where i is a positive integer less than or equal to N.

[0054] From the above content, it can be seen that this application designs a target compressed file (such as a jar package) to control N application executors to establish a connection with the service cluster. The target compressed file needs to be referenced, and then the monitoring program can register the service node information of each application executor to the target node of the target compressed file. In this way, the target node can uniformly record the status information of all application executors, and determine whether each application executor is offline based on the status information of the application executor.

[0055] It can be seen that the method of batch management of task executors provided in this application does not require human intervention. Regardless of the number of application executors, batch management can be easily implemented, which improves the efficiency of determining the status of task executors and solves the technical problem of low status determination efficiency in the existing technology when managing the status of large batches of task executors.

[0056] In an optional embodiment, the N application executors include at least one of the following types of application executors: a first type of application executor, used to execute a preceding dependent application task, wherein the preceding dependent application task represents an application task that needs to be completed before executing the current application task in the task execution sequence; a second type of application executor, used to execute a succeeding dependent application task, wherein the succeeding dependent application task represents an application task that needs to be started after the current application task is successfully executed in the task execution sequence.

[0057] Optionally, regarding the execution control of dependent application tasks: When the i-th application executor starts, it registers its information through the server cluster's storage path and monitors the status of its associated dependent task executors under that path. When the i-th application executor prepares to execute its task, the monitoring program checks the health status and task completion flags of the dependent task executors. If all dependent task executors are healthy and their tasks have completed, the i-th executor begins executing its own task. Otherwise, the executor enters a waiting state until all dependent tasks have completed.

[0058] Optionally, regarding the execution trigger of the subsequent dependent application task: after completing the task, the i-th application executor will update its task completion status through the server cluster and mark it as completed. This status update will serve as a trigger signal and be monitored by the monitoring program. After the monitoring program detects that an application executor has completed a task, it will notify the subsequent dependent application executors in all registry keys that the predecessor dependent task has been completed. After receiving the notification, the subsequent dependent application executor will start executing the subsequent dependent task based on its own execution conditions. If the execution conditions are not met, such as insufficient resources or the output of the predecessor task does not meet expectations, the subsequent dependent executor will delay execution until the conditions are met.

[0059] Optionally, the monitoring program can periodically check the health of all registered application executors. If any offline executors are detected, the monitoring program records their status and notifies the relevant team for resolution. Furthermore, the monitoring program can adjust the order of task execution based on executor types and dependencies to ensure consistent and correct task execution. If the monitoring program detects that a type 1 executor is offline or unable to complete a dependent task, it notifies all dependent type 2 executors to suspend execution until the dependent task is restored or an alternative solution is found.

[0060] It should be noted that, through the registration and notification mechanism of the server cluster, the dependencies between executors are automatically managed without manual intervention, which greatly improves the degree of automation of task execution. In addition, it ensures that the subsequent dependent tasks are executed after the previous dependent tasks are completed, thus avoiding execution confusion or failure due to improper handling of dependencies, and improving the order and accuracy of task execution. Moreover, the intelligent coordination mechanism of the monitoring program can optimize resource allocation according to the health status of the executors and the completion of tasks, and quickly isolate the affected executors and tasks when a fault occurs, reducing the spread of faults and improving the overall stability and efficiency of the system. Finally, through this embodiment, the distributed batch task execution framework can effectively manage different types of executors and their task dependencies, ensure the smooth execution of tasks, and provide a mechanism for fault handling and resource optimization, which significantly improves the operating efficiency and stability of the distributed system.

[0061] In an optional embodiment, to determine whether each application executor is offline based on the status information of each application executor recorded in the target node, the status determination system may determine whether each application executor maintains a connection with the target node based on the status information of each application executor. If it is determined that the i-th application executor maintains a connection with the target node, the i-th application executor is determined to be online. If it is determined that the i-th application executor does not maintain a connection with the target node, a monitoring program may be used to send a check message to all containers corresponding to the i-th application executor. Upon receiving the check message, any container corresponding to the i-th application executor returns a target feedback value to the monitoring program. Finally, based on the monitoring program's response to the target feedback value, it is determined whether the i-th application executor is offline.

[0062] Optionally, when the status determination system detects a target node, for each registered application executor, the system first checks whether the executor node maintains a continuous connection with the server cluster (i.e., checks for the presence of a health heartbeat or status update instruction), including: the status determination system periodically (e.g., every 10 seconds) accesses the target node to obtain the latest status information of each application executor. If the target node contains heartbeat information for the i-th application executor, and the update time of the heartbeat information is within a permitted threshold (e.g., the update time is no more than 30 seconds from the current time), the status determination system determines that the executor maintains a valid connection with the server cluster and is in an online state.

[0063] Optionally, if the latest status information for the i-th executor cannot be detected in the target node, the status determination system will send a health check request (check message) to all containers associated with the i-th executor through the monitoring program, requesting a target feedback value representing the container's health status. After receiving the check message, each container will execute the health check logic and generate a feedback value based on the hardware status, software status, and task execution status of the application executor. For example, this can be represented by a status code such as HTTP 200 (healthy) or HTTP 500 (unhealthy).

[0064] Optionally, the monitoring program collects feedback values ​​from all relevant containers and analyzes the statistical results of these feedback values. If the feedback values ​​of all containers indicate an unhealthy state, or the feedback values ​​fail to return within a preset time (for example, within 2 seconds), the status determination system marks the i-th application executor as offline. Conversely, if at least one container feedback indicates a healthy state, or the feedback value returns successfully, the status determination system will consider that the connection problem between the i-th application executor and the server cluster may be temporary, and the executor is currently in a recoverable online state.

[0065] Optionally, the status determination system updates the online and offline status determination results in a database. For offline executors, the system records the specific offline time, container information, application ID, and possible offline reasons. Furthermore, if an application executor is detected as offline, the status determination system sends an alert to the application owner via email or SMS, notifying them of the executor's offline status. It also provides a preliminary offline cause analysis and recommended remediation measures to accelerate troubleshooting and remediation.

[0066] It should be noted that by introducing the dual mechanisms of task executor connection status check and container health check, this embodiment significantly improves the accuracy of executor status detection, avoids misjudgment caused by a single detection method, and ensures the reliability of system monitoring.

[0067] In an optional embodiment, in the process of determining whether the i-th application executor is in an offline state based on the reception result of the monitoring program for the target feedback value, if it is detected that the monitoring program has not received the target feedback value, it is determined that the i-th application executor is in an offline state; if it is detected that the monitoring program has received the target feedback value, it is determined that the i-th application executor is in an online state.

[0068] Optionally, when the monitoring program fails to detect the latest status information for the i-th application executor in the target node, it sends a health check request to each container of that executor. The target feedback value returned by the request represents the current health status of the container. After receiving the health check request, each container executes its internal health check logic, which includes but is not limited to checking the application service status, resource usage, task execution status, etc., and generates a feedback value representing the container's health status. The container sends the feedback value back to the monitoring program via an HTTP response (for example, HTTP 200 indicates normal, HTTP 500 indicates abnormal).

[0069] Optionally, after sending a health check request, the monitoring program sets a response timeout (e.g., 5 seconds) to wait for feedback from all containers. If the monitoring program fails to receive feedback from any container within the timeout, it is considered that the container or executor of the i-th application executor has a communication failure or is offline. In this case, the monitoring program marks the status of the i-th application executor as offline and records information such as the time of the check and the list of containers attempted to be accessed. Conversely, if the monitoring program receives feedback from at least one container, and this feedback indicates that the container is healthy (e.g., an HTTP 200 response), the monitoring program determines that at least some containers of the i-th application executor are still online, and the overall status of the executor is online. Even if some containers fail to respond, as long as there are healthy containers, the executor status is still determined to be online. Furthermore, after determining the status, the monitoring program updates the database with information such as the current time, the ID of the i-th application executor, container information, and executor status (online / offline), providing a basis for subsequent troubleshooting and status auditing. For executors marked as offline, the monitoring program will send an alert to the application-side person in charge through the preset email / SMS notification system, including detailed information about the offline executor, possible offline reasons, and recommended treatment measures, so as to quickly respond to and handle the abnormal status of the executor.

[0070] It should be noted that, through the intelligent analysis of the container feedback value by the monitoring program, this embodiment can accurately judge the health status of the actuator, avoid the misjudgment that may be caused by single-point inspection, and improve the accuracy and stability of the actuator status detection in the distributed framework. The response timeout mechanism in the embodiment can quickly identify the communication failure or offline status of the actuator. Combined with the status records of the database, it helps to quickly locate the fault point, take isolation or repair measures, and reduce the impact of the fault on the system operation. Regular health checks and status updates enable the framework to adjust the resource allocation strategy in a timely manner and optimize the operating environment of the actuator. At the same time, timely notification of offline status allows operation and maintenance personnel to intervene quickly, reducing maintenance costs and improving the overall operation and maintenance efficiency of the system.

[0071] In an optional embodiment, if the monitoring program detects that the number of target feedback values ​​received is less than the number of containers corresponding to the i-th application executor, the status determination system may determine that the i-th application executor is disconnected from some containers, and then read the container identifier in each target feedback value received by the monitoring program. Finally, the status determination system may determine the target container disconnected from the i-th application executor based on the container identifier in each target feedback value received by the monitoring program.

[0072] Optionally, when the status determination system performs a health check, it compares the number of containers registered by the i-th application executor in the server cluster with the number of received valid target feedback values. If the number of received feedback values ​​is less than the number of registered containers, the status determination system immediately determines that there is a disconnection between the i-th application executor and some of the containers, or that the container status is abnormal.

[0073] In addition, after receiving the target feedback value, the status determination system will parse the container identifier (for example, container ID or name) in each feedback value and record it in a temporary cache or a temporary table in the database for subsequent analysis. The status determination system identifies containers that have not responded to health check requests by comparing the list of containers registered in the server cluster with the list of container identifiers that received the feedback value. For each unresponsive container, the status determination system analyzes the possible reasons for the disconnection, such as network problems, container crashes, application failures, etc., and records them in the database as a basis for subsequent maintenance and troubleshooting.

[0074] Optionally, the status determination system can also update the detailed information of the identified disconnected containers (including container ID, status, possible reasons for disconnection) to a specific database table in the database, so that operation and maintenance personnel can quickly locate the problem container. At the same time, the status determination system can generate isolation or restart instructions for the disconnected containers, and send them to the container management system (such as Docker, Kubernetes) through API or message queue to automatically isolate or restart the faulty container to ensure the overall stability of the executor and service continuity. The status determination system can also send the list of disconnected containers and related data to the person in charge of the application side via email or text message, along with a preliminary fault analysis and recommended repair measures. The person in charge of the application side conducts further troubleshooting based on the information received, and decides whether manual intervention is required, such as adjusting resource allocation, modifying application configuration, or performing code repairs, to restore the normal operation of the container.

[0075] By comparing the number of feedback values ​​with the number of registered containers, this embodiment can accurately identify containers disconnected from the actuator, enhancing the comprehensiveness and accuracy of the monitoring system. Identifying disconnected containers and recording their status can provide operations and maintenance personnel with a basis for quickly locating fault points. Combined with automatic isolation and restart mechanisms, this shortens the repair time of faulty containers and improves the overall availability and efficiency of the system. Through detailed container identification and disconnection cause analysis, misjudgments caused by temporary fluctuations in container status or transient network outages are avoided, reducing unnecessary resource consumption and manual maintenance costs.

[0076] In an optional embodiment, in the process of determining the target container disconnected from the i-th application executor based on the container identifier in each target feedback value received by the monitoring program, the state determination system may use the container corresponding to the container identifier in the target feedback value as the first container and use the container other than the first container among all containers corresponding to the i-th application executor as the target container.

[0077] Optionally, when the monitoring program sends a health check request to the i-th application executor and receives a target feedback value, it first parses each feedback value and extracts the container identifiers contained therein. These identifiers are regarded as the "first container", that is, the container that is currently still connected to the executor.

[0078] Optionally, the status determination system obtains a list of all container information registered by the i-th application executor, including container ID, container name, and container status. The system compares the first container identifier list for which feedback values ​​are received with the list of container information registered in the server cluster to identify any containers that are not included in the feedback values. Containers that are not included in the feedback values ​​are considered "target containers" disconnected from the i-th application executor. The status determination system records detailed information about these containers, including container ID, name, and last online time.

[0079] Optionally, for the identified target container, the status determination system sends a disconnection alert to the person in charge on the application side through a preset alarm mechanism (such as email, SMS, enterprise-level instant messaging tools, etc.), including detailed information of the target container and possible reasons for disconnection, as well as recommended inspection and recovery steps.

[0080] In addition, based on the reason for the target container's disconnection, the status determination system automatically or semi-automatically starts the container recovery process. For example, for a target container caused by a network problem, the status determination system can try to re-establish the network connection or restart the container service through a container management system (such as Docker, Kubernetes). For target container disconnections caused by software failures or application errors, the status determination system will generate a diagnostic report and trigger manual intervention. The application-side development or operation and maintenance personnel will perform code repairs or application status adjustments based on the detailed information in the report. The status determination system will continuously monitor the identified target container until the container restores the connection and sends a health feedback value. Once the target container is restored, its status will be immediately updated to the database, and the person in charge on the application side will be notified to ensure the real-time and accuracy of the status information.

[0081] It should be noted that by comparing the first container with the target container, this embodiment can accurately distinguish containers disconnected from the application executor, avoiding misjudgments caused by feedback delays or network fluctuations, and improving the accuracy of status detection. By quickly identifying the target container and combining automatic recovery processes with manual intervention mechanisms, the normal operation of the failed container can be quickly restored, reducing service interruption time and ensuring the continuity and high availability of task execution.

[0082] In an optional embodiment, when it is detected that the i-th application executor is in an online state, a data interaction record between the i-th application executor and the target node is stored in a database.

[0083] In an optional embodiment, Figure 3 is a schematic diagram of an optional task executor state determination process according to an embodiment of the present application, such as Figure 3 As shown, in order to meet the real-time monitoring needs of the health status of task execution nodes in a distributed computing environment, this application provides a monitor integrated into a distributed batch framework. The monitor is implemented through software and is specifically designed to monitor and maintain the operating status of the executor. Through close collaboration with the server cluster, the monitor can listen to and parse the progress reporting instructions (i.e., heartbeat signals) of the executor, which are regularly sent by the executor to a dedicated path preset in the server cluster. In addition, the monitor is also responsible for collecting and recording the real-time operating status of each application executor, and updating these key data to the database in a timely manner, providing detailed information support for system operation and maintenance.

[0084] Optionally, the distributed batch framework specifies the target node in the core jar package, which is used to detect the online status and health level of the application-side executor node, ensuring the accurate implementation of the monitoring strategy. Figure 3 As shown, the application executors include one for executing preceding dependent tasks and one for executing subsequent dependent tasks. Upon startup, the batch executor node automatically references and loads the JAR package from the framework, establishing a connection through the server cluster. During operation, each executor node registers its information with the target node defined above, enabling real-time status reporting and two-way communication with the framework.

[0085] Optionally, the monitor can employ a scheduled task mechanism, for example, every 10 seconds, to proactively scan target nodes to verify the online status of executors. Upon detecting an executor node's heartbeat signal, the monitor collects the node information and synchronously records it to the database, along with the current timestamp, as real-time verification of the executor's operational status. If the heartbeat signal for an executor node is lost, the monitor immediately initiates an HTTP health check request to all of the executor's containers. By analyzing the response values ​​from these HTTP requests, the monitor can accurately determine the executor node's true status—i.e., whether it is offline or unavailable.

[0086] When the monitor confirms that an application executor node is offline or unavailable, it will record detailed information such as the precise time of the offline, the name of the affected container, and application information, ensuring that the database status information is always up to date. Simultaneously, the system will send an alert notification to the application manager via email or SMS to ensure timely response and resolution of the issue. Upon receiving the notification, the application manager must verify the cause of the executor node's offline status and, depending on the circumstances, take manual intervention measures, such as restarting the service, fixing application errors, or adjusting network configuration, to restore the executor's normal operation as soon as possible.

[0087] Through the implementation of the above mechanism, an efficient and accurate executor health status monitoring and management platform has been built, which not only optimizes the operating efficiency of the executors, but also greatly reduces the burden on the operation and maintenance team, and enhances the overall stability and reliability of the distributed batch task processing system.

[0088] According to another aspect of an embodiment of the present application, a task executor status determination system is also provided, including: a service cluster; N application executors, wherein N is an integer greater than 1, and each application executor is a virtual machine for executing application services; a monitoring program, for registering the service node information of each application executor to the target node in the target compressed file after detecting that the N application executors successfully reference the target compressed file to connect to the service cluster, wherein the target node is used to detect the status information of each application executor that references the target compressed file; the monitoring program is also used to determine whether each application executor is in an offline state based on the status information of each application executor recorded in the target node; when it is detected that the i-th application executor is in an offline state, the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor are recorded in a database, wherein i is a positive integer less than or equal to N.

[0089] Alternatively, the target compressed file can be interpreted as a specific node in the server cluster for storing and managing health status information about the application executor. The target node can serve as a registration point for detecting the status information of the application executor.

[0090] Optionally, when N application executors (N>1, N is an integer, each executor is a separate instance running on a virtual machine for executing a specific application service) successfully reference the target compressed file to connect to the service cluster (this can be understood as the application executor successfully loading and using the required resources or services, such as a specific compressed file or service endpoint), each executor registers its service node information (including executor ID, virtual machine IP address, service port, health check endpoint, etc.) to the target node through the client.

[0091] Optionally, the monitoring program will scan the target node periodically (for example, every 10 seconds) to check the registration information of each application executor. If the information of an application executor is found to have been registered, the monitoring program will check the health status of the executor.

[0092] Optionally, health checks can be performed by accessing the health check endpoint in the registration information. If a health check fails, the monitoring program will record the executor's unavailable status and update the database with relevant information (such as the time the container went offline, the container name, and application information). Simultaneously, the application's responsible person will be notified via email or SMS to trigger appropriate operations and maintenance.

[0093] Optionally, when the monitoring program finds that an application executor is not registered or the registration information disappears, it can be considered that the executor has gone offline or encountered a network problem. At this time, the monitoring program will also record this event and notify relevant personnel to intervene.

[0094] Optionally, to further confirm the status of the application executor, the monitoring program can attempt to access the executor's health check endpoint. If the health check returns an unhealthy status or the endpoint is unreachable, the monitoring program determines that the application executor is offline. For any application executors identified as offline, the monitoring program records information such as the offline time, IP address, and executor ID, and updates this information to the database for subsequent fault analysis and resolution.

[0095] Optionally, when the monitoring program detects that an executor is offline, it triggers an alert mechanism, notifying the application manager via email or text message. Upon receiving the notification, the application manager can log in to the relevant virtual machine to verify whether the executor is offline due to insufficient resources, hardware failure, software anomalies, or network issues. Based on the cause of the offline, the application manager can take appropriate operational and maintenance measures, such as restarting the executor, fixing software anomalies, or increasing resource allocation, to restore normal operation of the executor.

[0096] Optionally, when the monitoring program (i.e., the monitor of the distributed batch framework) detects in the target node that the status information of the i-th application executor fails to be updated within a preset time interval (for example, the heartbeat time is not refreshed for more than 30 seconds), or an abnormal result is returned when attempting a health check, the monitoring program will determine that the executor is offline.

[0097] Optionally, the monitoring program can also record the current time when the executor is detected to be offline as an offline time record. The monitoring program can also extract the container-related data of the i-th application executor from the registration information of the server cluster, including the container ID, the creation time of the container, the IP of the host where the container runs, etc. In addition, the monitoring program obtains the application identifier of the application executor, the team to which the application belongs, the application type (such as batch processing tasks, stream processing tasks, etc.) and any other relevant metadata from the registration information. For example, the monitoring program organizes the obtained offline time, container information and application information into structured data, and stores this information in a database table specifically used to manage the health status of the application executor through a communication interface with the database.

[0098] It's important to note that the monitoring program stores this information in a structured database, ensuring detailed records of offline events for easy analysis and auditing. Furthermore, the monitoring program notifies the application manager or operations team of offline events via email or text message, including the executor's offline time, container ID, and application information, enabling rapid response and troubleshooting.

[0099] From the above content, it can be seen that this application designs a target compressed file (such as a jar package) to control N application executors to establish a connection with the service cluster. The target compressed file needs to be referenced, and then the monitoring program can register the service node information of each application executor to the target node of the target compressed file. In this way, the target node can uniformly record the status information of all application executors, and determine whether each application executor is offline based on the status information of the application executor.

[0100] It can be seen that the method of batch management of task executors provided in this application does not require human intervention. Regardless of the number of application executors, batch management can be easily implemented, which improves the efficiency of determining the status of task executors and solves the technical problem of low status determination efficiency in the existing technology when managing the status of large batches of task executors.

[0101] According to another aspect of the embodiment of the present application, a device for determining the state of a task executor is also provided, such as Figure 4 As shown, the state determination device of the task executor includes: a first processing unit 401, a second processing unit 402, and a third processing unit 403.

[0102] Among them, the first processing unit 401 is used to register the service node information of each application executor to the target node in the target compressed file through the monitoring program after detecting that N application executors successfully reference the target compressed file to connect to the service cluster, wherein N is an integer greater than 1, and the target node is used to detect the status information of each application executor that references the target compressed file, and each application executor is a virtual machine for executing application services; the second processing unit 402 is used to determine whether each application executor is in an offline state based on the status information of each application executor recorded in the target node; the third processing unit 403 is used to record the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor in a database when detecting that the i-th application executor is in an offline state, wherein i is a positive integer less than or equal to N.

[0103] Optionally, the N application executors include at least one of the following types of application executors: a first type of application executor, used to execute a preceding dependent application task, wherein the preceding dependent application task represents an application task that needs to be completed before executing the current application task in the task execution sequence; a second type of application executor, used to execute a succeeding dependent application task, wherein the succeeding dependent application task represents an application task that needs to be started after the current application task is successfully executed in the task execution sequence.

[0104] Optionally, the second processing unit 402 includes: a first processing sub-unit, a second processing sub-unit, a third processing sub-unit, and a fourth processing sub-unit. The first processing sub-unit is configured to determine whether each application executor maintains a connection with the target node based on the status information of each application executor; the second processing sub-unit is configured to determine whether the i-th application executor is online when it is determined that the i-th application executor maintains a connection with the target node; the third processing sub-unit is configured to send a check message to all containers corresponding to the i-th application executor through a monitoring program when it is determined that the i-th application executor does not maintain a connection with the target node, wherein any container corresponding to the i-th application executor returns a target feedback value to the monitoring program after receiving the check message; and the fourth processing sub-unit is configured to determine whether the i-th application executor is offline based on the monitoring program's reception result of the target feedback value.

[0105] Optionally, the fourth processing sub-unit includes: a first determining module and a second determining module. The first determining module is configured to determine that the i-th application executor is in an offline state if it detects that the monitoring program has not received the target feedback value; and the second determining module is configured to determine that the i-th application executor is in an online state if it detects that the monitoring program has received the target feedback value.

[0106] Optionally, the task executor status determination device further includes: a first determination unit, a reading unit, and a second determination unit. The first determination unit is configured to determine that the i-th application executor is disconnected from some containers when detecting that the number of target feedback values ​​received by the monitoring program is less than the number of containers corresponding to the i-th application executor; the reading unit is configured to read the container identifier in each target feedback value received by the monitoring program; and the second determination unit is configured to determine the target container to be disconnected from the i-th application executor based on the container identifier in each target feedback value received by the monitoring program.

[0107] Optionally, the second determining unit includes: a fifth processing subunit and a sixth processing subunit. The fifth processing subunit is configured to use the container corresponding to the container identifier in the target feedback value as the first container; and the sixth processing subunit is configured to use the container other than the first container among all containers corresponding to the i-th application executor as the target container.

[0108] Optionally, the task executor status determination device further includes: a storage unit, configured to store data interaction records between the i-th application executor and the target node in a database when it is detected that the i-th application executor is in an online state.

[0109] An embodiment of the present application may further provide an electronic device, Figure 5 This is a structural block diagram of an electronic device according to an embodiment of the present application. Figure 5 As shown, the electronic device may include: one or more ( Figure 5 Only one is shown) processor, memory, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0110] Among them, the memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and devices in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, realizing the state determination method of the above-mentioned task executor. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely located relative to the processor, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0111] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: after detecting that N application executors successfully reference the target compressed file to connect to the service cluster, register the service node information of each application executor to the target node in the target compressed file through the monitoring program, where N is an integer greater than 1, and the target node is used to detect the status information of each application executor that references the target compressed file, and each application executor is a virtual machine for executing application services; determine whether each application executor is in an offline state based on the status information of each application executor recorded in the target node; when it is detected that the i-th application executor is in an offline state, record the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor in a database, where i is a positive integer less than or equal to N.

[0112] The processor can call the information and application programs stored in the memory through the transmission device to perform the following steps: determine whether each application executor maintains a connection with the target node based on the status information of each application executor; when it is determined that the i-th application executor maintains a connection with the target node, determine that the i-th application executor is in an online state; when it is determined that the i-th application executor does not maintain a connection with the target node, send a check message to all containers corresponding to the i-th application executor through the monitoring program, wherein any container corresponding to the i-th application executor returns a target feedback value to the monitoring program after receiving the check message; and determine whether the i-th application executor is in an offline state based on the reception result of the target feedback value by the monitoring program.

[0113] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: when it is detected that the monitoring program has not received the target feedback value, determine that the i-th application executor is in an offline state; when it is detected that the monitoring program has received the target feedback value, determine that the i-th application executor is in an online state.

[0114] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: when it is detected that the number of target feedback values ​​received by the monitoring program is less than the number of containers corresponding to the i-th application executor, determine that the i-th application executor is disconnected from some containers; read the container identifier in each target feedback value received by the monitoring program; and determine the target container to be disconnected from the i-th application executor based on the container identifier in each target feedback value received by the monitoring program.

[0115] The processor may call the information and application stored in the memory through the transmission device to perform the following steps: using the container corresponding to the container identifier in the target feedback value as the first container; and using the container other than the first container among all containers corresponding to the i-th application executor as the target container.

[0116] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: when it is detected that the i-th application executor is online, the data interaction record between the i-th application executor and the target node is stored in the database.

[0117] It can be understood by those skilled in the art that Figure 5 The structure shown is for illustration only, and the electronic device may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (MID), a PAD, or other terminal devices. Figure 5 It does not limit the structure of the above electronic device. For example, the electronic device may also include Figure 5 More or fewer components (such as network interfaces, display devices, etc.) shown in, or with Figure 5 Different configurations shown.

[0118] A person skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0119] According to another aspect of the present application, a computer program product is provided, comprising computer instructions, wherein the computer instructions implement the steps of the above-mentioned method for determining the state of a task executor when executed by a processor.

[0120] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0121] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0122] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0123] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0124] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0125] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0126] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for determining the state of a task executor, characterized in that: include: After detecting that N application executors successfully reference the target compressed file to connect to the service cluster, register the service node information of each application executor to the target node in the target compressed file through a monitoring program, wherein N is an integer greater than 1, and the target node is used to detect the status information of each application executor that references the target compressed file, and each application executor is a virtual machine used to execute application services; Determining whether each application executor is in an offline state according to the state information of each application executor recorded in the target node; When it is detected that the i-th application executor is in the offline state, the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor are recorded in a database, where i is a positive integer less than or equal to N.

2. The method for determining the state of a task executor according to claim 1, characterized in that: The N application executors include at least one of the following types of application executors: The first type of application executor is used to execute the application task that is dependent on the previous item, wherein the application task that is dependent on the previous item represents the application task that needs to be completed before executing the current application task in the task execution sequence; The second type of application executor is used to execute subsequent dependent application tasks, wherein the subsequent dependent application tasks represent application tasks that need to be executed after the current application task is successfully executed in the task execution sequence.

3. The method for determining the state of a task executor according to claim 1, characterized in that: Determining whether each application executor is in an offline state according to the state information of each application executor recorded in the target node includes: Determining, according to the status information of each application executor, whether each application executor maintains a connection with the target node; In a case where it is determined that the i-th application executor maintains a connection with the target node, determining that the i-th application executor is in an online state; When it is determined that the i-th application executor is not connected to the target node, a check message is sent to all containers corresponding to the i-th application executor through the monitoring program, wherein any container corresponding to the i-th application executor returns a target feedback value to the monitoring program after receiving the check message; According to the reception result of the monitoring program for the target feedback value, it is determined whether the i-th application executor is in an offline state.

4. The method for determining the state of a task executor according to claim 3, characterized in that: Determining whether the i-th application executor is in an offline state according to a result of receiving the target feedback value by the monitoring program includes: In a case where it is detected that the monitoring program has not received the target feedback value, determining that the i-th application executor is in an offline state; In a case where it is detected that the monitoring program receives the target feedback value, it is determined that the i-th application executor is in an online state.

5. The method for determining the state of a task executor according to claim 4, characterized in that: The method for determining the state of the task executor also includes: When it is detected that the number of the target feedback values ​​received by the monitoring program is less than the number of containers corresponding to the i-th application executor, determining that the i-th application executor is disconnected from some containers; reading a container identifier in each of the target feedback values ​​received by the monitoring program; A target container disconnected from the i-th application executor is determined according to a container identifier in each target feedback value received by the monitoring program.

6. The method for determining the state of a task executor according to claim 5, characterized in that: Determining a target container disconnected from the i-th application executor according to a container identifier in each target feedback value received by the monitoring program includes: Using a container corresponding to the container identifier in the target feedback value as a first container; The container other than the first container among all containers corresponding to the i-th application executor is used as the target container.

7. The method for determining the state of a task executor according to claim 1, characterized in that: The method for determining the state of the task executor also includes: When it is detected that the i-th application executor is in an online state, a data interaction record between the i-th application executor and the target node is stored in the database.

8. A task executor state determination system, characterized in that: include: Service cluster; N application executors, where N is an integer greater than 1, and each application executor is a virtual machine for executing an application service; A monitoring program, configured to register the service node information of each application executor with the target node in the target compressed file after detecting that the N application executors successfully reference the target compressed file to connect to the service cluster, wherein the target node is used to detect the status information of each application executor that references the target compressed file; The monitoring program is also used to determine whether each application executor is in an offline state based on the status information of each application executor recorded in the target node; when it is detected that the i-th application executor is in the offline state, the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor are recorded in a database, where i is a positive integer less than or equal to N.

9. A device for determining the state of a task executor, characterized in that: include: A first processing unit is configured to register service node information of each application executor to a target node in the target compressed file through a monitoring program after detecting that N application executors successfully reference the target compressed file to connect to the service cluster, wherein N is an integer greater than 1, and the target node is used to detect status information of each application executor that references the target compressed file, and each application executor is a virtual machine used to execute application services; A second processing unit, configured to determine whether each application executor is in an offline state according to the state information of each application executor recorded in the target node; The third processing unit is used to record the offline time of the i-th application executor, the container information corresponding to the i-th application executor, and the application information corresponding to the i-th application executor in a database when it is detected that the i-th application executor is in the offline state, where i is a positive integer less than or equal to N.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored executable program, wherein when the executable program is executed, the device where the computer-readable storage medium is located is controlled to execute the state determination method of the task executor according to any one of claims 1 to 7.

11. An electronic device, characterized in that: include: A memory storing an executable program; A processor is used to run the program, wherein the program executes the state determination method of the task executor described in any one of claims 1 to 7 when running.

12. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the steps of the method for determining the state of a task executor described in any one of claims 1 to 7 are implemented.

Images