Task chain-based multi-database inspection flow automatic arrangement method and system

Abstract

The invention discloses a multi-database inspection process automatic arrangement method and system based on a task chain, and relates to the technical field of database inspection, and the method comprises the steps: taking an inspection step as a task node based on an inspection task chain model, employing a directed acyclic graph to construct a dependency relationship between task nodes, defining an inspection index and an early warning strategy, label classification is added to the task nodes according to execution types, and if the sub-inspection tasks exist, modular packaging is carried out on chains of the sub-inspection tasks to obtain inspection task chains; executing an inspection task, and carrying out concurrent processing on the task nodes without dependence; wherein during execution, standard plug-ins are provided for different database types according to interface agreement, so that the corresponding inspection steps are executed by loading the corresponding standard plug-ins; and obtaining an inspection result and carrying out abnormity judgment. Through flexible arrangement of node chains, unified scheduling, execution and result tracking across databases are realized, the inspection efficiency is improved, errors are reduced, and the service continuity and the system stability are improved.

Description

Technical Field

[0001] This invention relates to the field of database inspection technology, and in particular to a method and system for automatically orchestrating multi-database inspection processes based on task chains. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] As enterprises continue to improve their informatization and data intelligence, a large number of heterogeneous databases (such as Oracle, MySQL, OceanBase, TiDB, etc.) are deployed simultaneously within enterprises, undertaking the tasks of storing and processing business data.

[0004] Currently, using separate inspection methods for different databases has the following limitations: (1) Significant differences in database types: There are obvious differences in inspection indicators, command syntax, and data structure among various database systems, which makes it difficult to adapt when using a unified tool.

[0005] (2) The inspection process is rigid: the traditional inspection process is fixed and cannot flexibly adjust the execution order and conditions of various tasks according to actual needs; when abnormal situations occur, there is a lack of flexible retry or backup plans.

[0006] (3) Frequent manual intervention: Maintenance personnel need to log in to each system to manually perform tasks, which not only reduces the efficiency of inspection but also increases the risk of errors.

[0007] (4) Lack of closed-loop process management: Inspection results are often presented in the form of scattered data and reports, making it difficult to achieve automatic archiving, review and continuous optimization of results. Summary of the Invention

[0008] To address the aforementioned issues, this invention proposes an automatic orchestration method and system for multi-database inspection processes based on task chains. Through the flexible orchestration of node chains, unified scheduling, execution, and result tracking across databases are achieved, thereby improving inspection efficiency, reducing errors, enhancing business continuity, and improving system stability.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides an automatic orchestration method for multi-database inspection processes based on task chains, comprising: After an inspection task is triggered, the corresponding inspection task chain template is loaded based on the database type. Based on the inspection task chain model, the inspection steps are used as task nodes. A directed acyclic graph is used to construct the dependency relationship between task nodes. Inspection indicators and early warning strategies are defined. Task nodes are categorized by adding labels according to their execution type. If there are sub-inspection tasks, the chain of the sub-inspection tasks is modularly encapsulated to obtain the inspection task chain. Inspection tasks are executed according to the inspection task chain, and task nodes without dependencies are processed concurrently. During execution, standard plugins are provided for different database types according to the interface agreement, so that the corresponding inspection steps can be executed by loading the corresponding standard plugin. Obtain inspection results and make anomaly judgments.

[0010] As an alternative implementation, prerequisite dependencies and conditional jump paths are set between task nodes; Pre-dependency refers to the current task node executing only after the task node it depends on has completed and succeeded. Conditional jump path refers to dynamically determining whether to jump to other branches based on the inspection results, and combining the context state to achieve path selection during execution.

[0011] As an alternative implementation, the sub-chains of the sub-inspection tasks are modularly encapsulated so that they can be referenced by the main chain in a modular manner. When the sub-chains are executed, they share the sub-chain context, and after completion, the output is passed through as a parameter to the next node of the main chain. The process of parameter context passing through includes: building a unified context dictionary, and reading and writing the context during the execution of each task node.

[0012] As an alternative implementation, if all task nodes are executed successfully, the inspection results are summarized, including the execution status and standardized inspection data, and trend charts, health scoring models and exportable reports are generated. If any task node fails, an exception handling process will be implemented, including: automatically retrying the task node, starting a backup task chain, and generating an alarm notification.

[0013] As an alternative implementation, the process of concurrent processing of dependency-free task nodes includes: Based on topological analysis, all task nodes without dependencies, i.e., those with an in-degree of 0, are analyzed. Submit task nodes without dependencies to the task queue and monitor their execution status; When a task node completes its execution, the dependency count of its downstream task nodes is updated. If the dependency count is 0, the downstream task node is submitted to the task queue.

[0014] As an alternative implementation method, by defining an abstract base class, the interface for standard plugin implementation is uniformly agreed upon, including: establishing a database connection, collecting database metadata, automatically generating detection SQL, executing SQL and obtaining results, standardizing the results into a JSON structure, and encapsulating exception handling; Each standard plugin encapsulates connection logic for supporting connection pool reuse, an SQL orchestrator for combining detection statements, and an exception recognizer for encapsulating error code mappings and log output. It is also hot-swappable and supports dynamic expansion.

[0015] Secondly, the present invention provides an automatic orchestration system for multi-database inspection processes based on task chains, comprising: The initial module is configured to load the corresponding inspection task chain template based on the database type after triggering the inspection task. The orchestration module is configured to be based on the inspection task chain model, with inspection steps as task nodes. It uses a directed acyclic graph to build the dependency relationship between task nodes, and defines inspection indicators and early warning strategies. It adds labels to task nodes according to execution type and classifies them. If there are sub-inspection tasks, the chain of the sub-inspection tasks is modularly encapsulated to obtain the inspection task chain. The execution module is configured to execute inspection tasks according to the inspection task chain and to process independent task nodes concurrently. During execution, standard plugins are provided for different database types according to the interface agreement, so that the corresponding inspection steps can be executed by loading the corresponding standard plugins. The analysis module is configured to acquire inspection results and perform anomaly detection.

[0016] Thirdly, the present invention provides an electronic device including a memory and a processor, and computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0017] Fourthly, the present invention provides a computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in the first aspect.

[0018] Fifthly, the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0019] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention proposes an automatic orchestration method and system for multi-database inspection processes based on task chains. It loads corresponding inspection task chain templates according to database type; based on the inspection task chain model, inspection steps are used as task nodes, and a directed acyclic graph is used to construct dependencies between task nodes. Inspection indicators and early warning strategies are defined, and task nodes are categorized by execution type. If sub-inspection tasks exist, their chains are modularly encapsulated to obtain the inspection task chain. Inspection tasks are executed according to the task chain, and non-dependent task nodes are processed concurrently. During execution, standard plugins are provided for different database types according to interface conventions, allowing the loading of corresponding standard plugins to execute corresponding inspection steps. Through flexible orchestration of node chains, unified scheduling, execution, and result tracking across databases are achieved, thereby improving inspection efficiency, reducing errors, enhancing business continuity and system stability, and solving problems such as process fragmentation, decentralized management, and poor traceability in traditional inspection methods.

[0020] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0021] 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.

[0022] Figure 1 Here is a flowchart of the automatic orchestration method for multi-database inspection processes based on task chains provided in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the automatic orchestration method for multi-database inspection processes based on task chains provided in Embodiment 1 of the present invention. Detailed Implementation

[0023] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0024] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0025] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form as well. Furthermore, it should be understood that the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0027] Example 1 This embodiment provides an automatic orchestration method for multi-database inspection processes based on task chains, aiming to solve the problems of process fragmentation, decentralized management, and poor traceability in traditional inspection methods.

[0028] like Figure 1 As shown, it specifically includes: After an inspection task is triggered, the corresponding inspection task chain template is loaded based on the database type. Based on the inspection task chain model, the inspection steps are used as task nodes. A directed acyclic graph is used to construct the dependency relationship between task nodes. Inspection indicators and early warning strategies are defined. Task nodes are categorized by adding labels according to their execution type. If there are sub-inspection tasks, the chain of the sub-inspection tasks is modularly encapsulated to obtain the inspection task chain. Inspection tasks are executed according to the inspection task chain, and task nodes without dependencies are processed concurrently. During execution, standard plugins are provided for different database types according to the interface agreement, so that the corresponding inspection steps can be executed by loading the corresponding standard plugin. Obtain inspection results and make anomaly judgments.

[0029] The following is combined with Figure 2 The method of this embodiment will be described in detail.

[0030] S1: Task chain triggered; The triggering of the task chain adopts a unified task scheduling and execution mechanism: It supports multiple execution strategies, including timed expressions (Cron), periodic modes, and external API triggering, and can automatically schedule, manually trigger, and trigger task chains at regular intervals.

[0031] Meanwhile, a scheduling adaptation interface is reserved to connect with existing enterprise scheduling platforms (such as Azkaban and XXL-Job). The scheduler has a built-in task rate limiting and priority control mechanism to ensure reasonable task distribution during peak periods and prevent excessive database load.

[0032] S2: Load the corresponding inspection task chain template based on the database type.

[0033] Specifically: S2-1: Supports defining inspection task structures in YAML / JSON format. The inspection task chain template contains the definition of multiple inspection metrics, including tablespace utilization, peak connection count, slow log entries, etc., and sets default thresholds, validation expressions, and other early warning strategies.

[0034] Meanwhile, the built-in template version control system supports template retrospection and difference comparison, allowing different environments to reuse or adjust parameters as needed, thus improving the consistency and flexibility of management.

[0035] S2-2: The orchestration mechanism for task chains includes: A Directed Acyclic Graph (DAG) is used to construct task dependencies. Each task node represents a specific inspection step, such as connection testing, indicator collection, and anomaly detection. Prerequisite dependencies and conditional jump paths can be set between task nodes.

[0036] Each task node is defined with a specified prerequisite node (depends_on field), meaning that the task node can only be executed after the task nodes it depends on have been executed successfully.

[0037] Conditional branch paths dynamically determine whether to jump to other branches based on the status code and output results in the task execution result; Specifically, it uses a DAG structure for modeling and combines the context state during execution to achieve path selection, supporting conditional expressions such as result.code == 'ERROR'.

[0038] For example, when task node A results in "connection failed", it can be set to jump to the "connection diagnosis" node; if successful, the normal inspection process continues.

[0039] S2-3: Use a graph database (such as Neo4j) to store the task chain topology and implement advanced orchestration capabilities such as nested subchains, parameter context passing, and node label classification.

[0040] Specifically: (1) Nested subchains: Multiple sub-task chains can be encapsulated into an independent process (such as a "tablespace check sub-chain"), which can be referenced in a modular manner by the main task chain. The sub-chain shares the parent chain context during execution and passes its output as a parameter to the next node in the main chain upon completion.

[0041] (2) Parameter context pass-through: A unified context dictionary (context dict) is constructed, and each task node reads and writes this context during execution.

[0042] It supports variable resolution and dynamic parameter referencing (such as ${db_name}), and supports scope control (local variables vs. global variables).

[0043] (3) Task node tag classification: Each task node supports tagging, such as "Storage," "Connectivity," and "Performance." Nodes can be categorized and filtered based on these tags in the configuration interface. This facilitates the automated generation of inspection task templates and the statistical analysis of task execution coverage.

[0044] S2-4: During dynamic execution, combining asynchronous scheduling frameworks (such as Celery) to handle concurrent processing of dependent task nodes significantly improves execution efficiency.

[0045] Specifically: (1) When the execution engine is initialized, all independent task nodes are analyzed based on the topology relationship, i.e., the in-degree is 0.

[0046] (2) These task nodes are submitted to the Celery task queue, and the scheduler monitors their execution status.

[0047] (3) When a task node finishes execution, the scheduler updates the dependency count of its downstream task nodes. If the count is 0, the downstream task node is submitted to the task queue to realize pipeline-style dynamic concurrent scheduling.

[0048] (4) Maintain task context consistency during concurrent scheduling by using Redis shared memory to manage the context dictionary and ensure thread safety.

[0049] Compared to the traditional pipeline model that executes according to a timeline, this module uses a DAG graph structure to implement multi-branch concurrent control and node-level jump decision logic, supporting flexible combinations of complex processes and significantly enhancing the expressive power of the process.

[0050] S3: During execution, standard plugins are provided for different database types according to the interface agreement, so that the corresponding inspection steps can be executed by loading the corresponding standard plugins.

[0051] Specifically: S3-1: When the database inspection task is executed, its adaptation mechanism is as follows: adopt a plug-in architecture and provide standard plug-in development templates for different database types based on interface conventions (such as the BaseDbPlugin class).

[0052] Specifically, an abstract base class `BaseDbPlugin` is defined, which uniformly defines the interfaces that plugins should implement: connect(): Establishes a database connection; fetch_params(): Collects necessary database metadata; generate_sql(): Automatically generates test SQL; execute(): Executes the SQL and retrieves the result; standardize(): Standardizes the result into a JSON structure; handle_error(): Exception handling encapsulation.

[0053] Plugin developers only need to inherit from this base class and implement the methods described above. The platform will automatically load the module and identify supported database types (via plugin descriptor). Simultaneously, the platform provides a command-line tool to automatically generate template skeleton code, including interface comments and default exception handling logic, reducing the burden of manual coding.

[0054] S3-2: Each plugin encapsulates sub-modules such as connection logic (supporting connection pool reuse), SQL orchestrator (automatically combining commonly used detection statements), and exception recognizer (encapsulating error code mapping and log output), and has hot-swappable capability, supporting dynamic expansion.

[0055] in, (1) The connection logic is as follows: A unified connection pool (such as SQLAlchemy or DBUtils) is provided, and connection parameters are registered through plugin description information, supporting connection reuse and reconnection strategies after disconnection. The maximum number of connections and connection keep-alive time can be configured to avoid resource waste.

[0056] (2) SQL orchestrator: Maintain a built-in SQL statement template library, differentiated by database type (such as MySQL lock wait query, Oracle AWR snapshot extraction).

[0057] Each plugin dynamically populates variables to generate the final SQL based on the current task context, and supports DSL rule configuration.

[0058] (3) Anomaly Detector: Define the mapping relationship between error codes and exception types, such as ORA-00942 corresponding to "table does not exist".

[0059] During execution, exceptions are captured and output to the logging module in a standardized manner, which facilitates unified platform alerts and allows users to quickly locate problems.

[0060] The above method differs from the script stacking execution logic used in most existing systems. The method in this embodiment achieves modularity and portability of database access through a unified plug-in protocol and encapsulation mechanism, which facilitates rapid adaptation to new database systems and reduces operation and maintenance costs.

[0061] Among them, the plugin protocol refers to the interface signature, return format, and lifecycle management specifications (such as init and destroy) that the plugin must meet.

[0062] Plugin metadata (supported database types, supported inspection items, dependencies, etc.) is registered using JSON / YAML format, and the platform uses this information to load and schedule plugins.

[0063] The encapsulation mechanism is as follows: plugins are deployed as independent Python modules or Docker containers and registered to the platform through a unified plugin loader; plugins communicate with the shared context module through an event mechanism to avoid coupling; the plugin package structure is unified (e.g., plugins / mysql_plugin / ), and version control and canary releases are supported.

[0064] S4: Obtain inspection results and make anomaly judgments.

[0065] for example: Task Node 1: Database connection status check; includes: all databases; Task Node 2: Basic Resource Inspection; including CPU, memory, tablespace, and active connections; Task Node 3: Typed Deep Inspection; including: tasks for MySQL sub-nodes, such as master-slave replication and lock waits; tasks for Oracle sub-nodes, such as tablespaces, watermarks, and backup status; tasks for TiDB sub-nodes, such as region classification and TiKV status; and tasks for OceanBase sub-nodes, such as tenant utilization and read / write hotspots.

[0066] If all task nodes are executed successfully, the inspection results are summarized, including the execution status and standardized inspection data; and a report and health score are generated, including trend charts, scoring models, and exportable reports; finally, the data is archived and displayed.

[0067] If any task node fails, an exception handling process will be implemented, including: automatically retrying the task node; starting a backup task chain for in-depth diagnosis; and generating an alarm notification via email, etc.

[0068] Specifically: S4-1: Task chain execution tracking and status management module.

[0069] State management details: A state machine framework (such as the transitions library) is introduced to finely manage the state transitions of each node in the task, and state changes are synchronized to the scheduling center and visualization interface through an event bus (such as a Redis message queue). Tasks support failure retry, skip execution, manual recovery, and chained rollback mechanisms to ensure the robustness of the execution chain.

[0070] S4-2: Anomaly detection and alarm linkage module.

[0071] Rule engine mechanism: Constructs a rule description syntax based on DSL (Domain Specific Language). Users can set alarm conditions through the configuration UI interface, such as: slow query count > 100 and tablespace utilization > 85%. The rule engine monitors the node execution results in real time and triggers multi-channel alarms.

[0072] Linkage Mechanism: Integrates with WeChat Work, DingTalk, and email systems, supporting alarm policy templates and recipient group management. It can be configured to generate exception work orders and push them to external systems (such as ServiceNow) to achieve closed-loop alarm processing.

[0073] S4-3: Visual Arrangement and Reporting Module.

[0074] Front-end implementation: A front-end workflow editing component (such as jsPlumb / ReactFlow) is used to build a graphical task chain. Node attributes support parameterized configuration, SQL template selection, and dependency visualization. The reporting module generates graphic reports based on the rendering engine, including task execution paths, indicator trend charts, anomaly statistics, and a scoring system. It supports one-click export to PDF or HTML, adapting to audit or compliance archiving scenarios.

[0075] This embodiment constructs an automatic orchestration method for multi-database inspection processes based on task chains, enabling efficient inspection, automatic scheduling, and anomaly warning for heterogeneous database systems within an enterprise. Compared to traditional methods, it has significant technical advantages and practical effectiveness in the following aspects: 1. Inspection efficiency has been significantly improved, and batch processing capabilities have been enhanced.

[0076] By using a unified DAG model for modeling and task chain orchestration, it supports parallel inspection and off-peak scheduling of hundreds of database instances. Combined with a plug-in execution engine and scheduling strategy, it enables the collection of large-scale database health status within minutes, completely replacing manual scripts and scheduled tasks, and greatly reducing the manpower and time costs of operation and maintenance.

[0077] 2. Flexible and visual workflow arrangement reduces configuration and maintenance costs.

[0078] It provides graphical task chain building capabilities, supporting modular decomposition, template reuse, and parameter injection of inspection processes, facilitating rapid configuration switching between different project teams and database types. Combined with task chain version management and structure persistence mechanisms, it enhances the maintainability and traceability of inspection processes.

[0079] 3. Strong adaptability.

[0080] Its plug-in design allows for flexible adaptation to various database types, including MySQL, Oracle, OceanBase, TiDB, and PostgreSQL, and it boasts excellent technical scalability.

[0081] 4. The stability and reliability guarantee mechanism is sound.

[0082] Built-in task state machine and link fault tolerance mechanism effectively avoid link breakage problems caused by mid-task interruption. Automatic retry, skipping and backup path configuration in abnormal scenarios ensure the continuous progress of the task chain, avoid the single point of failure risk of the entire chain, and improve system stability and business continuity.

[0083] 5. Data closed-loop and alarm linkage enable more timely response to anomalies.

[0084] It possesses a closed-loop capability from data collection, analysis, alarming to coordinated handling. Alarm rules support flexible configuration and multi-channel notification, enabling rapid feedback and response, and significantly shortening the time window from database problem discovery to handling.

[0085] 6. Standardized output of health reports to support review and auditing.

[0086] The inspection reports are comprehensive and formatted in a standardized manner, combining scoring algorithms and trend charts to help technical and management personnel fully understand the database's operational status. The reports support archiving and export, as well as automatic email distribution, adapting to scenarios such as internal and external audits, compliance with information security standards, and operational retrospectives.

[0087] It should be noted that all data acquisition is conducted in accordance with laws and regulations and with user consent, and the data is used legally.

[0088] Example 2 This embodiment provides an automatic orchestration system for multi-database inspection processes based on task chains, including: The initial module is configured to load the corresponding inspection task chain template based on the database type after triggering the inspection task. The orchestration module is configured to be based on the inspection task chain model, with inspection steps as task nodes. It uses a directed acyclic graph to build the dependency relationship between task nodes, and defines inspection indicators and early warning strategies. It adds labels to task nodes according to execution type and classifies them. If there are sub-inspection tasks, the chain of the sub-inspection tasks is modularly encapsulated to obtain the inspection task chain. The execution module is configured to execute inspection tasks according to the inspection task chain and to process independent task nodes concurrently. During execution, standard plugins are provided for different database types according to the interface agreement, so that the corresponding inspection steps can be executed by loading the corresponding standard plugins. The analysis module is configured to acquire inspection results and perform anomaly detection.

[0089] It should be noted that the above modules correspond to the steps described in Embodiment 1, and the examples and application scenarios implemented by the above modules and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should also be noted that the above modules, as part of the system, can be executed in a computer system such as a set of computer-executable instructions.

[0090] In further embodiments, the following is also provided: An electronic device includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the method described in Embodiment 1. For brevity, further details are omitted here.

[0091] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0092] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.

[0093] A computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the method described in Embodiment 1.

[0094] The method in Example 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.

[0095] A computer program product includes a computer program that, when executed by a processor, implements the method described in Embodiment 1.

[0096] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which execute in a device on a target real or virtual processor to perform the processes / methods described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided among program modules as needed. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside in both local and remote storage media.

[0097] The computer program code used to implement the methods of the present invention may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the computer or other programmable data processing device, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a stand-alone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0098] In the context of this invention, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0099] Those skilled in the art will recognize that the units and algorithm steps described in conjunction with the embodiments herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. 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 implementation should not be considered beyond the scope of this application.

[0100] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A method for automatically orchestrating multi-database inspection processes based on task chains, characterized in that, include: After an inspection task is triggered, the corresponding inspection task chain template is loaded based on the database type. Based on the inspection task chain model, the inspection steps are used as task nodes. A directed acyclic graph is used to construct the dependency relationship between task nodes. Inspection indicators and early warning strategies are defined. Task nodes are categorized by adding labels according to their execution type. If there are sub-inspection tasks, the chain of the sub-inspection tasks is modularly encapsulated to obtain the inspection task chain. Inspection tasks are executed according to the inspection task chain, and task nodes without dependencies are processed concurrently. During execution, standard plugins are provided for different database types according to the interface agreement, so that the corresponding inspection steps can be executed by loading the corresponding standard plugin. Obtain inspection results and make anomaly judgments.

2. The automatic orchestration method for multi-database inspection processes based on task chains as described in claim 1, characterized in that, Set prerequisite dependencies and conditional jump paths between task nodes; Pre-dependency refers to the current task node executing only after the task node it depends on has completed and succeeded. Conditional jump path refers to dynamically determining whether to jump to other branches based on the inspection results, and combining the context state to achieve path selection during execution.

3. The automatic orchestration method for multi-database inspection processes based on task chains as described in claim 1, characterized in that, The sub-chains of the sub-inspection tasks are modularly encapsulated so that they can be referenced by the main chain in a modular way. When the sub-chains are executed, they share the sub-chain context, and when they are completed, they pass the output as a parameter to the next node of the main chain. The process of parameter context passing through includes: building a unified context dictionary, and reading and writing the context during the execution of each task node.

4. The automatic orchestration method for multi-database inspection processes based on task chains as described in claim 1, characterized in that, If all task nodes are executed successfully, the inspection results are summarized, including the execution status and standardized inspection data, and trend charts, health scoring models and exportable reports are generated. If any task node fails, an exception handling process will be implemented, including: automatically retrying the task node, starting a backup task chain, and generating an alarm notification.

5. The automatic orchestration method for multi-database inspection processes based on task chains as described in claim 1, characterized in that, The process of concurrently processing independent task nodes includes: Based on topological analysis, all task nodes without dependencies, i.e., those with an in-degree of 0, are analyzed. Submit task nodes without dependencies to the task queue and monitor their execution status; When a task node completes its execution, the dependency count of its downstream task nodes is updated. If the dependency count is 0, the downstream task node is submitted to the task queue.

6. The automatic orchestration method for multi-database inspection processes based on task chains as described in claim 1, characterized in that, By defining an abstract base class, the interface implemented by the standard plugin is uniformly agreed upon, including: establishing a database connection, collecting database metadata, automatically generating detection SQL, executing SQL and obtaining results, standardizing the results into a JSON structure, and encapsulating exception handling; Each standard plugin encapsulates connection logic for supporting connection pool reuse, an SQL orchestrator for combining detection statements, and an exception recognizer for encapsulating error code mappings and log output. It is also hot-swappable and supports dynamic expansion.

7. An automatic orchestration system for multi-database inspection processes based on task chains, characterized in that, include: The initial module is configured to load the corresponding inspection task chain template based on the database type after triggering the inspection task. The orchestration module is configured to be based on the inspection task chain model, with inspection steps as task nodes. It uses a directed acyclic graph to build the dependency relationship between task nodes, and defines inspection indicators and early warning strategies. It adds labels to task nodes according to execution type and classifies them. If there are sub-inspection tasks, the chain of the sub-inspection tasks is modularly encapsulated to obtain the inspection task chain. The execution module is configured to execute inspection tasks according to the inspection task chain and to process independent task nodes concurrently. During execution, standard plugins are provided for different database types according to the interface agreement, so that the corresponding inspection steps can be executed by loading the corresponding standard plugins. The analysis module is configured to acquire inspection results and perform anomaly detection.

8. An electronic device, characterized in that, It includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, which, when executed by the processor, perform the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, Used to store computer instructions, which, when executed by a processor, perform the method described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method described in any one of claims 1-6.

Images