Business failure analysis method, device, electronic equipment and medium

Abstract

The present application provides a service fault analysis method, device, electronic device and medium. The method includes: obtaining service alarm information and non-service alarm information reported by the controller, and associating each service with the alarm information, wherein the service alarm information can be directly associated with the relevant service, and the non-service alarm information is indirectly associated with the service through the service end-to-end path. When a single-domain service failure is detected, the alarm information corresponding to the faulty service is obtained according to the association relationship, and the single-domain service fault analysis result is obtained by analysis. The method of the present application performs OTN dedicated line fault analysis with the service as the center, and can perform service fault analysis in a timely and accurate manner.

Description

Technical Field

[0001] The present application relates to communication technology, and in particular to a service failure analysis method, device, electronic device and medium. Background Art

[0002] Optical Transport Network (OTN) is the basic network of operators. OTN private lines have become the first choice for many customers to build their own networks and carry services due to their advantages of high bandwidth, low latency, high security, and high privacy. In actual applications, services are the direct needs of customers, and service failures are the direct mapping of OTN private line fault alarms. Therefore, fault analysis of OTN private line services is an important part of operator network maintenance.

[0003] In the prior art, fault analysis uses an XML interface protocol to obtain resource alarm information reported by a controller, and obtains a fault analysis result by analyzing and processing the obtained resource alarm information.

[0004] In the above solution, the XML interface can only be used to analyze non-business faults by analyzing resource status, while business faults rely on customer reporting and can only be passively troubleshooted, resulting in untimely business fault analysis. Summary of the invention

[0005] The present application provides a service failure analysis method, device, electronic device and medium to solve the problem that service failure analysis cannot be performed in a timely and accurate manner.

[0006] On the one hand, the present application provides a service fault analysis method, including: obtaining alarm information reported by a controller, the alarm information including service alarm information and non-service alarm information; performing association processing to establish an association relationship between each service and the alarm information, the association processing including: for the service alarm information, according to the service field in the service alarm information, establishing an association between the service alarm information and the service represented by the service field; for the non-service alarm information, according to the service end-to-end path, determining the service related to the non-service alarm information, and establishing an association between the non-service alarm information and the service; if a single-domain fault service is detected, obtaining the alarm information corresponding to the single-domain fault service according to the association relationship, and performing fault analysis according to the alarm information corresponding to the single-domain fault service to obtain a service fault analysis result.

[0007] In one possible implementation, obtaining the alarm information reported by the controller includes: establishing a long connection with the controller through the YANG-SSE or Websocket interface; receiving the message events reported by the controller through the established long connection; parsing and identifying the message events reported by the controller based on the data structure YANG model of the ACTN or T-API protocol, and obtaining the alarm information in the message event.

[0008] In a possible implementation, after obtaining the alarm information reported by the controller, it also includes: standardizing the format of the alarm information; filtering the target field in the alarm information, removing fields other than the target field in the alarm information, the target field including a field representing the information type, a field representing the time, a field representing the name, and a field representing the status, wherein the information type includes business alarm information and non-business alarm information; and writing the current alarm information into a database.

[0009] In a possible implementation, before writing the current alarm information into the database, the method further includes: removing duplicate alarms, synonymous alarms, and marginal alarms in the alarm information.

[0010] In a possible implementation, the method further includes: if a cross-domain fault service is detected, determining each single-domain service under the cross-domain fault service according to the inter-domain link and time slot allocation; detecting whether the cross-domain service fault is related to the fault of each single-domain service; if related, analyzing based on the service fault analysis results of each single-domain service in combination with a knowledge base and empirical rules to obtain a fault analysis result of the cross-domain fault service; if not related, collecting link alarm information of the cross-domain link corresponding to the cross-domain fault service, analyzing in combination with the single-domain service fault analysis results, the knowledge base and empirical rules corresponding to the cross-domain service, to obtain a fault analysis result of the cross-domain fault service.

[0011] On the other hand, the present application provides a service fault analysis device, including: an acquisition module, used to acquire alarm information reported by a controller, the alarm information including service alarm information and non-service alarm information; an association module, used to perform association processing to establish an association relationship between each service and the alarm information, the association processing including: for the service alarm information, according to the service field in the service alarm information, establishing an association between the service alarm information and the service represented by the service field; for the non-service alarm information, according to the service end-to-end path, determining the service related to the non-service alarm information, and establishing an association between the non-service alarm information and the service; an analysis module, used to obtain the alarm information corresponding to the single-domain fault service according to the association relationship if a single-domain fault service is detected, and perform fault analysis according to the alarm information corresponding to the single-domain fault service to obtain a service fault analysis result.

[0012] In one possible implementation, the acquisition module is specifically used to: establish a long connection with the controller through the YANG-SSE or Websocket interface; receive message events reported by the controller through the established long connection; parse and identify the message events reported by the controller based on the data structure YANG model of the ACTN or T-API protocol, and obtain the alarm information in the message event.

[0013] In one possible implementation, the acquisition module is also used to: standardize the format of the alarm information; filter the target fields in the alarm information and remove fields other than the target fields in the alarm information, wherein the target fields include fields representing information type, fields representing time, fields representing names, and fields representing status, wherein information types include business alarm information and non-business alarm information; and write the current alarm information into a database.

[0014] In a possible implementation, the acquisition module is further used to remove duplicate alarms, synonymous alarms, and edge alarms in the alarm information.

[0015] In a possible implementation, the device also includes: a second analysis module, which is used to determine, if a cross-domain fault service is detected, each single-domain service under the cross-domain fault service according to the inter-domain link and time slot allocation; detect whether the cross-domain service failure is related to the failure of each single-domain service; if related, analyze according to the service failure analysis results of each single-domain service, combined with the knowledge base and experience rules, to obtain the fault analysis result of the cross-domain fault service; if not related, collect link alarm information of the cross-domain link corresponding to the cross-domain fault service, combine the single-domain service failure analysis results corresponding to the cross-domain service, the knowledge base and the experience rules for analysis, and obtain the fault analysis result of the cross-domain fault service.

[0016] On the other hand, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method described above.

[0017] On the other hand, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the method as described above.

[0018] In the service fault analysis method, device, electronic device and medium provided by the present application, the service alarm information and non-service alarm information reported by the controller are obtained, and each service is associated with the alarm information, wherein the service alarm information can be directly associated with the relevant service, and the non-service alarm information is indirectly associated with the service through the service end-to-end path. When a single-domain service failure is detected, the alarm information corresponding to the faulty service is obtained according to the association relationship, and the single-domain service fault analysis result is obtained by analysis. The present application obtains service alarm information and non-service alarm information, and associates the alarm information with the service to obtain the service fault analysis result, thereby solving the problem that it is impossible to perform service-centric fault analysis on the OTN dedicated line and it is impossible to perform service fault analysis in a timely and accurate manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0020] Figure 1 A flow chart of a service fault analysis method provided in Embodiment 1 of the present application is exemplarily shown in FIG.

[0021] Figure 2 exemplarily shows a flow chart of another service fault analysis method provided in Embodiment 1 of the present application;

[0022] Figure 3 A flow chart of another service fault analysis method provided in Embodiment 1 of the present application is exemplarily shown in FIG.

[0023] Figure 4 The flowchart of the cross-domain service fault analysis method provided in the first embodiment of the present application is exemplarily shown in FIG.

[0024] Figure 5 The schematic diagram of the architecture of the cross-domain service provided in the first embodiment of the present application is exemplarily shown in FIG.

[0025] Figure 6 The structure diagram of the service fault analysis device provided in the second embodiment of the present application is exemplarily shown in FIG.

[0026] Figure 7 The structural diagram of the business fault analysis electronic device provided in Example 3 of the present application is exemplarily shown in FIG.

[0027] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0028] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0029] The module in this application refers to a functional module or a logic module. It can be in the form of software, where the processor executes program code to realize its function, or it can be in the form of hardware.

[0030] First, the terms involved in this application are explained:

[0031] ACTN (Abstraction and Control of Traffic Engineered Networks): refers to the northbound interface standard of OTN controllers led by IETF. Its architecture meets the basic layered model of SDN, and is divided into forwarding layer, intermediate control layer, and application layer from south to north. For ACTN controllers, the underlying equipment is the OTN physical network topology, and the controller is used to complete the control configuration. The control plane implements operations such as full network topology maintenance, point information collection, configuration of flow table information, and full network routing in a hierarchical control manner. At the same time, it provides an application-oriented northbound open interface, which is sent to the control unit through this interface to automatically complete the routing and forwarding deployment. The application layer is mainly for application deployment based on SDN technology. Through customized management applications such as network management systems, the interaction logic at the control and forwarding levels is reduced, and rapid service deployment is achieved through software API programming.

[0032] T-API (Transport API): refers to the northbound interface standard of the former OTN controller led by ONF. In the T-API interface model, a single physical network node is abstracted into three layers of nodes: ETH layer, ODU layer, and OCH layer. On each layer of nodes, NEP (NodeEdge Point) corresponds to the physical port, and SIP is used to describe the service start and end points. The equipment manufacturer's controller has the ability to abstract link information and SIP information. Different layers are connected through inter-layer links, nodes within a layer are connected through intra-layer links, and are connected to other network domains through inter-domain links. There are several NEPs on each node in the abstract layer, and each NEP corresponds to several SIPs.

[0033] Software Defined Network (SDN) refers to a new type of innovative network architecture and a way to implement network virtualization. Its core technology, OpenFlow, separates the control plane from the data plane of network devices, thereby achieving flexible control of network traffic, making the network more intelligent and providing a good platform for innovation of core networks and applications.

[0034] Optical Transport Network (OTN) is the basic network of operators. Due to the advantages of high bandwidth, low latency, high security and high privacy, OTN dedicated lines have become the first choice for many customers to organize their own networks and carry services. With the maturity and large-scale commercial use of SDN technology, the disadvantages of traditional OTN dedicated lines, which rely on customer reports for service failures and passive troubleshooting, are becoming increasingly prominent.

[0035] In order to promote the SDN of OTN dedicated lines, this application proposes to obtain business alarm information and non-business alarm information from the controller, and associate the alarm information with the business for analysis, so as to realize business-centric fault analysis of OTN dedicated lines.

[0036] The technical solution of the present application is illustrated below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0037] Embodiment 1

[0038] Figure 1 The flowchart of the service failure analysis method provided by an embodiment of the present application is as follows. Figure 1 As shown, the service failure analysis method provided in this embodiment may include:

[0039] S101, obtaining alarm information reported by a controller, wherein the alarm information includes business alarm information and non-business alarm information;

[0040] S102, performing association processing to establish an association relationship between each service and the alarm information, the association processing comprising: for the service alarm information, according to the service field in the service alarm information, establishing an association between the service alarm information and the service represented by the service field; for the non-service alarm information, according to the service end-to-end path, determining the service related to the non-service alarm information, and establishing an association between the non-service alarm information and the service;

[0041] S103: If a single-domain faulty service is detected, alarm information corresponding to the single-domain faulty service is obtained according to the association relationship, and fault analysis is performed according to the alarm information corresponding to the single-domain faulty service to obtain a service fault analysis result.

[0042] In practical applications, the executor of this embodiment may be a business fault analysis device, which may be implemented through a computer program, such as application software, etc.; or, it may be implemented as a medium storing relevant computer programs, such as a USB flash drive, a cloud disk, etc.; or, it may be implemented through a physical device integrated or installed with relevant computer programs, such as a chip, a server, etc.

[0043] Specifically, the service fault analysis device obtains alarm information from the controller, wherein the alarm information includes service class (such as service status, service details, etc.) and non-service class. In actual applications, non-service class alarm information can specifically include resource class alarm information (such as network element, port, link, layer, etc.) and performance class alarm information (such as delay, rate, bandwidth, etc.), which can be selected according to the interface protocol used and the actual production needs, and are not limited here. For example, the service fault analysis device can obtain service alarm information and non-service alarm information from the controller through the ACTN protocol and the T-API protocol, including resource class alarm information and performance class alarm information. After obtaining the alarm information, the alarm information is associated with each service, wherein the service alarm information can be directly associated with the service, and the corresponding service can be matched according to the service name field in the alarm information; for non-service class alarm information, the alarm information related to the equipment and link passed through can be associated from the service route according to the service end-to-end path, thereby establishing an association. Since service failures may cause changes in service status, such as changes in the status and performance of related network elements, links in the service path, these changes can be extracted by obtaining the alarm information corresponding to the single-domain fault service, and then integrated, analyzed and processed. Finally, the fault point and fault cause can be analyzed as the single-domain service fault analysis result. Finally, the fault demarcation result and fault point can be sent to users and other systems through Restful protocols and other methods.

[0044] For example, assuming that a certain OTN dedicated line service is currently degraded, the service fault analysis device can obtain alarm information from the controller, including service class, resource class, and performance class. Among them, service alarm information indicates that the service is in a degraded state, resource class alarm information indicates that some equipment links are abnormal, and performance class alarm information indicates that the rate is slow. Among them, the service alarm information represents the service status and service details of the service, and can be directly associated with the service; the resource alarm information can be determined according to the end-to-end path of the service, and the network element, link, and port passed by the service are determined, and the corresponding resource alarm information is associated with the service. Match the alarm information associated with the service, list the possible causes of the fault, and finally combine the knowledge base and experience rules to prioritize all the causes of the fault, find out the key causes, and finally output the cause of the fault of the service as a certain network element interruption.

[0045] There are many ways to obtain the alarm information reported by the controller. Figure 2 A flowchart of another service fault analysis method provided in an embodiment of the present application is shown as follows: Figure 2 As shown, in one example, S101 may specifically include:

[0046] S201, establish a long connection with the controller through YANG-SSE or Websocket interface;

[0047] S202, receiving a message event reported by the controller through the established long connection;

[0048] S203: Based on the data structure YANG model of ACTN or T-API protocol, parse and identify the message event reported by the controller to obtain the alarm information in the message event.

[0049] Specifically, the service fault analysis device establishes a long connection with the controller through the YANG-SSE or Websocket interface, thereby establishing a listening channel and receiving the message events pushed by the controller. In combination with the data structure YANG model of the ACTN and T-API protocols, the message events reported by the controller are parsed, and the alarm information is parsed from the message events, thereby realizing the SDN of traditional services. For example, "down" in the ACTN protocol is a field representing an alarm, and "cut" in the T-API protocol is a field representing an alarm. The service fault analysis device can identify it as the actual operating status of the service based on the YANG model. In combination with the YANG model of the ACTN and T-API protocols, the service operation status can be divided into normal, off-network interruption, on-network interruption, backup path interruption and other alarm conditions.

[0050] In order to improve the accuracy of the alarm information, the alarm information can be pre-processed. Figure 3 A flowchart of another service fault analysis method provided in an embodiment of the present application is shown as follows: Figure 3 As shown, in one example, after obtaining the alarm information reported by the controller, the following steps may also be included:

[0051] S301, performing format standardization processing on the format of the alarm information;

[0052] S302, filtering the target field in the alarm information, removing fields other than the target field in the alarm information, wherein the target field includes a field representing information type, a field representing time, a field representing name, and a field representing status, wherein the information type includes business alarm information and non-business alarm information;

[0053] S303, write the current alarm information into the database.

[0054] Specifically, the alarm information obtained by the service fault analysis device through different protocols has the problem of inconsistent formats, so the format of the obtained alarm information needs to be standardized. For example, the northbound interface used by some manufacturers currently follows the ACTN standard, and the northbound interface used by some manufacturers follows the T-API 2.0 standard. The incompatibility of the northbound interface of the control system makes cross-vendor collaboration and unified orchestration objectively impossible to achieve. The service fault analysis device can unify the format of the obtained alarm information. In addition, since there will be redundant information in the alarm information, the important fields of the alarm information can be screened, and the information fields required for alarm analysis are retained. For example, for a certain resource class alarm information, its information type (here is the resource class), occurrence time, resource id, operation status and other fields are retained, and other fields not related to alarm analysis are removed. The processed alarm information is written to the database for storage, and the alarm information can be processed in memory operation so that the required alarm information can be called in real time during fault analysis.

[0055] Through the above processing, the format of the alarm information can be unified, important information fields can be screened out, and written into the database, thereby improving the quality of information and the accuracy of subsequent fault analysis.

[0056] Furthermore, to improve the effectiveness of the warning information, in one example, before S303, the following steps may also be included:

[0057] The duplicate alarms, synonymous alarms and marginal alarms in the alarm information are removed.

[0058] Specifically, there will be a large number of irrelevant alarms under a single domain controller, and duplicate alarms, synonymous alarms, and edge alarms in the alarm information are deleted and deduplicated. For example, alarm compression technology can be used to remove duplicate alarms, synonymous alarms, and edge alarms in the alarm information. The technical means used can be selected according to the actual application and are not limited here. The above operations can be used to retain valid alarm information and improve the efficiency of fault analysis.

[0059] After obtaining the single-domain service failure analysis results, you can further analyze cross-domain service failures. Figure 4 A flow chart of a cross-domain service fault analysis method provided in an embodiment of the present application is shown as follows: Figure 4 As shown, in one example, the method may further include:

[0060] S401, if a cross-domain fault service is detected, determining each single-domain service under the cross-domain fault service according to the inter-domain link and time slot allocation;

[0061] S402, detecting whether the cross-domain service failure is related to the failure of each single-domain service;

[0062] If relevant, executing S403, analyzing according to the service fault analysis results of each single-domain service in combination with the knowledge base and the experience rules to obtain the fault analysis result of the cross-domain fault service;

[0063] If not, execute S404 to collect link alarm information of the cross-domain link corresponding to the cross-domain fault service, and analyze it in combination with the single-domain service fault analysis result, knowledge base and experience rules corresponding to the cross-domain service to obtain the cross-domain service fault analysis result.

[0064] Specifically, the cross-domain service is composed of multiple segments of single-domain services. Therefore, for the cross-domain fault service, the single-domain services corresponding to the cross-domain fault service can be determined, and the analysis of the cross-domain fault service can be realized by analyzing the single-domain services. Different single-domain services are connected and combined by inter-domain links. Therefore, according to the inter-domain links and their time slot allocation, the determination of each single-domain service under the cross-domain fault service can be realized. The fault point of the cross-domain service failure can be divided into intra-domain and inter-domain. By judging whether the fault of the cross-domain service is related to the fault of each corresponding single-domain service, the judgment of the fault point of the cross-domain service can be realized. If the fault of the cross-domain service is related to the fault of each corresponding single-domain service, the fault point of the cross-domain service is within the domain; if the fault of the cross-domain service is not related to the fault of each corresponding single-domain service, the fault point of the cross-domain service is between domains. For intra-domain faults, the alarm information of each single domain is collected for fault analysis, and the cross-domain business fault analysis results are obtained based on the business fault analysis results of each single domain business; for intra-domain faults, the inter-domain alarm information is combined with the single domain business fault analysis results for analysis.

[0065] For example, Figure 5 A schematic diagram of the architecture of a cross-domain service provided in an embodiment of the present application, such as Figure 5 As shown in the figure, assuming that there is currently a long-distance telephone service between Beijing and Guangzhou, and the service is interrupted, as a cross-domain service failure, it can be determined that the single-domain services corresponding to the service are Beijing telephone service and Guangzhou telephone service. The telephone services of Beijing and Guangzhou are analyzed respectively, and it is found that the telephone services of Beijing and Guangzhou are in normal state. It is determined that the long-distance telephone service failure is not related to the corresponding single-domain service failure, and the fault point is between domains. From the managed inter-domain information, the alarm information such as the status and performance of the cross-domain link related to the service is loaded. According to the status change, performance change and single-domain analysis results of the inter-domain link, combined with the expert knowledge base and experience algorithm, it is determined that the cause of the cross-domain service failure is the interruption of a certain link.

[0066] The OTN network and its management and control system are independent domains, which form barriers to each other and lack unified cross-domain and cross-vendor collaboration. This solution combines the single-domain service fault analysis results for further analysis to obtain cross-domain service fault analysis results, thereby realizing cross-domain fault analysis.

[0067] In the service fault analysis method provided in this embodiment, the service alarm information and non-service alarm information reported by the controller are obtained, and each service is associated with the alarm information, wherein the service alarm information can be directly associated with the relevant service, and the non-service alarm information is indirectly associated with the service through the service end-to-end path. When a single-domain service failure is detected, the alarm information corresponding to the faulty service is obtained according to the association relationship, and the single-domain service fault analysis result is obtained by analysis. This application obtains service alarm information and non-service alarm information, and associates the alarm information with the service to obtain the service fault analysis result, thereby realizing service-centric fault analysis of the OTN dedicated line, solving the problem of not being able to perform service fault analysis in a timely and accurate manner.

[0068] Embodiment 2

[0069] Figure 6 This is a schematic diagram of the structure of a service failure analysis device provided by an embodiment of the present application. Figure 6 As shown, the service failure analysis device provided in this embodiment may include:

[0070] An acquisition module 61 is used to acquire alarm information reported by the controller, wherein the alarm information includes business alarm information and non-business alarm information;

[0071] The association module 62 is used to perform association processing to establish an association relationship between each service and the alarm information, wherein the association processing includes: for the service alarm information, according to the service field in the service alarm information, establishing an association between the service alarm information and the service represented by the service field; for the non-service alarm information, according to the service end-to-end path, determining the service related to the non-service alarm information, and establishing an association between the non-service alarm information and the service;

[0072] The analyzing device 63 is used for obtaining the alarm information corresponding to the single-domain faulty service according to the association relationship if a single-domain faulty service is detected, and performing fault analysis according to the alarm information corresponding to the single-domain faulty service to obtain a service fault analysis result.

[0073] In actual applications, the business fault analysis device can be implemented through a computer program, such as application software, etc.; or, it can also be implemented as a medium storing relevant computer programs, such as a USB flash drive, a cloud disk, etc.; or, it can also be implemented through a physical device integrated or installed with relevant computer programs, such as a chip, a server, etc.

[0074] Specifically, the service fault analysis device obtains alarm information from the controller, wherein the alarm information includes service class and non-service class. In actual applications, non-service class alarm information may specifically include resource class alarm information and performance class alarm information, which may be selected according to the interface protocol used and the actual production needs, and are not limited here. For example, the service fault analysis device may obtain service alarm information and non-service alarm information from the controller through the ACTN protocol and the T-API protocol, including resource class alarm information and performance class alarm information. After obtaining the alarm information, an association relationship is established between the alarm information and each service, wherein the service alarm information may be directly associated with the service, and the corresponding service may be matched according to the service name field in the alarm information; for non-service class alarm information, the alarm information related to the equipment and link passed through may be associated from the service route according to the service end-to-end path, thereby establishing an association. Since service failures may cause changes in service status, such as changes in the status and performance of related network elements, links in the service path, these changes can be extracted by obtaining the alarm information corresponding to the single-domain fault service, and then integrated, analyzed and processed. Finally, the fault point and fault cause can be analyzed as the single-domain service fault analysis result. Finally, the fault demarcation result and fault point can be sent to users and other systems through Restful protocols and other methods.

[0075] There are many ways to obtain the alarm information reported by the controller. In one example, the obtaining module 61 can be specifically used to:

[0076] Establish a persistent connection with the controller through YANG-SSE or Websocket interface;

[0077] Receiving the message event reported by the controller through the established long connection;

[0078] Based on the data structure YANG model of ACTN or T-API protocol, the message event reported by the controller is parsed and identified to obtain the alarm information in the message event.

[0079] Specifically, the service fault analysis device establishes a long connection with the controller through the YANG-SSE or Websocket interface, thereby establishing a listening channel and receiving the message events pushed by the controller. In combination with the data structure YANG model of the ACTN and T-API protocols, the message events reported by the controller are parsed, and the alarm information is parsed from the message events, thereby realizing the SDN of traditional services. For example, "down" in the ACTN protocol is a field representing an alarm, and "cut" in the T-API protocol is a field representing an alarm. The service fault analysis device can identify it as the actual operating status of the service based on the YANG model. In combination with the YANG model of the ACTN and T-API protocols, the service operation status can be divided into normal, off-network interruption, on-network interruption, backup path interruption and other alarm conditions.

[0080] In order to pre-process the obtained alarm information, in one example, the acquisition module 61 can be specifically used to:

[0081] Performing format standardization processing on the format of the warning information;

[0082] Filtering the target field in the alarm information, removing fields other than the target field in the alarm information, wherein the target field includes a field representing the information type, a field representing the time, a field representing the name, and a field representing the status, wherein the information type includes business alarm information and non-business alarm information;

[0083] Write the current alarm information into the database.

[0084] Specifically, the alarm information obtained by the service fault analysis device through different protocols has the problem of inconsistent formats, so the format of the obtained alarm information needs to be standardized. For example, the northbound interface used by some manufacturers currently follows the ACTN standard, and the northbound interface used by some manufacturers follows the T-API 2.0 standard. The incompatibility of the northbound interface of the control system makes cross-vendor collaboration and unified orchestration objectively impossible to achieve. The service fault analysis device can unify the format of the obtained alarm information. In addition, since there will be redundant information in the alarm information, the important fields of the alarm information can be screened, and the information fields required for alarm analysis are retained. For example, for a certain resource class alarm information, its information type (here is the resource class), occurrence time, resource id, operation status and other fields are retained, and other fields not related to alarm analysis are removed. The processed alarm information is written to the database for storage, and the alarm information can be processed in memory operation so that the required alarm information can be called in real time during fault analysis.

[0085] Through the above processing, the format of the alarm information can be unified, important information fields can be screened out, and written into the database, thereby improving the quality of information and the accuracy of subsequent fault analysis.

[0086] Furthermore, to improve the effectiveness of the warning information, in one example, the acquisition module 61 may also be used to:

[0087] The duplicate alarms, synonymous alarms and marginal alarms in the alarm information are removed.

[0088] Specifically, there will be a large number of irrelevant alarms under a single domain controller, and duplicate alarms, synonymous alarms, and edge alarms in the alarm information are deleted and deduplicated. For example, alarm compression technology can be used to remove duplicate alarms, synonymous alarms, and edge alarms in the alarm information. The technical means used can be selected according to the actual application and are not limited here. The above operations can be used to retain valid alarm information and improve the efficiency of fault analysis.

[0089] After obtaining the single-domain service failure analysis result, the cross-domain service failure can be further analyzed. In one example, the device may further include:

[0090] The second analysis module determines, if a cross-domain fault service is detected, each single-domain service under the cross-domain fault service according to the inter-domain link and time slot allocation;

[0091] Detecting whether the cross-domain service failure is related to the failure of each single-domain service;

[0092] If relevant, the fault analysis result of the cross-domain fault service is obtained by analyzing the service fault analysis results of each single-domain service in combination with the knowledge base and experience rules; if not relevant, the link alarm information of the cross-domain link corresponding to the cross-domain fault service is collected, and the fault analysis result of the cross-domain service is obtained by analyzing the single-domain service fault analysis results, the knowledge base and experience rules corresponding to the cross-domain service.

[0093] Specifically, the cross-domain service is composed of multiple segments of single-domain services. Therefore, for the cross-domain fault service, the single-domain services corresponding to the cross-domain fault service can be determined, and the analysis of the cross-domain fault service can be realized by analyzing the single-domain services. Different single-domain services are connected and combined by inter-domain links. Therefore, according to the inter-domain links and their time slot allocation, the determination of each single-domain service under the cross-domain fault service can be realized. The fault point of the cross-domain service failure can be divided into intra-domain and inter-domain. By judging whether the fault of the cross-domain service is related to the fault of each corresponding single-domain service, the judgment of the fault point of the cross-domain service can be realized. If the fault of the cross-domain service is related to the fault of each corresponding single-domain service, the fault point of the cross-domain service is within the domain; if the fault of the cross-domain service is not related to the fault of each corresponding single-domain service, the fault point of the cross-domain service is between domains. For intra-domain faults, the alarm information of each single domain is collected for fault analysis, and the cross-domain business fault analysis results are obtained based on the business fault analysis results of each single domain business; for intra-domain faults, the inter-domain alarm information is combined with the single domain business fault analysis results for analysis.

[0094] The OTN network and its management and control system are independent domains, which form barriers to each other and lack unified cross-domain and cross-vendor collaboration. This solution combines the single-domain service fault analysis results for further analysis to obtain cross-domain service fault analysis results, thereby realizing cross-domain fault analysis.

[0095] In the service fault analysis device provided by this embodiment, by obtaining the service alarm information and non-service alarm information reported by the controller, and establishing associations between each service and the alarm information, the service alarm information can be directly associated with the relevant service, and the non-service alarm information is indirectly associated with the service through the service end-to-end path. When a single-domain service failure is detected, the alarm information corresponding to the faulty service is obtained according to the association relationship, and the single-domain service fault analysis result is obtained by analysis. This application obtains service alarm information and non-service alarm information, and establishes associations between the alarm information and the service to obtain the service fault analysis result, thereby realizing service-centric fault analysis of the OTN dedicated line, solving the problem of not being able to perform service fault analysis in a timely and accurate manner.

[0096] Embodiment 3

[0097] Figure 7 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure, such as Figure 7 As shown, the electronic device includes:

[0098] The electronic device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, the memory 292, and the communication interface 293 may communicate with each other through the bus 294. The communication interface 293 may be used for information transmission. The processor 291 may call the logic instructions in the memory 292 to execute the method of the above embodiment.

[0099] In addition, the logic instructions in the above-mentioned memory 292 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product.

[0100] The memory 292 is a computer-readable storage medium that can be used to store software programs and computer executable programs, such as program instructions / modules corresponding to the methods in the embodiments of the present disclosure. The processor 291 executes the software programs, instructions, and modules stored in the memory 292 to perform functional applications and data processing, that is, to implement the methods in the above method embodiments.

[0101] The memory 292 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 292 may include a high-speed random access memory and may also include a non-volatile memory.

[0102] An embodiment of the present disclosure provides a non-transitory computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the method described in the above embodiment.

[0103] Embodiment 4

[0104] An embodiment of the present disclosure provides a computer program product, including a computer program. When the computer program is executed by a processor, the method provided in any embodiment of the present disclosure is implemented.

[0105] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0106] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A service failure analysis method, characterized in that: include: Acquire alarm information reported by the controller, wherein the alarm information includes service alarm information, resource alarm information, and performance alarm information; Performing association processing to establish an association relationship between each service and the alarm information, the association processing comprising: for the service alarm information, according to the service field in the service alarm information, establishing an association between the service alarm information and the service represented by the service field; for the resource alarm information, according to the service end-to-end path, determining the network element, link, and port passed by the service, and establishing an association between the service and the corresponding information in the resource alarm information; for the performance alarm information, according to the service end-to-end path, determining the service related to the performance alarm information, and establishing an association between the performance alarm information and the service; wherein the resource alarm information includes network elements, links, and ports; If a single-domain faulty service is detected, alarm information corresponding to the single-domain faulty service is obtained according to the association relationship, and fault analysis is performed according to the alarm information corresponding to the single-domain faulty service to obtain a service fault analysis result.

2. The method according to claim 1, characterized in that The obtaining of alarm information reported by the controller includes: Establish a persistent connection with the controller through YANG-SSE or Websocket interface; Receiving the message event reported by the controller through the established long connection; Based on the data structure YANG model of ACTN or T-API protocol, the message event reported by the controller is parsed and identified to obtain the alarm information in the message event.

3. The method according to claim 2, characterized in that After obtaining the alarm information reported by the controller, the method further includes: Performing format standardization processing on the format of the warning information; Filtering the target field in the alarm information, removing fields other than the target field in the alarm information, wherein the target field includes a field representing the information type, a field representing the time, a field representing the name, and a field representing the status, wherein the information type includes business alarm information and non-business alarm information; Write the current alarm information into the database.

4. The method according to claim 3, characterized in that Before writing the current alarm information into the database, the method further includes: The duplicate alarms, synonymous alarms and marginal alarms in the alarm information are removed.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: If a cross-domain fault service is detected, determining each single-domain service under the cross-domain fault service according to the inter-domain link and time slot allocation; Detecting whether the cross-domain service failure is related to the failure of each single-domain service; If relevant, the fault analysis results of the single-domain services are analyzed in combination with the knowledge base and experience rules to obtain the fault analysis results of the cross-domain fault service; if not relevant, the link alarm information of the cross-domain link corresponding to the cross-domain fault service is collected, and the fault analysis results of the single-domain services corresponding to the cross-domain services, the knowledge base and experience rules are analyzed to obtain the fault analysis results of the cross-domain fault service.

6. A service failure analysis device, characterized in that: include: An acquisition module, used to acquire alarm information reported by the controller, wherein the alarm information includes service alarm information, resource alarm information, and performance alarm information; An association module is used to perform association processing to establish an association relationship between each service and the alarm information, wherein the association processing includes: for the service alarm information, according to the service field in the service alarm information, establishing an association between the service alarm information and the service represented by the service field; for the resource alarm information, according to the service end-to-end path, determining the network element, link, and port passed by the service, and establishing an association between the service and the corresponding information in the resource alarm information; for the performance alarm information, according to the service end-to-end path, determining the service related to the performance alarm information, and establishing an association between the performance alarm information and the service; wherein the resource alarm information includes network elements, links, and ports; The analysis module is used to obtain the alarm information corresponding to the single-domain faulty service according to the association relationship if a single-domain faulty service is detected, and perform fault analysis according to the alarm information corresponding to the single-domain faulty service to obtain a service fault analysis result.

7. The device according to claim 6, characterized in that The acquisition module is specifically used for: Establish a persistent connection with the controller through YANG-SSE or Websocket interface; Receiving the message event reported by the controller through the established long connection; Based on the data structure YANG model of ACTN or T-API protocol, the message event reported by the controller is parsed and identified to obtain the alarm information in the message event.

8. The device according to claim 7, characterized in that The acquisition module is further used for: Performing format standardization processing on the format of the warning information; Filtering the target field in the alarm information, removing fields other than the target field in the alarm information, wherein the target field includes a field representing the information type, a field representing the time, a field representing the name, and a field representing the status, wherein the information type includes business alarm information and non-business alarm information; Write the current alarm information into the database.

9. The device according to claim 8, characterized in that The acquisition module is further used for: The duplicate alarms, synonymous alarms and marginal alarms in the alarm information are removed.

10. The device according to any one of claims 6 to 9, characterized in that: The device further comprises: A second analysis module is used to determine, if a cross-domain fault service is detected, each single-domain service under the cross-domain fault service according to the inter-domain link and time slot allocation; Detecting whether the cross-domain service failure is related to the failure of each single-domain service; If relevant, the fault analysis results of the single-domain services are analyzed in combination with the knowledge base and experience rules to obtain the fault analysis results of the cross-domain fault service; if not relevant, the link alarm information of the cross-domain link corresponding to the cross-domain fault service is collected, and the fault analysis results of the single-domain services corresponding to the cross-domain services, the knowledge base and experience rules are analyzed to obtain the fault analysis results of the cross-domain fault service.

11. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 5.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 5 when executed by a processor.

Images