Airport data service interface fault analysis method and system

Abstract

The invention belongs to the technical field of airport data processing, and discloses an airport data service interface fault analysis method and system. According to the method, a fault judgment model is established according to the operation characteristics of the airport data service interface, the fault judgment model is divided into a resource type, a performance type and an error type, and whether the fault judgment model needs root cause analysis or not is configured; generating an alarm event and alarm event details according to the fault judgment model in combination with monitoring data in three dimensions of indexes, logs and links; judging whether the generated alarm event needs root cause analysis or not; and for the divided resource faults, performance faults and error faults, alarm event root causes and disposal recommendations are given according to corresponding disposal modes. According to the method, the performance development trend is predicted through a machine learning algorithm, and the occurrence probability of performance faults is reduced; performance type and error type fault root cause analysis is carried out through the knowledge graph, operation and maintenance personnel are helped to discover problems in time, the problems are efficiently processed, and risks and hidden dangers are eliminated.

Description

Technical Field

[0001] The invention belongs to the technical field of airport data processing, and in particular relates to an airport data service interface fault analysis method and system. Background Art

[0002] There are many information systems within the airport, such as the A-CDM system, ground service system, and airfield management system, which involve production, service, safety, and management. Data interaction and sharing are required between the information systems, and external system data, such as air traffic control data and airline data, are also required. Data service interfaces are often used for data transmission and storage between application systems. Once an abnormality occurs, the airport data will not be received in time or even interrupted, affecting the normal operation of the airport and leading to passenger complaints. Therefore, it is particularly necessary to invent an efficient and intelligent data service interface fault analysis method.

[0003] The invention patent (publication number CN113032238A, publication date 20210625) discloses a real-time root cause analysis method based on application knowledge graph. By constructing an application knowledge graph, real-time detection and root cause analysis of KPI indicators of operation and maintenance objects are realized. The core methods used include: multi-indicator anomaly detection method, cross-layer application knowledge graph anomaly reasoning, fault chain pruning; instance-level root cause analysis based on similarity algorithm, which can eventually locate the root cause of system failure. The above methods start with resource failures such as application services, databases, and middleware, and do not involve the analysis of error and performance failures. They are not comprehensive enough and the efficiency of fault location is not high. Summary of the invention

[0004] In order to overcome the problems existing in the related art, the disclosed embodiments of the present invention provide a method and system for analyzing the fault of an airport data service interface. Timely and efficient data transmission is the cornerstone of the normal production and operation of an airport. Once a fault occurs, it will have adverse effects, ranging from flight delays and passenger backlogs to safety issues. The purpose of the present invention is to propose a method for analyzing the fault of an airport data service interface, detect anomalies through a machine learning algorithm, and analyze the root cause of the fault through a knowledge graph, so as to help operation and maintenance personnel to find problems in a timely manner, handle problems efficiently, eliminate risks and hidden dangers, and avoid affecting the normal production of the airport due to data problems, thereby improving the quality of passenger service.

[0005] The technical solution is as follows: an airport data service interface fault analysis method, comprising: S1, establish a fault judgment model and configure whether the fault judgment model requires root cause analysis; S2, based on the fault judgment model, combines the monitoring data of the three dimensions of indicators, logs, and links to generate alarm events and alarm event details; S3: Determine whether the generated alarm event needs root cause analysis. For the divided resource faults, performance faults, and error faults, give the root cause of the alarm event and give treatment recommendations according to the corresponding treatment methods.

[0006] In step S1, the fault determination model is divided into resource class, performance class, and error class; The resource type makes fault determination based on the usage of server resources. The determination elements of this type of model are indicator data, comparison symbol, and threshold value. The performance type determines the fault based on the response time of the service interface. The determination factors of this type are response time, comparison operator, and threshold. The error class makes fault determination based on the error log of the service, and the determination factor of this type is the exception keyword.

[0007] In step S2, the indicator dimension monitoring data is used to determine resource-related faults. When the indicator monitoring data meets the elements of the resource-related fault determination model, an alarm event and alarm event details are generated; Log dimension monitoring data is used to determine error-type faults. When the log monitoring data meets the elements of the error-type fault determination model, an alarm event and alarm event details are generated; The link dimension monitoring data is used to determine performance-related faults. When the link monitoring data meets the elements of the performance-related fault determination model, the alarm event and the alarm event details are generated.

[0008] Furthermore, for the performance-related fault judgment model, the thresholds in the judgment factors are divided into fixed thresholds and dynamic thresholds. The fixed thresholds are configured by manual maintenance, and the dynamic thresholds are automatically calculated through historical time series data using a machine learning algorithm.

[0009] Furthermore, the calculation method of the dynamic threshold is based on the performance change law of the interface in the daily operation of the airport, and a machine learning algorithm is introduced to generate an interface performance curve through a regression prediction algorithm, and the performance status of the data service interface is judged based on this curve; The interface performance curve collects and calculates historical data through a regression prediction algorithm, including: (1) Data sampling: extracting interface call performance data from Skywalking at regular intervals and sending the data to the Kafka message middleware; (2) Sample processing: Use the streaming computing engine Storm to analyze and calculate large-scale, real-time data samples. To reduce errors, correct abnormal data, delete sample data with too few calls, calculate the average value of data with similar call volumes according to the corresponding time consumption, and then correct the data with 0 call volumes to the average value. Finally, store the preprocessed sample data in the time series database openTSDB; (3) Anomaly detection: The anomaly detection module takes into account the actual operation of the airport, including the period of flow control, the period of security, large-scale flight delays, the peak of summer and spring travel, and the failure of airport equipment. The L2 regularization algorithm is used to perform predictive analysis on the preprocessed sample data, the data is standardized to 0-1, and the formula is used for linear transformation so that the result falls into the [0,1] interval. In the formula, is the standardized data, is the original data, is the maximum value of the original data, is the minimum value of the original data, is the loss coefficient, is the target variable, is the feature matrix, is the model weight, is the regularization parameter; It is more in line with actual needs to obtain the regression coefficient by deleting some invalid information and reducing some precision. The larger the regression coefficient, the greater the overall growth trend of the data. Through the obtained regression coefficient, the development trend of the data service interface is divided according to size, the performance status of the data service interface is actively judged, and intervention is carried out in advance before performance failure occurs.

[0010] Furthermore, in the resource fault handling method, for different types of resource indicators, the corresponding indicator drill-down query method is executed, and the Prometheus query API is called to obtain detailed data as the root cause of the fault.

[0011] Furthermore, in the performance fault handling method, if a performance fault occurs, relying on the call chain and combining the system topology, locate the time-consuming nodes in the link, take the time-consuming nodes as the starting point, trace the downstream topology according to the error fault handling process, analyze the anomalies, obtain the anomaly causal link, and take the end point of the link as the root cause of the alarm event.

[0012] Furthermore, the error-type fault handling method includes: obtaining event-related assets, matching the fault case library, calculating the knowledge graph, obtaining all suspicious paths of the fault event, calculating related events from the time dimension, screening the root cause path, and then calculating the relevance of the root cause path from the semantic dimension, screening the root cause path, and finally generating the root cause path and giving handling recommendations.

[0013] Furthermore, the root cause location process of error faults includes: Step 1: Obtain all suspicious paths of fault events based on the system map. The system map consists of the physical and logical components of each business system, including the physical environment where the system is located, related logical components and their relationships. The system map is constructed through the CMDB library, data links, and network discovery technology. Step 2: Analyze the correlation of node events on each path from the time dimension to narrow the path range; Step 3: Analyze the correlation between upstream and downstream node events on each path from a semantic dimension based on the operation and maintenance knowledge graph, accurately locate the root cause path, and determine the root cause of the fault.

[0014] Another object of the present invention is to provide an airport data service interface fault analysis system, which implements the airport data service interface fault analysis method, and the system comprises: The fault model definition module is used to define resource-type, performance-type, and link-type fault judgment model instances, define fault judgment model element information, and configure the judgment model to perform root cause analysis; The alarm event generation module is used to generate alarm events and generate alarm event details; generate dynamic threshold curves for performance-related faults; The root cause analysis module is used to generate the system graph and operation and maintenance knowledge graph required for fault root cause analysis; for the classified resource type faults, performance type faults and error type faults, the root cause of the alarm event and the disposal recommendation are given according to the corresponding disposal method.

[0015] In combination with all the above technical solutions, the beneficial effects of the present invention are as follows: the present invention classifies and processes airport data interface failures, predicts performance development trends through machine learning algorithms, and reduces the probability of performance-related failures; performs root cause analysis of performance-related and error-related failures through knowledge graphs, helping operation and maintenance personnel to promptly discover problems, efficiently handle problems, eliminate hidden risks, and avoid affecting normal airport production due to data problems, thereby improving the quality of passenger services. The present invention effectively reduces the frequency of airport data interface failures, improves the efficiency of fault resolution, and reduces reliance on technical experts. It solves the problem of difficult-to-predict and difficult-to-solve failures encountered by airport operation and maintenance personnel during the operation and maintenance of data interface services. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings herein are incorporated in and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description, serve to explain the principles of the present disclosure; Figure 1 is a flow chart of a method for analyzing a fault in an airport data service interface provided by an embodiment of the present invention; Figure 2 is a schematic diagram of an interface performance prediction process provided by an embodiment of the present invention; Figure 3is a schematic diagram of an airport data service interface fault analysis system provided by an embodiment of the present invention; In the figure: 1. Fault model definition module; 2. Alarm event generation module; 3. Root cause analysis module. DETAILED DESCRIPTION

[0017] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention, so the present invention is not limited by the specific implementation disclosed below.

[0018] The innovation of this invention lies in: in the operation and maintenance of airport data services, an intelligent and systematic approach is used to replace the traditional manual analysis and problem-solving process, and performance development trends are predicted through machine learning algorithms to reduce the probability of performance-related failures. The root cause analysis of performance and error-related failures is performed through knowledge graphs to help operation and maintenance personnel discover problems in a timely manner, handle problems efficiently, and eliminate potential risks.

[0019] Embodiment 1, as Figure 1 As shown, the airport data service interface fault analysis method provided by the embodiment of the present invention includes: S1, establish a fault judgment model and configure whether the fault judgment model requires root cause analysis; For example, the resource class makes fault determination based on the usage of server resources, such as CPU usage, memory usage, remaining disk space, etc. The determination factors of this type of model are indicator data + comparison operator + threshold, such as CPU usage>90%; the performance class makes fault determination based on the response time of the service interface, and the determination factors of this type are response time + comparison operator + threshold, such as XX interface response time>3 seconds; the error class makes fault determination based on the error log of the service, and the determination factors of this type are exception keywords, such as "OutOfMemoryError" and "NullPointerException", etc. S2, based on the fault judgment model, combines the monitoring data of the three dimensions of indicators, logs, and links to generate alarm events and alarm event details; For example, the indicator dimension monitoring data is derived from Prometheus and is used to determine resource-related faults. When the indicator monitoring data meets the elements of the resource-related fault determination model, the alarm event and the alarm event details are generated. For example, when the CPU usage indicator of the Server1 server meets the determination element of "CPU usage>90%", the alarm event "Server1 server CPU usage is high" is generated, and the alarm event details "Server1 server CPU usage 95%" are generated at the same time; The log dimension monitoring data comes from Loki and is used to determine error-type faults. When the log monitoring data meets the elements of the error-type fault determination model, the alarm event and alarm event details are generated. For example, when the log of Service1 service contains the determination element of "OutOfMemoryError", the alarm event "Service1 service log contains OutOfMemoryError" is generated, and the alarm event details "Service1 service error log: java.lang.OutOfMemoryError: Java heap space at java.util.ArrayList.grow(ArrayList.java:242) at java.util.ArrayList.add(ArrayList.java:411) at com.example.MemoryLeakExample.addToList(MemoryLeakExample.java:23)"; The link dimension monitoring data comes from Skywalking and is used to determine performance-related faults. When the link monitoring data meets the elements of the performance-related fault determination model, the alarm event and alarm event details are generated. For example, when the response time of the getList() interface of Service1 service meets the determination element of “>3 seconds”, the alarm event "The getList() interface of Service1 service responds slowly" is generated, and the alarm event details "The getList() interface of Service1 service takes a total of 4500ms, of which setp1 takes 1000ms and setp2 takes 3500ms" are generated.

[0020] S3: Determine whether the generated alarm event needs root cause analysis. For the resource faults, performance faults, and error faults, give the root cause of the alarm event and give treatment recommendations according to the corresponding treatment methods. Exemplarily, whether the alarm event requires root cause analysis is determined. This factor is inherited from the fault determination model configuration of the source of the alarm event and is configured manually. If root cause analysis is not required, the process ends here. If root cause analysis is required, the following root cause analysis process is performed.

[0021] In step S3, if it is a resource fault, a fixed drill-down query method is set according to different resource types to locate the cause of the fault; In the actual operation environment of the airport, this type of fault handling method is relatively simple and fast. A fixed drill-down query method is set according to the resource type. The drill-down query calls the Prometheus query API and executes the corresponding query expression for different resource types to obtain the required detailed data. For example, when a server CPU alarm occurs, the server ID and the time when the alarm is generated are obtained from the alarm event information, and the server information is further queried to determine the server type. The query expression is determined according to the server type. For example, the query expression for the Windows server is "win_proc_Percent_Processor_Time". The expression for querying the top 10 processes with CPU occupancy according to the alarm time and the server to which it belongs is "topk(10,sort_desc(win_proc_Percent_Processor_Time{assetCode='Server1',instance!='Idle'}))&time=1728956026.897", and the resulting process is used as the root cause of the alarm event.

[0022] If it is a performance fault, locate the high-time-consuming node in the link, take the high-time-consuming node as the starting point, trace the downstream topology according to the error process, match it with the case library, analyze the anomaly, obtain the anomaly causal link, and locate the cause of the fault; In the actual operation environment of the airport, performance failures occur relatively frequently. Traditional performance analysis is judged by time-consuming calls and manual drawing. It is unable to automatically analyze the performance of the data service interface according to the actual operation status of the airport, effectively optimize the performance before the failure actually occurs, and cannot effectively analyze and iterate different scenarios such as performance deterioration. This solution is based on historical interface call data, mines the law of interface performance changes, introduces machine learning algorithms, and automatically identifies the trend of interface performance deterioration through regression prediction models. It establishes a closed loop of interface performance analysis, improves the work efficiency of the service operation team in service interface performance management, eliminates manual analysis input, and only retains result verification work.

[0023] If it is an error-type fault, obtain event-related assets, match the fault case library, calculate the knowledge graph, obtain all suspicious paths of the fault event, calculate related events from the time dimension, filter the root cause path, and then calculate the relevance of the root cause path from the semantic dimension. Filter the root cause path, finally generate the root cause path, and give disposal recommendations.

[0024] Among them, in the actual operation environment of the airport, error-type failures are the most complex type in root cause analysis. Due to the complexity of the fault system structure, the causal path of the fault event is usually more complicated.

[0025] Exemplary methods for handling performance-related faults include: Performance failures of data service interfaces are predictable. Based on the changing patterns of interface performance during daily airport operations, machine learning algorithms are used to set thresholds and automatically analyze interface performance. When the threshold is reached, an alarm is issued to remind operation and maintenance personnel to handle the situation in a timely manner, thereby reducing the actual number of failures.

[0026] The time consumed by each data call of the data interface is recorded and collected to form a sample library. Sampling is performed every ten minutes, and the performance status of the interface is judged through the regression prediction algorithm. Figure 2 As shown in the figure, the interface performance prediction process diagram first uses the microservice architecture to automatically send the real-time performance data of the data interface to the message middleware, then performs streaming calculations on the samples, corrects the abnormal data, and stores the pre-processed sample data in the time series database. Finally, the data is predicted and analyzed through the anomaly detection module to obtain the performance trend of the data interface. The details are as follows: (1) Data sampling: Develop a scheduled collection program to extract interface call performance data from Skywalking at regular intervals and send the data to the Kafka message middleware; (2) Sample processing: Use the streaming computing engine Storm to preprocess large-scale, real-time data samples. To reduce errors, correct abnormal data such as time consumption and call volume of 0 and too few sample data. Correction measures include: ① Deleting sample data with too few calls; ② Calculating the average value of data with similar call volume according to the corresponding time consumption; ③ Correcting the data with 0 call volume to the average value. Finally, store the preprocessed sample data in the time series database openTSDB; (3) Anomaly detection: The anomaly detection module should take into account the actual operation of the airport, such as special situations such as flow control period, security period, large-scale flight delays, summer and spring travel peaks, airport equipment failures and security anomalies. The L2 regularization algorithm is used to predict and analyze the preprocessed sample data. The L2 regularization algorithm is an improved least squares method. The algorithm adds an L2 regularization term to the original loss function to prevent the model from overfitting and avoids the inversion difficulties such as matrix irreversibility, increased numerical instability, and uncertainty of solutions in the case of non-full rank matrices. The data is standardized to 0-1, and the formula is first used for linear transformation so that the result falls into the [0,1] interval.

[0027] In the formula, is the standardized data, is the original data, is the maximum value of the original data, is the minimum value of the original data, is the loss coefficient, is the target variable, is the feature matrix, is the model weight, is the regularization parameter; It is more in line with actual needs to obtain the regression coefficient by deleting some invalid information and reducing some precision. The larger the regression coefficient, the greater the overall growth trend of the data. The development trend of the data service interface is divided according to the size of the obtained regression coefficient. The larger the coefficient, the greater the trend of interface performance deterioration, so as to actively judge the performance status of the data service interface and intervene in advance before performance failure occurs.

[0028] If a performance failure occurs, relying on the call chain and combining the system topology, the longest span in the call chain is taken according to the execution time of the span in the link, and then the slow node is located according to the type of span. If the span is a local call, the current node is taken as the high-time node. If the span is a cross-node call, the target node is taken as the high-time node. The high-time node is used as the starting point, and the downstream topology is traced according to the error-type fault handling process. The anomaly is analyzed, the abnormal causal link is obtained, and the end point of the link is taken as the root cause of the alarm event.

[0029] Exemplary error handling methods include: Error-type faults rely on the system topology to trace and analyze the abnormal conditions of the downstream nodes of the abnormal node, obtain the abnormal causal links with high correlation, and take the end point of the link as the root cause of the error-type fault alarm event.

[0030] The root cause location process of error faults is divided into the following three steps: Step 1: Based on the system graph, all reachable paths starting from the abnormal node are used as all suspicious paths of the fault event; Step 2: Analyze the correlation of node events on each path from the time dimension. Node events that occur at the same time are considered to be correlated, thus narrowing the scope of suspicious paths. Step 3: Based on the operation and maintenance knowledge graph, analyze the correlation of upstream and downstream node events on each path from the semantic dimension, accurately locate the root cause path, and determine the root cause of the fault. If the events of two nodes in the path meet the causal relationship between "Error log: "Too many connections"" and "Insufficient number of available database connections" in the operation and maintenance knowledge graph, then it is considered that the two nodes of the path have a strong causal relationship. Calculate all downstream nodes in the path one by one. When all calculation results are strong causal relationships, the path is identified as a strong causal root cause path.

[0031] Among them, steps 1 and 3 utilize knowledge graph technology, which is divided into two types of applications: system graph and operation and maintenance knowledge graph. The system graph refers to the physical and logical composition of each business system, including the physical environment where the system is located, related logical components and their relationships. The system graph is constructed through technical means such as CMDB library, data link, network discovery, etc. CMDB contains the software, hardware and their deployment relationships involved in the system. This part of information is used to generate the system's software and hardware nodes and deployment relationships; the data link contains the calling relationship of each application in the system, and this part of information is used to generate the system's software calling relationship; network discovery obtains network equipment and network hops in the network to supplement the hardware network relationship in the graph.

[0032] The operation and maintenance knowledge graph is an operation and maintenance knowledge base shared by all airport business systems. It is used for fault identification and handling, fault impact analysis, and cause-and-effect analysis of abnormal events. Its data sources include system graphs, airport operation and maintenance knowledge base, airport operation and maintenance and development expertise, airport historical faults and case data, etc. The construction process of the knowledge graph is as follows: (i) Data source collection: Collect various types of data related to root cause analysis, including system deployment architecture, system failure records, airport operation and maintenance logs, airport user feedback, system design documents, system test reports, etc.

[0033] The data source should be representative and comprehensive to ensure that the constructed knowledge graph can cover all aspects required for root cause analysis.

[0034] (ii) Knowledge extraction: Extract basic information such as entities, relationships, and attributes from the collected data to form structured or semi-structured data. Knowledge extraction is performed using natural language processing (NLP) technology, machine learning algorithms, or manual annotation. First, natural language processing technology is used to preprocess the text, identify entities, extract relationships, and extract attributes, and automatically identify key information from the text using rules or models. Second, machine learning algorithms are used to train models based on feature engineering to identify and extract entities, relationships, and attributes from the text, and model performance is improved through evaluation and optimization. Finally, with the assistance of manual annotation, the text is manually labeled with entities, relationships, and attributes, and quality control and result integration are performed to ensure the accuracy and completeness of the data.

[0035] (iii) Knowledge fusion: Integrate knowledge from different sources, connect scattered knowledge graphs through boundary connections to form a complete large graph, and solve the conflicts and redundancies between knowledge. Establish a unified knowledge representation system to ensure the consistency and accuracy of the knowledge graph.

[0036] (iv) Knowledge graph storage: Use the graph database Neo4j to store knowledge graphs. When storing, factors such as data query efficiency, scalability, and maintenance costs need to be considered.

[0037] The present invention also provides an airport data service interface fault analysis system, which implements the airport data service interface fault analysis method, and the system comprises: Fault model definition module 1 is used to define resource class, performance class, link class fault judgment model instances, define fault judgment model element information, and configure the judgment model to perform root cause analysis; Alarm event generation module 2, used for generating alarm events and generating alarm event details; generating dynamic threshold curves for performance-related faults; Root cause analysis module 3 is used to generate the system map and operation and maintenance knowledge map required for fault root cause analysis; for the divided resource type faults, performance type faults and error type faults, the root cause of the alarm event and the disposal recommendation are given according to the corresponding disposal method.

[0038] To further illustrate the effects of the embodiments of the present invention, the following experiments are performed: The verification environment includes three servers named Server1, Server2, and Server3, two application service nodes and a database named Service1, Service2, and DB. Service1 is deployed on Server1, Service2 is deployed on Server2, and DB is deployed on Server3. The call link is Service1->Service2->DB. The simulation scenario is that the number of DB connections is exhausted, resulting in an exception in the Service1 interface.

[0039] The experimental process is as follows: 1. Configure the fault judgment model: ① Application log ERROR exception model; ② Insufficient database connection number exception model, and configure ① to require root cause analysis.

[0040] 2. Service startup: Start DB, Service2, and Service1 in sequence, and continue to call the Service1 test interface through the jmeter tool. At this time, everything is normal with the interface.

[0041] 3. Simulate failure: Start the test program and fill up the number of DB connections. At this time, three alarm events are generated: ① There is an ERROR exception in the Service1 application log, and the details are "ERROR: call Service2 failed"; ② There is an ERROR exception in the Service2 application log, and the details are "ERROR: Could not create connection to database server"; ③ There is an exception of insufficient number of DB links, and the details are "Number of available database connections = 0".

[0042] 4. Root cause analysis: The system performs root cause analysis on alarm event ① and calculates the root cause path as ①->②->③, successfully obtaining root cause event ③.

[0043] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any modifications, equivalent substitutions and improvements made by any technician familiar with the technical field within the technical scope disclosed by the present invention and within the spirit and principles of the present invention should be covered within the protection scope of the present invention.

Claims

1. A method for analyzing airport data service interface failure, characterized in that: The method includes: S1, establish a fault judgment model and configure whether the fault judgment model requires root cause analysis; S2, based on the fault judgment model, combines the monitoring data of the three dimensions of indicators, logs, and links to generate alarm events and alarm event details; S3: Determine whether the generated alarm event needs root cause analysis. For the divided resource faults, performance faults, and error faults, give the root cause of the alarm event and give treatment recommendations according to the corresponding treatment methods.

2. The airport data service interface fault analysis method according to claim 1, characterized in that: In step S1, the fault determination model is divided into resource class, performance class, and error class; The resource type makes fault determination based on the usage of server resources. The determination elements of this type of model are indicator data, comparison symbol, and threshold value. The performance type determines the fault based on the response time of the service interface. The determination factors of this type are response time, comparison operator, and threshold. The error class makes fault determination based on the error log of the service, and the determination factor of this type is the exception keyword.

3. The airport data service interface fault analysis method according to claim 1, characterized in that: In step S2, the indicator dimension monitoring data is used to determine resource-related faults. When the indicator monitoring data meets the elements of the resource-related fault determination model, an alarm event and alarm event details are generated; Log dimension monitoring data is used to determine error-type faults. When the log monitoring data meets the elements of the error-type fault determination model, an alarm event and alarm event details are generated; The link dimension monitoring data is used to determine performance-related faults. When the link monitoring data meets the elements of the performance-related fault determination model, the alarm event and the alarm event details are generated.

4. The airport data service interface fault analysis method according to claim 3, characterized in that: For the performance fault judgment model, the thresholds in the judgment factors are divided into fixed thresholds and dynamic thresholds. The fixed thresholds are configured by manual maintenance, and the dynamic thresholds are automatically calculated through historical time series data using a machine learning algorithm.

5. The airport data service interface fault analysis method according to claim 4, characterized in that: The calculation method of dynamic threshold is based on the performance change law of the interface in the daily operation of the airport, and introduces machine learning algorithm to generate interface performance curve through regression prediction algorithm, and judge the performance status of the data service interface based on this curve; The interface performance curve collects and calculates historical data through a regression prediction algorithm, including: (1) Data sampling: extracting interface call performance data from Skywalking at regular intervals and sending the data to the Kafka message middleware; (2) Sample processing: Use the streaming computing engine Storm to analyze and calculate large-scale, real-time data samples. To reduce errors, correct abnormal data, delete sample data with too few calls, calculate the average value of data with similar call volumes according to the corresponding time consumption, and then correct the data with 0 call volumes to the average value. Finally, store the preprocessed sample data in the time series database openTSDB; (3) Anomaly detection: The anomaly detection module takes into account the actual operation of the airport, including the period of flow control, the period of security, large-scale flight delays, the peak of summer and spring travel, and the failure of airport equipment. The L2 regularization algorithm is used to perform predictive analysis on the preprocessed sample data, the data is standardized to 0-1, and the formula is used for linear transformation so that the result falls into the [0,1] interval. In the formula, is the standardized data, is the original data, is the maximum value of the original data, is the minimum value of the original data, is the loss coefficient, is the target variable, is the feature matrix, is the model weight, is the regularization parameter; It is more in line with actual needs to obtain the regression coefficient by deleting some invalid information and reducing some precision. The larger the regression coefficient, the greater the overall growth trend of the data. Through the obtained regression coefficient, the development trend of the data service interface is divided according to size, the performance status of the data service interface is actively judged, and intervention is carried out in advance before performance failure occurs.

6. The airport data service interface fault analysis method according to claim 3, characterized in that: In the resource fault handling method, for different types of resource indicators, execute the corresponding indicator drill-down query method, call the Prometheus query API, and obtain detailed data as the root cause of the fault.

7. The airport data service interface fault analysis method according to claim 3, characterized in that: In the performance fault handling method, if a performance fault occurs, rely on the call chain and combine the system topology to locate the high-time-consuming nodes in the link. Take the high-time-consuming nodes as the starting point, trace the downstream topology according to the error fault handling process, analyze the anomalies, obtain the abnormal causal link, and take the end point of the link as the root cause of the alarm event.

8. The airport data service interface fault analysis method according to claim 3, characterized in that: The method for handling error-related faults includes: obtaining event-related assets, matching the fault case library, calculating the knowledge graph, obtaining all suspicious paths of the fault event, calculating related events from the time dimension, screening the root cause path, and then calculating the relevance of the root cause path from the semantic dimension, screening the root cause path, and finally generating the root cause path and giving handling recommendations.

9. The airport data service interface fault analysis method according to claim 8, characterized in that: The root cause location process of error faults includes: Step 1: Obtain all suspicious paths of fault events based on the system map. The system map consists of the physical and logical components of each business system, including the physical environment where the system is located, related logical components and their relationships. The system map is constructed through the CMDB library, data links, and network discovery technology. Step 2: Analyze the correlation of node events on each path from the time dimension to narrow the path range; Step 3: Analyze the correlation between upstream and downstream node events on each path from a semantic dimension based on the operation and maintenance knowledge graph, accurately locate the root cause path, and determine the root cause of the fault.

10. An airport data service interface fault analysis system, characterized in that: Implementing the airport data service interface fault analysis method as described in any one of claims 1 to 9, the system comprises: The fault model definition module (1) is used to define resource-type, performance-type, and link-type fault judgment model instances, define fault judgment model element information, and configure the judgment model to perform root cause analysis; An alarm event generation module (2) is used to generate alarm events and generate alarm event details; and to generate a dynamic threshold curve for performance-related faults; The root cause analysis module (3) is used to generate the system map and operation and maintenance knowledge map required for fault root cause analysis; for the divided resource type faults, performance type faults and error type faults, the root cause of the alarm event and the disposal recommendation are given according to the corresponding disposal method.

Images