Business fault automatic positioning method based on low code

Abstract

The invention discloses an automatic business fault positioning method based on low codes, and belongs to the technical field of IT and software research and development, and the method comprises the steps: S1, constructing a low-code platform for business fault diagnosis process design; s2, observing a service state through the acquisition index, identifying a service fault, and sending an alarm; and S3, analyzing the business with the fault by using the alarm, triggering the operation of the business fault diagnosis process, and positioning the reason of the business fault. According to the method, fault positioning is processed, normalized and automated in a low-code visualization form, the unit research and development operation and maintenance cost is reduced, the service fault positioning time is shortened, and the troubleshooting efficiency is improved; according to the method, expert fault experience, enterprise-level business fault diagnosis large models, business fault knowledge maps and other capabilities are accessed to a low-code platform, the capabilities are packaged and loaded to a fault diagnosis link through low-code capabilities, diagnosis processes are automatically driven and diagnosis capabilities are called based on fault events and data, and the agility and rapidness of business fault positioning are enhanced.

Description

Technical Field

[0001] The present invention relates to the field of IT and software development technology, and in particular to a low-code-based automated business fault location method. Background Art

[0002] In the wave of digital transformation, the stability and reliability of the telecommunications industry's business systems are crucial. Traditional monitoring and operation and maintenance methods mainly rely on various monitoring tools to monitor system processes and component status in real time, and use early warning mechanisms and visual charts to display the relationship between systems to assist operation and maintenance personnel in identifying potential problems. However, with the expansion of the scale of telecommunications business and the widespread application of microservice architecture, the complexity of system operation and maintenance has increased dramatically, and the amount of monitoring data has increased exponentially. In this context, the traditional manual experience-driven, passive response operation and maintenance model is difficult to cope with massive amounts of information, resulting in a time-consuming and inefficient troubleshooting process.

[0003] Although there are some automated operation and maintenance platforms on the market that enhance fault diagnosis capabilities by introducing advanced technologies such as artificial intelligence and machine learning, they still have the following limitations in actual applications. 1. Strong dependence. Most tools rely too much on specific threshold settings, rule bases, or pre-trained models during fault location. They are not adaptable enough to the complex and dynamically changing telecommunications business environment, and are prone to false alarms and missed reports. 2. Low efficiency of human-computer interaction. The existing troubleshooting process usually requires operation and maintenance personnel to frequently switch between multiple tools, manually collect and analyze data, and the human-computer interaction interface design is not user-friendly, which increases the operational burden and decision-making delays. 3. Difficulty in customization. Faced with business scenarios and fault types unique to the telecommunications industry, general-purpose operation and maintenance platforms are often difficult to quickly and flexibly customize and adjust to meet specific fault location needs.

[0004] The technical problems existing in the existing technical solutions are as follows:

[0005] (1) After the system is migrated to the cloud, troubleshooting is costly and inefficient: In large-scale, highly complex telecommunications business scenarios, traditional monitoring tools collect massive amounts of indicators, which requires extremely high levels of experience and technical skills from operation and maintenance personnel. Operation and maintenance personnel also need to devote a lot of energy to troubleshooting, and the processing speed is slow, which affects service quality and increases operating costs.

[0006] (2) The development of new network and IT technologies has brought many unknown failures: Faced with the rapid iteration and complex changes in telecommunications business systems, there are more and more scenarios in which failures occur. Existing technologies are unable to adjust fault location strategies in a timely and effective manner, are insensitive to new types of failures, and are unable to locate faults based on business fluctuations.

[0007] (3) Difficulty in locating the root cause of business failures: Existing tools are easily affected by human factors during the fault location process, such as biased experience and data interpretation errors, resulting in low accuracy in fault location. It is impossible to quickly analyze the root cause of the failure from massive monitoring indicators, and operations and developers have to analyze process stack logs, service logs, and source code to locate the root cause, resulting in a long fault recovery time.

[0008] The above problems need to be solved urgently. To this end, a low-code-based automatic location method for business faults is proposed. Summary of the invention

[0009] The technical problem to be solved by the present invention is: how to solve the problems of high troubleshooting cost, low efficiency and difficulty in locating the root cause of business failures after the system is put on the cloud in the prior art, and provide a low-code based automatic location method for business failures.

[0010] The present invention solves the above technical problems through the following technical solutions, and the present invention comprises the following steps:

[0011] Step S1: Build a low-code platform for business fault diagnosis process design;

[0012] Step S2: Observe the service status by collecting indicators and identify service failures to send alarms;

[0013] Step S3: Analyze the failed service using the alarm, trigger the service fault diagnosis process to run, and locate the cause of the service fault.

[0014] Furthermore, in step S1, the specific processing process is as follows:

[0015] Step S11: Develop or integrate a process engine based on the business process model specification to manage and control the execution of the business fault diagnosis process;

[0016] Step S12: Combining business characteristics, expert troubleshooting experience, business fault diagnosis large model and business fault knowledge graph, the link capabilities of JVM diagnosis, slow SQL diagnosis, Redis slow instruction diagnosis, system disk space diagnosis, system memory diagnosis, system IO diagnosis, call chain diagnosis, abnormal log prediction and timing prediction are expanded through the extension mechanism and embedded into the business fault diagnosis link;

[0017] Step S13: Develop or integrate visualization components based on business process model specifications, provide drag-and-drop operations for business fault diagnosis, and thereby obtain a low-code platform for business fault diagnosis process design;

[0018] Step S14: Analyze the business fault diagnosis process according to the actual business scenario, combine the capabilities of different business fault diagnosis links through low-code visual drag-and-drop operations, handle various situations through conditional branch links, and finally associate the business fault diagnosis process with the alarm rules.

[0019] Furthermore, in the step S11, the process engine provides lifecycle events, including: before the link starts, the end of the link execution, and the link execution exception. Before the link starts, the lifecycle creates a business fault diagnosis link report and sets the status to start execution; at the end of the link execution lifecycle, a business fault diagnosis link report is generated and the status is set to end of execution; at the lifecycle of the link execution exception, the business fault diagnosis link report status is set to exception.

[0020] Furthermore, in step S12, the serviceTask class is implemented on the server side to customize the extended link processing logic, and the expert troubleshooting experience is converted into a program through coding to realize automated troubleshooting; the business fault diagnosis big model or the business fault knowledge graph is called through the HTTP protocol, so that different businesses can extend different serviceTask classes, thereby completing the expansion of the business fault diagnosis link.

[0021] Furthermore, in the step S13, the visualization component provides an extension mechanism that can expand the visualization link of the business fault diagnosis process and provide a link visualization attribute configuration page, which corresponds to the process engine link extension mechanism; at the same time, the visualization attributes in step S13 will be mapped to the business fault diagnosis link customized in step S12, thereby completing the integrated diagnosis link design from design to operation.

[0022] Furthermore, in step S2, the specific processing process is as follows:

[0023] Step S21: collecting key business indicators in a variety of ways;

[0024] Step S22: configuring static alarm rules for key business indicators on the low-code platform;

[0025] Step S23: Generate dynamic alarm rules for key business indicators based on time series anomaly prediction;

[0026] Step S24: Push the collected indicators to the application server through the gRPC protocol. The application server performs real-time calculations based on static and dynamic alarm rules to determine whether to trigger the alarm rules and generate alarm events.

[0027] Furthermore, in step S21, key business indicators are collected in the following three ways:

[0028] Method 1: Modify the startup command when the application service is started and load the probe to collect key business indicators;

[0029] Method 2: Organize key business indicators into SQL or API interfaces, execute and collect them regularly;

[0030] Method 3: Calculate key business indicators in the application service source code and push them through the collection SDK;

[0031] For the work order system, the number of work orders received, the number of work orders successfully processed, and the number of exceptions processed are the key indicators of the business.

[0032] Furthermore, in step S22, the static alarm rules are manually set by the operation and maintenance personnel based on operation and maintenance experience, server performance, and business scenarios. Once set, they will serve as the judgment conditions for triggering alarm events; in step S23, the dynamic alarm rules are calculated based on the model, and the model compares and analyzes the historical indicator data and the indicator data in the current period to predict whether an alarm event will be triggered.

[0033] Furthermore, in step S3, the specific processing process is as follows:

[0034] Step S31: automatically analyzing the business services related to the alarm when the alarm is triggered;

[0035] Step S32: When the application server matches the service fault diagnosis process, it will automatically start the process to automatically diagnose and locate the service fault and locate the cause of the service fault.

[0036] Furthermore, in the step S32, the business fault diagnosis process is designed by the operation and maintenance personnel, and is composed of a combination of multiple business fault diagnosis links, wherein the business fault diagnosis link is based on the small model AI capability of expert experience, the enterprise-level business fault diagnosis large model AI capability and the business fault knowledge graph capability expansion, and the fault diagnosis business path is executed according to the matching priority from high to low until the root cause fault point consistent with the existing network production is found. After the end-to-end diagnosis is completed, the root cause fault conclusion and related judgment instructions are given.

[0037] Compared with the prior art, the present invention has the following advantages:

[0038] (1) The present invention streamlines, standardizes and automates fault location in a low-code visual format, reduces unit R&D and operation and maintenance costs, shortens business fault location time, and improves troubleshooting efficiency.

[0039] (2) The present invention proposes a flexible expansion idea for the fault diagnosis link, which connects expert fault experience, enterprise-level business fault diagnosis model, business fault knowledge graph and other capabilities to the low-code platform, and loads them into the fault diagnosis link through low-code capability encapsulation. It automatically drives the diagnosis process and calls the diagnosis capability based on fault events and data, thereby enhancing the agility and speed of business fault location.

[0040] (3) The present invention collects configuration, performance, alarm, link, log and other data based on probe technology. There are many similar mature general collection tools on the market, such as: SkyWalking (application performance management tool), PinPoint (application performance management tool), Filebeat (file collection tool), OpenTelemetry (general collection product with observability), etc., which provide collection technology support for the present invention and reduce the implementation cost.

[0041] (4) The present invention proposes a method for automatically executing a business fault diagnosis process by using alarm events and data to trigger the execution of the business fault diagnosis process, thereby automating the business fault diagnosis. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 It is a flow chart of a method for automatically locating business faults based on low code in an embodiment of the present invention. DETAILED DESCRIPTION

[0043] The following is a detailed description of an embodiment of the present invention. This embodiment is implemented on the premise of the technical solution of the present invention, and a detailed implementation method and a specific operation process are given, but the protection scope of the present invention is not limited to the following embodiment.

[0044] Embodiment 1

[0045] This embodiment provides a technical solution: a low-code-based automatic location method for business faults, which mainly includes the following steps:

[0046] Step 1: Build a low-code platform for business troubleshooting process design;

[0047] Step 2: Observe the business status by collecting indicators and automatically identify business failures and send alarms;

[0048] Step 3: Use the alarm to analyze the failed business, trigger the business fault diagnosis process to run, and automatically locate the cause of the business failure.

[0049] (1) The low-code platform in step 1 includes basic functional modules such as process engine, rule engine, report engine, page design, standardized API design, data source and external API access design, and docking with production application systems; it supports general basic capabilities such as process orchestration of manual and automatic links, business form page design, data- or event-based rule design required by the business, and report design; it supports the orchestration of business diagnosis processes, microservice design of capabilities, and flexible configuration and expansion of input and output parameters, and connects external capabilities such as small model AI capabilities based on expert experience, enterprise-level business fault diagnosis large model capabilities, and business fault knowledge graphs to the low-code platform to participate in the orchestration design of business diagnosis logic flows.

[0050] Main invention points: Combined with production reality, low-code capabilities are enhanced, support is provided for access to external data sources and various external API capabilities, and participation in the orchestration of business fault diagnosis processes; the results of the business fault diagnosis process orchestration are connected and distributed to the production application system, and the process can be driven based on events and data.

[0051] (2) The indicator collection and visualization in step 2, as well as the configuration of alarm rules based on indicators, can also be developed based on low-code design. The collected indicators include the configuration, performance, logs, traffic, routing, etc. of I / P / SaaS and network layers, as well as customized end-to-end business call chains, business golden indicators, and operation logs; the alarm rule configuration includes the configuration of alarm rules based on static indicators and dynamic alarm judgment combined with time series anomaly prediction technology to achieve the purpose of effective observation system.

[0052] Main invention points: Combined with production practice, the dynamic nature of alarm rules is supported. In addition to the static rules for generating alarms based on basic indicator thresholds, dynamic rules for generating alarms based on trend anomaly predictions implemented based on historical operating data and time series prediction technology are added and applied to the business fault diagnosis process.

[0053] (3) The automated business fault location in step 3 is achieved through the design and arrangement of steps 1 and 2. Based on the alarm rules and time series anomaly prediction, the business alarm is automatically monitored. When the alarm threshold is reached or anomalies are discovered, the business fault diagnosis process is automatically triggered, and the docked large and small model AI capabilities and business fault knowledge graph are called to automatically diagnose and locate the root cause of the business fault.

[0054] It should be noted that in this embodiment, small model AI capability refers to an AI model with a smaller scale, lower computing requirements, and less resource consumption in the field of artificial intelligence compared to large or complex models; large model AI capability refers to an AI model with a large number of parameters and complex structures in the field of artificial intelligence. These models usually require a large amount of data to train and can handle and solve complex tasks. The enterprise-level business fault diagnosis big model is a professional field big model built based on big model technology, combined with the enterprise's massive historical business fault knowledge, through pre-training, fine-tuning, thinking chain, enhanced learning and other technologies; the enterprise-level business fault knowledge graph is a knowledge graph built based on graph technology, combined with the enterprise's massive historical business fault knowledge and business topology.

[0055] Embodiment 2

[0056] like Figure 1 As shown, this embodiment provides a technical solution: a low-code-based automatic location method for business faults. This method is mainly used in the enterprise-level business service platform and the business operations carried thereon. When a fault occurs, automatic and rapid diagnosis and root cause location can be achieved. The diagnosis scope includes IaaS, PaaS, SaaS, network, call chain of business service processes, manual operation, and automatic root cause location after alarms or abnormalities are discovered during automatic operation. This method includes the following steps:

[0057] Step S1: Build a low-code platform for business fault diagnosis process design;

[0058] Step S2: Observe the service status by collecting indicators and automatically identify service failures and send alarms;

[0059] Step S3: Analyze the failed service using the alarm, trigger the service fault diagnosis process to run, and automatically locate the cause of the service fault.

[0060] The specific implementation of each step of the present invention is given below:

[0061] In this embodiment, the specific process of step S1 is as follows:

[0062] Step S11: Develop or integrate a process engine based on the bpmn2.0 (business process model) specification to manage and control the execution of business fault diagnosis processes; for example, integrate flowable (an open source workflow engine).

[0063] To be more specific, the process engine provides lifecycle events, including: before the link starts, the end of the link execution, and the link execution exception. Before the link starts, the lifecycle creates a business fault diagnosis link report and sets the status to start execution; at the end of the link execution lifecycle, a business fault diagnosis link report is generated and the status is set to end of execution; at the end of the link execution lifecycle, the business fault diagnosis link report status is set to exception.

[0064] More specifically, the process engine provides a link extension mechanism to facilitate the extension of business fault diagnosis link types, such as customizing flowable serviceTask (a link type) and implementing custom links by implementing serviceTask.

[0065] Step S12: Combining business characteristics, expert troubleshooting experience, business fault diagnosis large model and business fault knowledge graph, the extension mechanism is used to expand JVM diagnosis, slow SQL diagnosis, Redis slow instruction diagnosis, system disk space diagnosis, system memory diagnosis, system IO diagnosis, call chain diagnosis, abnormal log prediction, timing prediction and other link capabilities, and embed them into the business fault diagnosis link.

[0066] To be more specific, on the server side, the serviceTask class is implemented to customize the processing logic of the extension link, and the expert troubleshooting experience is converted into a program through coding to realize automated troubleshooting; the business fault diagnosis big model or business fault knowledge graph is called through the HTTP protocol, so that different businesses can extend different serviceTask classes, thereby completing the expansion of the business fault diagnosis link.

[0067] Step S13: Develop or integrate visualization components based on the bpmn2.0 specification to provide drag-and-drop operations for business fault diagnosis, such as bmpn-js (a front-end visualization process plug-in).

[0068] As a more specific example, the visualization component provides an extension mechanism that can extend the visualization link of the business fault diagnosis process and provide a link visualization attribute configuration page, which corresponds to the process engine link extension mechanism. At the same time, the visualization attribute in step S13 will be mapped to the business fault diagnosis link customized in step S12, thereby completing the integrated diagnosis link design from design to operation.

[0069] Step S14: Analyze the business fault diagnosis process according to the actual business scenario, combine the capabilities of different business fault diagnosis links through low-code visual drag-and-drop operations, handle various situations through conditional branch links, and finally associate the business fault diagnosis process with the alarm rules.

[0070] As a more specific example, the alarm rules and the business fault diagnosis process are in a many-to-many relationship, where the association can be manually set. For example, the alarm rule for the server host CPU usage exceeding 90% is associated with a handle-wlbz (network assurance service) whether it is in a high-concurrency business fault diagnosis process. It can also be associated with a fault diagnosis process for whether the server host IO usage suddenly increases.

[0071] In this embodiment, the specific process of step S2 is as follows:

[0072] Step S21: collecting indicators in three ways;

[0073] As a more specific example, the three methods of indicator collection are as follows:

[0074] Method 1: When the application service is started, modify the startup command, load the probe agent, and complete the collection of indicators such as CPU, memory, network, disk space, file system, log, JVM, thread, link, slow SQL, Redis slow instructions, etc.; such as: SkyWalking, PinPoint, OpenTelemetry, etc.;

[0075] Method 2: Organize key business indicators into SQL or API interfaces, execute and collect them regularly; for example, schedule tasks through xxl-job (scheduled task framework);

[0076] To be more specific, for a work order system, the number of work orders received, the number of work orders successfully processed, and the number of work orders processed abnormally are the key indicators of the business. For different business systems, the key indicators of the business are different.

[0077] Method 3: Calculate key business indicators in the application service source code and push them through the collection SDK; for example: skywalking-client-js (browser collector).

[0078] Step S22: Configure static alarm rules for key business indicators on the low-code platform.

[0079] More specifically, static alarm rules support aggregation operations of multiple factor combinations, such as sum, maximum value, minimum value, and average value, and support combined operations of multiple indicators, such as avg(5,jvm.cpu.us>90||trace.time>5000), which means that the cpu usage of the JVM in the last 5 minutes is greater than 90% or the call link takes more than 5 seconds.

[0080] It should be noted that static alarm rules are manually set by operation and maintenance personnel based on operation and maintenance experience, server performance, business scenarios, etc. Once set, they will serve as the judgment condition for triggering alarm events. Dynamic alarm rules are calculated based on models. The model compares and analyzes historical data (key business indicators, server indicators, I / P / SaaS indicators, etc.) and data within a period of time to predict whether an alarm event will be triggered.

[0081] Step S23: Generate dynamic alarm rules for key business indicators based on time series anomaly prediction; the indicators that can be predicted by time series anomaly are required to be digitized, such as the number of records in the anomaly log instead of the anomaly log details.

[0082] To be more specific, time series anomaly prediction is based on the analysis of business historical operation data and time series prediction technology, predicting abnormal indicators that suddenly increase or decrease and triggering alarms, using the time series anomaly prediction capability as a type of alarm rule.

[0083] As a more specific example, the specific process of timing anomaly prediction is as follows:

[0084] S231: Select an appropriate time series anomaly prediction model based on data and business characteristics, such as the ARIMA model, LSTM neural network, and GRU neural network.

[0085] S232: Use the model to predict the future data of the indicator and compare it with the actual observed value to detect whether there is an anomaly. The anomaly detection method may include judgment based on thresholds, inspection based on statistical distribution, etc.

[0086] Step S24: Push the collected indicators to the application server through the gRPC protocol. The application server performs real-time calculations based on static and dynamic alarm rules to determine whether to trigger the alarm rules and generate alarm events.

[0087] In this embodiment, the specific process of step S3 is as follows:

[0088] Step S31: When an alarm is triggered, the business service related to the alarm is automatically parsed, such as: the call chain collected by the agent can locate the business service name as handle-wlbz (custom name, abbreviation of network assurance service); the diagnosis process is parsed through the business service name to find out that the diagnosis process is the business fault diagnosis process of the abnormal network assurance service.

[0089] Step S32: When the application server matches the service fault diagnosis process, it will automatically start the process to automatically diagnose and locate the service fault and locate the cause of the service fault.

[0090] In this embodiment, based on the alarm events, business operation data and related I / P / SaaS indicator data, the business fault diagnosis process in production is automatically triggered. The whole diagnosis process, each diagnosis processing logic and the whole chain of results are visualized.

[0091] To be more specific, the business fault diagnosis process is designed by the operation and maintenance personnel and is composed of multiple business fault diagnosis links. The business fault diagnosis link is based on the small model AI capabilities of expert experience, the enterprise-level business fault diagnosis large model AI capabilities and the business fault knowledge graph capability expansion. The fault diagnosis business path is executed according to the matching priority from high to low until the root cause fault point consistent with the existing network production is found. After the end-to-end diagnosis is completed, the root cause fault conclusion and related judgment instructions are given.

[0092] As an example, through call chain collection, the entire topology of the call service chain of business operation can be obtained, and application service information, middleware information, host information, network information, etc. can be identified and obtained. Combined with the collected service call method time consumption, various instruction execution conditions, etc., these indicator data can be used to preliminarily confirm which service anomaly caused the system to freeze. Based on the business fault knowledge graph and the AI ​​capabilities of large and small models, the context of system operation, that is, the current performance, logs, and abnormal impact of abnormalities on business orders, can be associated to determine whether it is a process anomaly of a single service, a container anomaly, a network communication anomaly, or a system host performance anomaly.

[0093] To sum up, the low-code-based automated business fault location method of the above-mentioned embodiment, by building a low-code platform and designing a business fault diagnosis process, realizes the process and standardization of fault location, reduces the manpower investment in operation and maintenance, reduces the technical requirements of personnel, shortens the fault handling time, and improves the efficiency of troubleshooting; the knowledge and capabilities such as the experience of experts in solving faults, the enterprise-level business fault diagnosis model, and the enterprise-level business fault knowledge graph are accumulated and embedded into the diagnosis logic to enhance the speed, efficiency and accuracy of business fault location, and flexibly configure the business fault diagnosis process by dragging and dropping according to the actual business scenarios, quickly adapt to the complex changes of the telecommunications business system, and effectively respond to various new and old fault scenarios; various indicators and time series anomaly prediction technologies are used to automatically observe the operating status of the business system, and the business fault diagnosis process is automatically triggered by alarms and abnormal events and data, reducing manual intervention and ensuring the standardization and specialization of the fault location process.

[0094] Although the embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and are not to be construed as limitations of the present invention. A person skilled in the art may change, modify, replace and vary the above embodiments within the scope of the present invention.

Claims

1. A low-code-based automated business fault location method, characterized in that: The following steps are involved: Step S1: Build a low-code platform for business fault diagnosis process design; Step S2: Observe the service status by collecting indicators and identify service failures to send alarms; Step S3: Analyze the failed service using the alarm, trigger the service fault diagnosis process to run, and locate the cause of the service fault.

2. According to the low-code-based automated business fault location method of claim 1, it is characterized in that: In step S1, the specific processing process is as follows: Step S11: Develop or integrate a process engine based on the business process model specification to manage and control the execution of the business fault diagnosis process; Step S12: Combining business characteristics, expert troubleshooting experience, business fault diagnosis large model and business fault knowledge graph, the link capabilities of JVM diagnosis, slow SQL diagnosis, Redis slow instruction diagnosis, system disk space diagnosis, system memory diagnosis, system IO diagnosis, call chain diagnosis, abnormal log prediction and timing prediction are expanded through the extension mechanism and embedded into the business fault diagnosis link; Step S13: Develop or integrate visualization components based on business process model specifications, provide drag-and-drop operations for business fault diagnosis, and thereby obtain a low-code platform for business fault diagnosis process design; Step S14: Analyze the business fault diagnosis process according to the actual business scenario, combine the capabilities of different business fault diagnosis links through low-code visual drag-and-drop operations, handle various situations through conditional branch links, and finally associate the business fault diagnosis process with the alarm rules.

3. According to the low-code-based automated business fault location method of claim 2, it is characterized in that: In step S11, the process engine provides life cycle events, including: before the link starts, the end of the link execution, and the link execution exception. Before the link starts, the life cycle creates a business fault diagnosis link report and sets the status to start execution; at the end of the link execution life cycle, a business fault diagnosis link report is generated and the status is set to end of execution; at the life cycle of the link execution exception, the business fault diagnosis link report status is set to exception.

4. According to the low-code-based automated business fault location method of claim 2, it is characterized in that: In step S12, the serviceTask class is implemented on the server side to customize the processing logic of the extension link, and the expert troubleshooting experience is converted into a program through coding to realize automated troubleshooting; the business fault diagnosis big model or business fault knowledge graph is called through the HTTP protocol, so that different services can extend different serviceTask classes, thereby completing the expansion of the business fault diagnosis link.

5. According to the low-code-based automated business fault location method of claim 2, it is characterized in that: In the step S13, the visualization component provides an extension mechanism that can expand the visualization link of the business fault diagnosis process and provide a link visualization attribute configuration page, which corresponds to the process engine link extension mechanism; at the same time, the visualization attributes in step S13 will be mapped to the business fault diagnosis link customized in step S12, thereby completing the integrated diagnosis link design from design to operation.

6. According to the low-code-based automated business fault location method of claim 2, it is characterized in that: In step S2, the specific processing process is as follows: Step S21: collecting key business indicators in a variety of ways; Step S22: configuring static alarm rules for key business indicators on the low-code platform; Step S23: Generate dynamic alarm rules for key business indicators based on time series anomaly prediction; Step S24: Push the collected indicators to the application server through the gRPC protocol. The application server performs real-time calculations based on static and dynamic alarm rules to determine whether to trigger the alarm rules and generate alarm events.

7. According to claim 6, a low-code-based automated business fault location method is characterized in that: In step S21, key business indicators are collected in the following three ways: Method 1: Modify the startup command when the application service is started and load the probe to collect key business indicators; Method 2: Organize key business indicators into SQL or API interfaces, execute and collect them regularly; Method 3: Calculate key business indicators in the application service source code and push them through the collection SDK.

8. According to the low-code-based automated business fault location method of claim 7, it is characterized in that: In step S22, the static alarm rules are manually set by the operation and maintenance personnel based on operation and maintenance experience, server performance, and business scenarios. Once set, they will serve as the judgment conditions for triggering alarm events; in step S23, the dynamic alarm rules are calculated based on the model. The model compares and analyzes historical indicator data and indicator data in the current period to predict whether an alarm event will be triggered.

9. A low-code-based automated business fault location method according to claim 8, characterized in that: In step S3, the specific processing process is as follows: Step S31: automatically analyzing the business services related to the alarm when the alarm is triggered; Step S32: When the application server matches the service fault diagnosis process, it will automatically start the process to automatically diagnose and locate the service fault and locate the cause of the service fault.

10. A low-code-based automated business fault location method according to claim 9, characterized in that: In step S32, the business fault diagnosis process is designed by the operation and maintenance personnel and is composed of a combination of multiple business fault diagnosis links, wherein the business fault diagnosis link is based on the small model AI capability of expert experience, the enterprise-level business fault diagnosis large model AI capability and the business fault knowledge graph capability expansion, and the fault diagnosis business path is executed according to the matching priority from high to low until the root cause fault point consistent with the existing network production is found. After the end-to-end diagnosis is completed, the root cause fault conclusion and related judgment instructions are given.

Images