Method and apparatus for scenario-based monitoring component from application perspective

Abstract

The application discloses a kind of with the method and device of the application perspective scene monitoring component, the method includes: extracting each to be monitored application system used basic component type;According to basic component type, from the matching current monitoring package template in scene monitoring package library;Scene monitoring package library includes multiple basic component types, historical abnormal scene, the relationship between the historical abnormal log features, alarm condition and mode of application system;From each to be monitored application system, real-time extraction and current monitoring package template matching abnormal log features, when satisfying alarm condition, generate alarm event single and issue by current monitoring package template corresponding monitoring alarm template.The application establishes scene monitoring package library from the application perspective, based on the package library, can capture the abnormal log generated when application calls various basic components, reversely associated to infer the service abnormal state of underlying component, realize the rapid perception, positioning and influence evaluation of component fault.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a method and apparatus for a scenario-based monitoring component from an application perspective. Background Technology

[0002] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] In today's increasingly complex system architectures, databases (such as MySQL and DB2), middleware (such as Redis and Kafka), and various basic software are key components supporting the stable operation of applications. Existing monitoring technologies mostly focus on directly monitoring basic components (such as database processes and message queue backlogs) or performing general log collection and analysis, which has the following inherent shortcomings: 1. Abnormal metrics of basic components (such as a brief spike in the number of database connections) may not cause application service calls to fail, generating irrelevant alarms and interfering with operations and maintenance personnel.

[0004] 2. The basic components themselves do not detect any abnormalities (such as process survival and normal resources), but their external services have already experienced abnormalities (such as network partitions causing connection unreachability), and the application has started to report errors, but the basic components are unaware of this.

[0005] 3. Existing monitoring is based on the perspective of the "service provider" (the component itself) and cannot directly verify the actual availability of its service to the upstream caller (application).

[0006] 4. When an application experiences a business anomaly, operations and maintenance personnel need to manually link the application error logs and check all potentially dependent underlying components one by one, with a long and time-consuming investigation chain.

[0007] In summary, existing technologies lack a solution that can effectively correlate application-side anomalies with underlying component failures, and use this as the core data for monitoring and diagnosis. Summary of the Invention

[0008] This invention provides a method for scenario-based monitoring components from an application perspective. This method establishes a scenario-based monitoring package library from an application perspective. Based on this library, it can capture abnormal logs generated by applications when calling various basic components, and infer the service abnormal status of underlying components through reverse correlation. This enables rapid detection, location, and impact assessment of component failures. The method includes: Extract the basic component types used by each application system to be monitored; Based on the basic component types used by each application system to be monitored, the applicable current monitoring package template is matched from the pre-built application system scenario-based monitoring package library; the application system scenario-based monitoring package library includes multiple basic component types as service providers, historical abnormal scenarios, and the relationship between the historical abnormal log characteristics, alarm conditions and alarm methods of the application system as monitoring package templates. The system extracts abnormal log features that match the current monitoring package template from each application system to be monitored in real time. When the alarm conditions are met, it generates an alarm event form through the monitoring alarm template corresponding to the current monitoring package template and sends the alarm event form to the preset personnel terminal.

[0009] This invention also provides an apparatus for scenario-based monitoring components from an application perspective, used to establish a scenario-based monitoring package library from an application perspective. Based on this package library, it can capture abnormal logs generated by applications when calling various basic components, and inversely correlate and infer the service abnormal status of underlying components, thereby achieving rapid detection, location, and impact assessment of component failures. The apparatus includes: The extraction unit is used to extract the basic component types used by each application system to be monitored. The matching unit is used to match the applicable current monitoring package template from the pre-built application system scenario-based monitoring package library according to the basic component type used by each application system to be monitored; the application system scenario-based monitoring package library includes multiple basic component types as service providers, historical abnormal scenarios, and the relationship between the historical abnormal log characteristics, alarm conditions and alarm methods of the application system as monitoring package templates. The monitoring unit is used to extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time. When the alarm conditions are met, an alarm event ticket is generated through the monitoring alarm template corresponding to the current monitoring package template, and the alarm event ticket is sent to the preset personnel terminal.

[0010] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described method for a scenario-based monitoring component from an application perspective.

[0011] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for a scenario-based monitoring component from an application perspective.

[0012] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for a scenario-based monitoring component from an application perspective.

[0013] In this embodiment of the invention, the scenario-based monitoring component solution from an application perspective involves: extracting the basic component types used by each application system to be monitored; matching the applicable current monitoring package template from a pre-built application system scenario-based monitoring package library based on the basic component types used by each application system to be monitored; the application system scenario-based monitoring package library includes multiple basic component types as service providers, historical abnormal scenarios, and the relationship between historical abnormal log characteristics, alarm conditions, and alarm methods of the application system as monitoring package templates; extracting abnormal log characteristics matching the current monitoring package template from each application system to be monitored in real time; when alarm conditions are met, generating an alarm event form through the monitoring alarm template corresponding to the current monitoring package template, and sending the alarm event form to a preset personnel terminal. This enables the establishment of a scenario-based monitoring package library from an application perspective. Based on this package library, abnormal logs generated by applications when calling various basic components can be captured, and the service abnormal status of underlying components can be inferred through reverse correlation, achieving rapid perception, location, and impact assessment of component failures. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a flowchart illustrating the method of a scenario-based monitoring component from an application perspective in an embodiment of the present invention. Figure 2 This is a schematic diagram illustrating the principle of a scenario-based monitoring component from an application perspective in an embodiment of the present invention. Figure 3 This is a schematic diagram illustrating the process of constructing an application system scenario-based monitoring package library in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a scenario-based monitoring component from an application perspective in an embodiment of the present invention; Figure 5 This is a schematic diagram of a computer device structure according to an embodiment of the present invention. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0016] The acquisition, transmission, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0017] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0018] Before introducing the embodiments of the present invention, we will first identify the technical problems existing in the prior art and the ideas behind proposing the solutions of the embodiments of the present invention based on these technical problems.

[0019] As information systems become increasingly complex, they typically rely on numerous foundational components such as databases, message queues, Redis, and technology platforms. Currently, monitoring of these components primarily focuses on their own operational metrics (e.g., CPU, memory, connection count, slow queries), triggering alerts when these metrics exceed thresholds. However, existing monitoring solutions suffer from the following significant drawbacks: 1. Disconnect between alarms and business impact: Alarms from the basic components themselves (such as a surge in database connection count) may not indicate that the upper-layer application has failed or detected anomalies. It is difficult for operations and maintenance personnel to quickly determine whether the alarm has had an actual impact on the business system.

[0020] 2. Lack of self-service status awareness: Many basic software programs cannot accurately perceive whether the services they provide to the outside world are truly normal. They can only reflect the survival status of their own processes or the consumption of resources, and cannot verify the availability of services from the perspective of the service caller (i.e., the application).

[0021] 3. Difficulty in fault location: When an application malfunctions, it requires manual inspection of each underlying component, making it difficult to quickly pinpoint which basic service is causing the business problem.

[0022] 4. Fragmented monitoring configuration: Different monitoring metrics and alarm rules need to be configured for different middleware and databases, lacking a scenario-based monitoring package from a unified application perspective.

[0023] Therefore, there is an urgent need for a unified monitoring method that can reflect anomalies in underlying basic components from an application perspective through application logs, so as to achieve rapid fault detection, location and impact assessment.

[0024] Based on the above technical problems, the core idea of ​​this invention lies in perspective shifting from traditional component-centric monitoring to application-centric monitoring. It aims to provide a scenario-based monitoring solution from an application perspective. This solution, built from an application-centric perspective, captures exception logs generated when the application layer calls various basic components. It then uses this data to infer the service anomalies of underlying databases, middleware, and other components, thereby constructing a universal monitoring package centered on application experience and covering multiple basic components. This achieves the monitoring goal of perceptible business impact and rapid fault root cause location. The main technical problems solved are as follows: 1. How to quickly and accurately identify basic component failures that have had a real impact on upper-layer business applications, and avoid irrelevant alarm interference.

[0025] 2. How to establish an effective measurement mechanism for the availability of basic component services from the perspective of the service caller (application).

[0026] 3. How to automatically and quickly locate the root cause component of an application exception when an exception occurs, thereby shortening the troubleshooting time.

[0027] 4. How to provide a general and standardized monitoring configuration method to reduce the complexity of monitoring configuration and maintenance for diverse basic components.

[0028] The following section provides a detailed introduction to the scenario-based monitoring component solution from an application perspective.

[0029] Figure 1 This is a flowchart illustrating the method of a scenario-based monitoring component from an application perspective in an embodiment of the present invention, as shown below. Figure 1 As shown, the method includes the following steps: Step 101: Extract the basic component types used by each application system to be monitored; Step 102: Based on the basic component type used by each application system to be monitored, match the applicable current monitoring package template from the pre-built application system scenario-based monitoring package library; the application system scenario-based monitoring package library includes multiple basic component types as service providers, historical abnormal scenarios, and the relationship between the historical abnormal log characteristics, alarm conditions and alarm methods of the application system as monitoring package templates. Step 103: Extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time. When the alarm conditions are met, generate an alarm event form through the monitoring alarm template corresponding to the current monitoring package template, and send the alarm event form to the preset personnel terminal.

[0030] The method for scenario-based monitoring components from an application perspective provided in this embodiment of the invention operates as follows: Extracting the basic component types used by each application system to be monitored; matching the applicable current monitoring package template from a pre-built application system scenario-based monitoring package library based on the basic component types used by each application system to be monitored; the application system scenario-based monitoring package library includes multiple basic component types serving as service providers, historical abnormal scenarios, and the relationship between historical abnormal log characteristics, alarm conditions, and alarm methods of the application system as monitoring package templates; extracting abnormal log characteristics matching the current monitoring package template from each application system to be monitored in real time; when alarm conditions are met, generating an alarm event form through the monitoring alarm template corresponding to the current monitoring package template, and sending the alarm event form to a preset personnel terminal.

[0031] This invention establishes a scenario-based monitoring package library from an application perspective. Based on this library, it can capture abnormal logs generated by applications when calling various basic components, and inversely correlate and infer the service abnormal status of underlying components, thereby achieving rapid detection, location, and impact assessment of component failures. The following is a detailed description of this scenario-based monitoring component method from an application perspective.

[0032] This invention provides a method for scenario-based monitoring components from an application perspective. This method establishes a scenario-based monitoring package library from an application perspective, transforming the monitoring viewpoint and introducing the concept of "application perspective." This involves proactively and indirectly diagnosing faults in underlying supporting components (databases, middleware) and their actual impact on business operations through specific exception logs generated by upper-layer applications (such as JdbcConnectException). This provides a new approach to solving operational and maintenance problems such as "components issuing alarms but business operations are actually unaffected" or "components not issuing alarms but business operations are already damaged."

[0033] This invention proposes a scenario-based monitoring solution based on application perspective and application log analysis. Its core lies in building and managing a scenario-based monitoring package library. This package library defines various common underlying component failure scenarios and associates specific abnormal log characteristics that the application will inevitably or with a high probability of generating in each scenario (such as the "RedisCommandTimeoutException" error log generated when the application accesses Redis abnormally). When the application log generates a corresponding alarm, the faulty component and its impact on the application can be immediately determined through the alarm title and content. Figure 2 This is a schematic diagram illustrating the principle of a scenario-based monitoring component from an application perspective in an embodiment of the present invention, such as... Figure 2As shown, this method mainly includes: summarizing abnormal scenarios of basic components, establishing an abnormal scenario library, establishing an abnormal scenario-application log mapping, constructing mapping relationships, constructing monitoring package templates, generating a package template library, generating alarm templates, forming an alarm template set, and distributing monitoring configurations and alarms. The following section will combine these steps with... Figure 2 The core steps and solutions are explained below: First, we will introduce a solution for pre-building a scenario-based monitoring package library for application systems.

[0034] Figure 3 This is a schematic diagram illustrating the process of constructing an application system scenario-based monitoring package library in one embodiment of the present invention. Figure 3 As shown, the above-mentioned method for application-oriented scenario-based monitoring components can also include constructing an application system scenario-based monitoring package library according to the following method: Step 201: Obtain historical exception scenarios for multiple basic components acting as the service provider; Step 202: Establish a mapping relationship between multiple basic component types as service providers, historical anomaly scenarios of basic components, and historical anomaly log characteristics of application systems; Step 203: Based on the mapping relationship, construct an application system scenario-based monitoring package library. This scenario-based monitoring package library includes multiple basic component types that serve as service providers, historical abnormal scenarios, and the relationship between historical abnormal log characteristics, alarm thresholds, alarm frequencies, and alarm levels of the application system.

[0035] 1. Summarize the abnormal scenarios of basic components, i.e., step 201 above.

[0036] Objective: To systematically identify common failure modes of various basic components (including but not limited to databases, Redis, message queues, configuration centers, etc.) and form a standardized classification of abnormal scenarios.

[0037] Implementation plan: through, for example Figure 2 The methods shown include historical failure reviews, best practice references, and product documentation analysis (referencing product documentation or development specifications) to summarize potential abnormal scenarios for basic components. These scenarios are categorized into basic software / open-source software or industry-developed basic frameworks or platforms. Examples of abnormal scenarios are as follows: (1) Abnormal scenarios of basic software / open source software: Database errors: connection errors, deadlocks, SQL execution timeouts, SQL execution exceptions, etc. Redis errors: Redis command timeout, Redis connection failure, etc. Kafka errors include: message sending timeout, consumer offset commit failure, missing Topic or Partition, and excessively large message size. Elasticsearch errors include: clients being unable to connect to any node in the cluster, the cluster failing to elect a master node, and network connectivity being interrupted. RabbitMQ exceptions: No queue available, message consumption failed, message sending queue failed, or producer or consumer failed to be retrieved. (2) Infrastructure or platform error: File transfer errors: file exceeds maximum value, no download permission, login to server failed, authentication failed, file download failed, etc. Configuration center errors: parameter initialization failed, dynamic configuration refresh failed, parameter retrieval failed, unknown errors, etc. Distributed transaction exceptions: Unable to find distributed transaction service, distributed transaction heartbeat failure, failure to register distributed transaction, etc. Registration center errors: instance registration failed, heartbeat failed, failure to obtain subscription information failed, incorrect data type of received subscription, etc.

[0038] 2. Establish a mapping relationship between abnormal scenarios and application abnormal logs, i.e., step 202 above.

[0039] Objective: To construct a deterministic mapping library from component failures to application performance, which is the core technology of this invention.

[0040] Implementation Plan: For each abnormal scenario, associate it with one or more highly identifiable abnormal log features that are bound to occur or have a very high probability of occurring in one or more applications. The mapping relationship is discovered and established through the following methods: (1) Historical fault log mining, such as Figure 2 The historical log mining shown describes how, at known points in time when component failures occurred, relevant application logs are traced back to identify abnormal log spikes.

[0041] (2) Figure 2 The example shown is a fault injection test. In the test environment, faults in the components are actively injected (such as killing a process), and application logs are collected in real time to record the generated exception logs.

[0042] (3) Review product documentation and development specifications, such as Figure 2 The document specifications outlined are as follows. The system systematically reviews product documentation for basic software / open-source software and development specifications for industry-standard frameworks or platforms, identifying exception logs corresponding to abnormal scenarios.

[0043] As can be seen from the above, in one embodiment, establishing a mapping relationship between multiple basic component types acting as service providers, historical anomaly scenarios of basic components, and historical anomaly log characteristics of the application system includes: At the known time points of abnormal scenarios where component failures occur, backtrack the relevant application system logs to uncover the abnormal log characteristics of the abnormal scenarios that correspond to the sudden increase in abnormality. In the test environment, component failures in abnormal scenarios are proactively injected, application system logs are collected in real time, and the abnormal log characteristics corresponding to the generated abnormal scenarios are recorded. Identify the abnormal log characteristics corresponding to abnormal scenarios from the product documentation of basic software or open source software and the development specifications of the basic framework or platform developed in the industry. Based on the abnormal log features corresponding to the abnormal scenarios obtained in the above steps, the mapping relationship is obtained.

[0044] The logical mapping relationship between basic component exceptions and application-printed exception logs is illustrated in Table 1 below: Table 1

[0045] 3. Set up monitoring packages, i.e., step 203 above, and build a monitoring package template library.

[0046] Objective: To package the results of the first two steps into a subscribing and manageable "monitoring product" for use in monitoring and alerting.

[0047] Implementation Plan: Based on the above mapping relationship, construct a scenario-based monitoring package template, including abnormal scenarios, application logs, alarm thresholds, alarm frequency, and alarm levels, as shown in Table 2 below: Table 2

[0048] Therefore, multiple scenario-based monitoring package templates constitute the application system scenario-based monitoring package library.

[0049] In practice, this step can be implemented by participating in, for example... Figure 2 The diagram shows how to define abnormal scenarios, set alarm thresholds, determine alarm levels, and configure notification policies. Alarm conditions can be determined using the alarm thresholds in Table 2 above, and alarm methods can be implemented using the alarm frequencies in Table 2 above. Of course, the scenario-based monitoring package template can also include alarm levels to help staff determine the urgency of alarms and improve user experience.

[0050] Steps “1” to “3” above constitute the solution for pre-building a scenario-based monitoring package library for application systems.

[0051] 4. Define monitoring and alarm templates, for example Figure 2 The generated alarm templates and the formed alarm template set are shown.

[0052] Objective: To transform monitoring packages into actionable and understandable alerting policies and notification content.

[0053] Implementation plan: Based on the monitoring package set above, define the corresponding alarm titles (e.g., ...). Figure 2 The design alarm title shown) and alarm content (such as) Figure 2 (See the example of writing alarm content). The alarm title includes the name of the underlying component and the exception scenario, allowing direct identification of the faulty component. The alarm content records detailed exception logs and possible causes, providing guidance for alarm handling, such as... Figure 2 The configuration processing guidelines are shown below. Taking a scenario where retrieving parameters from the configuration center fails as an example, the alarm event form could be: Alarm title:

【 [System] Failed to retrieve parameters from the configuration center [Configuration Center General Alert] Alarm content: The application log shows the error "failed to pull configItems from remote ecscserver", indicating that it failed to pull parameters from the configuration center. Possible reasons include: configuration center service failure, configuration set not being downloaded, inaccurate input parameters, etc.

[0054] The above multiple alarm event forms can be generated as follows: Figure 2 The alarm template set shown.

[0055] As can be seen from the above, in one embodiment, the method for scenario-based monitoring components from an application perspective may further include converting the monitoring package template into a corresponding monitoring alarm template; the monitoring alarm template includes: alarm title and alarm content, the alarm title includes the name of the basic component and the abnormal scenario, which can directly locate the abnormal basic component through the title, and the alarm content records detailed abnormal log characteristics and possible abnormal causes, providing guidance for alarm handling.

[0056] Step "4" above is the solution for pre-building the monitoring alarm template corresponding to the monitoring package template.

[0057] After completing the preparatory steps from "1" to "4" above, step 5 is introduced below, which is the method of using the pre-built "application system scenario-based monitoring package library" and "monitoring alarm template corresponding to the monitoring package template" to perform real-time scenario-based monitoring components from the application perspective.

[0058] 5. Monitoring configuration distribution and alarms.

[0059] Objective: To achieve automated distribution of configurations and real-time, accurate generation and delivery of alerts.

[0060] Implementation plan: (1) Extract the list of basic components used by each application system from the CMDB, such as Figure 2The CMDB data extraction shown above, i.e. step 101, extracts the basic component types used by each application system to be monitored.

[0061] As can be seen from the above, in one embodiment, extracting the basic component types used by each application system to be monitored includes: extracting the basic component types used by each application system to be monitored from the configuration management database (CMDB).

[0062] (2) Match the appropriate monitoring template from the package library based on the type of basic component used, such as Figure 2 The template shown is automatically matched.

[0063] (3) Generate a customized monitoring configuration for the application system.

[0064] The above steps “(2)” and “(3)”, namely step 102, match the applicable current monitoring package template from the pre-built application system scenario-based monitoring package library according to the basic component type used by each application system to be monitored.

[0065] (4) Collect application logs via Agent, such as Figure 2 The Agent deployment shown supports regular expressions, keyword matching, and other methods to extract abnormal log entries that match the package rules in real time. When alarm conditions are met, an alarm event ticket is generated to notify the on-duty personnel to handle the alarm process, such as... Figure 2 The alarm event form shown above is generated to notify the duty officer to handle it, i.e., step 103 above.

[0066] As can be seen from the above, in one embodiment, extracting abnormal log features that match the current monitoring package template from each application system to be monitored in real time may include: extracting abnormal log features that match the current monitoring package template from each application system to be monitored in real time through an Agent proxy.

[0067] As can be seen from the above, in one embodiment, extracting abnormal log features that match the current monitoring package template from each application system to be monitored in real time includes: using regular expressions to extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time.

[0068] To facilitate understanding of how this invention is implemented, the following example illustrates the entire workflow using the establishment of an Elasticsearch component anomaly monitoring package: 1. When Elasticsearch service exceptions affected application access on multiple occasions, by tracing back the application exception logs, it was found that the logs printed keywords such as "NoNodeAvailableException" and "UnavailableShardsException". Through destructive testing in the test environment and referring to the development documentation, it was confirmed that the exception logs were characteristic of Elasticsearch exceptions.

[0069] 2. Establish the mapping relationship between Elasticsearch component exception scenarios and application exception logs, as shown in Table 3 below: Table 3

[0070] 3. Based on the severity of the abnormal scenario, set the corresponding alarm thresholds, alarm frequencies, and alarm levels to generate a monitoring package, as shown in Table 4 below: Table 4

[0071] 4. Based on the monitoring package settings described above, define the corresponding alarm titles and alarm content. For example, consider the scenario "The client cannot connect to any node in the cluster": Alarm title:

【 The system log shows an exception (NoNodeAvailableException) where the client cannot connect to any node in the cluster [Elasticsearch General Alert].

[0072] Alarm message: The application log shows a "NoNodeAvailableException" error. This exception indicates that the Elasticsearch client cannot establish a connection with any node in the cluster, which may be due to a problem with the cluster status. Please check the Elasticsearch cluster status.

[0073] 5. Extract a list of systems using Elasticsearch from the CMDB, add them to the corresponding monitoring packages, and generate an alarm event ticket when the collected application logs meet the alarm conditions, notifying the on-duty personnel to handle it. The "

General Elasticsearch Alarm

[0074] The beneficial technical effects of the application-oriented scenario-based monitoring component method provided in this embodiment of the invention are: 1. Precise and visible business impact: The application logs directly reflect the real business experience, enabling operations and maintenance personnel to identify underlying faults that have affected the business in the first instance, reducing fault discovery time by more than 50%.

[0075] 2. Rapid fault location: Through predefined "abnormal features - faulty components" mapping rules, the scope of investigation can be narrowed down to specific components the moment an application error occurs, shortening the fault investigation time from hours or tens of minutes to minutes or even seconds.

[0076] 3. Standardized and simplified monitoring configuration: Provide monitoring packages based on "scenario" rather than "component model", reducing the complexity of monitoring configuration for different middleware and databases. For example, there is no need to care about the differences in monitoring indicators of different MySQL versions. Just deploy the "database connection anomaly package" for the application, which greatly reduces the configuration and maintenance costs, improves the level of standardization, and reduces the configuration time by more than 70%.

[0077] 4. Strong technical versatility and scalability: This solution does not depend on whether the underlying components provide monitoring interfaces. As long as the application logs can reflect call exceptions, it is applicable. It covers various self-developed, open-source, or commercial components and can cover more than 90% of the typical exception scenarios of mainstream basic components.

[0078] 5. Improve alarm accuracy: By combining application-side anomaly logs with component-specific indicator alarms, "alarms have immediate impact," reducing false alarms and improving alarm accuracy, with a false alarm rate reduction of over 60%.

[0079] 6. Improve operational efficiency: The experience of senior operations and maintenance personnel is distilled into reusable and manageable packages and templates, reducing reliance on individual experience, empowering junior staff, improving overall team efficiency, and reducing monitoring and configuration manpower costs by more than 40%.

[0080] This invention also provides an apparatus for a scenario-based monitoring component from an application perspective, as described in the following embodiments. Since the principle by which this apparatus solves the problem is similar to the method of the scenario-based monitoring component from an application perspective, the implementation of this apparatus can refer to the implementation of the method of the scenario-based monitoring component from an application perspective; repeated details will not be elaborated further.

[0081] Figure 4 This is a schematic diagram of the structure of a scenario-based monitoring component from an application perspective in an embodiment of the present invention, such as... Figure 4 As shown, the device includes: Extraction unit 01 is used to extract the basic component types used by each application system to be monitored. Matching unit 02 is used to match the applicable current monitoring package template from the pre-built application system scenario-based monitoring package library according to the basic component type used by each application system to be monitored; the application system scenario-based monitoring package library includes multiple basic component types as service providers, historical abnormal scenarios, and the relationship between the historical abnormal log characteristics, alarm conditions and alarm methods of the application system as monitoring package templates. Monitoring unit 03 is used to extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time. When the alarm conditions are met, an alarm event ticket is generated through the monitoring alarm template corresponding to the current monitoring package template, and the alarm event ticket is sent to the preset personnel terminal.

[0082] In one embodiment, the aforementioned device for application-oriented scenario-based monitoring components may further include a construction unit for constructing an application system scenario-based monitoring package library according to the following method: Obtain historical anomaly scenarios for multiple basic components used by the service provider; Establish a mapping relationship between multiple basic component types as service providers, historical anomaly scenarios of basic components, and historical anomaly log characteristics of application systems; Based on the mapping relationship, an application system scenario-based monitoring package library is constructed. This scenario-based monitoring package library includes multiple basic component types that serve as service providers, historical abnormal scenarios, and the relationship between the application system's historical abnormal log characteristics, alarm thresholds, alarm frequencies, and alarm levels.

[0083] In one embodiment, establishing a mapping relationship between multiple basic component types acting as service providers, historical anomaly scenarios of basic components, and historical anomaly log characteristics of the application system includes: At the known time points of abnormal scenarios where component failures occur, backtrack the relevant application system logs to uncover the abnormal log characteristics of the abnormal scenarios that correspond to the sudden increase in abnormality. In the test environment, component failures in abnormal scenarios are proactively injected, application system logs are collected in real time, and the abnormal log characteristics corresponding to the generated abnormal scenarios are recorded. Identify the characteristics of exception logs corresponding to abnormal scenarios from the product documentation of basic software or open-source software and the development specifications of industry-developed basic frameworks or platforms.

[0084] In one embodiment, the above-mentioned application-oriented scenario-based monitoring component device may further include a conversion unit for: converting the monitoring package template into a corresponding monitoring alarm template; the monitoring alarm template includes: an alarm title and an alarm content, the alarm title includes the name of the basic component and the abnormal scenario, which can directly locate the abnormal basic component through the title, and the alarm content records detailed abnormal log characteristics and possible abnormal causes, providing guidance for alarm handling.

[0085] In one embodiment, the monitoring unit is specifically used to: extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time through an Agent proxy.

[0086] In one embodiment, the monitoring unit is specifically used to: extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time using regular expressions.

[0087] In one embodiment, the extraction unit is specifically used to: extract the basic component types used by each application system to be monitored from the configuration management database (CMDB).

[0088] Based on the aforementioned inventive concept, such as Figure 5 As shown, the present invention also proposes a computer device 500, including a memory 510, a processor 520, and a computer program 530 stored in the memory 510 and executable on the processor 520. When the processor 520 executes the computer program 530, it implements the aforementioned method for a scenario-based monitoring component from an application perspective.

[0089] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for a scenario-based monitoring component from an application perspective.

[0090] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for a scenario-based monitoring component from an application perspective.

[0091] In this embodiment of the invention, the scenario-based monitoring component solution from an application perspective involves: extracting the basic component types used by each application system to be monitored; matching the applicable current monitoring package template from a pre-built application system scenario-based monitoring package library based on the basic component types used by each application system to be monitored; the application system scenario-based monitoring package library includes multiple basic component types as service providers, historical abnormal scenarios, and the relationship between historical abnormal log characteristics, alarm conditions, and alarm methods of the application system as monitoring package templates; extracting abnormal log characteristics matching the current monitoring package template from each application system to be monitored in real time; when alarm conditions are met, generating an alarm event form through the monitoring alarm template corresponding to the current monitoring package template, and sending the alarm event form to a preset personnel terminal. This enables the establishment of a scenario-based monitoring package library from an application perspective. Based on this package library, abnormal logs generated by applications when calling various basic components can be captured, and the service abnormal status of underlying components can be inferred through reverse correlation, achieving rapid perception, location, and impact assessment of component failures.

[0092] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0094] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0095] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0096] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for scenario-based monitoring components from an application perspective, characterized in that, include: Extract the basic component types used by each application system to be monitored; Based on the basic component types used by each application system to be monitored, the applicable current monitoring package template is matched from the pre-built application system scenario-based monitoring package library; the application system scenario-based monitoring package library includes multiple basic component types as service providers, historical abnormal scenarios, and the relationship between the historical abnormal log characteristics, alarm conditions and alarm methods of the application system as monitoring package templates. The system extracts abnormal log features that match the current monitoring package template from each application system to be monitored in real time. When the alarm conditions are met, it generates an alarm event form through the monitoring alarm template corresponding to the current monitoring package template and sends the alarm event form to the preset personnel terminal.

2. The method as described in claim 1, characterized in that, This also includes building a library of application system scenario-based monitoring packages using the following methods: Obtain historical anomaly scenarios for multiple basic components used by the service provider; Establish a mapping relationship between multiple basic component types as service providers, historical anomaly scenarios of basic components, and historical anomaly log characteristics of application systems; Based on the mapping relationship, an application system scenario-based monitoring package library is constructed. This scenario-based monitoring package library includes multiple basic component types that serve as service providers, historical abnormal scenarios, and the relationship between the application system's historical abnormal log characteristics, alarm thresholds, alarm frequencies, and alarm levels.

3. The method as described in claim 2, characterized in that, Establish a mapping relationship between multiple basic component types acting as service providers, historical anomaly scenarios of basic components, and historical anomaly log characteristics of application systems, including: At the known time points of abnormal scenarios where component failures occur, backtrack the relevant application system logs to uncover the abnormal log characteristics of the abnormal scenarios that correspond to the sudden increase in abnormality. In the test environment, component failures in abnormal scenarios are proactively injected, application system logs are collected in real time, and the abnormal log characteristics corresponding to the generated abnormal scenarios are recorded. Identify the characteristics of exception logs corresponding to abnormal scenarios from the product documentation of basic software or open-source software and the development specifications of industry-developed basic frameworks or platforms.

4. The method as described in claim 1, characterized in that, Also includes: Convert the monitoring package template into the corresponding monitoring alarm template; The monitoring and alarm template includes: alarm title and alarm content. The alarm title includes the name of the basic component and the abnormal scenario, which can directly locate the abnormal basic component through the title. The alarm content records detailed abnormal log characteristics and possible abnormal causes, and provides guidance for alarm handling.

5. The method as described in claim 1, characterized in that, Extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time, including: extracting abnormal log features that match the current monitoring package template from each application system to be monitored in real time through an Agent proxy.

6. The method as described in claim 1, characterized in that, Extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time, including: using regular expressions to extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time.

7. The method as described in claim 1, characterized in that, Extract the basic component types used by each application system to be monitored, including: extracting the basic component types used by each application system to be monitored from the configuration management database (CMDB).

8. A device for scenario-based monitoring components from an application perspective, characterized in that, include: The extraction unit is used to extract the basic component types used by each application system to be monitored. The matching unit is used to match the applicable current monitoring package template from the pre-built application system scenario-based monitoring package library according to the basic component type used by each application system to be monitored. The application system scenario-based monitoring package library includes multiple basic component types as service providers, historical abnormal scenarios, and the relationship between the historical abnormal log characteristics, alarm conditions and alarm methods of the application system as monitoring package templates. The monitoring unit is used to extract abnormal log features that match the current monitoring package template from each application system to be monitored in real time. When the alarm conditions are met, an alarm event ticket is generated through the monitoring alarm template corresponding to the current monitoring package template, and the alarm event ticket is sent to the preset personnel terminal.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images