Observable distributed task scheduling system based on cloud edge collaboration

Abstract

The invention belongs to the field of task scheduling, relates to a data analysis technology, is used for solving the problems of no full-link tracking, single monitoring dimension, log fragmentation and the like in the prior art, and particularly relates to an observable distributed task scheduling system based on cloud-edge collaboration, which adopts a cloud-edge collaboration architecture and comprises a cloud control layer and an edge execution layer, the cloud control layer comprises a management node and a task storage module, and the edge execution layer comprises a scheduling node, an execution node and an observable node; according to the invention, the alarm threshold configuration is reversely pushed to the management module through the HTTP protocol to form closed-loop optimization, and the collaborative design of the protocol specification and the cluster architecture between the components enables the data transmission security mechanism and the observable data integration process to be organically fused, thereby fundamentally solving the problem of transmission reliability caused by protocol confusion.

Description

Technical Field

[0001] This invention belongs to the field of task scheduling and involves data analysis technology. Specifically, it is an observable distributed task scheduling system based on cloud-edge collaboration. Background Technology

[0002] Currently, distributed task scheduling systems mainly adopt either a "single-node architecture" or a "schedule-execution two-node architecture," both of which lack systematic observability. The single-node architecture integrates task creation, permission management, scheduling and distribution, and execution feedback into a single node, lacking an independent monitoring module and only allowing viewing of basic execution results through log files. The two-node architecture separates the "schedule node" and the "execution node." The scheduler node integrates permission management and task distribution functions, while the execution node only handles task execution. Observability is limited to single metrics such as "schedule node CPU utilization" and "execution node task success rate," lacking end-to-end tracing and unified log analysis.

[0003] The invention patent with publication number CN118012590A discloses a distributed task scheduling method, a distributed task scheduling system, and a distributed task processing system. Based on the stored local node resource status information and neighbor node resource status information, it performs local neighborhood task scheduling and neighborhood task routing based on a small-world network. However, this scheduling method has problems such as lack of full-link tracing, single monitoring dimension, and fragmented logs.

[0004] To address the aforementioned technical problems, this application proposes a solution. Summary of the Invention

[0005] The purpose of this invention is to provide an observable distributed task scheduling system based on cloud-edge collaboration, which solves the problems of lack of full-link tracing, single monitoring dimension, and fragmented logs in the existing technology; The technical problem that this invention aims to solve is: how to provide a distributed task scheduling system with a four-element decoupling of "management-scheduling-execution-observability".

[0006] The objective of this invention can be achieved through the following technical solutions: An observable distributed task scheduling system based on cloud-edge collaboration is disclosed. The system adopts a cloud-edge collaborative architecture, including a cloud control layer and an edge execution layer. The cloud control layer includes management nodes and a task storage module, and the edge execution layer includes scheduling nodes, execution nodes, and observable nodes. The management node includes an authorization authentication submodule, an audit log submodule, a task configuration submodule, a system configuration submodule, and an observable configuration submodule. The scheduling node is used for task scheduling and alarm analysis: after reading the tasks to be scheduled, the tasks are prioritized, the execution nodes are load-filtered to obtain matching nodes, the tasks are verified by distributed locks, the tasks to be scheduled are sent to the matching nodes and a tracking ID is generated, the scheduling time indicators of the scheduling process are collected, and the scheduling process indicators and tracking spans are reported to the observable nodes; the load filtering process is periodically optimized and analyzed. The observable node includes a monitoring submodule, a tracking submodule, and a log submodule; When an alarm is triggered, the observable node automatically generates alarm information containing the following identifiers: tracking identifier, task identifier, and resource identifier.

[0007] Furthermore, the task storage module includes a MySQL cluster and a Redis cluster. The management node sends synchronization task information and audit logs to the task storage module via HTTPS protocol. The management node sends push alarm rules and system configurations to the scheduling node via HTTP protocol. The scheduling node sends task distribution and status reporting to the execution node via TCP protocol. The scheduling node obtains distributed locks and load data from the Redis cluster via Redis protocol. The scheduling node performs read / write tasks and alarm records on the MySQL cluster via MySQL protocol. The node sends reported monitoring metrics, tracing links, and log data to the observable node via OpenTelemetry protocol. The observable node pushes observable alarm threshold configurations to the management module via HTTP protocol.

[0008] Furthermore, the permission authentication submodule connects to the audit log submodule, task configuration submodule, and system configuration submodule through an internal interface. The task configuration submodule synchronizes basic task information to the MySQL cluster via HTTPS. The observable configuration submodule sends monitoring indicator thresholds, tracking sampling rates, and log retention durations to observable nodes via HTTP. The permission authentication submodule is a prerequisite for all operations.

[0009] Furthermore, the specific process of load screening for execution nodes includes: determining whether the load rate of the execution node is less than the load threshold; if yes, marking the corresponding execution node as a matching node; if no, re-screening the execution nodes until the marking of matching nodes is completed; performing anomaly detection during the execution of the scheduled task, triggering an alarm when an anomaly exists, and marking the corresponding task as an abnormal task; marking the task status as successful when no anomaly exists.

[0010] Furthermore, the specific process of periodically optimizing the load screening process includes: generating an optimization period, retrieving the load rate of abnormal tasks during load screening within the optimization period, constructing a load optimization set from the load rates of all abnormal tasks, calculating the variance of the load optimization set to obtain the load distribution coefficient, and comparing the load distribution coefficient with a preset load distribution threshold: if the load distribution coefficient is greater than or equal to the load distribution threshold, the maximum and minimum elements in the load optimization set are removed, and the load optimization coefficient is recalculated, and so on, until the load distribution coefficient is less than the load distribution threshold; if the load distribution coefficient is less than the load distribution threshold, the minimum element in the load optimization set is marked as the load threshold for the next optimization period.

[0011] Furthermore, the monitoring submodule includes an indicator collection unit, an indicator storage unit, and an indicator analysis unit, which triggers alarms after indicator analysis; the tracing submodule includes a link collection unit, a link storage unit, and a link visualization unit, which visualizes the entire path of task submission, scheduling, and execution; and the logging submodule includes a log collection unit, a log storage unit, and a log retrieval unit.

[0012] Furthermore, the tracking identifier includes TraceID, the task identifier includes task ID, task version number, and task priority; and the resource identifier includes node ID and resource type.

[0013] Furthermore, the specific process of fault location includes the following steps: Step S1: Locate the time-consuming abnormal link by tracing the sub-module: Enter TraceID to query Jaeger link data, display the full path of "task submission → scheduling and distribution → execution feedback", and mark the span that exceeds the time threshold; Step S2: Confirm the type of resource anomaly through the monitoring submodule: Based on the anomaly in step S1, query the corresponding Prometheus metrics: Node layer: CPU utilization / memory usage / network IO packet loss rate; Task layer: execution success rate / number of retries. Step S3: Extract fault details through the log submodule: Enter "TraceID + node ID" to retrieve Elasticsearch logs and filter logs containing error codes and abnormal keywords; Step S4: Eliminate human error factors through the task storage module: Query the task configuration (parameters / priority) and audit log (last operator / modification time) in MySQL by associating the task ID.

[0014] The present invention has the following beneficial effects: 1. This application utilizes a cluster architecture design for the task storage module. Basic task information and alarm records are persistently stored in a MySQL cluster using transactional methods, while distributed locks and load data are cached in memory using a Redis cluster, forming a read-write separation strategy to avoid single-point bottlenecks. Based on this, the management node securely synchronizes task information and audit logs using HTTPS, employing encrypted transmission mechanisms to prevent unauthorized access. Simultaneously, it uses HTTP to lightweightly push alarm rules and system configurations, ensuring dynamic adaptation of scheduling strategies. The scheduling node reliably distributes tasks to execution nodes using TCP and efficiently retrieves distributed locks and load data from Redis for precise scheduling. Task data is then stably processed via MySQL, and finally, monitoring metrics, tracing links, and log data are uniformly reported to observable nodes using the OpenTelemetry protocol. Observable nodes, in turn, push alarm threshold configurations back to the management module via HTTP, forming a closed-loop optimization. This collaborative design of inter-component protocol specifications and cluster architecture organically integrates data transmission security mechanisms with observable data integration processes, fundamentally solving the transmission reliability problem caused by protocol confusion and providing a unified data foundation for end-to-end analysis. 2. This application defines the analysis time window by periodically generating optimization cycles, retrieves the load rate data of abnormal tasks within the optimization cycle to construct a load optimization set, calculates the variance of the set to obtain the load distribution coefficient, compares the load distribution coefficient with a preset threshold, and if the coefficient is greater than or equal to the threshold, iteratively removes the largest and smallest elements in the set to purify the data until the coefficient is less than the threshold; finally, the minimum load rate of the purified set is marked as the load threshold for the next cycle, thereby realizing dynamic optimization of the load threshold. 3. This application uses an indicator acquisition unit to capture system operation data in real time, an indicator storage unit to perform structured and persistent storage of the collected data, and an indicator analysis unit to perform multi-dimensional correlation analysis based on the stored historical data. After indicator analysis, an alarm mechanism is triggered to ensure that alarm decisions are based on in-depth analysis rather than simple threshold judgment. At the same time, the link acquisition unit completely records the time-series data of each stage of the task from submission to execution, the link storage unit ensures the continuity and traceability of link data, and the link visualization unit dynamically presents the entire path of task submission-scheduling-execution in a graphical manner. In addition, the log acquisition unit uniformly collects logs from each node of the edge execution layer, the log storage unit realizes centralized management of log data, and the log retrieval unit provides efficient query capabilities based on keywords and context. Overall, the collaborative design of each unit ensures the organic integration of monitoring, tracking, and logging functions, providing end-to-end observability assurance for task scheduling under the cloud-edge collaborative architecture. 4. This application initiates the fault location process using TraceID as a unified index. First, the tracing submodule queries Jaeger link data and marks spans whose time consumption exceeds the threshold to identify performance bottlenecks. Then, based on this bottleneck, the monitoring submodule is called to query Prometheus metrics, focusing on node-level resource metrics and task-level execution metrics to distinguish between infrastructure or task logic problems. Next, using both TraceID and node ID as identifiers, Elasticsearch logs are retrieved in the log submodule to filter abnormal keywords and obtain the fault context. Finally, the MySQL configuration and audit logs are queried by associating the task ID with the task storage module to eliminate human intervention interference. The above steps form a logically progressive diagnostic chain. Each module accurately triggers subsequent operations based on the output of the preceding steps, avoiding duplicate queries caused by data dispersion, and achieving closed-loop verification from phenomenon location to root cause analysis. Attached Figure Description

[0015] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a system block diagram of the present invention; Figure 2 This is a flowchart illustrating the task scheduling and execution monitoring process of the present invention. Figure 3 This is a flowchart of the fault location process of the present invention. Detailed Implementation

[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. 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.

[0018] In traditional distributed task scheduling systems, insufficient observability leads to technical shortcomings such as lack of end-to-end tracing, limited monitoring dimensions, and fragmented logs. Specifically, the lack of end-to-end tracing prevents the complete recording of task execution paths; limited monitoring dimensions mean system status can only be assessed through limited indicators such as scheduling node CPU utilization; and log fragmentation results in scattered and inconsistent log data storage, hindering cross-node correlation analysis. These issues collectively impact fault diagnosis efficiency, resource scheduling accuracy, and system reliability, leaving maintenance processes without necessary data support.

[0019] For example, in financial transaction processing scenarios, distributed task scheduling involves multiple microservice nodes such as order generation, risk assessment, and fund settlement. When a transaction task fails, the lack of a full-link tracing mechanism prevents operations personnel from pinpointing the specific stage of the failure. Monitoring systems only collect task success rate metrics from execution nodes, neglecting crucial dimensions like network latency and database response time. Furthermore, log data is scattered across execution nodes, and format differences necessitate manual piecing together of fragmented information during log queries, significantly reducing fault location efficiency. This lack of observability further complicates the analysis of task failure causes, directly impacting system stability.

[0020] If these issues are not addressed, the observability deficiencies in distributed task scheduling systems will lead to increased task failure rates, prolonged fault recovery periods, and potentially cascading failures, impacting business continuity. Furthermore, fragmented logs and limited monitoring dimensions result in a lack of comprehensive data for system optimization, hindering resource utilization improvements and continuously increasing operational costs. In critical business scenarios, these problems can pose service interruption risks, damaging system reputation and user experience.

[0021] like Figure 1 As shown, an observable distributed task scheduling system based on cloud-edge collaboration is presented. The system adopts a cloud-edge collaborative architecture, including a cloud control layer and an edge execution layer. The cloud control layer includes management nodes and a task storage module, while the edge execution layer includes scheduling nodes, execution nodes, and observable nodes.

[0022] This application achieves deep integration of a cloud-edge collaborative architecture with observable nodes, enabling traceable performance data, monitorable resource status, and correlated log information during task scheduling. It realizes full-path visualization from task submission to execution feedback, effectively solving technical problems such as lack of end-to-end tracing, single monitoring dimensions, and fragmented logs in traditional distributed task scheduling systems. Specifically, the cloud control layer centrally manages control logic, the edge execution layer distributes task execution, and observable nodes uniformly handle monitoring, tracing, and logging functions, thus forming a systematic observable framework. This ensures real-time reporting of scheduling metrics and tracing spans, enabling precise fault location by associating task, resource, and link data. Furthermore, during task priority ranking and load filtering, scheduling nodes dynamically generate tracing IDs and collect scheduling time metrics, making task scheduling context data traceable. Observable nodes integrate multi-dimensional metric collection and structured alarm information generation, thereby eliminating log fragmentation and improving the overall observability of the system. As a preferred implementation, load filtering can be implemented by combining network I / O metrics for node selection, primarily to adapt to task scheduling needs under different resource constraints.

[0023] The task storage module includes a MySQL cluster and a Redis cluster. The management node sends synchronous task information and audit logs to the task storage module via HTTPS protocol. The management node sends push alarm rules and system configurations to the scheduling node via HTTP protocol. The scheduling node sends task distribution and status reporting to the execution node via TCP protocol. The scheduling node obtains distributed locks and load data from the Redis cluster via Redis protocol. The scheduling node performs read and write tasks and alarm records on the MySQL cluster via MySQL protocol. It sends reported monitoring metrics, tracing links, and log data to the observable nodes via OpenTelemetry protocol. The observable nodes push observable alarm threshold configurations to the management module via HTTP protocol.

[0024] The task storage module, comprising a MySQL cluster and a Redis cluster, is composed of a relational database cluster and an in-memory database cluster working together. Specifically, the MySQL cluster is a database system used for persistent storage of basic task information and alarm records, implemented using a master-slave replication architecture or a sharded cluster architecture to ensure data transaction consistency and high reliability. The Redis cluster is an in-memory database system used for real-time caching of distributed locks and load data, implemented using sentinel mode or cluster mode to provide sub-millisecond response speeds to support high-concurrency access. The management node uses HTTPS, meaning it uses a TLS-encrypted Hypertext Transfer Protocol for data interaction, implemented using TLS 1.2 or TLS 1.3 to ensure the confidentiality and integrity of task information and audit logs during transmission. The scheduling node uses TCP, meaning the scheduling node uses TCP... Nodes establish reliable connections with execution nodes using the Transmission Control Protocol (TCP), which utilizes sequence number acknowledgment and automatic retransmission mechanisms to ensure task distribution instructions are delivered intact despite network fluctuations. Scheduling nodes access the Redis cluster directly via the Redis proprietary communication protocol, enabling efficient data exchange based on RESP serialization to accelerate distributed lock verification and load data queries. Scheduling nodes operate the MySQL cluster using the standard MySQL client protocol, employing prepared statements to optimize database interactions and improve read / write efficiency for large-scale task data. The OpenTelemetry protocol uses the OpenTelemetry standardized data model for observable data reporting, unifying the semantic format of monitoring metrics, tracing links, and logs to eliminate multi-source data fragmentation.

[0025] The management node includes an authentication submodule, an audit log submodule, a task configuration submodule, a system configuration submodule, and an observability configuration submodule. The authentication submodule connects to the audit log submodule, the task configuration submodule, and the system configuration submodule through internal interfaces. The task configuration submodule synchronizes basic task information to the MySQL cluster via HTTPS. The observability configuration submodule sends monitoring indicator thresholds, tracking sampling rates, and log retention durations to the observable nodes via HTTP. The authentication submodule is a prerequisite for all operations.

[0026] Internal interfaces refer to the secure communication channels established between modules. These can be implemented using encrypted RESTful APIs or two-way authenticated message queues. Their purpose is to ensure the integrity and tamper-proof nature of data exchange between the authorization authentication submodule and the audit log submodule, task configuration submodule, and system configuration submodule, preventing operational traceability failures caused by fragmented authorization information. HTTPS refers to the Hypertext Transfer Security Protocol, which can be implemented using TLS 1.3 cipher suites or a certificate two-way verification mechanism. Its purpose is to provide end-to-end encryption protection for the task configuration submodule when transmitting basic task information to the MySQL cluster, preventing... Plaintext transmission carries the risk of parameter theft or tampering; HTTP refers to the Hypertext Transfer Protocol, which can be implemented using standardized HTTP methods and status code mechanisms. Its purpose is to enable the observable configuration submodule to send monitoring indicator thresholds, tracking sampling rates, and log retention durations to observable nodes in a unified format, ensuring the accurate parsing and execution of configuration commands; the authorization authentication submodule, as a prerequisite for all operations, refers to the mandatory execution of identity verification processes before any system function is triggered. It can be deployed at the user request entry point or the starting point of the service call chain, with the aim of building a unified security verification baseline and fundamentally blocking unauthorized access paths.

[0027] This application establishes a real-time linkage mechanism between permission verification, operation auditing, and task configuration by bringing the permission authentication submodule to the forefront and connecting it internally with the audit log submodule, task configuration submodule, and system configuration submodule. This allows user behavior to automatically trigger audit log recording and synchronize task configuration status during the authentication phase. Simultaneously, the task configuration submodule uses HTTPS protocol to transmit basic task information to the MySQL cluster, utilizing an encrypted channel to ensure data confidentiality and integrity during transmission. The observable configuration submodule distributes monitoring parameters to observable nodes via HTTP protocol, forming a standardized configuration management process. This design creates a closed-loop verification between the permission authentication process and system operations, ensures secure transmission of task data synchronization, and standardizes the observable configuration distribution protocol. This systematically solves the problems of fragmented permission management and configuration synchronization risks, strengthening the security boundary and the reliability of observable configuration.

[0028] like Figure 2 As shown, the scheduling node is used for task scheduling and alarm analysis: after reading the tasks to be scheduled, the tasks are prioritized, load filtering of execution nodes is performed to obtain matching nodes, distributed lock verification is performed on the tasks, the tasks to be scheduled are sent to the matching nodes and a tracking ID is generated, scheduling time metrics are collected during the scheduling process, and scheduling stage metrics and tracking spans are reported to observable nodes; the specific process of load filtering of execution nodes includes: determining whether the load rate of the execution node is less than the load threshold; if so, the corresponding execution node is marked as a matching node; if not, the execution node filtering is repeated until the matching nodes are marked; anomaly detection is performed during the execution of the scheduled tasks, an alarm is triggered when an anomaly exists, and the corresponding task is marked as an abnormal task; if no anomaly exists, the task status is marked as successful.

[0029] Among them, load rate refers to the resource utilization of the execution node, which can be measured by indicators such as CPU utilization, memory usage, or network I / O load rate, aiming to reflect the current workload status of the node in real time; load threshold refers to the preset upper limit of resource usage, which can be dynamically set based on historical system load data or configured through management nodes, aiming to serve as a benchmark for judging whether a node is suitable for executing new tasks; matching node can be understood as the execution node with a load rate lower than the load threshold, aiming to ensure that tasks are assigned to healthy nodes with sufficient resources, avoiding task failure due to node overload; anomaly detection specifically refers to the real-time monitoring of the task execution process, which can be achieved through heartbeat detection mechanisms, error log analysis, or performance indicator deviation calculation, aiming to dynamically capture deviations in task execution and promptly discover potential faults; alarm triggering can be understood as the system automatically issuing an alarm when an anomaly is detected, which can notify observable nodes through message queues or API calls, aiming to provide accurate basis for fault location; task status marking specifically updates the task status according to the execution result, which can record success or anomaly indicators in the task storage module, aiming to form a closed-loop feedback and support complete tracking and statistical analysis of the task lifecycle.

[0030] Perform periodic optimization analysis on the load screening process: Generate an optimization cycle, retrieve the load rate of abnormal tasks during load screening within the optimization cycle, construct a load optimization set from the load rates of all abnormal tasks, calculate the variance of the load optimization set to obtain the load distribution coefficient, and compare the load distribution coefficient with a preset load distribution threshold: If the load distribution coefficient is greater than or equal to the load distribution threshold, remove the maximum and minimum elements in the load optimization set, and then recalculate the load optimization coefficient, and so on, until the load distribution coefficient is less than the load distribution threshold; if the load distribution coefficient is less than the load distribution threshold, mark the minimum element in the load optimization set as the load threshold for the next optimization cycle.

[0031] Specifically, the optimization cycle refers to the time interval for periodically performing load screening and optimization analysis. This can be implemented using a fixed time period or a dynamic period based on task volume, aiming to avoid real-time computation overhead and ensure manageable optimization processes. Load rate can be understood as a resource utilization indicator of an execution node during task scheduling. It can be implemented using specific indicators such as CPU utilization, memory utilization, or network I / O load rate, aiming to quantify the node's load level. In practical applications, the load optimization set is specifically the set of load rate data for all abnormal tasks during load screening within the optimization cycle. This data can be stored in a memory cache or database for centralized analysis of abnormal data. Specifically, the load distribution coefficient is an indicator of the load rate dispersion obtained through variance calculation. It can be calculated using a statistical variance formula, aiming to reflect the stability of the load distribution. The load distribution threshold can be understood as a preset load distribution coefficient threshold, which can be set based on historical data experience, aiming to serve as a basis for judging whether the load distribution is reasonable. In practical applications, the load threshold is specifically a threshold used to determine whether an execution node is a match. It can be dynamically adjusted to the minimum element in the load optimization set, aiming to ensure that only low-load nodes are selected.

[0032] The observable nodes include a monitoring submodule, a tracing submodule, and a logging submodule. The monitoring submodule includes an indicator collection unit, an indicator storage unit, and an indicator analysis unit, triggering alarms after indicator analysis. The tracing submodule includes a link collection unit, a link storage unit, and a link visualization unit, displaying the entire path from "task submission → scheduling → execution." The logging submodule includes a log collection unit, a log storage unit, and a log retrieval unit. The monitoring submodule collects over 20 dimensions of indicators, such as "node CPU / memory / network I / O" and "task scheduling time / execution success rate." The tracing submodule generates indicators containing Tr... The entire aceID tracing process (e.g., T001 corresponds to "task submission (10ms) → scheduling and distribution (50ms) → execution node A processing (200ms)") is implemented. The log submodule aggregates logs from each node and associates them with TraceIDs to solve the problem of scattered observable data. When an alarm is triggered, the observable node automatically generates alarm information containing the following identifiers: trace identifier, task identifier, and resource identifier. The trace identifier includes TraceID, the task identifier includes task ID, task version number, and task priority, and the resource identifier includes node ID and resource type (CPU / memory / network I / O). The system comprises the following components: **Indicator Acquisition Unit:** This unit captures real-time system runtime data. It can be implemented using open-source monitoring agents or custom data collectors, aiming to obtain key performance indicators during task scheduling. **Indicator Storage Unit:** This unit persistently stores the collected data. It can be implemented using time-series databases or distributed file systems, ensuring the continuity and traceability of monitoring data. **Indicator Analysis Unit:** This unit performs multi-dimensional analysis based on historical data. It can be implemented using rule engines or machine learning models, aiming to identify potential performance bottlenecks and trigger deep alerts. **Tracking Path Acquisition Unit:** This unit records task flow time-series data. It can be implemented using distributed tracing SDKs or custom tracking tools, aiming to capture the complete path from task submission to execution. **Tracking Path Storage Unit:** This unit stores tracking path data. It can be implemented using distributed tracing backends or graph databases, aiming to maintain the integrity and relevance of tracking path data. **Tracking Path Visualization Unit:** This unit graphically displays the task flow path. It can be implemented using web front-end frameworks or dedicated visualization tools, aiming to intuitively present the entire path from task submission to scheduling to execution. The log collection unit refers to the component that collects system logs in a unified manner. It can be implemented using a log collection agent or a message queue client, with the aim of integrating scattered log sources. The log storage unit refers to the component that centrally manages log data. It can be implemented using a search engine or a distributed log system, with the aim of achieving efficient storage and retrieval of log data. The log retrieval unit refers to the component that provides log query capabilities. It can be implemented using a full-text search engine or a structured query interface, with the aim of supporting accurate positioning based on keywords and context.

[0033] In practical applications, the trace identifier refers to the unique identifier for distributed tracing, which can be implemented using TraceID. TraceID can be generated using a globally unique string such as UUID format. Its purpose is to ensure accurate reconstruction of the entire task path and avoid link breakage issues caused by non-unique identifiers. The task identifier includes the task ID, task version number, and task priority. The task ID is the unique identifier for the task instance, which can be implemented using an auto-incrementing integer sequence or a task hash value generated by a hash algorithm. The task version number is an identifier that records the historical changes in the task configuration, and it can use a semantic version number format such as "major.minor". The `.patch` tag is used to implement this; task priority refers to the identifier that quantifies the importance of a task, which can be implemented using a predefined level system such as numbers 1-5 or text descriptions such as "high, medium, low". Its purpose is to provide a full lifecycle context for the task, supporting the rapid differentiation of task instances and assessment of the scope of impact; resource identifiers include node ID and resource type, where node ID is the identifier that precisely locates the specific execution node, which can be implemented using IP address or hostname string; resource type is the identifier that distinguishes resource categories, which can be implemented using predefined enumeration values ​​such as CPU, memory, network I / O, with the purpose of generating fine-grained identifiers that directly associate physical nodes with resource dimensions.

[0034] like Figure 3 As shown, the specific process of fault location includes the following steps: Step S1: Locate the time-consuming abnormal link by tracing the sub-module: Enter TraceID to query Jaeger link data, display the full path of "task submission → scheduling and distribution → execution feedback", and mark the span that exceeds the time threshold; Step S2: Confirm the type of resource anomaly through the monitoring submodule: Based on the anomaly in step S1, query the corresponding Prometheus metrics: Node layer: CPU utilization / memory usage / network IO packet loss rate; Task layer: execution success rate / number of retries. Step S3: Extract fault details through the log submodule: Enter "TraceID + node ID" to retrieve Elasticsearch logs and filter logs containing error codes and abnormal keywords; Step S4: Eliminate human error factors through the task storage module: Query the task configuration (parameters / priority) and audit log (last operator / modification time) in MySQL by associating the task ID.

[0035] The observable nodes have a built-in fault feature library. By matching the location results with the feature library, the fault type can be automatically diagnosed. The feature library can be updated through management node configuration. The diagnostic rules include: Matching characteristics corresponding to node resource overload include: execution node load coefficient > 60% (CPU > 80% or memory > 75%), and logs containing the keywords "insufficient resources" and "task queuing"; The matching characteristics corresponding to task execution exceptions include: task timeout > 3s and error code 5xx (server) / 4xx (parameter), stack information including "interface timeout" and "parameter format error"; Matching characteristics for scheduling logic failures include: the number of times the distributed lock acquisition failed > 3 times (Redis logs contain "lock contention"), and the scheduling and distribution time > 100ms (tracking Span anomalies). The matching characteristics corresponding to network link anomalies include: network IO packet loss rate > 1% or inter-node communication delay > 50ms, and the traced link contains a "network timeout" span (such as scheduling → execution communication). Matching characteristics corresponding to human error include: audit logs showing that task parameters were modified within the last hour (operator without administrator privileges), and task ID and version number not matching.

[0036] The criteria for determining the location of the above fault types are: satisfying any matching feature.

[0037] Among them, TraceID refers to a globally unique tracing identifier used in a distributed system to identify a complete task chain. It can be implemented using a string generated based on timestamps and random sequences, aiming to ensure that the chain data can be accurately correlated throughout the entire lifecycle of a task from submission to execution. Jaeger chain data refers to a data set that stores distributed service call path information. It can be implemented using the serialized data format of an open-source distributed tracing system, aiming to record the temporal relationship and dependency topology of each stage during task execution. Span refers to the basic unit representing a single operation in the tracing chain. It can be understood as a data structure containing operation name, start and end timestamps, and context information, aiming to quantify the time consumption performance of each stage. Prometheus metrics refer to real-time performance measurement data collected by the monitoring system. It can include a set of multi-dimensional metrics from the resource layer and task layer, aiming to dynamically reflect the system's operating status. Elasticsearch logs refer to log information stored through a distributed search engine. It can use a structured JSON document format for efficient retrieval, aiming to support fast log filtering based on keywords. MySQL task configuration refers to a relational database table that stores task parameters and operation history. It can include configuration fields for task ID indexes and audit records, aiming to provide complete traceability of task configuration.

[0038] An observable distributed task scheduling system based on cloud-edge collaboration is proposed. During operation, through deep integration of the cloud-edge collaborative architecture with observable nodes, the performance data of the task scheduling process is traceable, resource status is monitorable, and log information is correlated. This achieves full-path visualization from task submission to execution feedback, effectively solving technical problems such as lack of full-link tracing, single monitoring dimensions, and log fragmentation in traditional distributed task scheduling systems. The cloud control layer centrally manages the control logic, the edge execution layer distributes task execution, and the observable nodes uniformly handle monitoring, tracing, and logging functions, thus forming a systematic observable framework. This ensures real-time reporting of scheduling indicators and tracing spans, enabling precise fault location by associating task, resource, and link data. During task priority sorting and load filtering, the scheduling nodes dynamically generate tracing IDs and collect scheduling time indicators, making task scheduling context data traceable. The observable nodes integrate multi-dimensional indicator collection and structured alarm information generation, thereby eliminating log fragmentation and improving the overall observability of the system.

[0039] The above description is merely an example and illustration of the structure of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the structure of the invention or exceed the scope defined in the claims, all of which should fall within the protection scope of the present invention.

[0040] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0041] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. An observable distributed task scheduling system based on cloud-edge collaboration, characterized in that, The system adopts a cloud-edge collaborative architecture, including a cloud control layer and an edge execution layer. The cloud control layer includes management nodes and a task storage module, while the edge execution layer includes scheduling nodes, execution nodes, and observable nodes. The management node includes an authorization authentication submodule, an audit log submodule, a task configuration submodule, a system configuration submodule, and an observable configuration submodule. The scheduling node is used for task scheduling and alarm analysis: after reading the tasks to be scheduled, the tasks are prioritized, the execution nodes are load-filtered to obtain matching nodes, the tasks are verified by distributed locks, the tasks to be scheduled are sent to the matching nodes and a tracking ID is generated, the scheduling time indicators of the scheduling process are collected, and the scheduling process indicators and tracking spans are reported to the observable nodes; the load filtering process is periodically optimized and analyzed. The observable node includes a monitoring submodule, a tracking submodule, and a log submodule; When an alarm is triggered, the observable node automatically generates alarm information containing the following identifiers: tracking identifier, task identifier, and resource identifier.

2. The observable distributed task scheduling system based on cloud-edge collaboration according to claim 1, characterized in that, The task storage module includes a MySQL cluster and a Redis cluster. The management node sends synchronization task information and audit logs to the task storage module via HTTPS protocol. The management node sends push alarm rules and system configurations to the scheduling node via HTTP protocol. The scheduling node sends task distribution and status reporting to the execution node via TCP protocol. The scheduling node obtains distributed locks and load data from the Redis cluster via Redis protocol. The scheduling node performs read / write tasks and alarm records on the MySQL cluster via MySQL protocol. The node sends reported monitoring metrics, tracing links, and log data to the observable nodes via OpenTelemetry protocol. The observable nodes push observable alarm threshold configurations to the management module via HTTP protocol.

3. The observable distributed task scheduling system based on cloud-edge collaboration according to claim 2, characterized in that, The authorization submodule connects to the audit log submodule, task configuration submodule, and system configuration submodule through an internal interface. The task configuration submodule synchronizes basic task information to the MySQL cluster via HTTPS. The observable configuration submodule sends monitoring indicator thresholds, tracking sampling rates, and log retention durations to observable nodes via HTTP. The authorization submodule is a prerequisite for all operations.

4. The observable distributed task scheduling system based on cloud-edge collaboration according to claim 3, characterized in that, The specific process of load screening for execution nodes includes: determining whether the load rate of the execution node is less than the load threshold; if yes, marking the corresponding execution node as a matching node; if no, re-screening the execution nodes until the matching nodes are marked; performing anomaly detection during the execution of the scheduled task, triggering an alarm when an anomaly exists, and marking the corresponding task as an abnormal task; marking the task status as successful when no anomaly exists.

5. The observable distributed task scheduling system based on cloud-edge collaboration according to claim 4, characterized in that, The specific process of periodically optimizing the load screening process includes: generating an optimization period, retrieving the load rate of abnormal tasks during load screening within the optimization period, constructing a load optimization set from the load rates of all abnormal tasks, calculating the variance of the load optimization set to obtain the load distribution coefficient, and comparing the load distribution coefficient with a preset load distribution threshold: if the load distribution coefficient is greater than or equal to the load distribution threshold, the maximum and minimum elements in the load optimization set are removed, and the load optimization coefficient is recalculated, and so on, until the load distribution coefficient is less than the load distribution threshold; if the load distribution coefficient is less than the load distribution threshold, the minimum element in the load optimization set is marked as the load threshold for the next optimization period.

6. The observable distributed task scheduling system based on cloud-edge collaboration according to claim 5, characterized in that, The monitoring submodule includes an indicator collection unit, an indicator storage unit, and an indicator analysis unit, which triggers alarms after indicator analysis; the tracing submodule includes a link collection unit, a link storage unit, and a link visualization unit, which visualizes the entire path of task submission, scheduling, and execution; and the logging submodule includes a log collection unit, a log storage unit, and a log retrieval unit.

7. The observable distributed task scheduling system based on cloud-edge collaboration according to claim 6, characterized in that, The trace identifier includes TraceID; the task identifier includes task ID, task version number, and task priority; and the resource identifier includes node ID and resource type.

8. The observable distributed task scheduling system based on cloud-edge collaboration according to claim 7, characterized in that, The specific process of fault location includes the following steps: Step S1: Locate the time-consuming abnormal link by tracking the sub-module; Step S2: Confirm the type of resource anomaly through the monitoring submodule; Step S3: Extract fault details through the log submodule; Step S4: Eliminate human error factors through the task storage module.

Images