Zero-intrusion service monitoring method and device, storage medium and computer equipment

Abstract

According to the zero-intrusion service monitoring method and device, the storage medium and the computer equipment provided by the invention, registration is completed in the configuration center through the monitoring Agent, and the latest registry is acquired in real time, so that dynamic management of the version of the DSL configuration file and dynamic updating of the monitoring rule are realized. When the version of the DSL configuration file in the service is updated, the monitoring Agent can automatically detect that the version is inconsistent, obtains the latest target DSL configuration file, and dynamically updates the monitoring rule in the DSL rule engine according to the target DSL configuration file. The process does not need to modify codes or re-publish services, so that the updating process of the monitoring rule is greatly simplified. In addition, according to the method, the updated monitoring rule can be used for carrying out reconversion on the currently loaded target class, and monitoring data is sent to a corresponding back-end system after monitoring implantation is carried out on the target method, so that the real-time performance and accuracy of monitoring are ensured.

Description

Technical Field

[0001] This application relates to the field of distributed system monitoring technology, and in particular to a zero-intrusion business monitoring method, device, storage medium and computer equipment. Background Art

[0002] Given the rapid development of e-commerce, traditional monitoring solutions are no longer sufficient to meet business needs, primarily due to the following key pain points:

[0003] 1. Rigid monitoring: Traditional monitoring solutions often require code modification and redeployment, a process that is not only cumbersome but also unable to adapt to the rapid iteration needs of e-commerce businesses;

[0004] 2. Fragmented Management: In a microservice architecture, monitoring policies are often scattered across various services, lacking unified control. Furthermore, this fragmented management approach not only increases operational complexity but also complicates the collection and analysis of monitoring data.

[0005] 3. Waste of resources: In e-commerce operations, even after a product is taken down, redundant monitoring code still needs to be maintained, which not only wastes resources but also increases the burden of operations and maintenance.

[0006] 4. Weak emergency response capability: In the event of sudden traffic surges, traditional monitoring solutions cannot quickly enable or disable monitoring, which may affect business operations.

[0007] In summary, existing monitoring solutions suffer from poor monitoring flexibility and low monitoring efficiency. Summary of the Invention

[0008] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the technical deficiencies of poor monitoring flexibility and low monitoring efficiency in existing monitoring schemes.

[0009] This application provides a zero-intrusion business monitoring method. The method is applied to monitoring agents integrated into various services within a microservice architecture. Each monitoring agent is registered in a configuration center. The method includes:

[0010] The latest registry is obtained from the configuration center. The registry records all services and their corresponding at least one DSL configuration file version. Each DSL configuration file version is configured with a corresponding DSL configuration file. Each DSL configuration file records specific monitoring rules.

[0011] The version of the DSL configuration file currently used by this service, recorded in the registry, is compared with the version of the DSL configuration file currently running in the cache of this service. If the versions are inconsistent, the target DSL configuration file corresponding to the version of the DSL configuration file currently used is obtained.

[0012] The monitoring rules in the pre-loaded DSL rule engine are dynamically updated according to the target DSL configuration file, and the target class to be reconverted and the target method to be implanted for monitoring are determined according to the updated monitoring rules.

[0013] After re-transforming the currently loaded, untransformed target class using the updated monitoring rules and implanting monitoring into the target method, the service obtains the monitoring data generated under the updated monitoring rules and sends the monitoring data to the corresponding backend system.

[0014] Optionally, comparing the DSL profile version currently used by the service recorded in the registry with the running DSL profile version cached by the service includes:

[0015] Obtain the list of available versions of this service recorded in the registry, wherein the list of versions includes the currently used DSL configuration file version and the DSL configuration file version to be used;

[0016] Extract the currently used DSL profile version from the version list and extract the running DSL profile version from the service cache;

[0017] Compare the currently used DSL configuration file version with the running DSL configuration file version.

[0018] Optionally, obtaining the target DSL configuration file corresponding to the currently used DSL configuration file version includes:

[0019] Determine whether the DSL configuration file version currently used by this service is recorded in the registry among all cached DSL configuration file versions;

[0020] If it exists, then retrieve the target DSL configuration file corresponding to the currently used DSL configuration file version from the cache;

[0021] If it does not exist, then obtain the target DSL configuration file corresponding to the currently used DSL configuration file version from the configuration center.

[0022] Optionally, before dynamically updating the monitoring rules in the pre-loaded DSL rule engine according to the target DSL configuration file, the method further includes:

[0023] Determine whether temporary overwriting is enabled for the target DSL configuration file based on the registry;

[0024] If enabled, the coverage configuration for enabling temporary coverage is obtained from the configuration center, the coverage configuration is merged with the target DSL configuration file, and the monitoring rules in the pre-loaded DSL rule engine are dynamically updated according to the merged target DSL configuration file.

[0025] If not enabled, the monitoring rules in the pre-loaded DSL rule engine will be dynamically updated directly based on the target DSL configuration file.

[0026] Optionally, the step of monitoring the target method using updated monitoring rules includes:

[0027] When the service detects that it is calling the target method, the updated monitoring rules are used to monitor and inject the target method through the monitoring interceptor.

[0028] Optionally, the method further includes:

[0029] The monitoring interceptor creates a Span at the method entry point of the target method and passes a Trace ID via HTTP headers / thread context. The Span and the Trace ID are generated in advance in the critical logs by ZipKin.

[0030] The monitoring interceptor records the monitoring data during the execution of the target method, and after capturing and marking the error span, terminates the span.

[0031] Optionally, sending the monitoring data to the corresponding backend system includes:

[0032] Determine the monitoring type of the monitoring data;

[0033] According to the pre-configured distribution strategy, the monitoring data is sent to the corresponding backend system according to the monitoring type.

[0034] This application also provides a zero-intrusion business monitoring device, which is applied to monitoring agents integrated in various services under a microservice architecture. Each monitoring agent is registered in a configuration center. The device includes:

[0035] The registry acquisition module is used to obtain the latest registry from the configuration center. The registry records all services and their corresponding at least one DSL configuration file version. Each DSL configuration file version is configured with a corresponding DSL configuration file, and each DSL configuration file records specific monitoring rules.

[0036] The configuration file acquisition module is used to compare the version of the DSL configuration file currently used by this service recorded in the registry with the version of the DSL configuration file currently running cached by this service. If the versions are inconsistent, the target DSL configuration file corresponding to the version of the currently used DSL configuration file is acquired.

[0037] The dynamic update module is used to dynamically update the monitoring rules in the pre-loaded DSL rule engine according to the target DSL configuration file, and determine the target class to be reconverted and the target method to be implanted for monitoring according to the updated monitoring rules.

[0038] The business monitoring module is used to re-transform the currently loaded target class that has not been re-transformed using the updated monitoring rules, and after monitoring is implanted into the target method, obtain the monitoring data generated by this service under the updated monitoring rules, and send the monitoring data to the corresponding backend system.

[0039] This application also provides a computer-readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the zero-intrusion business monitoring method as described in any of the above embodiments.

[0040] This application also provides a computer device, including: one or more processors, and memory;

[0041] The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the zero-intrusion service monitoring method as described in any of the above embodiments.

[0042] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0043] This application provides a zero-intrusion business monitoring method, apparatus, storage medium, and computer equipment. The method involves a monitoring agent registering in a configuration center and obtaining the latest registry entries in real time, thereby achieving dynamic management of DSL configuration file versions and dynamic updates of monitoring rules. In practice, when the DSL configuration file version in this service is updated, the monitoring agent automatically detects the version inconsistency and obtains the latest target DSL configuration file. Subsequently, it dynamically updates the monitoring rules in the pre-loaded DSL rule engine based on the target DSL configuration file. This process requires no code modification or service redeployment, greatly simplifying the monitoring rule update process. Furthermore, this application can also use the updated monitoring rules to re-transform the currently loaded target class and inject monitoring into the target methods before sending the monitoring data to the corresponding backend system. This method has advantages such as simple implementation, flexible monitoring, and high efficiency, and is suitable for business monitoring scenarios under various microservice architectures. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 A flowchart illustrating a zero-intrusion service monitoring method provided in this application embodiment;

[0046] Figure 2 This is a schematic diagram illustrating the process of re-converting the target class, injecting monitoring into the target method, and obtaining monitoring data using the updated monitoring rules provided in this embodiment of the application.

[0047] Figure 3 This is a schematic diagram illustrating the structure of sending different types of monitoring data to different backend systems, provided in an embodiment of this application.

[0048] Figure 4 A schematic diagram of a zero-intrusion business monitoring device provided in this application embodiment;

[0049] Figure 5 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0050] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] In one embodiment, such as Figure 1 As shown, Figure 1 This is a flowchart illustrating a zero-intrusion business monitoring method provided in an embodiment of this application. This application provides a zero-intrusion business monitoring method, which is applied to monitoring agents integrated into various services under a microservice architecture. Each monitoring agent is registered in a configuration center. The method may include:

[0052] S110: Obtain the latest registry from the configuration center. The registry records all services and their corresponding at least one DSL configuration file version. Each DSL configuration file version is configured with a corresponding DSL configuration file, and each DSL configuration file records specific monitoring rules.

[0053] In this step, the monitoring agents integrated into each service first communicate with the configuration center. As the centralized management point for all services and their monitoring configuration information, the configuration center ensures that all services obtain the latest monitoring rules. The registry, the core data structure of the configuration center, records in detail the version of each service and its corresponding DSL configuration file. Each DSL configuration file version is associated with a specific DSL configuration file, and each DSL configuration file records the specific monitoring rules. These monitoring rules define how to monitor the service's operational status, including but not limited to performance metrics and anomaly detection. By obtaining the latest registry from the configuration center, the monitoring agent ensures that it has the latest monitoring rule information, thus providing a foundation for subsequent dynamic updates and monitoring implementation.

[0054] In this application, the monitoring agent can obtain the latest registry information from the configuration center either proactively or after receiving a registry update notification from the configuration center. Of course, the monitoring agent can also obtain the latest registry information from the configuration center using other methods such as scheduled fetching and long polling to ensure timely access to the latest registry information. In practical implementation, the monitoring agent can choose an appropriate method to obtain the registry information based on its operating environment and business needs. Furthermore, to further improve the real-time performance and accuracy of monitoring, this application can also employ distributed caching and other technologies to accelerate the registry acquisition and update process.

[0055] Before obtaining the latest registry, the monitoring agent in this application needs to register in the monitoring center. Each service's monitoring agent can register with the configuration center via the Dubbo service for unified management by the monitoring backend. Furthermore, the configuration center in this application can be a highly configurable and scalable service registration and discovery platform, supporting switching between AP and CP modes. It can provide application with service registration and discovery capabilities, building a dynamic service mesh for cloud-native applications, while ensuring the secure and reliable deployment of service instances to the production environment. In specific implementations, the configuration center can be built based on open-source service registration and discovery components such as Nacos, Eureka, Consul, and Zookeeper to meet business needs in different scenarios. In addition, to further improve the availability and stability of the configuration center, this application can also employ multi-node deployment, load balancing, and other technical means to ensure high availability and data consistency.

[0056] Furthermore, the DSL configuration file versions recorded in the registry of this application refer to different iterative versions of the DSL (Domain Specific Language) configuration file. These versions record different states or changes of monitoring rules, enabling the monitoring agent to flexibly adjust according to the latest monitoring needs. Each DSL configuration file version is associated with its corresponding DSL configuration file, which defines monitoring rules with specific syntax and structure. These rules are the basis for the monitoring agent to perform monitoring tasks. By maintaining multiple DSL configuration file versions, this application can achieve version management of monitoring rules, ensuring that the monitoring agent can accurately obtain the latest version when updating monitoring rules, thereby avoiding monitoring failures or errors due to version inconsistencies. In addition, this version management mechanism also helps to realize the rollback and comparison of monitoring rules, further improving the stability and maintainability of the monitoring system.

[0057] S120: Compare the DSL configuration file version currently used by this service recorded in the registry with the running DSL configuration file version cached by this service. If the versions are inconsistent, obtain the target DSL configuration file corresponding to the currently used DSL configuration file version.

[0058] In this step, after obtaining the latest registry from the configuration center via S110, this application can compare the version of the DSL configuration file currently used by this service recorded in the registry with the version of the running DSL configuration file cached by this service. If the comparison finds that the version currently used recorded in the registry is inconsistent with the version of the running DSL configuration file cached by this service, the target DSL configuration file corresponding to the currently used version can be obtained, and the monitoring rules of this service can be dynamically updated using the target DSL configuration file.

[0059] Specifically, the monitoring agent in this application compares the version of the DSL configuration file currently used by the service, recorded in the registry, with the version of the DSL configuration file currently running in its own cache. If the two versions are inconsistent, it indicates that new monitoring rules need to be updated. In this case, the monitoring agent can proactively retrieve the target DSL configuration file corresponding to the currently used DSL configuration file version from the configuration center or from the service cache. This process ensures that the monitoring agent can obtain and apply the latest monitoring rules in a timely manner, thereby maintaining the accuracy and effectiveness of monitoring.

[0060] It is understood that the registry of this application records all services and their corresponding at least one DSL configuration file version. These DSL configuration file versions can be file versions specific to a particular service or file versions shared by multiple services, and each service can also have one or more DSL configuration file versions. To adapt to various business scenarios, such as large-scale promotional events or temporary removals, this application can further divide the DSL configuration file version of each service into a currently used file version and a file version to be used. The currently used file version refers to the DSL configuration file version that is currently running and in effect, while the file version to be used refers to the DSL configuration file version that is not yet in effect but is expected to be switched to at some point in the future. Through this division, this application can achieve pre-release and canary updates of monitoring rules, further improving the flexibility and stability of the monitoring system.

[0061] Each service cache in this application can also store one or more DSL configuration file versions and their corresponding DSL configuration files for quick retrieval and comparison when needed. During the comparison process, if an older version is found in the cache, the monitoring agent will prioritize retrieving the latest target DSL configuration file from the configuration center to ensure the accuracy and timeliness of the monitoring rules. This mechanism fully considers the dynamics and flexibility of services in a microservice architecture, enabling monitoring rule updates to keep pace with business changes and providing strong support for the stable operation of the business.

[0062] S130: Dynamically update the monitoring rules in the pre-loaded DSL rule engine according to the target DSL configuration file, and determine the target class to be reconverted and the target method to be implanted for monitoring based on the updated monitoring rules.

[0063] In this step, after obtaining the target DSL configuration file via S120, the monitoring agent can use this file to dynamically update the monitoring rules in the pre-loaded DSL rule engine. This step is a crucial part of the monitoring method, enabling the monitoring rules to be updated without interrupting service operation. The dynamic update process includes parsing the target DSL configuration file, generating new sets of monitoring rules, and applying these rule sets to the DSL rule engine. Thus, when the service is running, the monitoring agent can monitor the service according to the latest monitoring rules.

[0064] Specifically, when dynamically updating the monitoring rules in the pre-loaded DSL rule engine based on the target DSL configuration file, this application first parses the target DSL configuration file to extract the monitoring rules. Then, these monitoring rules are compared with the existing monitoring rules in the DSL rule engine to identify rules that need to be updated or added. Next, these updated or added rules are applied to the DSL rule engine, replacing or supplementing the original monitoring rules. This process ensures that the monitoring rules can reflect changes in business needs and monitoring strategies in real time, improving the accuracy and flexibility of monitoring.

[0065] After dynamically updating the monitoring rules, the monitoring agent also needs to determine the target classes to be re-transformed and the target methods to be monitored, based on the updated rules. The target classes refer to the classes that need to be monitored, while the target methods are the specific methods within those classes. Through techniques such as dynamic proxies, the monitoring agent can inject monitoring into the target methods. This process involves inserting monitoring code at the method's entry and exit points to collect runtime data such as execution time, return values, and exception information.

[0066] S140: After re-transforming the currently loaded target class that has not been re-transformed using the updated monitoring rules, and injecting monitoring into the target method, obtain the monitoring data generated by this service under the updated monitoring rules, and send the monitoring data to the corresponding backend system.

[0067] In this step, after determining the target class to be re-converted and the target method to be monitored according to the updated monitoring rules in S130, this application can use the updated monitoring rules to re-convert the currently loaded target class that has not been re-converted, and to monitor and implant the target method. In this way, the monitoring data generated by this service under the updated monitoring rules can be obtained and sent to the corresponding backend system.

[0068] Indicatively, such as Figure 2 As shown, Figure 2 This is a schematic diagram illustrating the process of re-converting the target class, injecting monitoring into the target method, and obtaining monitoring data using the updated monitoring rules provided in this embodiment of the application. Figure 2 During the refactoring and monitoring implantation process, the monitoring agent utilizes Java's proxy mechanism or bytecode enhancement technology to add monitoring logic to the target class and methods without altering their original implementations. This monitoring logic captures key information before and after method calls, such as parameter values, return values, and exception information, and encapsulates this information into monitoring data. Subsequently, the monitoring agent transmits the collected monitoring data over the network to the backend system for analysis and visualization by the monitoring platform.

[0069] Through the above-described zero-intrusion monitoring method, this application can achieve the following monitoring functions and realize the corresponding technical effects and business value, as detailed in Tables 1 and 2 below:

[0070] Table 1 shows the functions, corresponding effects, and business value achieved by this application.

[0071]

[0072] Table 2 compares the effectiveness of the traditional solution and the solution proposed in this application.

[0073]

[0074] In the above embodiments, the method achieves dynamic management of DSL configuration file versions and dynamic updates of monitoring rules by having the monitoring agent register in the configuration center and obtain the latest registry in real time. In specific implementation, when the DSL configuration file version in this service is updated, the monitoring agent can automatically detect the version inconsistency and obtain the latest target DSL configuration file. Subsequently, the monitoring rules in the pre-loaded DSL rule engine are dynamically updated according to the target DSL configuration file. This process does not require code modification or service redeployment, thus greatly simplifying the monitoring rule update process. Furthermore, this application can also use the updated monitoring rules to re-convert the currently loaded target class and implant monitoring into the target method before sending the monitoring data to the corresponding backend system. This method has the advantages of simple implementation, flexible monitoring, and high efficiency, and is suitable for business monitoring scenarios under various microservice architectures.

[0075] In one embodiment, comparing the DSL profile version currently used by the service recorded in the registry with the running DSL profile version cached by the service in step S120 may include:

[0076] S121: Obtain the list of available versions of this service recorded in the registry, wherein the list of versions includes the currently used DSL configuration file version and the DSL configuration file version to be used.

[0077] S122: Extract the currently used DSL profile version from the version list and extract the running DSL profile version from the service cache.

[0078] S123: Compare the currently used DSL configuration file version with the running DSL configuration file version.

[0079] In this embodiment, when comparing the DSL configuration file version currently used by the service recorded in the registry with the cached running DSL configuration file version, a list of available versions for the service recorded in the registry can be obtained first. This version list is an important collection of information, containing the DSL configuration file versions currently being used by the service, as well as those DSL configuration file versions that are not yet in effect but are expected to be switched to in use at some point in the future. By obtaining this version list, this application can clearly understand the overall picture of the current service's monitoring rules, providing a foundation for subsequent comparison and update work.

[0080] After obtaining the version list, this application can extract the currently used DSL configuration file version and the running DSL configuration file version from the service's cache. These two versions are the core objects of the comparison, and their differences will directly determine whether the monitoring rules need to be updated.

[0081] After extraction, this embodiment performs a detailed comparison between the currently used DSL configuration file version and the running DSL configuration file version. This comparison process is crucial, as it helps this application accurately determine whether new monitoring rules need to be obtained and applied. If the comparison result shows that the two versions are inconsistent, it indicates that new monitoring rules need to be introduced. In this case, the target DSL configuration file can be obtained through the process described in S120, and subsequent monitoring rule updates can be performed. If the comparison result shows that the two versions are consistent, no dynamic update is required, and registry monitoring continues.

[0082] In this way, this application enables flexible management and dynamic updates of monitoring rules, ensuring that monitoring work keeps pace with business changes and providing strong support for the stable operation of the business. At the same time, this version management mechanism also facilitates the rollback and comparison of monitoring rules, further improving the stability and maintainability of the monitoring system.

[0083] In one embodiment, obtaining the target DSL configuration file corresponding to the currently used DSL configuration file version in S120 may include:

[0084] S124: Determine whether the DSL configuration file version currently used by this service is recorded in the registry among all cached DSL configuration file versions.

[0085] S125: If it exists, extract the target DSL configuration file corresponding to the currently used DSL configuration file version from the cache.

[0086] S126: If it does not exist, obtain the target DSL configuration file corresponding to the currently used DSL configuration file version from the configuration center.

[0087] In this embodiment, when obtaining the target DSL configuration file corresponding to the currently used DSL configuration file version, this application first determines whether the target DSL configuration file of that version already exists in the service's cache. To improve the efficiency and response speed of the monitoring system, this application stores at least one copy of the DSL configuration file in the local cache. Thus, when monitoring rules need to be updated, the cache can be checked first to see if the required configuration file version already exists, avoiding unnecessary network requests and data transmission.

[0088] Specifically, this application can iterate through all DSL configuration file versions in the cache and check if there is a version that matches the DSL configuration file version currently used by this service, as recorded in the registry. If the version exists in the cache, it means that the target DSL configuration file for that version has already been obtained and cached. In this case, the file can be retrieved directly from the cache without having to retrieve it from the configuration center again. This step reduces network overhead and improves the speed of monitoring rule updates.

[0089] If the currently used DSL configuration file version is not found in the cache, it indicates that this is the first time the target DSL configuration file for that version has been retrieved, or that the previous cache has been cleared or expired. In this case, the application can redirect to the configuration center to search for and retrieve the target DSL configuration file corresponding to the currently used DSL configuration file version. This process ensures that the monitoring system can obtain the latest monitoring rule configuration file regardless of the cache status.

[0090] In this way, this application can fully utilize local caching when retrieving the target DSL configuration file, improving the efficiency and response speed of the monitoring system. Simultaneously, when the required version is not found in the cache, the latest configuration file can be retrieved from the configuration center in a timely manner, ensuring the accuracy and timeliness of the monitoring rules. This mechanism fully considers the dynamic nature and flexibility of services under a microservice architecture, providing strong support for the stable operation of the monitoring system.

[0091] In one embodiment, before dynamically updating the monitoring rules in the pre-loaded DSL rule engine according to the target DSL configuration file in S130, the following may also be included:

[0092] S127: Determine whether temporary overwriting is enabled for the target DSL configuration file based on the registry.

[0093] S128: If enabled, obtain the coverage configuration when enabling temporary coverage from the configuration center, merge the coverage configuration with the target DSL configuration file, and dynamically update the monitoring rules in the pre-loaded DSL rule engine according to the merged target DSL configuration file.

[0094] S129: If not enabled, the monitoring rules in the pre-loaded DSL rule engine will be dynamically updated directly according to the target DSL configuration file.

[0095] In this embodiment, during the dynamic updating of monitoring rules, this application also considers the special scenario of temporary overriding. Temporary overriding refers to the need to temporarily use a set of monitoring rules different from the currently effective ones under certain specific circumstances, such as during major promotional events or emergency troubleshooting. To meet this requirement, this application adds a flag to the registry to indicate whether temporary overriding is enabled for the target DSL configuration file.

[0096] When the monitoring agent determines whether temporary overriding is enabled in the target DSL profile based on the registry, if it is enabled, it can retrieve the overriding configuration when temporary overriding is enabled from the configuration center. This overriding configuration contains the monitoring rules that need to be temporarily applied, and these rules will override the corresponding rules in the original target DSL profile. Subsequently, the monitoring agent can merge the overriding configuration with the target DSL profile to generate a merged target DSL profile. This merging process ensures that the temporary overriding rules can be correctly applied to the monitoring system without affecting other non-overridden rules.

[0097] After the configuration merging is complete, the monitoring agent can dynamically update the monitoring rules in the pre-loaded DSL rule engine based on the merged target DSL configuration file. This allows the monitoring system to monitor services according to the new temporary rules during temporary overwrite periods, ensuring stable business operations and accurate monitoring.

[0098] If the registry indicates that temporary overwriting is not enabled in the target DSL configuration file, the monitoring agent can directly update the monitoring rules in the pre-loaded DSL rule engine based on the target DSL configuration file, without the need for configuration merging. This process simplifies the monitoring rule update process and improves the efficiency and response speed of the monitoring system.

[0099] In this way, this application can fully consider the special scenario of temporary overlay when dynamically updating monitoring rules, ensuring that the monitoring system can flexibly adapt to changes in various business needs. At the same time, this mechanism also improves the stability and maintainability of the monitoring system.

[0100] In one embodiment, the monitoring and implantation of the target method using the updated monitoring rules in S140 may include:

[0101] S141: When it is detected that this service calls the target method, the target method is monitored and injected by the monitoring interceptor using the updated monitoring rules.

[0102] In this embodiment, to improve the real-time performance and accuracy of monitoring when implanting monitoring into the target method using updated monitoring rules, this application employs a monitoring interceptor. A monitoring interceptor is a code component that can automatically execute specific logic before and after a method call, adding additional monitoring logic to the target method without changing the original method implementation.

[0103] Specifically, when this service calls the target method, the monitoring interceptor can capture this call event and trigger the corresponding monitoring logic. This logic will inject monitoring into the target method according to the updated monitoring rules. The injection process includes inserting monitoring code at the method entry and exit points of the target method to collect runtime data such as parameter values, return values, and exception information. This data is of great significance for subsequent business analysis and troubleshooting.

[0104] Through monitoring interceptors, this application enables fine-grained monitoring of target methods, ensuring that monitoring rules are accurately applied to each method requiring monitoring. Simultaneously, the monitoring interceptors possess excellent scalability and flexibility, easily adapting to changes in various business needs. This mechanism's design fully considers the complexity and diversity of services within a microservice architecture, providing strong support for the stable operation of the monitoring system.

[0105] In one embodiment, the method may further include:

[0106] S142: The monitoring interceptor creates a Span at the method entry point of the target method and passes a Trace ID through the HTTP header / thread context, wherein the Span and the Trace ID are generated in advance in the critical logs based on ZipKin.

[0107] S143: The monitoring interceptor records the monitoring data of the target method during runtime, and after capturing and marking the error span, the span is terminated.

[0108] In this embodiment, to further improve the traceability and troubleshooting efficiency of the monitoring system, this application introduces a distributed tracing technology based on ZipKin. When the target method is captured by the monitoring interceptor and is ready for monitoring injection, the monitoring interceptor creates a Span at the method entry point of the target method. This Span is a basic unit in distributed tracing, representing the execution process of a certain operation in the system. At the same time, the monitoring interceptor also passes a Trace ID through the HTTP header or thread context. This Trace ID is used to identify a complete distributed call chain, so that all Spans on the chain can be associated to form a complete call chain graph.

[0109] After creating the Span and passing the Trace ID, the monitoring interceptor begins monitoring the execution of the target method. During this process, the monitoring interceptor records detailed runtime data of the target method, including but not limited to method parameter values, return values, execution time, and whether exceptions are thrown. This data is crucial for subsequent business analysis and troubleshooting, helping developers quickly locate the problem and take appropriate remedial measures.

[0110] If the target method throws an exception or error during execution, the monitoring interceptor will pay special attention to these error spans. Error spans are those that represent abnormal or erroneous operations in the system; they typically contain detailed error information and stack traces. The monitoring interceptor captures and marks these error spans for subsequent analysis and handling. This step improves the fault detection capability of the monitoring system, enabling developers to promptly identify and address potential problems in the system.

[0111] After the target method completes execution, the monitoring interceptor terminates the span. This termination operation marks the end of one execution cycle of the target method and also means that the position of this execution cycle in the distributed tracing chain has been determined. Subsequently, the monitoring interceptor sends the collected monitoring data and the created span information to the corresponding backend system for subsequent analysis and visualization.

[0112] For example, this application can use distributed tracing technology to achieve business code penetration propagation: User Service (B10800) → Risk Control Service (B2010) → Payment Service (ALIPAY_ERROR). In this example of business code penetration propagation, the User Service (B10800), as the initiating point of the request, first triggers a distributed call. This call is captured by the monitoring system, which creates a Span at the method entry point of the User Service and assigns a unique Trace ID. This Trace ID is passed to the next service node, namely the Risk Control Service (B2010), along with the HTTP request header or thread context. In the Risk Control Service, the monitoring system also captures this request and creates another Span at its method entry point, reusing the previously passed Trace ID to maintain the continuity of the call chain. This process continues until the Payment Service (ALIPAY_ERROR), forming a complete call chain: User Service → Risk Control Service → Payment Service, with each service node's Span associated with the same Trace ID.

[0113] In this way, this application enables comprehensive tracing and monitoring of complex business calls within a microservice architecture. Whether it's an internal method call within a single service or a remote procedure call across multiple services, everything can be clearly recorded, forming a complete call chain diagram. When a service node encounters a problem, this application can quickly locate the entire call chain based on the TraceID, analyze the execution status of each service node, and thus efficiently troubleshoot the fault. The time for business anomaly localization is reduced from 15 minutes to within 1 minute, and causal chain tracing improves the efficiency of cross-service problem analysis by 70%. Therefore, this distributed tracing technology not only enhances the traceability of the monitoring system but also significantly improves the efficiency of fault diagnosis. Furthermore, the ZipKin-based distributed tracing technology also possesses excellent scalability and flexibility, easily adapting to changes in various business needs, thus providing strong support for the stable operation of the monitoring system.

[0114] In one embodiment, such as Figure 3 As shown, Figure 3 This is a schematic diagram illustrating the structure of sending different types of monitoring data to different backend systems, as provided in the embodiments of this application; sending the monitoring data to the corresponding backend system in A140 may include:

[0115] S144: Determine the monitoring type of the monitoring data.

[0116] S145: According to the pre-configured distribution strategy, the monitoring data is sent to the corresponding backend system according to the monitoring type.

[0117] In this embodiment, as Figure 3 As shown, when sending monitoring data to the corresponding backend system, this application first determines the monitoring type of the monitoring data. The types of monitoring data can be diverse, including but not limited to performance metric data, log data, and anomaly data. Each type of data has different meanings and values ​​for subsequent analysis and display, and therefore needs to be sent to different backend systems for specialized processing and storage.

[0118] Once the type of monitoring data is determined, this application will send the monitoring data to the corresponding backend system according to its pre-configured distribution strategy. This distribution strategy is set during the system configuration phase, specifying which backend system each type of monitoring data should be sent to, ensuring correct data processing and efficient utilization. In this way, this application can achieve granular management of monitoring data, ensuring that each type of data can be correctly processed and analyzed, thereby providing strong data support for business monitoring.

[0119] In practical implementation, this application can employ techniques such as message queues and data stream processing to distribute monitoring data. These techniques can efficiently handle large amounts of concurrent data, ensuring that data is sent to the corresponding backend systems in a timely and accurate manner.

[0120] The following describes the zero-intrusion service monitoring device provided in the embodiments of this application. The zero-intrusion service monitoring device described below can be referred to in correspondence with the zero-intrusion service monitoring method described above.

[0121] In one embodiment, such as Figure 4 As shown, Figure 4 This is a schematic diagram of a zero-intrusion business monitoring device provided in an embodiment of this application. This application also provides a zero-intrusion business monitoring device, which is applied to monitoring agents integrated in various services under a microservice architecture. Each monitoring agent is registered in a configuration center. The device may include a registry acquisition module 210, a configuration file acquisition module 220, a dynamic update module 230, and a business monitoring module 240, specifically including the following:

[0122] The registry acquisition module 210 is used to obtain the latest registry from the configuration center. The registry records all services and their corresponding at least one DSL configuration file version. Each DSL configuration file version is configured with a corresponding DSL configuration file, and each DSL configuration file records specific monitoring rules.

[0123] The configuration file acquisition module 220 is used to compare the version of the DSL configuration file currently used by this service recorded in the registry with the version of the running DSL configuration file cached by this service. If the versions are inconsistent, the target DSL configuration file corresponding to the version of the currently used DSL configuration file is acquired.

[0124] The dynamic update module 230 is used to dynamically update the monitoring rules in the pre-loaded DSL rule engine according to the target DSL configuration file, and to determine the target class to be reconverted and the target method to be implanted for monitoring according to the updated monitoring rules.

[0125] The business monitoring module 240 is used to re-transform the currently loaded target class that has not been re-transformed using the updated monitoring rules, and after monitoring is implanted into the target method, obtain the monitoring data generated by this service under the updated monitoring rules, and send the monitoring data to the corresponding backend system.

[0126] In the above embodiments, the method achieves dynamic management of DSL configuration file versions and dynamic updates of monitoring rules by having the monitoring agent register in the configuration center and obtain the latest registry in real time. In specific implementation, when the DSL configuration file version in this service is updated, the monitoring agent can automatically detect the version inconsistency and obtain the latest target DSL configuration file. Subsequently, the monitoring rules in the pre-loaded DSL rule engine are dynamically updated according to the target DSL configuration file. This process does not require code modification or service redeployment, thus greatly simplifying the monitoring rule update process. Furthermore, this application can also use the updated monitoring rules to re-convert the currently loaded target class and implant monitoring into the target method before sending the monitoring data to the corresponding backend system. This method has the advantages of simple implementation, flexible monitoring, and high efficiency, and is suitable for business monitoring scenarios under various microservice architectures.

[0127] In one embodiment, this application also provides a computer-readable storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the zero-intrusion business monitoring method as described in any of the above embodiments.

[0128] In one embodiment, this application also provides a computer device, including: one or more processors, and memory.

[0129] The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the zero-intrusion service monitoring method as described in any of the above embodiments.

[0130] Indicatively, such as Figure 5 As shown, Figure 5 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 5 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the zero-intrusion business monitoring method of any of the above embodiments.

[0131] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0132] Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0133] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0134] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0135] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A zero-intrusion business monitoring method, characterized in that, The method is applied to monitoring agents integrated into various services in a microservice architecture. Each monitoring agent is registered in a configuration center. The method includes: The latest registry is obtained from the configuration center. The registry records all services and their corresponding at least one DSL configuration file version. Each DSL configuration file version is configured with a corresponding DSL configuration file. Each DSL configuration file records specific monitoring rules. The version of the DSL configuration file currently used by this service, recorded in the registry, is compared with the version of the DSL configuration file currently running in the cache of this service. If the versions are inconsistent, the target DSL configuration file corresponding to the version of the DSL configuration file currently used is obtained. The monitoring rules in the pre-loaded DSL rule engine are dynamically updated according to the target DSL configuration file, and the target class to be reconverted and the target method to be implanted for monitoring are determined according to the updated monitoring rules. After re-transforming the currently loaded, untransformed target class using the updated monitoring rules and implanting monitoring into the target method, the service obtains the monitoring data generated under the updated monitoring rules and sends the monitoring data to the corresponding backend system.

2. The zero-intrusion service monitoring method according to claim 1, characterized in that, The step of comparing the DSL configuration file version currently used by this service recorded in the registry with the DSL configuration file version cached by this service includes: Obtain the list of available versions of this service recorded in the registry, wherein the list of versions includes the currently used DSL configuration file version and the DSL configuration file version to be used; Extract the currently used DSL profile version from the version list and extract the running DSL profile version from the service cache; Compare the currently used DSL configuration file version with the running DSL configuration file version.

3. The zero-intrusion business monitoring method according to claim 1, characterized in that, The step of obtaining the target DSL configuration file corresponding to the currently used DSL configuration file version includes: Determine whether the DSL configuration file version currently used by this service is recorded in the registry among all cached DSL configuration file versions; If it exists, then retrieve the target DSL configuration file corresponding to the currently used DSL configuration file version from the cache; If it does not exist, then obtain the target DSL configuration file corresponding to the currently used DSL configuration file version from the configuration center.

4. The zero-intrusion business monitoring method according to claim 1, characterized in that, Before dynamically updating the monitoring rules in the pre-loaded DSL rule engine according to the target DSL configuration file, the method further includes: Determine whether temporary overwriting is enabled for the target DSL configuration file based on the registry; If enabled, the coverage configuration for enabling temporary coverage is obtained from the configuration center, the coverage configuration is merged with the target DSL configuration file, and the monitoring rules in the pre-loaded DSL rule engine are dynamically updated according to the merged target DSL configuration file. If not enabled, the monitoring rules in the pre-loaded DSL rule engine will be dynamically updated directly based on the target DSL configuration file.

5. The zero-intrusion business monitoring method according to claim 1, characterized in that, The step of monitoring and implanting the target method using updated monitoring rules includes: When the service detects that it is calling the target method, the updated monitoring rules are used to monitor and inject the target method through the monitoring interceptor.

6. The zero-intrusion service monitoring method according to claim 5, characterized in that, The method further includes: The monitoring interceptor creates a Span at the method entry point of the target method and passes a Trace ID via HTTP headers / thread context. The Span and the Trace ID are generated in advance in the critical logs by ZipKin. The monitoring interceptor records the monitoring data during the execution of the target method, and after capturing and marking the error span, terminates the span.

7. The zero-intrusion business monitoring method according to claim 1, characterized in that, Sending the monitoring data to the corresponding backend system includes: Determine the monitoring type of the monitoring data; According to the pre-configured distribution strategy, the monitoring data is sent to the corresponding backend system according to the monitoring type.

8. A zero-intrusion business monitoring device, characterized in that, The device is used to integrate monitoring agents in various services under a microservice architecture. Each monitoring agent is registered in a configuration center. The device includes: The registry acquisition module is used to obtain the latest registry from the configuration center. The registry records all services and their corresponding at least one DSL configuration file version. Each DSL configuration file version is configured with a corresponding DSL configuration file, and each DSL configuration file records specific monitoring rules. The configuration file acquisition module is used to compare the version of the DSL configuration file currently used by this service recorded in the registry with the version of the running DSL configuration file cached by this service. If the versions are inconsistent, the target DSL configuration file corresponding to the version of the currently used DSL configuration file is acquired. The dynamic update module is used to dynamically update the monitoring rules in the pre-loaded DSL rule engine according to the target DSL configuration file, and to determine the target class to be reconverted and the target method to be implanted for monitoring according to the updated monitoring rules. The business monitoring module is used to re-transform the currently loaded target class that has not been re-transformed using the updated monitoring rules, and after monitoring is implanted into the target method, obtain the monitoring data generated by this service under the updated monitoring rules, and send the monitoring data to the corresponding backend system.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the zero-intrusion business monitoring method as described in any one of claims 1 to 7.

10. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the zero-intrusion business monitoring method as described in any one of claims 1 to 7.

Images