An annotation-driven based thread runtime observability monitoring method and system

Abstract

This invention provides a thread runtime observability monitoring method and system based on annotation-driven technology in the field of computer software monitoring and observability. The method includes: Step S1, defining and registering a thread monitoring annotation in the application system code; Step S2, intercepting the execution of the target method during application system runtime using aspect-oriented programming (AOP); Step S3, automatically embedding monitoring logic before and after the execution of the target method using AOP aspects to collect observability data of the thread executing the target method; Step S4, processing the collected observability data and storing it persistently and non-volatilely according to a preset configurable strategy; Step S5, providing a visual interface to display and query the real-time running status of threads and historical execution chain details in the application system. The advantage of this invention is that it effectively ensures the continuous high performance and high availability of the application system.

Description

Technical Field

[0001] This invention relates to the field of computer software monitoring and observability technology, and in particular to an annotation-driven method and system for monitoring the observability of threads during runtime. Background Technology

[0002] In today's modern enterprise application systems, threads, as the core carriers of business logic and driving system operation, are widely used in scenarios such as synchronous HTTP request processing and asynchronous background task execution. Mainstream development frameworks (such as Spring Boot and Quarkus) use automatic configuration mechanisms to transparently manage various built-in or integrated thread pools (such as web service thread pools and asynchronous task thread pools), significantly reducing the complexity of concurrent programming. However, this convenience also introduces a series of monitoring blind spots: frameworks have significant limitations in fine-grained thread-level measurement, visualization, and real-time status monitoring, making it difficult to gain real-time insight into the actual working status of thread pools, thus leading to performance bottlenecks, queue accumulation, and resource exhaustion.

[0003] Specifically, the existing technology has the following prominent problems: 1. Difficult and inefficient fault localization: When applications experience request waiting or a sudden drop in throughput, operations and maintenance personnel cannot view the current number of active threads, the backlog of task queues, and the specific execution logic of threads in real time. The lack of fine-grained monitoring of thread runtime states makes fault localization rely on limited business logs and exception stack traces for post-event backtracking, significantly increasing the mean time to recovery (MTTR).

[0004] 2. High Risk in Troubleshooting Mode: The traditional troubleshooting method, which relies on "supplementing logs and redeploying," is essentially a high-cost and high-risk online debugging approach. Frequent production environment deployments not only interrupt services but may also introduce new defects, violating the principle of prioritizing stability in operations and maintenance.

[0005] 3. Synchronous / Asynchronous Link Segmentation: A user request may involve a synchronous HTTP processing thread and its derived asynchronous task threads. However, existing monitoring systems have difficulty in correlating and analyzing the synchronous call chain with the execution of asynchronous threads, making it impossible to quickly locate the root cause of performance bottlenecks (such as main thread delay or asynchronous subtask blocking).

[0006] 4. Lack of ability to trace the root cause of problems: Many slow requests are instantaneous or sporadic, and the lack of continuous sampling and recording of thread states makes it impossible to effectively review the situation after a problem occurs. It is difficult to restore the scene based on log snapshots alone, which hinders closed-loop improvement.

[0007] To address the aforementioned issues, the industry has already developed several application performance monitoring (APM) solutions. For example, Spring Boot Actuator provides basic HTTP endpoints to expose the internal state of applications, but it focuses more on macro-level health metrics and lacks in-depth tracking of thread-level runtime details (such as task queuing, time distribution, and cross-thread call relationships). While distributed tracing tools such as SkyWalking and Pinpoint can monitor cross-service call chains, their focus is concentrated on distributed, cross-process calls, with limited capture of "thread-level" runtime information such as multi-threaded execution details within a single JVM and the internal state of thread pools. Furthermore, their relatively "heavy" deployment model may incur additional performance overhead.

[0008] The aforementioned existing technologies cannot effectively address the requirements of lightweight, low-intrusion, and real-time thread runtime monitoring. Therefore, how to provide an annotation-driven thread runtime observability monitoring method and system to improve fine-grained visibility of thread-level runtime states, reduce operational and troubleshooting costs and risks, and build complete observability capabilities for synchronous and asynchronous links, thereby ensuring the continuous high performance and high availability of application systems, has become an urgent technical problem to be solved. Summary of the Invention

[0009] The technical problem to be solved by this invention is to provide an annotation-driven thread runtime observability monitoring method and system, which improves the fine-grained visibility of thread-level runtime states, reduces operation and maintenance troubleshooting costs and risks, and builds complete synchronous and asynchronous link observability capabilities, thereby ensuring the continuous high performance and high availability of application systems.

[0010] In a first aspect, the present invention provides an annotation-driven method for monitoring the observability of threads at runtime, comprising the following steps: Step S1: In the application system code, define and register a thread monitoring annotation, which is used to declaratively mark the target method that needs to be monitored; Step S2: When the application system is running, intercept the execution of the target method using aspect-oriented programming (AOP) techniques; Step S3: Before and after the execution of the target method, monitoring logic is automatically injected through AOP aspects. The monitoring logic collects observability data of the thread executing the target method during runtime. The observable data includes at least the thread chain identifier, execution time, and method context information. Step S4: Process the collected observability data and store it in a non-volatile persistent manner according to a preset configurable strategy; Step S5: Provide a visual interface to display and query the real-time running status of threads in the application system and the details of historical execution links.

[0011] Furthermore, in step S1, the thread monitoring annotation includes one or more of the following configurable attributes: The name attribute is used to identify the name of the monitoring operation; The `type` attribute is used to categorize monitoring operations; The description attribute is used to provide a detailed description; The key attribute is used to uniquely identify the operation instance; The `extendColumns` array is used to record additional business attributes. The `handler` property is used for custom monitoring data creation and extension operations.

[0012] Furthermore, in step S3, the collection of observability data further includes: Generate and manage a unique link identifier for the execution of the thread; A software development kit (SDK) approach is used to ensure that the unique link identifier is passed between synchronous threads and asynchronous threads derived from them, thereby associating synchronous and asynchronous execution links.

[0013] Furthermore, in step S4, the configurable strategy includes an intelligent sampling strategy, which includes one or more of the following modes: Continuous recording mode; For the same monitoring key, only the first slow link triggered will be recorded; For slow link records of the same monitoring key, an interval recording mode based on the cooling time T is adopted; the formula for calculating the cooling time T is: T=T_base* 2^(n-1), where T_base is the configured base time interval, and n is the cumulative number of times slow link records are triggered for the same monitoring key since the application system started. The persistent storage adopts a multi-level storage structure, including: The first storage layer used for temporarily caching monitoring process data can be configured as memory, Redis, or local files. The second storage layer, used to ultimately store the monitoring results data, is configured as a local file system or an FTP server.

[0014] Furthermore, in step S5, the real-time running status includes the running metrics of the synchronous thread pool and the asynchronous thread pool; the historical execution chain details are displayed in a tree structure, showing the nested call relationship of the target method and the execution time of each node; Step S5 also includes a data lifecycle management step: The monitoring process data is stored asynchronously and automatically cleaned up after the corresponding monitoring result data is persisted. The files corresponding to the monitoring results data are organized by date, and the scattered files from the previous day are merged into a single file after the day crosses over. Expired files are also cleaned up periodically according to the configured retention time.

[0015] Secondly, the present invention provides an annotation-driven thread runtime observability monitoring system, comprising the following modules: The thread monitoring annotation registration module is used to define and register a thread monitoring annotation in the application system code. The thread monitoring annotation is used to declaratively mark the target method that needs to be monitored. The target method execution interception module is used to intercept the execution of the target method during the runtime of the application system using aspect-oriented programming techniques. An observability data acquisition module is used to automatically inject monitoring logic through AOP aspects before and after the execution of the target method, and to collect observability data of the thread executing the target method during runtime through the monitoring logic; the observability data includes at least thread link identifier, execution time, and method context information; The data processing and storage module is used to process the collected observable data and store it in a non-volatile persistent manner according to a preset configurable strategy. The data management module provides a visual interface for displaying and querying the real-time running status of threads and historical execution chain details in the application system.

[0016] Furthermore, in the thread monitoring annotation registration module, the thread monitoring annotation includes one or more of the following configurable attributes: The name attribute is used to identify the name of the monitoring operation; The `type` attribute is used to categorize monitoring operations; The description attribute is used to provide a detailed description; The key attribute is used to uniquely identify the operation instance; The `extendColumns` array is used to record additional business attributes. The `handler` property is used for custom monitoring data creation and extension operations.

[0017] Furthermore, in the observability data acquisition module, the acquisition of observable data further includes: Generate and manage a unique link identifier for the execution of the thread; A software development kit (SDK) approach is used to ensure that the unique link identifier is passed between synchronous threads and asynchronous threads derived from them, thereby associating synchronous and asynchronous execution links.

[0018] Furthermore, in the data processing and storage module, the configurable strategy includes an intelligent sampling strategy, which includes one or more of the following modes: Continuous recording mode; For the same monitoring key, only the first slow link triggered will be recorded; For slow link records of the same monitoring key, an interval recording mode based on the cooling time T is adopted; the formula for calculating the cooling time T is: T=T_base* 2^(n-1), where T_base is the configured base time interval, and n is the cumulative number of times slow link records are triggered for the same monitoring key since the application system started. The persistent storage adopts a multi-level storage structure, including: The first storage layer used for temporarily caching monitoring process data can be configured as memory, Redis, or local files. The second storage layer, used to ultimately store the monitoring results data, is configured as a local file system or an FTP server.

[0019] Furthermore, in the data management module, the real-time running status includes the running metrics of the synchronous thread pool and the asynchronous thread pool; the historical execution chain details are displayed in a tree structure, showing the nested call relationship of the target method and the execution time of each node; The data management module is also used for data lifecycle management steps: The monitoring process data is stored asynchronously and automatically cleaned up after the corresponding monitoring result data is persisted. The files corresponding to the monitoring results data are organized by date, and the scattered files from the previous day are merged into a single file after the day crosses over. Expired files are also cleaned up periodically according to the configured retention time.

[0020] The advantages of this invention are: 1. By defining and registering a thread monitoring annotation in the application system code to declaratively mark the target method that needs to be monitored; during application system runtime, the execution of the target method is intercepted using aspect-oriented programming (AOP); before and after the execution of the target method, monitoring logic is automatically injected through AOP aspects, and observable data, including at least thread link identifiers, execution time, and method context information, is collected during the execution of the thread executing the target method; the collected observable data is processed and stored in a non-volatile persistent manner according to a preset configurable strategy; a visual interface is provided to display and query the real-time running status and historical execution link details of threads in the application system; that is, by defining thread monitoring annotations and utilizing AOP technology, thread monitoring is automatically intercepted in a low-intrusive manner. The system marks target methods and collects fine-grained runtime data such as thread link identifiers, execution time, and method context information before and after their execution. This transforms the internal execution state of threads into visible, analyzable, and observable data, greatly improving the visibility of thread-level runtime states. The SDK ensures the transmission of link identifiers between synchronous and asynchronous threads, constructing a complete cross-thread execution link view and solving the problem of fragmented monitoring between synchronous and asynchronous links. Combined with configurable intelligent sampling and multi-level storage strategies, it significantly reduces performance overhead and operational risks while ensuring monitoring effectiveness. This allows operations personnel to gain real-time insight into thread states and accurately trace back historical issues through a visual interface, ultimately enabling online fault location without code modification and ensuring the continuous high performance and high availability of application systems.

[0021] 2. The annotation-driven approach allows developers to define the target methods to be monitored through declarative tags, which greatly simplifies the integration process of monitoring code. Compared with the traditional approach of hard-coding monitoring logic in business code, this annotation-based approach achieves non-intrusive monitoring, reduces code coupling, and makes monitoring functions easy to add to existing systems without modifying core business logic, thereby improving development efficiency and system maintainability.

[0022] 3. By using aspect-oriented programming (AOP) technology, monitoring logic is automatically embedded before and after the execution of the target method. Observable data such as link identifiers, execution time, and context information can be collected during thread execution without manual intervention. This automated collection mechanism not only reduces human error but also improves the real-time performance and accuracy of monitoring. It is particularly suitable for high-concurrency environments, can quickly identify performance bottlenecks, and improve system operation and maintenance efficiency.

[0023] 4. Generate and manage unique link identifiers during data acquisition, and ensure that the identifiers are passed between synchronous and asynchronous threads through SDK methods. This enables the synchronous and asynchronous execution in complex call chains to be effectively correlated. This design solves the problem of difficult asynchronous thread tracking in traditional monitoring, provides a more comprehensive view of the execution link, facilitates developers in diagnosing cross-thread problems, and improves system debuggability and reliability.

[0024] 5. Configurable strategies (such as intelligent sampling mode) and multi-level storage structure enable monitoring data to be processed flexibly according to actual needs. For example, a cooldown time mechanism can be used to reduce redundant data storage and avoid resource waste. This intelligent strategy not only optimizes storage efficiency but also allows users to adjust the monitoring granularity according to business scenarios, enhancing the adaptability and scalability of the solution while reducing long-term storage costs.

[0025] 6. The system displays real-time running status and historical execution details through a visual interface, presenting the call relationships in a tree structure, making the monitoring data easy to understand and analyze. In addition, data lifecycle management functions (such as asynchronous storage, file merging, and periodic cleanup) automate the data maintenance process, reduce manual intervention, ensure the rational use of storage resources, and improve the overall operability and sustainability of the system.

[0026] 7. By defining detailed configurable attributes (such as name, type, extendColumns, etc.) of thread monitoring annotations, the definition of monitoring behavior is highly parameterized. This allows developers to meet the monitoring needs of different business scenarios simply by adjusting annotation attributes, without modifying the underlying monitoring framework or AOP aspect logic (e.g., setting different monitoring granularities for methods of different importance). In particular, the extendColumns and handler attributes provide powerful custom extension capabilities for monitoring data, enabling the solution to easily adapt to future business changes and possessing good scalability.

[0027] 8. Data lifecycle management steps (such as organizing files by date, merging across days, and periodic cleanup) automate the monitoring data archiving process, organizing scattered data files into an orderly manner. This not only facilitates the querying and backtracking of historical data (e.g., quickly locating a problem on a specific day), but also automatically solves storage space management problems, preventing expired data from expanding indefinitely. This transforms massive monitoring data from a "storage burden" into a truly manageable and exploitable "data asset," enhancing its long-term value.

[0028] 9. By combining innovative annotation-driven and AOP aspects, low-intrusion, declarative monitoring of application thread observability is achieved. Its core advantages are that it not only greatly simplifies the integration and expansion of monitoring functions, but also efficiently balances monitoring granularity and system performance overhead through intelligent sampling and multi-level storage strategies. Furthermore, it ensures the visibility of synchronous and asynchronous call links with a complete link context passing mechanism. Finally, through automated data lifecycle management and an intuitive visualization interface, it provides users with integrated operation and maintenance support from real-time diagnosis to historical backtracking, thereby significantly improving the maintainability, debuggability, and operational reliability of complex distributed systems.

[0029] 10. Zero-code intrusion is achieved through AOP, solving the intrusiveness problem; intelligent sampling balances monitoring overhead, solving the performance problem; flexible caching, persistence, and lifecycle management of monitoring data are achieved through a multi-level storage structure of thread pool queue -> memory / file / redis -> file / database, solving the data storage and management problem; and a visual interface and multi-dimensional dashboard significantly reduce the understanding and usage threshold for operation and maintenance personnel and developers, solving the usability problem. Attached Figure Description

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

[0031] Figure 1 This is a flowchart of an annotation-driven thread runtime observability monitoring method according to the present invention.

[0032] Figure 2 This is a schematic diagram of the structure of an annotation-driven thread runtime observability monitoring system according to the present invention.

[0033] Figure 3 This is a schematic diagram of the interface showing the real-time running status of the synchronization thread of this invention. Detailed Implementation

[0037] The overall approach of the technical solution in this application is as follows: By defining thread monitoring annotations and utilizing AOP technology, the marked target methods are automatically intercepted in a low-intrusive manner. Fine-grained runtime data such as thread link identifiers, execution time, and method context information are collected before and after their execution, thereby transforming the internal execution state of the thread into visible, analyzable, and observable data, greatly improving the visibility of the thread-level runtime state. The SDK ensures that the link identifier is passed between synchronous and asynchronous threads, constructing a complete cross-thread execution link view and solving the problem of fragmented monitoring of synchronous and asynchronous links. With configurable intelligent sampling and multi-level storage strategies, performance overhead and operational risks are significantly reduced while ensuring the effectiveness of monitoring. This allows operations and maintenance personnel to gain real-time insight into thread states and accurately trace back historical issues through a visual interface, ultimately enabling online fault location without modifying code and ensuring the continuous high performance and high availability of the application system.

[0038] Please refer to Figures 1 to 3 As shown, a preferred embodiment of the annotation-driven thread runtime observability monitoring method of the present invention includes the following steps: Step S1: In the application system code, define and register a thread monitoring annotation (ThreadMonitor). The thread monitoring annotation is used to declaratively mark the target methods that need to be monitored. This step serves as the entry point for monitoring, achieving zero code intrusion through declarative annotations. The `ThreadMonitor` annotation includes configurable attributes (such as `name`, `type`, and `key`), allowing developers to flexibly tag target methods according to business needs. For example, the `name` attribute is used to identify the operation in the monitoring interface, and the `key` attribute can be combined with the resource ID to distinguish different instances, ensuring monitoring accuracy. Annotation registration is completed through Spring Boot's auto-configuration mechanism, loaded when the application starts, eliminating the need for manual coding and significantly reducing integration complexity. This design embodies the "convention over configuration" principle, improving maintainability.

[0039] Step S2: When the application system is running, intercept the execution of the target method using aspect-oriented programming (AOP) techniques; The interception layer is implemented based on Aspect-Oriented Programming (AOP). Aspect classes are predefined to intercept all target methods annotated with `@ThreadMonitor`, automatically injecting monitoring logic before and after the target method's execution. AOP frameworks (such as Spring AOP) dynamically generate proxy objects at runtime, ensuring transparent interception and avoiding pollution of business code. The key to this step lies in the precise definition of the pointcut, targeting only annotated methods to minimize performance overhead.

[0040] Step S3: Before and after the execution of the target method, monitoring logic is automatically injected through AOP aspects. The monitoring logic collects observability data of the thread executing the target method during runtime. The observable data includes at least the thread chain identifier, execution time, and method context information. Data acquisition is the core process, executed automatically through AOP aspects. The acquired data includes thread link identifiers, execution time, and method context information. The generation and management of unique link identifiers are implemented through SDK methods, ensuring transmission between synchronous and asynchronous threads (e.g., through ThreadLocal and asynchronous context passing mechanisms). This solves the problem of fragmented synchronous / asynchronous links in traditional monitoring. The acquisition process also involves data structures (such as thread basic information entities and link detail entities) that record nested call relationships in a tree structure, laying the foundation for visual analysis.

[0041] The core interception component is an aspect class based on Aspect-Oriented Programming (AOP), which is predefined and registered in the application context. This aspect is configured to inject monitoring logic before and after the execution of the target method, and its pointcut is defined as all target methods marked with the specified annotation (ThreadMonitor). When the application starts, this aspect is automatically activated, thus establishing a transparent and non-intrusive monitoring and interception layer throughout the entire system runtime.

[0042] Thread Basic Information Entity: This data structure records a summary of a complete thread execution process. Core fields include: unique identifier of the thread execution chain, name of the business monitoring point, execution thread ID, execution status, total time consumption, creation time, etc. This structure is used to track the overall lifecycle and status of thread execution.

[0043] Thread Call Details Entity: This data structure records every detailed step in the thread's execution process (i.e., each monitored method call). Core fields include: unique node identifier, associated sibling node identifiers, method signature, start time, end time, and node execution status. Multiple nodes of this type are associated through sibling relationships, allowing for the reconstruction of a complete, nested method call chain in a tree structure.

[0044] Step S4: Process the collected observability data and store it in a non-volatile persistent manner according to a preset configurable strategy; A configurable strategy balances monitoring granularity with system performance. Intelligent sampling strategies include continuous recording, initial trigger recording, and interval recording modes. Interval recording uses a cooldown time formula (T=T_base*2^(n-1)) to avoid redundant data storage. A multi-level storage structure is divided into a process data layer (memory, Redis, or file) and a result data layer (local file or FTP), ensuring flexible data caching and persistence. Process data is stored asynchronously to avoid blocking the main thread; result data is organized by date, and an automatic merging and cleanup of expired files is achieved through a monitoring mechanism, enabling automated lifecycle management.

[0045] Step S5: Provide a visual interface to display and query the real-time running status of threads in the application system and the details of historical execution links.

[0046] The visual interface is the main interaction point for operations and maintenance personnel. The interface displays the operating metrics of synchronous and asynchronous thread pools in real time (such as the number of active threads and queue backlog), and presents the details of historical execution links in a tree structure, which facilitates quick identification of bottlenecks.

[0047] The core of this invention is to transparently collect and visualize the entire execution process of synchronous and asynchronous threads within an application system by declaratively adding thread monitoring annotations to the target method and combining this with a context-aware thread tracing mechanism. Based on Aspect-Oriented Programming (AOP) technology, this solution automatically embeds monitoring probes (monitoring logic) before and after the target method execution, capturing key information such as thread chain identifiers, execution time, and method context information. It also supports intelligent sampling and persistence of monitoring data based on configurable strategies (such as time thresholds and abnormal conditions), and finally outputs structured thread execution records through a unified observation interface, providing data support for performance diagnosis, bottleneck location, and resource optimization.

[0048] In practical implementation, to enhance flexibility and configurability, a unified configuration attribute class was defined. This class centrally manages all adjustable parameters, such as the overall on / off switch for monitoring functions, performance thresholds for link detail records, data storage modes, slow link recording strategies, and the maximum number of link records. Monitoring behavior can be dynamically adjusted via an external configuration file (such as application.yml) without modifying the code. Furthermore, detailed Javadoc comments were added to key classes and methods to explain their design intent, functional logic, and parameter meanings, ensuring code readability and maintainability.

[0049] This invention offers high scalability in link monitoring, primarily achieved through inheriting the core abstract class and implementing specific interfaces. The entire framework adopts an object-oriented design philosophy, defining clear extension points and contracts, allowing developers to deeply customize the data model, processing logic, storage methods, and final display of the monitoring link without modifying existing stable logic.

[0050] In step S1, the thread monitoring annotation includes one or more of the following configurable attributes: The name attribute is used to identify the name of the monitored operation, that is, to identify and display the monitored method or operation in the monitoring system. The `type` attribute is used to categorize monitoring operations, such as by business module or technology type. The description attribute is used to provide a detailed description, that is, to supplement the explanation of the specific function or business meaning of the monitoring point; The key attribute is used to uniquely identify operation instances, that is, to distinguish different instances of the same operation in the monitoring system, such as using resource ID to distinguish different resource operations. The `extendColumns` array is used to record additional business attributes, i.e., to record additional business attributes or dimension information related to monitoring operations. The `handler` property is used to customize the creation and expansion operations of monitoring data. Specifically, it defines how to create monitoring data objects and how to perform expansion operations when the monitoring aspect is executed.

[0051] In step S1, the thread monitoring annotation includes one or more of the following configurable attributes: The name attribute is used to identify the name of the monitored operation, that is, to identify and display the monitored method or operation in the monitoring system. The `type` attribute is used to categorize monitoring operations, such as by business module or technology type. The description attribute is used to provide a detailed description, that is, to supplement the explanation of the specific function or business meaning of the monitoring point; The key attribute is used to uniquely identify operation instances, that is, to distinguish different instances of the same operation in the monitoring system, such as using resource ID to distinguish different resource operations. The `extendColumns` array is used to record additional business attributes, i.e., to record additional business attributes or dimension information related to monitoring operations. The `handler` property is used to customize the creation and expansion operations of monitoring data. Specifically, it defines how to create monitoring data objects and how to perform expansion operations when the monitoring aspect is executed.

[0052] In step S3, the acquisition of observability data further includes: Generate and manage a unique link identifier for the execution of the thread; A software development kit (SDK) approach is used to ensure that the unique link identifier is passed between synchronous threads and asynchronous threads derived from them, thereby associating synchronous and asynchronous execution links.

[0053] To implement the monitoring function, a set of core SDK (Software Development Kit) methods were designed. These methods are built into aspects and related utility classes, including: 1) Context initialization and passing method: Used to generate and manage a unique identifier for each monitoring link, and to ensure that the identifier is correctly passed between synchronous and asynchronous threads.

[0054] 2) Information storage and persistence methods: Based on the configured process data storage mode (such as memory, file or Redis), provide corresponding data writing, reading and cleaning functions, and based on the configured result data storage mode (such as local file or FTP file), provide corresponding data persistence.

[0055] 3) Performance data acquisition and calculation auxiliary methods: used to collect the start and end times of method execution, calculation time, and determine whether threshold conditions such as slow link recording are triggered.

[0056] When a thread first enters an aspect, thread information is recorded. Each time a thread enters an aspect, the thread execution chain is recorded according to the configuration. Thread pools or other asynchronous threads need to record the execution of asynchronous threads in synchronous threads through method instrumentation. The corresponding chain identifier needs to be obtained through SDK methods, and then the corresponding identifier needs to be set to the asynchronous thread by calling SDK methods at the beginning of thread execution. Asynchronous thread enhancement markers can also be added before and after asynchronous thread execution by calling SDK, and the start and end of asynchronous thread execution can be displayed in the chain information.

[0057] In step S4, the configurable strategy includes an intelligent sampling strategy, which includes one or more of the following modes: Continuous recording mode; For the same monitoring key, only the first slow link triggered will be recorded; For slow link records of the same monitoring key, an interval recording mode based on the cooling time T is adopted; the formula for calculating the cooling time T is: T=T_base* 2^(n-1), where T_base is the configured base time interval, and n is the cumulative number of slow link records triggered for the same monitoring key since the application system started; the monitoring key and key attributes both refer to identifiers used to uniquely distinguish monitoring operation instances; In a production environment, it is difficult to pinpoint the cause and solution for slow execution. When customers provide feedback, there is no good troubleshooting path. Specific rules can be set to perform slow link statistics. During thread monitoring, it can be decided whether to record the link based on the overall thread execution time or the execution time of a single method. Currently, there are three methods: the first is continuous recording, the second is recording only once, and the third is recording at time intervals.

[0058] The second and third schemes are introduced because link information still consumes some space resources. They can be used when space resources are limited. Considering that large loops may consume a large amount of meaningless information, a maximum number of links can be configured; if this number is exceeded, subsequent links will not be recorded. Daily alarm pushes can also be configured. For alarm anomalies, corresponding slow link files can be retrieved, analyzed, and the causes of system lag and slowness can be identified, allowing for targeted system optimization and performance improvement.

[0059] The persistent storage adopts a multi-level storage structure, including: The first storage layer is used for temporarily caching monitoring process data and can be configured as memory, Redis, or local files. Different solutions can be adopted for different server configurations. For a single machine with large memory, memory storage can be considered. For two servers, Redis and the system, where system memory resources are limited, Redis can be considered. For cases where memory resources are limited, disk space resources are sufficient, and IO performance is good, file storage can be considered. The process data storage uses asynchronous threads so as not to affect the execution of the main business. After the monitoring result data is recorded, the corresponding thread resources used and the corresponding process data will be automatically cleaned up.

[0060] The second storage layer, used to finally save the monitoring results data, is configured as a local file system or FTP server. The monitoring results data is stored in txt file format; each monitoring link is stored separately in a folder for the current day. A storage monitoring mechanism determines whether the data spans multiple days. If it does, the scattered link files from the previous day will be merged into a single txt file for easier analysis. Furthermore, expired files will be cleaned up according to the configured retention time to save system disk space.

[0061] In step S5, the real-time running status includes the running metrics of the synchronous thread pool and the asynchronous thread pool; the historical execution chain details are displayed in a tree structure, showing the nested call relationship of the target method and the execution time of each node; Step S5 also includes a data lifecycle management step: The monitoring process data is stored asynchronously and automatically cleaned up after the corresponding monitoring result data is persisted. The files corresponding to the monitoring results data are organized by date, and the scattered files from the previous day are merged into a single file after the day crosses over. Expired files are also cleaned up periodically according to the configured retention time.

[0062] A preferred embodiment of the annotation-driven thread runtime observability monitoring system of the present invention includes the following modules: The thread monitoring annotation registration module is used to define and register a thread monitoring annotation (ThreadMonitor) in the application system code. The thread monitoring annotation is used to declaratively mark the target methods that need to be monitored. This step serves as the entry point for monitoring, achieving zero code intrusion through declarative annotations. The `ThreadMonitor` annotation includes configurable attributes (such as `name`, `type`, and `key`), allowing developers to flexibly tag target methods according to business needs. For example, the `name` attribute is used to identify the operation in the monitoring interface, and the `key` attribute can be combined with the resource ID to distinguish different instances, ensuring monitoring accuracy. Annotation registration is completed through Spring Boot's auto-configuration mechanism, loaded when the application starts, eliminating the need for manual coding and significantly reducing integration complexity. This design embodies the "convention over configuration" principle, improving maintainability.

[0063] The target method execution interception module is used to intercept the execution of the target method during the runtime of the application system using aspect-oriented programming techniques. The interception layer is implemented based on Aspect-Oriented Programming (AOP). Aspect classes are predefined to intercept all target methods annotated with `@ThreadMonitor`, automatically injecting monitoring logic before and after the target method's execution. AOP frameworks (such as Spring AOP) dynamically generate proxy objects at runtime, ensuring transparent interception and avoiding pollution of business code. The key to this step lies in the precise definition of the pointcut, targeting only annotated methods to minimize performance overhead.

[0064] An observability data acquisition module is used to automatically inject monitoring logic through AOP aspects before and after the execution of the target method, and to collect observability data of the thread executing the target method during runtime through the monitoring logic; the observability data includes at least thread link identifier, execution time, and method context information; Data acquisition is the core process, executed automatically through AOP aspects. The acquired data includes thread link identifiers, execution time, and method context information. The generation and management of unique link identifiers are implemented through SDK methods, ensuring transmission between synchronous and asynchronous threads (e.g., through ThreadLocal and asynchronous context passing mechanisms). This solves the problem of fragmented synchronous / asynchronous links in traditional monitoring. The acquisition process also involves data structures (such as thread basic information entities and link detail entities) that record nested call relationships in a tree structure, laying the foundation for visual analysis.

[0065] The core interception component is an aspect class based on Aspect-Oriented Programming (AOP), which is predefined and registered in the application context. This aspect is configured to inject monitoring logic before and after the execution of the target method, and its pointcut is defined as all target methods marked with the specified annotation (ThreadMonitor). When the application starts, this aspect is automatically activated, thus establishing a transparent and non-intrusive monitoring and interception layer throughout the entire system runtime.

[0066] Thread Basic Information Entity: This data structure records a summary of a complete thread execution process. Core fields include: unique identifier of the thread execution chain, name of the business monitoring point, execution thread ID, execution status, total time consumption, creation time, etc. This structure is used to track the overall lifecycle and status of thread execution.

[0067] Thread Call Details Entity: This data structure records every detailed step in the thread's execution process (i.e., each monitored method call). Core fields include: unique node identifier, associated sibling node identifiers, method signature, start time, end time, and node execution status. Multiple nodes of this type are associated through sibling relationships, allowing for the reconstruction of a complete, nested method call chain in a tree structure.

[0068] The data processing and storage module is used to process the collected observable data and store it in a non-volatile persistent manner according to a preset configurable strategy. A configurable strategy balances monitoring granularity with system performance. Intelligent sampling strategies include continuous recording, initial trigger recording, and interval recording modes. Interval recording uses a cooldown time formula (T=T_base*2^(n-1)) to avoid redundant data storage. A multi-level storage structure is divided into a process data layer (memory, Redis, or file) and a result data layer (local file or FTP), ensuring flexible data caching and persistence. Process data is stored asynchronously to avoid blocking the main thread; result data is organized by date, and an automatic merging and cleanup of expired files is achieved through a monitoring mechanism, enabling automated lifecycle management.

[0069] The data management module provides a visual interface for displaying and querying the real-time running status of threads and historical execution chain details in the application system.

[0070] The visual interface is the main interaction point for operations and maintenance personnel. The interface displays the operating metrics of synchronous and asynchronous thread pools in real time (such as the number of active threads and queue backlog), and presents the details of historical execution links in a tree structure, which facilitates quick identification of bottlenecks.

[0071] The core of this invention is to transparently collect and visualize the entire execution process of synchronous and asynchronous threads within an application system by declaratively adding thread monitoring annotations to the target method and combining this with a context-aware thread tracing mechanism. Based on Aspect-Oriented Programming (AOP) technology, this solution automatically embeds monitoring probes (monitoring logic) before and after the target method execution, capturing key information such as thread chain identifiers, execution time, and method context information. It also supports intelligent sampling and persistence of monitoring data based on configurable strategies (such as time thresholds and abnormal conditions), and finally outputs structured thread execution records through a unified observation interface, providing data support for performance diagnosis, bottleneck location, and resource optimization.

[0072] In practical implementation, to enhance flexibility and configurability, a unified configuration attribute class was defined. This class centrally manages all adjustable parameters, such as the overall on / off switch for monitoring functions, performance thresholds for link detail records, data storage modes, slow link recording strategies, and the maximum number of link records. Monitoring behavior can be dynamically adjusted via an external configuration file (such as application.yml) without modifying the code. Furthermore, detailed Javadoc comments were added to key classes and methods to explain their design intent, functional logic, and parameter meanings, ensuring code readability and maintainability.

[0073] This invention offers high scalability in link monitoring, primarily achieved through inheriting the core abstract class and implementing specific interfaces. The entire framework adopts an object-oriented design philosophy, defining clear extension points and contracts, allowing developers to deeply customize the data model, processing logic, storage methods, and final display of the monitoring link without modifying existing stable logic.

[0074] During the application system's operation, a visual interface can be opened to view the running status of the synchronization thread, such as... Figure 3 By analyzing the number of concurrently executing threads and their execution duration, the system can identify and address stuttering and slow-running threads. For slow-running threads, the "View Thread" button can be clicked to view the detailed execution path and analyze the cause and duration of the stutter. Alternatively, asynchronous thread monitoring can be enabled to analyze thread pool usage and what operations asynchronous threads within the system are performing.

[0075] In the thread monitoring annotation registration module, the thread monitoring annotation includes one or more of the following configurable attributes: The name attribute is used to identify the name of the monitored operation, that is, to identify and display the monitored method or operation in the monitoring system. The `type` attribute is used to categorize monitoring operations, such as by business module or technology type. The description attribute is used to provide a detailed description, that is, to supplement the explanation of the specific function or business meaning of the monitoring point; The key attribute is used to uniquely identify operation instances, that is, to distinguish different instances of the same operation in the monitoring system, such as using resource ID to distinguish different resource operations. The `extendColumns` array is used to record additional business attributes, i.e., to record additional business attributes or dimension information related to monitoring operations. The `handler` property is used to customize the creation and expansion operations of monitoring data. Specifically, it defines how to create monitoring data objects and how to perform expansion operations when the monitoring aspect is executed.

[0076] In the observability data acquisition module, the acquisition of observable data further includes: Generate and manage a unique link identifier for the execution of the thread; A software development kit (SDK) approach is used to ensure that the unique link identifier is passed between synchronous threads and asynchronous threads derived from them, thereby associating synchronous and asynchronous execution links.

[0077] To implement the monitoring function, a set of core SDK (Software Development Kit) methods were designed. These methods are built into aspects and related utility classes, including: 1) Context initialization and passing method: Used to generate and manage a unique identifier for each monitoring link, and to ensure that the identifier is correctly passed between synchronous and asynchronous threads.

[0078] 2) Information storage and persistence methods: Based on the configured process data storage mode (such as memory, file or Redis), provide corresponding data writing, reading and cleaning functions, and based on the configured result data storage mode (such as local file or FTP file), provide corresponding data persistence.

[0079] 3) Performance data acquisition and calculation auxiliary methods: used to collect the start and end times of method execution, calculation time, and determine whether threshold conditions such as slow link recording are triggered.

[0080] When a thread first enters an aspect, thread information is recorded. Each time a thread enters an aspect, the thread execution chain is recorded according to the configuration. Thread pools or other asynchronous threads need to record the execution of asynchronous threads in synchronous threads through method instrumentation. The corresponding chain identifier needs to be obtained through SDK methods, and then the corresponding identifier needs to be set to the asynchronous thread by calling SDK methods at the beginning of thread execution. Asynchronous thread enhancement markers can also be added before and after asynchronous thread execution by calling SDK, and the start and end of asynchronous thread execution can be displayed in the chain information.

[0081] In the data processing and storage module, the configurable strategy includes an intelligent sampling strategy, which includes one or more of the following modes: Continuous recording mode; For the same monitoring key, only the first slow link triggered will be recorded; For slow link records of the same monitoring key, an interval recording mode based on the cooling time T is adopted; the formula for calculating the cooling time T is: T=T_base* 2^(n-1), where T_base is the configured base time interval, and n is the cumulative number of slow link records triggered for the same monitoring key since the application system started; the monitoring key and key attributes both refer to identifiers used to uniquely distinguish monitoring operation instances; In a production environment, it is difficult to pinpoint the cause and solution for slow execution. When customers provide feedback, there is no good troubleshooting path. Specific rules can be set to perform slow link statistics. During thread monitoring, it can be decided whether to record the link based on the overall thread execution time or the execution time of a single method. Currently, there are three methods: the first is continuous recording, the second is recording only once, and the third is recording at time intervals.

[0082] The second and third schemes are introduced because link information still consumes some space resources. They can be used when space resources are limited. Considering that large loops may consume a large amount of meaningless information, a maximum number of links can be configured; if this number is exceeded, subsequent links will not be recorded. Daily alarm pushes can also be configured. For alarm anomalies, corresponding slow link files can be retrieved, analyzed, and the causes of system lag and slowness can be identified, allowing for targeted system optimization and performance improvement.

[0083] The persistent storage adopts a multi-level storage structure, including: The first storage layer is used for temporarily caching monitoring process data and can be configured as memory, Redis, or local files. Different solutions can be adopted for different server configurations. For a single machine with large memory, memory storage can be considered. For two servers, Redis and the system, where system memory resources are limited, Redis can be considered. For cases where memory resources are limited, disk space resources are sufficient, and IO performance is good, file storage can be considered. The process data storage uses asynchronous threads so as not to affect the execution of the main business. After the monitoring result data is recorded, the corresponding thread resources used and the corresponding process data will be automatically cleaned up.

[0084] The second storage layer, used to finally save the monitoring results data, is configured as a local file system or FTP server. The monitoring results data is stored in txt file format; each monitoring link is stored separately in a folder for the current day. A storage monitoring mechanism determines whether the data spans multiple days. If it does, the scattered link files from the previous day will be merged into a single txt file for easier analysis. Furthermore, expired files will be cleaned up according to the configured retention time to save system disk space.

[0085] In the data management module, the real-time running status includes the running metrics of the synchronous thread pool and the asynchronous thread pool; the historical execution chain details are displayed in a tree structure, showing the nested call relationship of the target method and the execution time of each node; The data management module is also used for data lifecycle management steps: The monitoring process data is stored asynchronously and automatically cleaned up after the corresponding monitoring result data is persisted. The files corresponding to the monitoring results data are organized by date, and the scattered files from the previous day are merged into a single file after the day crosses over. Expired files are also cleaned up periodically according to the configured retention time.

[0086] In summary, the advantages of this invention are: 1. By defining and registering a thread monitoring annotation in the application system code to declaratively mark the target method that needs to be monitored; during application system runtime, the execution of the target method is intercepted using aspect-oriented programming (AOP); before and after the execution of the target method, monitoring logic is automatically injected through AOP aspects, and observable data, including at least thread link identifiers, execution time, and method context information, is collected during the execution of the thread executing the target method; the collected observable data is processed and stored in a non-volatile persistent manner according to a preset configurable strategy; a visual interface is provided to display and query the real-time running status and historical execution link details of threads in the application system; that is, by defining thread monitoring annotations and utilizing AOP technology, thread monitoring is automatically intercepted in a low-intrusive manner. The system marks target methods and collects fine-grained runtime data such as thread link identifiers, execution time, and method context information before and after their execution. This transforms the internal execution state of threads into visible, analyzable, and observable data, greatly improving the visibility of thread-level runtime states. The SDK ensures the transmission of link identifiers between synchronous and asynchronous threads, constructing a complete cross-thread execution link view and solving the problem of fragmented monitoring between synchronous and asynchronous links. Combined with configurable intelligent sampling and multi-level storage strategies, it significantly reduces performance overhead and operational risks while ensuring monitoring effectiveness. This allows operations personnel to gain real-time insight into thread states and accurately trace back historical issues through a visual interface, ultimately enabling online fault location without code modification and ensuring the continuous high performance and high availability of application systems.

[0087] 2. The annotation-driven approach allows developers to define the target methods to be monitored through declarative tags, which greatly simplifies the integration process of monitoring code. Compared with the traditional approach of hard-coding monitoring logic in business code, this annotation-based approach achieves non-intrusive monitoring, reduces code coupling, and makes monitoring functions easy to add to existing systems without modifying core business logic, thereby improving development efficiency and system maintainability.

[0088] 3. By using aspect-oriented programming (AOP) technology, monitoring logic is automatically embedded before and after the execution of the target method. Observable data such as link identifiers, execution time, and context information can be collected during thread execution without manual intervention. This automated collection mechanism not only reduces human error but also improves the real-time performance and accuracy of monitoring. It is particularly suitable for high-concurrency environments, can quickly identify performance bottlenecks, and improve system operation and maintenance efficiency.

[0089] 4. Generate and manage unique link identifiers during data acquisition, and ensure that the identifiers are passed between synchronous and asynchronous threads through SDK methods. This enables the synchronous and asynchronous execution in complex call chains to be effectively correlated. This design solves the problem of difficult asynchronous thread tracking in traditional monitoring, provides a more comprehensive view of the execution link, facilitates developers in diagnosing cross-thread problems, and improves system debuggability and reliability.

[0090] 5. Configurable strategies (such as intelligent sampling mode) and multi-level storage structure enable monitoring data to be processed flexibly according to actual needs. For example, a cooldown time mechanism can be used to reduce redundant data storage and avoid resource waste. This intelligent strategy not only optimizes storage efficiency but also allows users to adjust the monitoring granularity according to business scenarios, enhancing the adaptability and scalability of the solution while reducing long-term storage costs.

[0091] 6. The system displays real-time running status and historical execution details through a visual interface, presenting the call relationships in a tree structure, making the monitoring data easy to understand and analyze. In addition, data lifecycle management functions (such as asynchronous storage, file merging, and periodic cleanup) automate the data maintenance process, reduce manual intervention, ensure the rational use of storage resources, and improve the overall operability and sustainability of the system.

[0092] 7. By defining detailed configurable attributes (such as name, type, extendColumns, etc.) of thread monitoring annotations, the definition of monitoring behavior is highly parameterized. This allows developers to meet the monitoring needs of different business scenarios simply by adjusting annotation attributes, without modifying the underlying monitoring framework or AOP aspect logic (e.g., setting different monitoring granularities for methods of different importance). In particular, the extendColumns and handler attributes provide powerful custom extension capabilities for monitoring data, enabling the solution to easily adapt to future business changes and possessing good scalability.

[0093] 8. Data lifecycle management steps (such as organizing files by date, merging across days, and periodic cleanup) automate the monitoring data archiving process, organizing scattered data files into an orderly manner. This not only facilitates the querying and backtracking of historical data (e.g., quickly locating a problem on a specific day), but also automatically solves storage space management problems, preventing expired data from expanding indefinitely. This transforms massive monitoring data from a "storage burden" into a truly manageable and exploitable "data asset," enhancing its long-term value.

[0094] 9. By combining innovative annotation-driven and AOP aspects, low-intrusion, declarative monitoring of application thread observability is achieved. Its core advantages are that it not only greatly simplifies the integration and expansion of monitoring functions, but also efficiently balances monitoring granularity and system performance overhead through intelligent sampling and multi-level storage strategies. Furthermore, it ensures the visibility of synchronous and asynchronous call links with a complete link context passing mechanism. Finally, through automated data lifecycle management and an intuitive visualization interface, it provides users with integrated operation and maintenance support from real-time diagnosis to historical backtracking, thereby significantly improving the maintainability, debuggability, and operational reliability of complex distributed systems.

[0095] 10. Zero-code intrusion is achieved through AOP, solving the intrusiveness problem; intelligent sampling balances monitoring overhead, solving the performance problem; flexible caching, persistence, and lifecycle management of monitoring data are achieved through a multi-level storage structure of thread pool queue -> memory / file / redis -> file / database, solving the data storage and management problem; and a visual interface and multi-dimensional dashboard significantly reduce the understanding and usage threshold for operation and maintenance personnel and developers, solving the usability problem.

[0096] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A thread runtime observability monitoring method based on annotation-driven methods, characterized in that: Includes the following steps: Step S1: In the application system code, define and register a thread monitoring annotation, which is used to declaratively mark the target method that needs to be monitored; Step S2: When the application system is running, intercept the execution of the target method using aspect-oriented programming (AOP) techniques; Step S3: Before and after the execution of the target method, monitoring logic is automatically injected through AOP aspects. The monitoring logic collects observability data of the thread executing the target method during runtime. The observable data includes at least the thread chain identifier, execution time, and method context information. Step S4: Process the collected observability data and store it in a non-volatile persistent manner according to a preset configurable strategy; Step S5: Provide a visual interface to display and query the real-time running status of threads in the application system and the details of historical execution links.

2. The annotation-driven thread runtime observability monitoring method as described in claim 1, characterized in that: In step S1, the thread monitoring annotation includes one or more of the following configurable attributes: The name attribute is used to identify the name of the monitoring operation; The `type` attribute is used to categorize monitoring operations; The description attribute is used to provide a detailed description; The key attribute is used to uniquely identify the operation instance; The `extendColumns` array is used to record additional business attributes. The `handler` property is used for custom monitoring data creation and extension operations.

3. The annotation-driven thread runtime observability monitoring method as described in claim 1, characterized in that: In step S3, the acquisition of observability data further includes: Generate and manage a unique link identifier for the execution of the thread; A software development kit (SDK) approach is used to ensure that the unique link identifier is passed between synchronous threads and asynchronous threads derived from them, thereby associating synchronous and asynchronous execution links.

4. The annotation-driven thread runtime observability monitoring method as described in claim 1, characterized in that: In step S4, the configurable strategy includes an intelligent sampling strategy, which includes one or more of the following modes: Continuous recording mode; For the same monitoring key, only the first slow link triggered will be recorded; For slow link records of the same monitoring key, an interval recording mode based on the cooling time T is adopted; the formula for calculating the cooling time T is: T=T_base* 2^(n-1), where T_base is the configured base time interval, and n is the cumulative number of times slow link records are triggered for the same monitoring key since the application system started. The persistent storage adopts a multi-level storage structure, including: The first storage layer used for temporarily caching monitoring process data can be configured as memory, Redis, or local files. The second storage layer, used to ultimately store the monitoring results data, is configured as a local file system or an FTP server.

5. The annotation-driven thread runtime observability monitoring method as described in claim 1, characterized in that: In step S5, the real-time running status includes the running metrics of the synchronous thread pool and the asynchronous thread pool; the historical execution chain details are displayed in a tree structure, showing the nested call relationship of the target method and the execution time of each node; Step S5 also includes a data lifecycle management step: The monitoring process data is stored asynchronously and automatically cleaned up after the corresponding monitoring result data is persisted. The files corresponding to the monitoring results data are organized by date, and the scattered files from the previous day are merged into a single file after the day crosses over. Expired files are also cleaned up periodically according to the configured retention time.

6. An annotation-driven thread runtime observability monitoring system, characterized in that: Includes the following modules: The thread monitoring annotation registration module is used to define and register a thread monitoring annotation in the application system code. The thread monitoring annotation is used to declaratively mark the target method that needs to be monitored. The target method execution interception module is used to intercept the execution of the target method during the runtime of the application system using aspect-oriented programming techniques. An observability data acquisition module is used to automatically inject monitoring logic through AOP aspects before and after the execution of the target method, and to collect observability data of the thread executing the target method during runtime through the monitoring logic; the observability data includes at least thread link identifier, execution time, and method context information; The data processing and storage module is used to process the collected observable data and store it in a non-volatile persistent manner according to a preset configurable strategy. The data management module provides a visual interface for displaying and querying the real-time running status of threads and historical execution chain details in the application system.

7. The annotation-driven thread runtime observability monitoring system as described in claim 6, characterized in that: In the thread monitoring annotation registration module, the thread monitoring annotation includes one or more of the following configurable attributes: The name attribute is used to identify the name of the monitoring operation; The `type` attribute is used to categorize monitoring operations; The description attribute is used to provide a detailed description; The key attribute is used to uniquely identify the operation instance; The `extendColumns` array is used to record additional business attributes. The `handler` property is used for custom monitoring data creation and extension operations.

8. The annotation-driven thread runtime observability monitoring system as described in claim 6, characterized in that: In the observability data acquisition module, the acquisition of observable data further includes: Generate and manage a unique link identifier for the execution of the thread; A software development kit (SDK) approach is used to ensure that the unique link identifier is passed between synchronous threads and asynchronous threads derived from them, thereby associating synchronous and asynchronous execution links.

9. The annotation-driven thread runtime observability monitoring system as described in claim 6, characterized in that: In the data processing and storage module, the configurable strategy includes an intelligent sampling strategy, which includes one or more of the following modes: Continuous recording mode; For the same monitoring key, only the first slow link triggered will be recorded; For slow link records of the same monitoring key, an interval recording mode based on the cooling time T is adopted; the formula for calculating the cooling time T is: T=T_base* 2^(n-1), where T_base is the configured base time interval, and n is the cumulative number of times slow link records are triggered for the same monitoring key since the application system started. The persistent storage adopts a multi-level storage structure, including: The first storage layer used for temporarily caching monitoring process data can be configured as memory, Redis, or local files. The second storage layer, used to ultimately store the monitoring results data, is configured as a local file system or an FTP server.

10. The annotation-driven thread runtime observability monitoring system as described in claim 6, characterized in that: In the data management module, the real-time running status includes the running metrics of the synchronous thread pool and the asynchronous thread pool; the historical execution chain details are displayed in a tree structure, showing the nested call relationship of the target method and the execution time of each node; The data management module is also used for data lifecycle management steps: The monitoring process data is stored asynchronously and automatically cleaned up after the corresponding monitoring result data is persisted. The files corresponding to the monitoring results data are organized by date, and the scattered files from the previous day are merged into a single file after the day crosses over. Expired files are also cleaned up periodically according to the configured retention time.

Images