A detection task processing method, device and equipment and readable storage medium

Abstract

The application discloses a kind of detection task processing method, device, equipment and readable storage medium, applied to bare metal technical field, comprising: receiving detection task creation request, and according to detection task creation request determines detection configuration, detection configuration includes the configuration information needed for starting target bare metal device;Prepare starting environment for target bare metal device based on detection configuration, and trigger target bare metal device power-on;After target bare metal device starts successfully, receive the execution information that execution end returns, and update the state of corresponding detection task according to execution information, until detection task ends;When detection task ends, the resources occupied by starting environment are recycled.The application unifies the configuration information needed for starting with detection configuration, and includes the same processing procedure for starting environment preparation, device power-on, execution return and resource recycling, improves the execution success rate of starting link, reduces task abnormal suspension and resource residue after task ends.

Description

Technical Field

[0001] This invention relates to the field of bare metal technology, and in particular to a detection task processing method, apparatus, equipment, and readable storage medium. Background Technology

[0002] Bare metal equipment involves multiple technical stages in pre-delivery inspections, hardware testing, and startup verification, and these stages are typically implemented independently in different technical domains. Due to the lack of a unified coordination mechanism between these stages, issues such as missing parameters, state conflicts, and stage disconnects can easily occur during actual execution, leading to unsatisfactory overall performance and the possibility of resources not being released in a timely manner after the task is completed.

[0003] Therefore, improving the success rate of the bare metal equipment detection startup process, avoiding abnormal task suspension, and reducing resource residue are technical problems that urgently need to be solved in this field. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a detection task processing method, apparatus, device and readable storage medium, which solves the problems of low execution success rate, abnormal task suspension and resource residue in the bare metal device detection startup process in the prior art.

[0005] To address the aforementioned technical problems, this invention provides a detection task processing method, comprising: Receive a detection task creation request and determine the detection configuration based on the detection task creation request. The detection configuration includes the configuration information required to start the target bare metal device. Based on the detection configuration, a startup environment is prepared for the target bare metal device, and the target bare metal device is powered on. After the target bare metal device is successfully started, the execution information returned by the execution terminal for the target bare metal device is received, and the status of the detection task corresponding to the target bare metal device is updated according to the execution information until the detection task ends. At the end of the detection task, the resources used to prepare the startup environment for the target bare metal device are recovered.

[0006] Optionally, the detection configuration is determined based on the detection task creation request, including: The detection configuration is queried based on the detection configuration identifier in the detection task creation request, and the detection configuration is verified to have a data center identifier, a virtual private network identifier, a startup scheme identifier, and a diskless environment identifier. If so, then the detection configuration is confirmed to be valid; If not, an error log will be generated and an incomplete configuration message will be returned.

[0007] Optionally, preparing a startup environment for the target bare metal device based on the detection configuration includes: Based on the unique identifier of the target bare metal device, query the bound client from the diskless environment corresponding to the diskless environment identifier of the detection configuration; If the client exists, then the client is reused; If the client does not exist, a client is created according to the detection configuration; Configure a network link on the switch port connected to the target bare metal device that corresponds to the virtual private network identifier configured in the detection settings.

[0008] Optionally, before powering on the target bare metal device, the following steps are also included: Detect the power status of the target bare metal device; If the target bare metal device is powered on, a forced shutdown operation is performed, and the power status of the target bare metal device is continuously monitored within a first preset time period. If the target bare metal device is detected to have completed shutdown within the first preset time period, the target bare metal device is triggered to power on. If the target bare metal device is detected to have not been shut down within the first preset time period, the status of the detection task will be rolled back to the standby power-on state.

[0009] Optionally, before preparing the boot environment for the target bare metal device based on the detection configuration and triggering the power-on of the target bare metal device, the method further includes: A pre-verification is performed on the target bare metal device, which includes device status verification, task mutual exclusion verification, power status verification, and hardware specification integrity verification. If the aforementioned pre-verification fails, the reason for the failure will be recorded. If the pre-verification is passed, a main task record is created for the target bare metal device, and multiple sub-detection report records associated with the main task record are initialized according to the detection items to be executed.

[0010] Optionally, updating the status of the detection task corresponding to the target bare metal device based on the execution information includes: Upon receiving the first valid feedback for the target bare metal device, record the successful power-on time and update the detection task to the detection in progress status; The corresponding sub-detection report record is updated based on the detection results returned at the granularity of the detection items.

[0011] Optional, also includes: For detection tasks that have been powered on but have not received execution information after the second preset time, execute the startup timeout handling; For detection tasks that have not received a heartbeat for more than a third preset time, determine the cause of the abnormality by combining at least one of the following: startup event information and power status. For all the aforementioned sub-detection report records that have been completed, perform shutdown and resource recovery.

[0012] The present invention also provides a detection task processing device, comprising: A configuration determination module is used to receive a detection task creation request and determine the detection configuration based on the detection task creation request. The detection configuration includes the configuration information required to start the target bare metal device. An environment preparation module is used to prepare a startup environment for the target bare metal device based on the detection configuration and to trigger the target bare metal device to power on. The status update module is used to receive the execution information returned by the execution terminal for the target bare metal device after the target bare metal device is successfully started, and update the status of the detection task corresponding to the target bare metal device according to the execution information until the detection task ends. The resource recovery module is used to recover the resources used to prepare the startup environment for the target bare metal device when the detection task is completed.

[0013] The present invention also provides a detection task processing device, comprising: Memory, used to store computer programs; A processor is used to implement the detection task processing method described above when executing the computer program.

[0014] The present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when loaded and executed by a processor, implement the detection task processing method described above.

[0015] The present invention also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the detection task processing method described above.

[0016] As can be seen from the above technical solution, the present invention receives a detection task creation request and determines the detection configuration based on the request. The detection configuration includes the configuration information required to start the target bare metal device. Based on the detection configuration, a startup environment is prepared for the target bare metal device, and the target bare metal device is powered on. After the target bare metal device starts successfully, the execution information returned by the execution end for the target bare metal device is received, and the status of the detection task corresponding to the target bare metal device is updated according to the execution information until the detection task ends. When the detection task ends, the resources occupied by the startup environment prepared for the target bare metal device are reclaimed. The beneficial effects of this invention are as follows: This invention uses the detection configuration as a unified source of configuration information required for startup, incorporating startup environment preparation, device power-on, execution feedback, and resource reclamation into a single processing flow. This allows multiple previously dispersed steps to revolve around the same configuration, improving the integrity and consistency of the startup chain execution and reducing the probability of failure during startup. By receiving feedback from the execution end to advance the detection task status, the task execution process has a clear basis for status advancement, reducing the time the detection task remains in the intermediate state. By reclaiming the resources occupied by the startup environment at the end of the detection task, the residual network configuration, operating environment, and device status after the task ends are reduced, ensuring that bare metal devices can be restarted or detected normally again.

[0017] In addition, the present invention also provides a detection task processing device, equipment and readable storage medium, which also have the above-mentioned beneficial effects. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 A flowchart of a detection task processing method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a detection task processing method provided in an embodiment of the present invention; Figure 3 A flowchart illustrating the creation and pre-verification of a detection task is provided for an embodiment of the present invention. Figure 4 A flowchart illustrating the startup environment preparation and power-on process provided in an embodiment of the present invention; Figure 5 This is a flowchart illustrating an embodiment of the present invention for performing data return, timed patrol, and unified convergence. Figure 6This is a schematic diagram of the structure of a detection task processing device provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of a detection task processing device provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Please refer to Figure 1 , Figure 1 A flowchart illustrating a detection task processing method provided in an embodiment of the present invention. The method may include: S101: Receive a detection task creation request and determine the detection configuration based on the detection task creation request. The detection configuration includes the configuration information required to start the target bare metal device.

[0022] Each step in this embodiment can be executed by a designated electronic device, which can be a server (e.g., the server corresponding to the bare metal management platform), a portable terminal, or other forms; this embodiment does not limit this. A bare metal device refers to a physical server that is delivered or used directly in physical form without a virtualization layer installed. In scenarios such as pre-delivery inspection, hardware testing, startup verification, and basic input / output system refresh, bare metal devices typically require first preparing a startup environment, then powering on the device and waiting for successful startup, subsequently receiving the detection results returned by the execution end, and finally completing resource reclamation and status closure. This process spans multiple technical domains, including detection template selection, diskless client allocation, switch network switching, power control, execution feedback, heartbeat monitoring, and shutdown and cleanup after the task is completed. The execution end refers to the executable program running in the target bare metal device's operating environment after successful startup. It is used to obtain the detection items to be executed, perform the detection, and return execution information. The execution information may include heartbeat information and detection results returned at the granularity of each detection item.

[0023] In this embodiment, the detection task creation request initiated by the service side may include a detection configuration identifier, a set of identifiers for the target bare metal device, and a set of detection items to be executed. The detection configuration, as a unified constraint carrier for the startup link orchestration, may include configuration information such as the data center identifier, virtual private network identifier, startup scheme identifier, and diskless environment identifier required to start the target bare metal device. It is understood that in existing technologies, the network, startup scheme, diskless environment, and data center information upon which startup depends are often configured in a scattered manner, lacking a unified constraint object. This results in the device being selected during task creation, but the necessary parameters being missing during actual startup execution. This embodiment uses the detection configuration as a unified source of configuration information required for startup. Subsequent client creation, network link switching, and device power-on are all based on the same configuration context, thereby reducing the probability of runtime parameter missing failures. The client refers to a logical object bound to the target bare metal device in the diskless environment, used to carry the startup scheme and address information used by the target bare metal device in this startup link.

[0024] Furthermore, to ensure the integrity of the configuration information required for starting the process during the task creation phase, the process of determining the detection configuration based on the detection task creation request may specifically include: Step 11: Query the detection configuration based on the detection configuration identifier in the detection task creation request, and verify whether the detection configuration simultaneously has the data center identifier, virtual private network identifier, startup scheme identifier, and diskless environment identifier; Step 12: If yes, then confirm that the detection configuration is valid; Step 13: If not, generate an error log and return information indicating incomplete configuration.

[0025] In this embodiment, the data center identifier constrains the physical location and scheduling range of the target bare metal device, the virtual private network identifier constrains the network space used by the boot link, the boot scheme identifier constrains the boot scheme loaded for diskless boot, and the diskless environment identifier constrains the diskless environment to which the client belongs. If the detection configuration is missing, or any of the above key fields are missing, the creation of the detection task is directly rejected, an error log is generated, and incomplete configuration information is returned to the requester so that the configuration side can repair it in time. In this way, the integrity constraint of configuration information on the boot link is moved to the task creation stage. If any key field is missing, the creation of the detection task is rejected, instead of temporarily assembling the data center, virtual private network, boot scheme, and diskless environment from different entry points. This avoids the problem of missing parameters being exposed only after the task enters the boot link, thereby reducing the probability of missing parameters and failure during the boot process and improving the integrity and executability of the detection task creation. Among them, the diskless environment refers to the environment in which the target bare metal device does not rely on the local disk and completes the boot by loading the corresponding runtime environment of the boot scheme through the network. The virtual private network refers to the mutually isolated network space allocated for the detection task. To enable the target bare metal device to perform diskless boot and execution backhaul within a specified network space, a network link corresponding to the virtual private network needs to be configured on the switch port to which the target bare metal device is connected, such as a virtual LAN link, but not limited to this.

[0026] Furthermore, to minimize the risk of failure during the task creation phase, the process may also include: preparing the boot environment for the target bare metal device based on the detection configuration and powering on the target bare metal device before proceeding: Step 21: Perform pre-verification on the target bare metal device. Pre-verification includes device status verification, task mutual exclusion verification, power status verification, and hardware specification integrity verification. Step 22: If the pre-verification fails, record the reason for the failure; Step 23: If the pre-verification is successful, create a main task record for the target bare metal device, and initialize multiple sub-detection report records associated with the main task record based on the detection items to be executed.

[0027] In this embodiment, the pre-verification can be constrained in at least three layers: the first layer is device status verification and task mutual exclusion verification, used to exclude devices in an unauthorized operation state and devices with conflicting operation tasks; the second layer is power status verification, used to ensure that the device can be started; the third layer is hardware specification integrity verification, used to prevent devices from entering the detection process when key specification attributes such as processor, graphics processor, or memory are missing. For devices that fail the pre-verification, the corresponding failure reason is recorded for troubleshooting and traceability. For bare metal devices that pass the pre-verification, a main task record is first created for the target bare metal device as a global state carrier for this detection task, used to track the overall execution progress, associate various sub-processes, and record the final result. Subsequently, according to the set of detection items to be executed (e.g., CPU detection, memory detection, GPU detection, etc.) carried in the request, multiple sub-detection report records are initialized respectively, and these sub-records are associated with the aforementioned main task record. Each sub-detection report record independently corresponds to a detection item, responsible for storing the execution status, output results, log details, and other information of that item, thus forming a hierarchical data structure of a main task with multiple sub-reports. This design allows the main task to coordinate the overall process (such as power-on, power-off, and resource recovery), while the sub-reports execute and transmit specific test content in parallel or sequentially, facilitating fine-grained monitoring of the completion status of each test item. In this way, through multi-stage pre-checks of device status, task mutual exclusion, power status, and hardware specification integrity, failures are moved as early as possible to the task creation stage, reducing the probability of unqualified devices entering the startup process. Simultaneously, the two-layer state model composed of the main task record and multiple sub-test report records provides a unified state closed-loop carrier for subsequent execution and transmission, enhancing the observability of the execution process.

[0028] S102: Based on the detection configuration, prepare the boot environment for the target bare metal device and trigger the target bare metal device to power on.

[0029] In this embodiment, the preparation of the boot environment may include the preparation of the client in the diskless environment and the configuration of the network link on the switch port, and the client preparation and the switch network link configuration are performed sequentially. After the boot environment preparation is completed, the target bare metal device is then powered on, so that the boot environment preparation and device startup form a strict sequential relationship. The method of triggering the power-on of the target bare metal device can be to send a power-on command to the power port (e.g., the port of the power distribution unit) corresponding to the target bare metal device, and record the power-on time and the address information of the target bare metal device in the current boot link, so as to perform timeout judgment and anomaly location later.

[0030] In one embodiment, a timer scheduler can scan detection tasks that are in a standby state, limit the number of concurrently started tasks according to the data center dimension, and atomically switch the state of the selected detection tasks from standby to initialization, for example, by using optimistic locking to complete the state switch, so as to avoid the same detection task being started concurrently by multiple threads.

[0031] Furthermore, to ensure the boot environment remains consistent with the detection configuration and to improve client reusability, the process of preparing the boot environment for the target bare metal device based on the detection configuration may specifically include: Step 31: Based on the unique identifier of the target bare metal device, query the bound client from the diskless environment corresponding to the diskless environment identifier of the detection configuration; Step 32: If the client exists, reuse the client; Step 33: If the client does not exist, create the client according to the detection configuration; Step 34: Configure the network link corresponding to the virtual private network identifier configured in the detection settings on the switch port connected to the target bare metal device.

[0032] In this embodiment, when creating a client, a new client can be allocated and created based on the diskless environment identifier, data center identifier, boot scheme identifier, and virtual private network identifier in the detection configuration, and the client's address information is recorded. When configuring network links, the physical switch and port information connected to the target bare metal device can be obtained first, and then the network link corresponding to the virtual private network identifier, such as a virtual LAN link, can be configured on the corresponding switch port. It is understood that this embodiment integrates client preparation, network link configuration, and device power-on into the same execution chain, rather than having them independently controlled by multiple callers. Device power-on is triggered only after link preparation is complete, thus ensuring that the diskless boot environment and physical network access link of the target bare metal device are consistent with the detection configuration before the execution end starts. This prioritizes the reuse of already bound clients based on the device's unique identifier, avoiding resource waste caused by repeated creation. Client creation, network link switching, and device power-on are executed sequentially based on the same detection configuration, with each step revolving around the same configuration context, improving the consistency of the bare metal boot chain and reducing the probability of boot failure due to inconsistent configurations at each stage. Furthermore, the startup environment is kept consistent by first preparing the client machine, then configuring the network, and finally triggering power-on.

[0033] Furthermore, to address situations where the target bare metal device is in an abnormal power state, before powering on the target bare metal device after link preparation is complete, the following may also be included: Step 41: Detect the power status of the target bare metal device; Step 42: If the target bare metal device is powered on, perform a forced shutdown operation and continuously monitor the power status of the target bare metal device for a first preset time period. Step 43: If the target bare metal device is detected to have completed shutdown within the first preset time period, then the target bare metal device is powered on. Step 44: If the target bare metal device is not shut down within the first preset time period, the detection task status is rolled back to the standby power-on state.

[0034] This embodiment does not assume the target bare metal device is already powered off before unconditionally powering it on. Instead, it first queries the current power status of the target bare metal device through the power control interface. If the device is powered on, a forced shutdown is performed, and the power status is periodically checked through the power control interface, for example, by repeatedly performing power status checks according to preset cycles and time intervals. If the target bare metal device completes shutdown within the first preset time period, a power-on command is sent. If the target bare metal device fails to complete shutdown within the first preset time period, the detection task is not directly judged as a failure. Instead, the detection task status is rolled back from initialization to a pending power-on state, causing it to re-enter the next round of timed scheduling, and the timer restarts it. In this way, power status detection and forced shutdown ensure that the target bare metal device enters the power-on phase in a determined shutdown state. The rollback rescheduling mechanism improves the recovery capability of the startup process in complex field environments and avoids direct failure of the detection task due to momentary power anomalies.

[0035] S103: After the target bare metal device is successfully started, receive the execution information returned by the execution end for the target bare metal device, and update the status of the detection task corresponding to the target bare metal device according to the execution information until the detection task ends.

[0036] In this embodiment, after the target bare metal device is successfully started, the execution end can obtain the detection items to be executed through a polling interface, and continuously send back execution information during the execution process. The execution information may include heartbeat information and detection results sent back at the granularity of each detection item. This embodiment uses the feedback from the execution end to drive the state progression of the detection task, so that the task execution process has a clear basis for state progression and reduces the situation where the detection task stays in the intermediate state for a long time.

[0037] Furthermore, in order to form a closed loop of execution feedback between the main task and the sub-inspection report, the process of updating the status of the inspection task corresponding to the target bare metal equipment based on the execution information may specifically include: Step 51: Upon receiving the first valid feedback for the target bare metal device, record the successful power-on time and update the detection task to the detection in progress status; Step 52: Update the corresponding sub-test report record based on the test results returned at the test item granularity.

[0038] In this embodiment, the first valid feedback can be either the first time the execution end retrieves a detection task or the first time the execution end saves a single detection result. After the target bare metal device starts up, the execution end obtains the detection items to be executed through a polling interface. During execution, it reports detection results and log details at the granularity of each detection item and periodically reports heartbeats. At the same time, it updates the status of the corresponding sub-detection report record and saves the detection log, thus forming a complete execution feedback chain of task issuance, execution end retrieval, heartbeat maintenance, and result writing. In this way, using the first valid feedback as the basis for the actual successful startup of the target bare metal device and recording the successful startup time, it is possible to know whether the device has truly entered the execution state and also to know the independent completion status of each detection item (such as different detection items such as CPU, GPU, memory, power supply, etc.), further enhancing the observability of the detection task execution process.

[0039] Furthermore, to avoid prolonged suspension of the detection task and to achieve a uniform conclusion, the method may also include: Startup timeout handling: For detection tasks that have been powered on but have not received execution information after the second preset time, startup timeout handling is performed; Heartbeat timeout handling: For detection tasks that have not received a heartbeat for more than the third preset time, determine the cause of the abnormality by combining the startup event information and the power status; Unified shutdown process: For all testing tasks that have been completed in all sub-test reports, the system will be shut down and resources will be recycled.

[0040] In this embodiment, the unified monitoring task on the platform side can execute the above processing logic periodically: for detection tasks that are in the initialization state and have not entered the execution state after power-on for more than a second preset time, they are terminated and the startup timeout reason is written; for detection tasks that have not received a heartbeat for a long time, the abnormal reason can be determined as blue screen, startup timeout, host shutdown or host freeze, etc., by combining the startup event query results, startup identifier and power status, and the termination process is executed; for detection tasks that have completed all sub-detection report records, a unified shutdown and resource reclamation process is triggered to complete the final closure of the task. In this way, through the three types of timed closure mechanisms of startup timeout processing, heartbeat abnormality judgment and unified shutdown reclamation, together with the active feedback from the execution end, a dual closure mechanism of active feedback from the execution end and timed inspection on the platform side is formed, which reduces the risk of detection tasks remaining in the intermediate state of waiting to be powered on, initialization or detection for a long time, and reduces task suspension and resource residue.

[0041] S104: At the end of the inspection task, reclaim the resources used to prepare the startup environment for the target bare metal device.

[0042] In this embodiment, resource reclamation may specifically include: querying the current power status of the target bare metal device and performing a forced power-off while the target bare metal device is still powered on; releasing the network links configured on the switch port; and deleting the client machines bound to the detection task in the diskless environment. After resource reclamation is completed, the status of the detection task can be set to "completed". Through the integrated release in the completion phase, it is possible to avoid the residual diskless environment, network links, and device power-on status after the startup link execution is completed, ensuring that the bare metal device is restored to a basic state that can be re-orchestrated after a detection or startup verification is completed.

[0043] The detection task processing method provided by this embodiment of the invention includes the following steps: S101: receiving a detection task creation request and determining a detection configuration based on the request, the detection configuration including configuration information required to start the target bare metal device; S102: preparing a startup environment for the target bare metal device based on the detection configuration and triggering the target bare metal device to power on; S103: after the target bare metal device starts successfully, receiving execution information returned by the execution terminal for the target bare metal device and updating the status of the detection task corresponding to the target bare metal device based on the execution information until the detection task ends; S104: at the end of the detection task, reclaiming the resources occupied by the startup environment prepared for the target bare metal device. This invention uses the detection configuration as a unified source of configuration information required for startup, and incorporates startup environment preparation, device power-on, execution feedback, and resource reclamation into the same processing flow. This improves the integrity and consistency of the startup chain execution and reduces the probability of failure during startup. By using execution feedback to drive task state progression, the task execution process has a clear basis for state progression, reducing the time that detection tasks remain in intermediate states. By reclaiming the resources occupied by the startup environment at the end of the detection task, the residual network configuration, operating environment, and device state after the task ends are reduced, ensuring that bare metal devices can be successfully started or detected again.

[0044] For a clearer understanding of this invention, please refer to the following details. Figure 2 , Figure 2This is a flowchart illustrating a detection task processing method provided in an embodiment of the present invention. First, a detection task creation request is received, from which the detection configuration, target device identifier set, and set of detection items to be executed are read. Then, the integrity of the detection configuration is verified, confirming whether it contains necessary information such as the data center identifier, virtual private network identifier, startup scheme identifier, and diskless environment identifier. After successful verification, a pre-verification is performed on the target bare metal device, checking the device status, task mutual exclusion, power status, and hardware specification integrity. For devices that pass the pre-verification, a main task record is created, and multiple sub-detection report records are initialized according to the detection items to be executed. Next, tasks in the standby state are scheduled, and the startup environment is prepared: a client bound to the current task is reused or created, and the service link of the switch port where the target device is located is switched. After confirming the device's power status (forced shutdown is performed if necessary), a power-on command is sent, and the power-on time is recorded. After the device starts, it receives task pulls, heartbeat reports, and result feedback from each detection item initiated by the execution end, records the moment of the first valid feedback, and advances the status of the main task and sub-detection reports accordingly. Finally, the system uses a timed inspection mechanism to scan for tasks that have timed out, have abnormal heartbeats, or have completed all sub-detection reports. It then performs error determination, result processing, and release of network links and client resources, thereby completing the entire bare metal detection startup process.

[0045] Figure 3 This is a flowchart illustrating the creation and pre-verification process for a detection task according to an embodiment of the present invention. First, a detection task creation request is received, from which the detection configuration identifier, the target bare metal device identifier set, and the set of detection items to be executed are read. Then, the corresponding detection configuration is queried and read based on the detection configuration identifier, loading parameters such as the data center identifier, virtual private network identifier, startup scheme identifier, and diskless environment identifier. Next, the system determines whether the detection configuration is complete: if any of the above key fields are missing, a configuration error is directly returned, and the task is rejected from entering the subsequent startup chain; if the configuration is complete, the pre-verification stage proceeds to each device. The pre-verification checks the operating conditions of each target device, including: device status and task mutual exclusion verification to filter devices in an inoperable state and tasks with conflicting operations; power status verification to confirm that the device meets the power conditions before startup; and hardware specification integrity verification to confirm that hardware information such as CPU, GPU, and memory has been completely detected. After all pre-verifications pass, a main task record is created for the device, and multiple sub-detection report records are initialized according to the detection items to be executed, thus preparing for subsequent result feedback, status linkage, and unified consolidation.

[0046] Figure 4This is a flowchart illustrating the startup environment preparation and power-on process according to an embodiment of the present invention. The timer scheduler first scans the detection tasks in the pending startup state and controls the number of tasks simultaneously entering the initialization state according to the data center dimension to avoid resource conflicts. For the selected target task, its state is switched to "initializing," and the same task is prevented from being processed repeatedly through a state occupancy mechanism. Then, client resources are prepared: based on the unique identifier of the target bare metal device, a client bound to the current task is reused or created in the diskless environment. Next, the physical switch and port information connected to the target device are obtained, and the switch port is switched to the Virtual Private Network (VPC) service link specified in the detection configuration. After completing the network configuration, the device is checked to see if it meets the power-on conditions; that is, the power status is checked first to confirm that the device is in a powered-off state; if the device is not powered off, a forced shutdown process is performed, and the shutdown is waited for completion. After confirming that the device is powered off, a power-on command is sent, and the startup time is recorded. At this point, the startup environment preparation and device power-on are completed, and the process enters the task execution feedback stage, waiting for the execution end to pull tasks, report heartbeats, and send back detection results.

[0047] Figure 5 This is a flowchart illustrating the execution feedback, timed patrol, and unified interface provided in this embodiment of the invention. After device startup, the execution end obtains the current task information and the set of detection items to be executed based on the associated task. When the execution end successfully sends back any detection result for the first time, it records the moment of the first valid feedback as the successful startup time and advances the status of the main task accordingly. During execution, the execution end reports results and logs at the detection item granularity. The system updates the corresponding sub-detection report records accordingly, saves the execution status, exception information, and detailed logs of each item, and notifies of status changes. Simultaneously, the execution end periodically reports a heartbeat, and the system refreshes the task's active time based on the heartbeat to determine whether the task is progressing normally. The scheduled inspection mechanism executes three types of monitoring in parallel: For tasks in the initialization state that have not received any feedback after a preset timeout following power-on, an initialization timeout inspection is performed, the startup timeout reason is written, and the abnormal process is terminated; for tasks that have not received a heartbeat after a preset timeout, a heartbeat timeout inspection is performed, and the cause of the abnormality is determined by combining startup event information and power status information; when all sub-detection reports under a main task have been completed, the completion condition is met, triggering unified processing, and executing device shutdown and resource reclamation operations. Through the above linkage between feedback execution and scheduled inspection, closed-loop management and anomaly protection for detection tasks are achieved.

[0048] The detection task processing device provided in the embodiments of the present invention will be described below. The detection task processing device described below can be referred to in correspondence with the detection task processing method described above.

[0049] Please refer to the details. Figure 6 , Figure 6 A schematic diagram of a detection task processing device provided in an embodiment of the present invention may include: The configuration determination module 100 is used to receive a detection task creation request and determine the detection configuration based on the detection task creation request. The detection configuration includes the configuration information required to start the target bare metal device. The environment preparation module 200 is used to prepare the boot environment for the target bare metal device based on the detection configuration and to trigger the target bare metal device to power on. The status update module 300 is used to receive the execution information returned by the execution end for the target bare metal device after the target bare metal device is successfully started, and update the status of the detection task corresponding to the target bare metal device according to the execution information until the detection task ends. The resource recovery module 400 is used to recover the resources used in the startup environment prepared for the target bare metal device at the end of the detection task.

[0050] Furthermore, based on the above embodiments, the configuration determination module 100 may include: The configuration verification unit is used to query the detection configuration based on the detection configuration identifier in the detection task creation request, and verify whether the detection configuration has the data center identifier, virtual private network identifier, startup scheme identifier, and diskless environment identifier at the same time; if so, the detection configuration is determined to be valid; if not, an error log is generated and the incomplete configuration information is returned.

[0051] Furthermore, based on the above embodiments, the environment preparation module 200 may include: The client preparation unit is used to query the bound client from the diskless environment corresponding to the diskless environment identifier of the detection configuration based on the unique identifier of the target bare metal device; if the client exists, the client is reused; if the client does not exist, a client is created according to the detection configuration. The link configuration unit is used to configure the network link corresponding to the virtual private network identifier configured and detected on the switch port connected to the target bare metal device.

[0052] Furthermore, based on the above embodiments, the detection task processing device may further include: The power management module is used to detect the power status of the target bare metal device. If the target bare metal device is powered on, a forced shutdown operation is performed, and the power status of the target bare metal device is continuously monitored within a first preset time period. If the target bare metal device is detected to have completed shutdown within the first preset time period, the target bare metal device is powered on. If the target bare metal device is detected to have not completed shutdown within the first preset time period, the detection task status is rolled back to the standby power-on state.

[0053] Furthermore, based on the above embodiments, the detection task processing device may further include: The pre-verification module is used to perform pre-verification on the target bare metal device. The pre-verification includes device status verification, task mutual exclusion verification, power status verification, and hardware specification integrity verification. If the pre-verification fails, the reason for failure is recorded. If the pre-verification passes, a main task record is created for the target bare metal device, and multiple sub-detection report records associated with the main task record are initialized according to the detection items to be executed.

[0054] Furthermore, based on the above embodiments, the state update module 300 may include: The feedback recording unit is used to record the power-on success time and update the detection task to the detection status when the first valid feedback is received for the target bare metal device; The report update unit is used to update the corresponding sub-test report records based on the test results returned at the test item granularity.

[0055] Furthermore, based on the above embodiments, the detection task processing device may further include: The timed inspection module is used to perform startup timeout processing for detection tasks that have been powered on but have not received execution information for more than a second preset time; for detection tasks that have not received heartbeats for more than a third preset time, it determines the cause of the abnormality by combining startup event information and power status at least one of them; and for detection tasks that have been completed in all sub-detection report records, it performs shutdown and resource reclamation.

[0056] It should be noted that the order of the modules and units in the above-mentioned detection task processing device can be changed without affecting the logic.

[0057] An application of the detection task processing device provided in this embodiment of the invention includes a configuration determination module 100, which receives a detection task creation request and determines a detection configuration based on the request, the detection configuration including configuration information required to start a target bare metal device; an environment preparation module 200, which prepares a startup environment for the target bare metal device based on the detection configuration and triggers the power-on of the target bare metal device; a status update module 300, which receives execution information returned by the execution terminal for the target bare metal device after the device starts successfully, and updates the status of the detection task corresponding to the target bare metal device based on the execution information until the detection task ends; and a resource recycling module 400, which reclaims the resources occupied by the startup environment prepared for the target bare metal device when the detection task ends. This invention uses the detection configuration as a unified source of configuration information required for startup, and incorporates startup environment preparation, device power-on, execution feedback, and resource reclamation into the same processing flow. This improves the integrity and consistency of the startup chain execution and reduces the probability of failure during startup. By using execution feedback to drive task state progression, the task execution process has a clear basis for state progression, reducing the time that detection tasks remain in intermediate states. By reclaiming the resources occupied by the startup environment at the end of the detection task, the residual network configuration, operating environment, and device state after the task ends are reduced, ensuring that bare metal devices can be successfully started or detected again.

[0058] The detection task processing device provided in the embodiments of the present invention will be introduced below. The detection task processing device described below and the detection task processing method described above can be referred to each other.

[0059] refer to Figure 7 , Figure 7 A schematic diagram of a detection task processing device provided in an embodiment of the present invention may include: Memory 10 is used to store computer programs; The processor 20 is used to execute computer programs to implement the detection task processing method described above.

[0060] The memory 10, processor 20, and communication interface 31 all communicate with each other through the communication bus 32.

[0061] In this embodiment of the invention, the memory 10 is used to store one or more programs. The programs may include program code, which includes computer operation instructions. In this embodiment of the invention, the memory 10 may store programs for implementing the following functions: Receive a test task creation request and determine the test configuration based on the test task creation request. The test configuration includes the configuration information required to start the target bare metal device. Based on the detection configuration, prepare the boot environment for the target bare metal device and trigger the target bare metal device to power on; After the target bare metal device is successfully started, the execution information returned by the execution end for the target bare metal device is received, and the status of the detection task corresponding to the target bare metal device is updated according to the execution information until the detection task is completed. At the end of the testing mission, the resources used to prepare the startup environment for the target bare metal device are recovered.

[0062] In one possible implementation, the memory 10 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; and the data storage area may store data created during use.

[0063] Furthermore, memory 10 may include read-only memory and random access memory, providing instructions and data to the processor. A portion of the memory may also include NVRAM. The memory stores operating systems and operating instructions, executable modules, or data structures, or subsets thereof, or extended sets thereof, wherein the operating instructions may include various operating instructions for implementing various operations. The operating system may include various system programs for implementing various basic tasks and handling hardware-based tasks.

[0064] Processor 20 can be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, or other programmable logic device. Processor 20 can be a microprocessor or any conventional processor. Processor 20 can call programs stored in memory 10.

[0065] Communication interface 31 can be an interface for the communication module, used to connect with other devices or systems.

[0066] Of course, it should be noted that, Figure 7 The structure shown does not constitute a limitation on the detection task processing device in the embodiments of the present invention. In practical applications, the detection task processing device may include devices such as... Figure 7 More or fewer components as shown, or combinations of certain components.

[0067] It is understood that if the detection task processing method in the above embodiments is implemented as 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 invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk or optical disk, and other media capable of storing program code.

[0068] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the detection task processing method described above.

[0069] The following describes a computer program product provided by an embodiment of this application. The computer program product described below can be referred to in conjunction with other embodiments described herein.

[0070] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the aforementioned disclosed detection task processing method.

[0071] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0072] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0073] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0074] The above provides a detailed description of a detection task processing method, apparatus, device, and computer-readable storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A detection task processing method, characterized in that, include: Receive a detection task creation request and determine the detection configuration based on the detection task creation request. The detection configuration includes the configuration information required to start the target bare metal device. Based on the detection configuration, a startup environment is prepared for the target bare metal device, and the target bare metal device is powered on. After the target bare metal device is successfully started, the execution information returned by the execution terminal for the target bare metal device is received, and the status of the detection task corresponding to the target bare metal device is updated according to the execution information until the detection task ends. At the end of the detection task, the resources used to prepare the startup environment for the target bare metal device are recovered.

2. The detection task processing method according to claim 1, characterized in that, The detection configuration is determined based on the detection task creation request, including: The detection configuration is queried based on the detection configuration identifier in the detection task creation request, and the detection configuration is verified to have a data center identifier, a virtual private network identifier, a startup scheme identifier, and a diskless environment identifier. If so, then the detection configuration is confirmed to be valid; If not, an error log will be generated and an incomplete configuration message will be returned.

3. The detection task processing method according to claim 1, characterized in that, Based on the detection configuration, a startup environment is prepared for the target bare metal device, including: Based on the unique identifier of the target bare metal device, query the bound client from the diskless environment corresponding to the diskless environment identifier of the detection configuration; If the client exists, then the client is reused; If the client does not exist, a client is created according to the detection configuration; Configure a network link on the switch port connected to the target bare metal device that corresponds to the virtual private network identifier configured in the detection settings.

4. The detection task processing method according to claim 1, characterized in that, Before powering on the target bare metal device, the following is also included: Detect the power status of the target bare metal device; If the target bare metal device is powered on, a forced shutdown operation is performed, and the power status of the target bare metal device is continuously monitored within a first preset time period. If the target bare metal device is detected to have completed shutdown within the first preset time period, the target bare metal device is triggered to power on. If the target bare metal device is detected to have not been shut down within the first preset time period, the status of the detection task will be rolled back to the standby power-on state.

5. The detection task processing method according to any one of claims 1 to 4, characterized in that, Before preparing the boot environment for the target bare metal device based on the detection configuration and triggering the power-on of the target bare metal device, the method further includes: A pre-verification is performed on the target bare metal device, which includes device status verification, task mutual exclusion verification, power status verification, and hardware specification integrity verification. If the aforementioned pre-verification fails, the reason for the failure will be recorded. If the pre-verification is passed, a main task record is created for the target bare metal device, and multiple sub-detection report records associated with the main task record are initialized according to the detection items to be executed.

6. The detection task processing method according to claim 5, characterized in that, Update the status of the detection task corresponding to the target bare metal device according to the execution information, including: Upon receiving the first valid feedback for the target bare metal device, record the successful power-on time and update the detection task to the detection in progress status; The corresponding sub-detection report record is updated based on the detection results returned at the granularity of the detection items.

7. The detection task processing method according to claim 6, characterized in that, Also includes: For detection tasks that have been powered on but have not received execution information after the second preset time, execute the startup timeout handling; For detection tasks that have not received a heartbeat for more than a third preset time, determine the cause of the abnormality by combining at least one of the following: startup event information and power status. For all the aforementioned sub-detection report records that have been completed, perform shutdown and resource recovery.

8. A detection task processing device, characterized in that, include: A configuration determination module is used to receive a detection task creation request and determine the detection configuration based on the detection task creation request. The detection configuration includes the configuration information required to start the target bare metal device. An environment preparation module is used to prepare a startup environment for the target bare metal device based on the detection configuration and to trigger the target bare metal device to power on. The status update module is used to receive the execution information returned by the execution terminal for the target bare metal device after the target bare metal device is successfully started, and update the status of the detection task corresponding to the target bare metal device according to the execution information until the detection task ends. The resource recovery module is used to recover the resources used to prepare the startup environment for the target bare metal device when the detection task is completed.

9. A detection task processing device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the detection task processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the detection task processing method as described in any one of claims 1 to 7.

Images