Method, device and equipment for processing alarm information

Abstract

The present application discloses a method, device and equipment for processing alarm information, which relates to the field of information processing technology, and can aggregate errors with the same cause into an error set, which plays a role in noise reduction for the monitoring system, thereby reducing the number of errors in the alarm information. The method includes: receiving at least one alarm message reported by a monitoring client, the alarm message includes multiple errors, obtaining link tracking identifiers corresponding to the multiple errors according to the at least one alarm message, using the link tracking identifier to query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error, and in response to the processing of the alarm message, using the link topology relationship corresponding to the error and the abnormal log information corresponding to the error, performing aggregation processing on the multiple errors, so that the errors in the alarm message are divided into error sets of different error types.

Description

Technical Field

[0001] The present application relates to the field of information processing technology, and in particular to a method, device and equipment for processing alarm information. Background Art

[0002] With the continuous development of the Internet industry, the application scenarios of e-commerce are becoming increasingly diverse. With users at the center, link reconstruction of the basic elements in e-commerce will evolve into various deployment modes.

[0003] When the deployment mode of related technologies evolves into distributed and microservice scenarios, longer links and upstream and downstream relationships are often constructed. Once the monitoring system detects an anomaly, the anomaly will be associated with multiple errors. At this time, the monitoring system will count the number of errors. When the number of errors exceeds the threshold, an alarm message will be generated, which will generate a large number of alarm messages. However, the same error message may be recorded in a large number of alarm messages, so that the same error message needs to be repeatedly screened and processed, which distracts the attention of troubleshooting, complicates the problem, and affects the efficiency of alarm information processing. Summary of the invention

[0004] In view of this, the present application provides a method, device and equipment for processing alarm information, the main purpose of which is to solve the problem in the prior art that the same error may be recorded in a large amount of alarm data, so that the same error needs to be repeatedly screened and processed, affecting the processing efficiency of the alarm information.

[0005] According to a first aspect of the present application, a method for processing alarm information is provided, which is applied to a server, and the method includes:

[0006] Receiving at least one alarm message reported by a monitoring client, wherein the alarm message includes multiple error reports;

[0007] According to the at least one alarm information, obtaining link tracking identifiers corresponding to multiple error reports, and using the link tracking identifiers to query link topology relationships corresponding to the error reports and abnormal log information corresponding to the error reports;

[0008] In response to the processing of the alarm information, the multiple errors are aggregated using the link topology relationship corresponding to the error and the abnormal log information corresponding to the error, so that the errors in the alarm information are divided into error sets of different error types.

[0009] Further, obtaining link tracking identifiers corresponding to multiple error reports according to the at least one alarm information, and using the link tracking identifier to query the link topology relationship corresponding to the error report and the abnormal log information corresponding to the error report, includes:

[0010] According to the at least one alarm information, obtaining link tracking identifiers corresponding to the multiple error reports from the associated logs of the request calls corresponding to the multiple error reports;

[0011] The link tracking identifier is used to query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error from the troubleshooting log data source.

[0012] Further, in response to the processing of the alarm information, the multiple error reports are aggregated using the link topology relationship corresponding to the error report and the abnormal log information corresponding to the error report, so that the error reports in the alarm information are divided into error report sets of different error report types, including:

[0013] In response to the processing of the alarm information, a first aggregation processing is performed on multiple error reports using the link topology relationship corresponding to the error reports, so that the error reports with the same topology structure in the alarm information are classified into an error report set of one error report type;

[0014] The errors with the same topological structure are aggregated for the second time using the abnormal log information corresponding to the errors, so that the errors with the same cause in the alarm information are classified into an error set of one error type.

[0015] Further, the first aggregation processing of multiple error reports using the link topology relationship corresponding to the error reports so that the error reports with the same topology structure in the alarm information are classified into an error report set of one error report type includes:

[0016] Using the link topology relationship corresponding to the error report, tracking the link information of the request call corresponding to the error report, wherein the link information at least records the service sequence of the request call;

[0017] According to the service sequence of the request call, the errors with the same service sequence are subjected to a first aggregation process, so that the errors with the same topological structure in the alarm information are classified into an error set of one error type.

[0018] Further, the error reports with the same topological structure are aggregated for the second time using the abnormal log information corresponding to the error reports, so that the error reports with the same cause in the alarm information are classified into an error report set of one error report type, including:

[0019] Using the abnormal log information corresponding to the error report, perform feature value calculation on the abnormal log information to obtain a feature string corresponding to the abnormal log in the error report;

[0020] Compare the character strings corresponding to the abnormal log in the error report to see if they are consistent;

[0021] If they are consistent, a second aggregation process is performed on the errors with the same topological structure, so that the errors with the same cause in the alarm information are classified into an error set of the same error type.

[0022] Further, the abnormal log information corresponding to the error is used to calculate the characteristic value of the abnormal log information to obtain the characteristic string corresponding to the abnormal log, including:

[0023] Using the exception log information corresponding to the error report, obtaining the error details information recorded in the form of a stack in the exception log;

[0024] After deleting sensitive information from the error details information, determining a characteristic row in the exception log information where the error details information occurs;

[0025] The characteristic line where the error detail information occurs is converted into a character string in the form of a stack to obtain a characteristic character string corresponding to the exception log.

[0026] According to a second aspect of the present application, a method for processing alarm information is provided, which is applied to a monitoring client, and the method includes:

[0027] Deploy multiple monitoring points in a distributed system and aggregate the errors reported by the monitoring points;

[0028] When the number of error reports occurring at a monitoring point is greater than a set number, alarm information of the monitoring point is generated. One alarm information is generated for each monitoring point, and the alarm information includes multiple error reports.

[0029] The alarm information of the monitoring point is reported to the server, so that the server uses the link topology relationship corresponding to the error in the alarm information and the abnormal log information corresponding to the error to aggregate the multiple errors and obtain an error set of different error types.

[0030] Furthermore, the deploying of multiple monitoring points in the distributed system and aggregating the errors generated by the monitoring points include:

[0031] Deploy multiple monitoring points in a distributed system and obtain link information corresponding to the monitoring points in the distributed system;

[0032] Determine the application resource associated with the monitoring point according to the link information, and when the application resource is abnormal, trigger the monitoring point to generate an error report, and the error report is recorded in the monitoring log;

[0033] Scan the monitoring logs and summarize the errors that occurred at the monitoring points.

[0034] Furthermore, the method further comprises:

[0035] Receive error sets of different error types, analyze abnormal call causes corresponding to the error sets, and locate abnormal links in link information of the request call according to the abnormal call causes.

[0036] According to a third aspect of the present application, a device for processing alarm information is provided, the device comprising:

[0037] A receiving unit, configured to receive at least one alarm message reported by a monitoring client, wherein the alarm message includes multiple error reports;

[0038] A query unit, configured to obtain link tracking identifiers corresponding to multiple error reports according to the at least one alarm information, and query link topology relationships corresponding to the error reports and abnormal log information corresponding to the error reports using the link tracking identifiers;

[0039] The aggregation unit is used to respond to the processing of the alarm information, and utilize the link topology relationship corresponding to the error and the abnormal log information corresponding to the error to aggregate the multiple errors so that the errors in the alarm information are divided into error sets of different error types.

[0040] Furthermore, the query unit is specifically used to obtain link tracking identifiers corresponding to multiple error reports from the associated logs called by the request corresponding to the multiple error reports based on the at least one alarm information; and use the link tracking identifier to query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error from the troubleshooting log data source.

[0041] Furthermore, the polymerization unit comprises:

[0042] A first aggregation module, configured to perform a first aggregation process on multiple error reports in response to the processing of the alarm information by using the link topology relationship corresponding to the error reports, so that the error reports with the same topology structure in the alarm information are classified into an error report set of one error report type;

[0043] The second aggregation module is used to perform a second aggregation process on the errors with the same topological structure using the abnormal log information corresponding to the errors, so that the errors with the same cause in the alarm information are classified into an error set of one error type.

[0044] Furthermore, the first aggregation module is specifically used to utilize the link topology relationship corresponding to the error to track the link information of the request call corresponding to the error, and the link information at least records the service order of the request call; according to the service order of the request call, the errors with the same service order are subjected to the first aggregation processing, so that the errors with the same topology structure in the alarm information are divided into an error set of one error type.

[0045] Furthermore, the second aggregation module is specifically used to use the exception log information corresponding to the error report to calculate the characteristic value of the exception log information, and obtain the characteristic character string corresponding to the exception log in the error report; compare whether the character string corresponding to the exception log in the error report is consistent; if consistent, perform a second aggregation processing on the errors with the same topological structure, so that the errors with the same cause in the alarm information are divided into an error set of one error type.

[0046] Furthermore, the second aggregation module is specifically used to use the exception log information corresponding to the error report to obtain the error detail information recorded in the form of a stack in the exception log; after deleting sensitive information from the error detail information, determine the characteristic lines where the error detail information occurs in the exception log information; convert the characteristic lines where the error detail information occurs into strings in the form of a stack to obtain the characteristic strings corresponding to the exception log.

[0047] According to a fourth aspect of the present application, a device for processing alarm information is provided, the device comprising:

[0048] A summarizing unit, used to deploy multiple monitoring points in a distributed system and summarize the errors generated by the monitoring points;

[0049] A generating unit, configured to generate alarm information of a monitoring point when the number of error reports occurring at the monitoring point obtained by statistics is greater than a set number, wherein one alarm information is generated corresponding to one monitoring point, and the alarm information includes multiple error reports;

[0050] The reporting unit is used to report the alarm information of the monitoring point to the server, so that the server uses the link topology relationship corresponding to the error in the alarm information and the abnormal log information corresponding to the error to aggregate the multiple errors and obtain an error set of different error types.

[0051] Furthermore, the aggregation unit is specifically used to deploy multiple monitoring points in a distributed system, obtain link information corresponding to the monitoring points in the distributed system; determine the application resources associated with the monitoring points based on the link information, and when the application resources are abnormal, trigger the monitoring point to report an error, and the error is recorded in the monitoring log; scan the monitoring log and summarize the errors occurring at the monitoring points.

[0052] Furthermore, the device also includes:

[0053] The positioning unit is used to receive an error set of different error types, analyze the abnormal call cause corresponding to the error set, and locate the abnormal link in the link information of the request call according to the abnormal call cause.

[0054] According to a fifth aspect of the present application, a storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the above-mentioned method for processing alarm information is implemented.

[0055] According to the sixth aspect of the present application, there is provided an alarm information processing device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the above-mentioned alarm information processing method when executing the program.

[0056] By means of the above technical scheme, the present application provides a method, device and equipment for processing alarm information. Compared with the method of generating alarm information when the number of monitored errors exceeds a threshold in the prior art, the present application receives at least one alarm information reported by a monitoring client, and the alarm information includes multiple errors. According to the at least one alarm information, a link tracking identifier corresponding to the multiple errors is obtained, and the link tracking identifier is used to query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error. In response to the processing of the alarm information, the link topology relationship corresponding to the error and the abnormal log information corresponding to the error are used to aggregate the multiple errors, so that the errors in the alarm information are divided into error sets of different error types. This process can record the topological relationship corresponding to the essential link of the alarm information through the link tracking identifier in the alarm information, and use the abnormal log information on the basis of the consistent topological relationship to aggregate the errors with the same cause into an error set, which plays a role in noise reduction for the monitoring system, thereby reducing the number of errors in the alarm information, avoiding a large number of repeated alarms in the alarm information, and improving the processing efficiency of the alarm information.

[0057] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0059] Figure 1 A schematic diagram showing a flow chart of a method for processing alarm information provided by an embodiment of the present application;

[0060] Figure 2 A schematic diagram showing a flow chart of another method for processing alarm information provided by an embodiment of the present application;

[0061] Figure 3A flowchart corresponding to the process of processing alarm information provided by an embodiment of the present application is shown;

[0062] Figure 4 The interactive link diagram formed by the processing process of the alarm information provided by the embodiment of the present application is shown

[0063] Figure 5 A schematic diagram showing the structure of a device for processing alarm information provided by an embodiment of the present application is shown;

[0064] Figure 6 A schematic diagram of the structure of another alarm information processing device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0065] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that the embodiments and features in the embodiments of the present application can be combined with each other without conflict.

[0066] When the deployment mode of related technologies evolves into distributed and microservice scenarios, longer links and upstream and downstream relationships are often constructed. Once the monitoring system detects an anomaly, the anomaly will be associated with multiple errors. At this time, the monitoring system will count the number of errors. When the number of errors exceeds the threshold, an alarm message will be generated, which will generate a large number of alarm messages. However, the same error message may be recorded in a large number of alarm messages, so that the same error message needs to be repeatedly screened and processed, which distracts the attention of troubleshooting, complicates the problem, and affects the efficiency of alarm information processing.

[0067] In order to solve this problem, this embodiment provides an alarm information processing system, including a monitoring client and a server, where the monitoring client can deploy multiple monitoring points in a distributed system, summarize the errors occurring at the monitoring points, and generate alarm information of the monitoring points when the number of errors occurring at the monitoring points is greater than the set number. One alarm information is generated for each monitoring point, and the alarm information includes multiple errors, and the alarm information of the monitoring points is reported to the server. The server can receive at least one alarm information reported by the monitoring client, obtain the link tracking identifier corresponding to the multiple errors according to the at least one alarm information, query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error by using the link tracking identifier, and in response to the processing of the alarm information, aggregate the multiple errors by using the link topology relationship corresponding to the error and the abnormal log information corresponding to the error, so that the errors in the alarm information are divided into error sets of different error types. In an actual application scenario, the monitoring system will send the alarm information to the server, and the server will aggregate the multiple errors in the alarm information by using the link tracking identifier corresponding to the error in the alarm information, so as to aggregate the errors with the same cause together and avoid repeated errors in the alarm information.

[0068] Specifically, this embodiment provides a method for processing alarm information, which is applied to a server, such as Figure 1 As shown, the following steps are included:

[0069] 101. Receive at least one alarm message reported by a monitoring client.

[0070] Normally, if there is a service failure in the online environment, such as resource overload, business logic error, etc., it will directly affect the normal use of the service by users. Therefore, when a failure occurs, the operation and maintenance personnel will be informed of the failure in the form of an alarm message. Among them, the alarm information includes multiple errors. In the online system, the health of the service is monitored through the monitoring client, such as the business interface response time, key performance indicators, etc. Specifically, the error can be scanned by the monitoring client. The monitoring client will scan the error in the monitoring log at regular or interval times. When the number of errors reaches the preset value, an alarm message is generated and sent to the server.

[0071] It is understandable that the alarm information records the relevant information of each error, including the error type, error location, and the final identifier of the link corresponding to the error. Considering the evolution of different service architectures, the error in the alarm information will also appear in different forms when using different service architectures. For example, in the SOA service architecture, services communicate through simple and precisely defined interfaces, without involving underlying programming interfaces and communication models. The service call process is relatively simple, and the length of the link corresponding to the error is usually short. In the microservice architecture, services are split according to different dimensions. A request often involves multiple services, and application services are often built on different software module sets. The length of the link corresponding to the error is usually long. In the complex microservice architecture, almost every request will form a complex distributed service call link. For example, when the user triggers a browser request, it first enters application A, and then enters application B, application C, and the message server from application A, then enters application F and application G from application B, enters application G from application C, enters application C and application D from the message server, enters application G from application D, and finally enters the database from application F and application G. Once an error occurs in a distributed link, it will be associated with multiple errors. Take the above as an example. If an error occurs when application C enters application G, then errors will occur in the links associated with application C entering application G, including application A-application C-application G, message server-application C-application G. If an error occurs in application C, errors will occur in the links associated with application C.

[0072] The executing subject of the embodiment of the present invention can be a processing device for alarm information, which can be applied to the server. Under normal circumstances, for the same alarm source in the alarm information, it can be configured to generate alarm information within a fixed time. For example, an alarm information is generated within 5 minutes. In this way, the same error will not occur continuously. However, here, only the errors within the set time interval are summarized into one alarm information, and it cannot be guaranteed whether there are repeated errors in the alarm information generated multiple times. It is difficult to avoid repeated processing of errors. The embodiment of the present invention can aggregate multiple errors in the alarm information, so that errors with the same cause can be processed centrally, thereby improving the processing efficiency of the alarm information.

[0073] 102. According to the at least one alarm information, obtain link tracking identifiers corresponding to multiple error reports, and use the link tracking identifier to query the link topology relationship corresponding to the error report and the abnormal log information corresponding to the error report.

[0074] In the distributed service framework, when a network request flows in from the gateway, it is possible to call multiple services to process the network request and obtain the final processing result. In this process, the communication between each service is a separate network request. No matter which service the request passes through fails or processes too slowly, an error will be generated. In order to facilitate the query of the error link where the service has a problem, a distributed link tracking method can usually be used. Here, link tracking is the entire link view of the network request in the distributed system. In the entire network request call chain, the network request will always carry the link tracking identifier to pass to the downstream service. The link tracking identifier remains unchanged throughout the entire call chain of the network request, and then the link tracking identifier can be used in the log to query all logs recorded by the system during the entire request.

[0075] Considering that the alarm information usually includes multiple errors, each error corresponds to a link tracking identifier. There are many ways to obtain the link tracking identifier. As one way to obtain it, since most user requests are initiated on the end device, the best place to generate the link tracking identifier is on the end device, through the request pass-through to the back-end service, and then when debugging through the browser developer mode, the link tracking identifier corresponding to each error can be obtained in the current test request; as another way to obtain it, the gateway is a proxy transit station for all user requests to the back-end service, which can be regarded as the entrance to the back-end service. By adding the link tracking identifier to the gateway's access log, the trajectory and cause of each abnormal access can be quickly analyzed, so that the link tracking identifier can be obtained through the gateway's access log; as another way to obtain it, various business or system rows, intermediate states and results , it will be recorded in the application log during the development and coding process. The application log is a highly readable log. The link tracking identifier can also be recorded in the application log for association. Once a business exception occurs, the error can be located through the application log, and the other information of the upstream and downstream dependencies of the application can be traced through the associated link tracking identifier to finally locate the root cause of the problem. As another way to obtain it, in a distributed system, most applications rely on some external components, such as databases, messages, configuration centers, etc. External components often have exceptions, affecting the overall availability of application services, but external components are usually shared. The link tracking identifier can be transparently passed to the external component in advance and associated in the component log. At the same time, the component log query permission is opened, so that the link tracking identifier corresponding to the error can be obtained through the component log.

[0076] The link topology relationship corresponding to the error here is the entire call chain of the network request. Specifically, the link topology relationship records some basic features of the call chain itself, such as interface name, application call sequence, request status, response time, node IP, IP, application, etc. These basic information can be used as the basis for aggregating errors. For example, errors with the same application call sequence are aggregated, and errors with the same interface name are aggregated. The exception log information corresponding to the error here is the error log details of each application. Specifically, the application crash information is recorded in the exception log information, which usually contains the stack call information of each execution thread. The main log content includes the following three parts: the first part is the crash information, including identification, software and hardware information, and time information, etc. The second part is the memory page allocation information, as well as the process that currently occupies the most memory. The third part is the process list, which describes the memory usage and current status of each process.

[0077] Generally, a call chain can be considered as an undirected ring graph composed of multiple spans. The call relationship between each span can be directly seen through the call chain, and the link topology relationship between systems can be further abstracted. A single call chain may not be complete. The link topology relationship needs to summarize a large number or all call chains to be complete. Here, the link topology relationship includes the interface level and the application level. The application-level topology can be generated based on the interface-level topology. The specific interface topology calculation mainly analyzes and summarizes a large amount of call chain data to derive the relationship between the interfaces. First, the direct upstream and downstream corresponding to the interface are calculated, and then the cascade calculation is a complete topology diagram, that is, a complete link topology relationship including indirect upstream and downstream relationships.

[0078] 103. In response to the processing of the alarm information, the multiple error reports are aggregated using the link topology relationship corresponding to the error report and the abnormal log information corresponding to the error report, so that the error reports in the alarm information are divided into error report sets of different error report types.

[0079] Considering that alarm information will generate a large number of errors, and the accumulation of a large number of errors will affect the operation of the system, here you can automatically trigger the processing of alarm information according to the set time, and you can also automatically trigger the processing of alarm information when the number of accumulated errors is greater than the set value. You can also manually customize the triggering of alarm information processing, and you can directly trigger the processing of alarm information after receiving the alarm information.

[0080] Specifically, the link topology relationship corresponding to the error report and the exception log information corresponding to the error report are combined here to perform aggregation processing on multiple error reports. On the one hand, the link topology relationship corresponding to the error report can be used to obtain the call chain corresponding to the error report, which records the requested service and the service call sequence. Further, by comparing whether the called services and the service call sequence recorded in the call chains corresponding to multiple error reports are consistent, if they are consistent, the multiple error reports are aggregated. On the other hand, by using the exception log information corresponding to the error report, the location information recorded in the exception code in the log document can be obtained, and the exception code is extracted. By comparing whether the error features contained in the exception code are the same, if they are the same, the multiple error reports are aggregated. By combining the two aggregation methods, the errors in the alarm information can be divided into error sets of different error types.

[0081] It is understandable that the increase in alarm information will be accompanied by problems such as the accumulation of errors and untimely error analysis. On the one hand, the different triggering conditions of the error make the fault notification less accurate. Usually, the monitoring client will set different error triggering conditions, for example, setting a lower CPU utilization error threshold. The generation of an error does not necessarily mean that the system has failed, but can also be a warning of the fault. On the other hand, the cause of the error is unclear, making fault analysis difficult. Most errors only have information such as the device name of the corresponding fault, the time when the error occurred, and the error phenomenon, but do not provide a clear explanation of the root cause of the fault. It may even be hidden in the alarm information, which increases the difficulty of fault analysis. The error aggregation method can be used to analyze the errors in the alarm information, and the errors with related relationships can be aggregated and merged. The aggregated errors can form an error set of a certain error type.

[0082] Compared with the method of generating alarm information when the number of monitored errors exceeds a threshold in the prior art, the method for processing alarm information provided by the embodiment of the present application receives at least one alarm information reported by the monitoring client, and the alarm information includes multiple errors. According to the at least one alarm information, the link tracking identifier corresponding to the multiple errors is obtained, and the link tracking identifier is used to query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error. In response to the processing of the alarm information, the link topology relationship corresponding to the error and the abnormal log information corresponding to the error are used to aggregate the multiple errors, so that the errors in the alarm information are divided into error sets of different error types. This process can record the topology relationship corresponding to the essential link of the alarm information through the link tracking identifier in the alarm information, and use the abnormal log information on the basis of the consistent topology relationship to aggregate the errors with the same cause into an error set, which plays a role in noise reduction for the monitoring system, thereby reducing the number of errors in the alarm information, avoiding a large number of repeated alarms in the alarm information, and improving the processing efficiency of the alarm information.

[0083] Furthermore, in order to accurately obtain the link topology relationship and abnormal log information corresponding to the error in the alarm information, specifically, it can include obtaining the link tracking identifiers corresponding to multiple error reports from the associated logs of the request calls corresponding to the multiple error reports according to at least one alarm information, and using the link tracking identifier to query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error from the troubleshooting log data source. Here, the associated log of the request call records the information within the request range, such as the execution process and time consumption of a request call. With respect to the link topology relationship, code embedding is performed at the entrance and exit of each request call to record the relationship between the calls and the processing time point information of each call. The complete link restoration of a request and the request reaching the device end are sorted out through the call relationship, and then the path of the call request through all backend services is obtained to form a link topology relationship. When an error occurs in the path, the link tracking identifier is used to save the link topology relationship corresponding to the error to the troubleshooting log data source. Regarding abnormal log information, when a job is started or runs abnormally, logs are an important means of troubleshooting. When an error occurs, the abnormal problem is usually recorded in the log stack information. The link tracking identifier can be used to request the log stack information on the link and query the abnormal characteristics in the log stack information, so as to quickly locate the abnormal log information corresponding to the error.

[0084] As the number of alarm messages increases, the number of errors accumulated by the server also increases. Here, after receiving the alarm message, the server can specifically respond to the processing of the alarm message and use the link topology relationship corresponding to the error to perform a first aggregation process on multiple errors, so that the errors with the same topology structure in the alarm message are divided into an error set of one error type, and use the exception log information corresponding to the error to perform a second aggregation process on the errors with the same topology structure, so that the errors with the same cause in the alarm message are divided into an error set of one error type.

[0085] It should be noted that, considering that the two aggregation processes take different amounts of time, and that checking abnormal log information takes a lot of time, priority is given here to aggregating errors with the same link topology structure, and performing a second, longer aggregation based on the short first aggregation, which can greatly shorten the processing efficiency of alarm information.

[0086] Specifically, during the first aggregation processing, the link topology relationship corresponding to the error can be used to track the link information of the request call corresponding to the error. The link information at least records the service order of the request call. According to the service order of the request call, the errors with the same service order are subjected to the first aggregation processing, so that the errors with the same topology structure in the alarm information are divided into an error set of the same error type. For example, there are 6 errors in the alarm information, and each error corresponds to a call chain. Error m1 corresponds to call chain A: application 1-application 2-application 4, error m2 corresponds to call chain B: application 1-application 2, error m3 corresponds to call chain C: application 1-application 2-application 3, error m4 corresponds to call chain D: application 1-application 2-application 4, error m5 corresponds to call chain E: application 1-application 2-application 4, and error m6 corresponds to call chain F: application 1-application 2. Here, the service order of request calls in the call chain corresponding to errors m1, m4, and m5 is: application 1-application 2-application 4, which can be aggregated into an error set of the same error type. The service order of request calls in the call chain corresponding to errors m2 and m6 is: application 1-application 2, which can be aggregated into an error set of the same error type.

[0087] Specifically, during the second aggregation process, the abnormal log information corresponding to the error can be used to calculate the characteristic value of the abnormal log information, obtain the characteristic string corresponding to the abnormal log in the error, and compare whether the string corresponding to the abnormal log in the error is consistent. If it is consistent, the error with the same topological structure is subjected to a second aggregation process, so that the errors with the same cause in the alarm information are divided into an error set of the same error type. For example, after the characteristic value calculation, log L1 and log L4 in the abnormal log information have the same characteristic string, which can be aggregated into an error set of the same error type, log L2 and log L6 in the abnormal log information have the same characteristic string, which can be aggregated into an error set of the same error type, and log L3 and log L5 in the abnormal log information have the same characteristic string, which can be aggregated into an error set of the same error type.

[0088] Specifically, in the process of obtaining the characteristic string corresponding to the exception log, the exception log information corresponding to the error report can be used to obtain the error details information recorded in the form of a stack in the exception log. After deleting sensitive information from the error details information, the characteristic lines where the error details information occurs in the exception log information are determined, and the characteristic lines where the error details information occurs are converted into strings in the form of a stack to obtain the characteristic string corresponding to the exception log.

[0089] Specifically, this embodiment provides a method for processing alarm information, which is applied to a monitoring client, such as Figure 2 As shown, the following steps are included:

[0090] 201. Deploy multiple monitoring points in a distributed system and summarize the errors reported by the monitoring points.

[0091] Considering that distributed systems are complex and consist of large-scale clusters, each application is quite independent, and a complete call process of the system may span multiple services and data centers. Here, full-link performance monitoring can be performed for distributed systems. Usually, multiple system services will be passed through the call chain of the request, and the call relationship is complex. During the call, various performance indicators of the call can be monitored, such as throughput, response time, and error records. Specifically, multiple monitoring points can be deployed in the distributed system, and the link information corresponding to the monitoring points in the distributed system can be obtained. The application resources associated with the monitoring points are determined based on the link information. When an exception occurs in the application resources, the monitoring points are triggered to report errors, and the errors are recorded in the monitoring logs. The monitoring logs are scanned to summarize the errors that occurred at the monitoring points.

[0092] It can be understood that after the call chain data is generated, monitoring points are deployed for all applications in the entire call process and logs are output. Monitoring points can also be set up and logs are output upstream, inside the service, and downstream of the docking respectively, and then the log data in the application is collected and stored, and various treatment operations are further performed on the log data, and the results of the operations are saved. When there is an abnormality in the log data, the alarm function is triggered to generate an error report at the monitoring point, and the errors occurring at the monitoring point are summarized.

[0093] Furthermore, while deploying multiple monitoring points in the link, alarm rules can also be arranged for the monitoring points. If the alarm rules on the monitoring point meet the conditions, the alarm function is triggered to generate an error report for the monitoring point. The specific conditions met by the alarm rule can be that the field set in the matching index contains the "error" string, and does not contain "info" and "readimed out" logs. It can be executed once a minute, and if more than one log matches the rule within 5 minutes, an email error will be triggered.

[0094] 202. When the number of error reports occurring at the monitoring point is greater than the set number, an alarm message of the monitoring point is generated.

[0095] One monitoring point generates one alarm message. The monitoring client will count the errors that occur at each monitoring point in real time. When the number of errors reaches the set number, an alarm message of the monitoring point is generated, which includes multiple errors.

[0096] It is understandable that the alarm information of the monitoring point can be triggered in the monitoring client through sound, light, email, etc., and the specific alarm information can record the corresponding time of the error, log information, call chain and other information.

[0097] 203. Report the alarm information of the monitoring point to the server, so that the server uses the link topology relationship corresponding to the error in the alarm information and the abnormal log information corresponding to the error to aggregate the multiple error reports and obtain an error set of different error types.

[0098] The specific aggregation process has been described in the server above and will not be repeated here.

[0099] Furthermore, considering the display process of alarm information, after the server aggregates the errors, the monitoring client can also receive error sets of different error types, analyze the abnormal call causes corresponding to the error sets, and locate the abnormal link in the link information of the request call according to the abnormal call causes. For example, the call link in the error set is: application A-application C-application D, and the abnormal call cause is an application request error. Further, in the request call link, it is located that the number of application dependent service requests is too large.

[0100] Here you can also set up an alarm console on the monitoring client, use the alarm console to display the service call chain diagram formed by the application in the call chain, and provide various application indicator data (including normal application indicator data and abnormal application indicator data) in the corresponding abnormal link. Users can display a certain application indicator data by selecting it on the page.

[0101] The method for processing alarm information provided by the embodiment of the present invention is compared with the method of generating alarm information when the number of monitored errors exceeds a threshold in the current prior art. The present application deploys multiple monitoring points in a distributed system, summarizes the errors that occur at the monitoring points, and generates alarm information for the monitoring points when the number of errors that occur at the monitoring points is greater than the set number. One alarm information is generated for each monitoring point, and the alarm information includes multiple errors. The alarm information of the monitoring point is reported to the server, so that the server uses the link topology relationship corresponding to the error in the alarm information and the abnormal log information corresponding to the error to aggregate the multiple errors and obtain an error set of different error types. This process can record the topology relationship corresponding to the essential link of the alarm information through the link tracking identifier in the alarm information, and use the abnormal log information on the basis of the consistent topology relationship to aggregate the errors with the same cause into an error set, which plays a role in noise reduction for the monitoring system, thereby reducing the number of errors in the alarm information, avoiding a large number of repeated alarms in the alarm information, and improving the processing efficiency of the alarm information.

[0102] In actual application scenarios, Figure 3The flowchart of the processing process of providing alarm information in an embodiment of the present invention is shown. Monitoring point A and monitoring point B are deployed in the monitoring client. By scanning the monitoring log data source, the error reports occurring at monitoring point A and the error reports occurring at monitoring point B are obtained respectively. The error reports occurring at monitoring point A correspond to call chain 1, call chain 2 and call chain 3 respectively. The error reports occurring at monitoring point B correspond to call chain 4, call chain 5 and call chain 6 respectively. According to the link tracking identifier carried by the call chain, the link topology corresponding to the error is queried from the troubleshooting log. The link topology corresponding to call chain 1, call chain 5 and call chain 6 has the same link topology structure, which is APP1-APP2-APP4. The error reports corresponding to call chain 1, call chain 5 and call chain 6 are aggregated for the first time. Call chain 2 and call chain 6 have the same link topology structure, which is APP1-APP2-APP4. For APP1-APP2, the errors corresponding to call chain 2 and call chain 6 are aggregated for the first time, and then, based on the error set formed by the first aggregation result, according to the link tracking identifier carried by the call chain, the exception log corresponding to each error in the error set is queried from the troubleshooting log, and the feature value in the exception log is calculated to obtain that log LOG1 and log LOG4 have the same feature string, and the errors corresponding to log LOG1 and log LOG4 are aggregated for the second time, log LOG2 and log LOG6 have the same feature string, and the errors corresponding to log LOG2 and log LOG6 are aggregated for the second time, log LOG3 and log LOG5 have the same feature string, and the errors corresponding to log LOG3 and log LOG5 are aggregated for the second time to obtain the final joint clustering result.

[0103] In actual application scenarios, Figure 4 The interactive link diagram formed in the process of processing alarm information provided by an embodiment of the present invention is shown. First, a monitoring client deploys multiple monitoring points in a distributed system, summarizes the errors occurring at the monitoring points, and generates alarm information for the monitoring points when the number of errors occurring at the monitoring points is greater than a set number. One alarm information is generated for each monitoring point, and the alarm information of the monitoring point is sent to the server. The server obtains link tracking identifiers corresponding to multiple errors based on the at least one alarm information, and uses the link tracking identifier to query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error. In response to the processing of the alarm information, the server uses the link topology relationship corresponding to the error and the abnormal log information corresponding to the error to aggregate the multiple errors, so that the errors in the alarm information are divided into error sets of different error types, and the error sets of different error types are sent to the monitoring client. The monitoring client analyzes the abnormal call cause corresponding to the error set, and locates the abnormal link in the link information of the request call according to the abnormal call cause.

[0104] Further, as Figure 1The specific implementation of the method, the embodiment of the present application provides a processing device for alarm information that can be applied to the server, such as Figure 5 As shown, the device includes: a receiving unit 51, a query unit 52, and an aggregation unit 53.

[0105] A receiving unit 51, configured to receive at least one alarm message reported by a monitoring client, wherein the alarm message includes multiple error reports;

[0106] A query unit 52, configured to obtain link tracking identifiers corresponding to multiple error reports according to the at least one alarm information, and query link topology relationships corresponding to the error reports and abnormal log information corresponding to the error reports using the link tracking identifiers;

[0107] The aggregation unit 53 is used to respond to the processing of the alarm information and aggregate the multiple errors using the link topology relationship corresponding to the error and the abnormal log information corresponding to the error, so that the errors in the alarm information are divided into error sets of different error types.

[0108] Compared with the method of generating alarm information when the number of monitored errors exceeds a threshold in the prior art, the alarm information processing device provided by the embodiment of the present invention receives at least one alarm information reported by the monitoring client, and the alarm information includes multiple errors. According to the at least one alarm information, the link tracking identifier corresponding to the multiple errors is obtained, and the link topology relationship corresponding to the error and the abnormal log information corresponding to the error are queried using the link tracking identifier. In response to the processing of the alarm information, the link topology relationship corresponding to the error and the abnormal log information corresponding to the error are used to aggregate the multiple errors, so that the errors in the alarm information are divided into error sets of different error types. This process can record the topology relationship corresponding to the essential link of the alarm information through the link tracking identifier in the alarm information, and use the abnormal log information on the basis of the consistent topology relationship to aggregate the errors with the same cause into an error set, which plays a role in noise reduction for the monitoring system, thereby reducing the number of errors in the alarm information, avoiding a large number of repeated alarms in the alarm information, and improving the processing efficiency of the alarm information.

[0109] In actual application scenarios, the query unit 52 is specifically used to obtain the link tracking identifiers corresponding to multiple error reports from the associated logs called by the request corresponding to the multiple error reports based on the at least one alarm information; and use the link tracking identifier to query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error from the troubleshooting log data source.

[0110] In an actual application scenario, the aggregation unit 53 includes:

[0111] A first aggregation module, configured to perform a first aggregation process on multiple error reports in response to the processing of the alarm information by using the link topology relationship corresponding to the error reports, so that the error reports with the same topology structure in the alarm information are classified into an error report set of one error report type;

[0112] The second aggregation module is used to perform a second aggregation process on the errors with the same topological structure using the abnormal log information corresponding to the errors, so that the errors with the same cause in the alarm information are classified into an error set of one error type.

[0113] In actual application scenarios, the first aggregation module is specifically used to utilize the link topology relationship corresponding to the error to track the link information of the request call corresponding to the error, and the link information at least records the service order of the request call; according to the service order of the request call, the errors with the same service order are subjected to the first aggregation processing, so that the errors with the same topology structure in the alarm information are divided into an error set of one error type.

[0114] In actual application scenarios, the second aggregation module is specifically used to use the exception log information corresponding to the error report to perform feature value calculation on the exception log information to obtain a feature character string corresponding to the exception log in the error report; compare whether the character strings corresponding to the exception log in the error report are consistent; if they are consistent, perform a second aggregation processing on the errors with the same topological structure, so that the errors with the same cause in the alarm information are divided into an error set of the same error type.

[0115] In actual application scenarios, the second aggregation module is specifically used to use the exception log information corresponding to the error report to obtain the error detail information recorded in the form of a stack in the exception log; after deleting sensitive information from the error detail information, determine the characteristic lines where the error detail information occurs in the exception log information; convert the characteristic lines where the error detail information occurs into strings in the form of a stack to obtain the characteristic strings corresponding to the exception log.

[0116] It should be noted that for other corresponding descriptions of the functional units involved in the alarm information processing device applicable to the server side provided in this embodiment, please refer to Figure 1 The corresponding description in will not be repeated here.

[0117] Further, as Figure 2 The specific implementation of the method, the embodiment of the present application provides a processing device for monitoring the alarm information of the client, such as Figure 6 As shown, the device includes: a summarizing unit 61, a generating unit 62, and a reporting unit 63.

[0118] A summarizing unit 61 is used to deploy multiple monitoring points in a distributed system and summarize the errors generated by the monitoring points;

[0119] A generating unit 62 is used to generate alarm information of the monitoring point when the number of error reports occurring at the monitoring point is greater than a set number. One alarm information is generated for each monitoring point, and the alarm information includes multiple error reports;

[0120] The reporting unit 63 is used to report the alarm information of the monitoring point to the server, so that the server uses the link topology relationship corresponding to the error in the alarm information and the abnormal log information corresponding to the error to aggregate the multiple errors and obtain an error set of different error types.

[0121] Compared with the method of generating alarm information when the number of monitored errors exceeds a threshold in the prior art, the present application deploys multiple monitoring points in a distributed system, summarizes the errors that occur at the monitoring points, and generates alarm information for the monitoring points when the number of errors that occur at the monitoring points is greater than the set number. One alarm information is generated for each monitoring point, and the alarm information includes multiple errors. The alarm information of the monitoring point is reported to the server, so that the server uses the link topology relationship corresponding to the error in the alarm information and the abnormal log information corresponding to the error to aggregate the multiple errors and obtain an error set of different error types. This process can record the topology relationship corresponding to the essential link of the alarm information through the link tracking identifier in the alarm information, and use the abnormal log information on the basis of the consistent topology relationship to aggregate the errors with the same cause into an error set, which plays a role in noise reduction for the monitoring system, thereby reducing the number of errors in the alarm information, avoiding a large number of repeated alarms in the alarm information, and improving the processing efficiency of the alarm information.

[0122] In actual application scenarios, the aggregation unit 61 is specifically used to deploy multiple monitoring points in a distributed system, obtain link information corresponding to the monitoring points in the distributed system; determine the application resources associated with the monitoring points based on the link information, and when the application resources are abnormal, trigger the monitoring point to report an error, and the error is recorded in the monitoring log; scan the monitoring log and summarize the errors that occurred at the monitoring point.

[0123] In an actual application scenario, the device further includes:

[0124] The positioning unit is used to receive an error set of different error types, analyze the abnormal call cause corresponding to the error set, and locate the abnormal link in the link information of the request call according to the abnormal call cause.

[0125] It should be noted that for other corresponding descriptions of the functional units involved in the alarm information processing device applicable to the server provided in this embodiment, please refer to Figure 2 The corresponding description in will not be repeated here.

[0126] Based on the above Figure 1 The method shown in the embodiment of the present application accordingly provides a storage medium on which a computer program is stored, and when the program is executed by a processor, the above-mentioned Figure 1 The processing method of the alarm information shown in FIG. Figure 2 The method shown in the embodiment of the present application accordingly provides another storage medium on which a computer program is stored, and when the program is executed by the processor, the above-mentioned Figure 2 The method of handling the alarm information shown.

[0127] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each implementation scenario of the present application.

[0128] Based on the above Figure 1 The method shown, and Figure 5 In order to achieve the above-mentioned purpose, the embodiment of the present application also provides a physical device of a server, which can be a computer, a smart phone, a tablet computer, a smart watch, a server, or a network device, etc. The physical device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 1 The method of handling the alarm information shown.

[0129] Based on the above Figure 2 The method shown, and Figure 6 In order to achieve the above-mentioned purpose, the embodiment of the present application also provides a client entity device, which can be a computer, a smart phone, a tablet computer, a smart watch, or a network device, etc. The entity device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 2 The method of handling the alarm information shown.

[0130] Optionally, both of the above-mentioned physical devices may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a WI-FI module, etc. The user interface may include a display screen (Display), an input unit such as a keyboard (Keyboard), etc., and the optional user interface may also include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (such as a WI-FI interface), etc.

[0131] Those skilled in the art will appreciate that the physical device structure for processing alarm information provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different component arrangements.

[0132] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device for the store search information processing, and supports the operation of the information processing program and other software and / or programs. The network communication module is used to realize the communication between the components inside the storage medium, and the communication with other hardware and software in the physical device for information processing.

[0133] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform, or by hardware. By applying the technical solution of the present application, compared with the current existing methods, the present application records the topological relationship corresponding to the essential link of the alarm information through the link tracking identifier in the alarm information, and uses the abnormal log information on the basis of the consistent topological relationship to aggregate the errors with the same cause into an error set, which plays a role in noise reduction for the monitoring system, thereby reducing the number of errors in the alarm information, avoiding a large number of repeated alarms in the alarm information, and improving the processing efficiency of the alarm information.

[0134] Those skilled in the art will appreciate that the accompanying drawings are only schematic diagrams of a preferred implementation scenario, and the modules or processes in the accompanying drawings are not necessarily necessary for implementing the present application. Those skilled in the art will appreciate that the modules in the devices in the implementation scenario can be distributed in the devices of the implementation scenario according to the description of the implementation scenario, or can be changed accordingly and located in one or more devices different from the present implementation scenario. The modules of the above-mentioned implementation scenario can be combined into one module, or can be further split into multiple submodules.

[0135] The above serial numbers of this application are only for description and do not represent the advantages and disadvantages of the implementation scenarios. The above disclosure is only a few specific implementation scenarios of this application, but this application is not limited to them, and any changes that can be thought of by technicians in this field should fall within the scope of protection of this application.

Claims

1. A method for processing alarm information, characterized in that: include: Receiving at least one alarm message reported by a monitoring client, wherein the alarm message includes multiple error reports; According to the at least one alarm information, obtaining link tracking identifiers corresponding to multiple error reports, and using the link tracking identifiers to query link topology relationships corresponding to the error reports and abnormal log information corresponding to the error reports; In response to the processing of the alarm information, the link topology relationship corresponding to the error is used to obtain the call chain corresponding to the error, and the calling services and service calling sequences recorded in the call chains corresponding to multiple error reports are compared to see if they are consistent; if they are consistent, the multiple error reports are aggregated; the exception log information corresponding to the error is used to obtain the location information recorded in the log document of the exception code, and the exception code is extracted; the error features contained in the exception code are compared to see if they are the same. If they are the same, the multiple error reports are aggregated to divide the errors in the alarm information into error sets of different error types.

2. The method according to claim 1, characterized in that The obtaining, according to the at least one alarm information, link tracking identifiers corresponding to multiple error reports, and using the link tracking identifiers to query link topology relationships corresponding to the error reports and abnormal log information corresponding to the error reports, comprises: According to the at least one alarm information, obtaining link tracking identifiers corresponding to the multiple error reports from the associated logs of the request calls corresponding to the multiple error reports; The link tracking identifier is used to query the link topology relationship corresponding to the error and the abnormal log information corresponding to the error from the troubleshooting log data source.

3. The method according to claim 1, characterized in that The processing in response to the alarm information, using the link topology relationship corresponding to the error and the abnormal log information corresponding to the error, aggregates the multiple error reports so that the errors in the alarm information are divided into error sets of different error types, including: In response to the processing of the alarm information, a first aggregation processing is performed on multiple error reports using the link topology relationship corresponding to the error reports, so that the error reports with the same topology structure in the alarm information are classified into an error report set of one error report type; The errors with the same topological structure are aggregated for the second time using the abnormal log information corresponding to the errors, so that the errors with the same cause in the alarm information are classified into an error set of one error type.

4. The method according to claim 3, characterized in that The first aggregation processing of multiple error reports using the link topology relationship corresponding to the error reports, so that the error reports with the same topology structure in the alarm information are classified into an error report set of one error report type, includes: Using the link topology relationship corresponding to the error report, tracking the link information of the request call corresponding to the error report, wherein the link information at least records the service sequence of the request call; According to the service sequence of the request call, the errors with the same service sequence are subjected to a first aggregation process, so that the errors with the same topological structure in the alarm information are classified into an error set of one error type.

5. The method according to claim 3, characterized in that: The second aggregation processing of the errors with the same topological structure by using the abnormal log information corresponding to the errors so that the errors with the same cause in the alarm information are classified into an error set of an error type includes: Using the abnormal log information corresponding to the error report, perform feature value calculation on the abnormal log information to obtain a feature string corresponding to the abnormal log in the error report; Compare the character strings corresponding to the abnormal log in the error report to see if they are consistent; If they are consistent, a second aggregation process is performed on the errors with the same topological structure, so that the errors with the same cause in the alarm information are classified into an error set of the same error type.

6. The method according to claim 5, characterized in that The method of calculating the characteristic value of the abnormal log information by using the abnormal log information corresponding to the error report to obtain the characteristic character string corresponding to the abnormal log includes: Using the exception log information corresponding to the error report, obtaining the error details information recorded in the form of a stack in the exception log; After deleting sensitive information from the error details information, determining a characteristic row in the exception log information where the error details information occurs; The characteristic line where the error detail information occurs is converted into a character string in the form of a stack to obtain a characteristic character string corresponding to the exception log.

7. A method for processing alarm information, characterized in that: include: Deploy multiple monitoring points in a distributed system and aggregate the errors reported by the monitoring points; When the number of error reports occurring at a monitoring point is greater than a set number, alarm information of the monitoring point is generated. One alarm information is generated for each monitoring point, and the alarm information includes multiple error reports. The alarm information of the monitoring point is reported to the server, so that the server uses the link topology relationship corresponding to the error to obtain the call chain corresponding to the error, and compares whether the calling services and service calling sequences recorded in the call chains corresponding to multiple error reports are consistent; if they are consistent, the multiple error reports are aggregated; the location information of the exception code recorded in the log document is obtained by using the exception log information corresponding to the error, and the exception code is extracted; by comparing whether the error features contained in the exception code are the same, if they are the same, the multiple error reports are aggregated to obtain an error set of different error types.

8. The method according to claim 7, characterized in that The deploying multiple monitoring points in the distributed system and aggregating the errors generated by the monitoring points includes: Deploy multiple monitoring points in a distributed system and obtain link information corresponding to the monitoring points in the distributed system; Determine the application resource associated with the monitoring point according to the link information, and when the application resource is abnormal, trigger the monitoring point to generate an error report, and the error report is recorded in the monitoring log; Scan the monitoring logs and summarize the errors that occurred at the monitoring points.

9. A device for processing alarm information, characterized in that: include: A receiving unit, configured to receive at least one alarm message reported by a monitoring client, wherein the alarm message includes multiple error reports; A query unit, configured to obtain link tracking identifiers corresponding to multiple error reports according to the at least one alarm information, and query link topology relationships corresponding to the error reports and abnormal log information corresponding to the error reports using the link tracking identifiers; An aggregation unit is used to respond to the processing of alarm information, use the link topology relationship corresponding to the error to obtain the call chain corresponding to the error, and compare whether the calling services and service calling sequences recorded in the call chains corresponding to multiple error reports are consistent; if they are consistent, the multiple error reports are aggregated; use the exception log information corresponding to the error to obtain the location information recorded in the log document of the exception code and extract the exception code; compare whether the error features contained in the exception code are the same, if they are the same, the multiple error reports are aggregated to divide the errors in the alarm information into error sets of different error types.

10. A device for processing alarm information, characterized in that: include: A summarizing unit, used to deploy multiple monitoring points in a distributed system and summarize the errors generated by the monitoring points; A generating unit, configured to generate alarm information of a monitoring point when the number of error reports occurring at the monitoring point obtained by statistics is greater than a set number, wherein one alarm information is generated corresponding to one monitoring point, and the alarm information includes multiple error reports; A reporting unit is used to report the alarm information of the monitoring point to the server, so that the server uses the link topology relationship corresponding to the error to obtain the call chain corresponding to the error, and compares whether the calling services and service calling sequences recorded in the call chains corresponding to multiple error reports are consistent; if they are consistent, the multiple error reports are aggregated; the location information of the exception code recorded in the log document is obtained by using the exception log information corresponding to the error, and the exception code is extracted; by comparing whether the error features contained in the exception code are the same, if they are the same, the multiple error reports are aggregated to obtain an error set of different error types.

Images