Alarm Method, Device, Equipment, System and Medium Based on Flink

Abstract

The present application provides an alarm method, device, equipment, system and medium based on Flink. In this method, the server obtains real-time transaction data, aggregates and pushes it into Kafka, and then uses the stream processing framework Flink to obtain data from Kafka, register entities and store the field data of the entities into a custom table. The Flink Structured Query Language (Flink SQL) script and the QLExpress script are respectively obtained from Redis and run to perform preliminary screening and cutting on the field data in the custom table, and refined screening, generation and pushing of alarm information are performed on the cut data. In this solution, when wanting to update the threshold conditions, only the Flink SQL script and the QLExpress script need to be updated, effectively improving the maintenance efficiency.

Description

Technical Field

[0001] This application relates to the field of data security, and in particular, to an alarm method, device, equipment, system and medium based on Flink. Background Technique

[0002] With the rapid development of technology, the data on various platforms is increasing day by day. For enterprises or platforms, the high efficiency of data processing, the real-time nature of alarms, the flexibility of alarm configuration, the timely effectiveness, and the diversity of application systems receiving alarm information are strong index requirements for their own alarm systems.

[0003] In the prior art, the original data is formatted and then pushed to the message system Kafka. Then, Flink is used to extract the data from Kafka and perform screening processing according to preset threshold conditions. The preset threshold conditions include the threshold conditions for primary screening of data and refined screening customized by users. Then, the screened data is written into the Remote Dictionary Server (abbreviation: Redis), and Promethues is used to pull data from Redis, and Grafana is used for data chart display and alarm.

[0004] In summary, when the existing alarm method wants to update the threshold conditions, it can only stop the execution of the method and then modify the program code corresponding to the threshold conditions, resulting in low maintenance efficiency. Summary of the Invention

[0005] This application provides an alarm method, device, equipment, system and medium based on Flink, which is used to solve the problem that when the existing alarm method wants to update the threshold conditions, it can only stop the execution of the method and then modify the program code corresponding to the threshold conditions, resulting in low maintenance efficiency.

[0006] In a first aspect, this application provides an alarm method based on Flink, which is applied to a server. The method includes:

[0007] Combining the main service field and the sub-service field of the real-time transaction data obtained from the database to obtain combined data, and storing the combined data in the message system Kafka;

[0008] Through the stream processing framework Flink, read the Json format data from the Kafka, register the Json format data as an entity, and store the field data of the entity in a custom table;

[0009] Retrieve the pre - stored Flink Structured Query Language (Flink SQL) script from the remote dictionary service Redis. The Flink SQL script is a processing script corresponding to the first threshold condition for initial screening of data set through the management console.

[0010] Run the Flink SQL script to perform initial screening and cutting on the field data in the custom table to obtain primary alarm data.

[0011] Retrieve the pre - stored rule engine QLExpress script from Redis. The rule engine QLExpress script is a processing script corresponding to the second threshold condition for refined screening of data, the alarm information generation method, and the push method customized by the user through the management console.

[0012] Run the QLExpress script to perform refined screening, generate, and push alarm information for the primary alarm data.

[0013] In a specific implementation manner, the running of the Flink SQL script to perform initial screening and cutting on the field data in the custom table to obtain primary alarm data includes:

[0014] Run the Flink SQL script to obtain the field data corresponding to the preset fields from the custom table.

[0015] Perform preliminary screening processing on the field data according to the preset first threshold condition.

[0016] Cut the preliminarily screened data according to the preset minute - length granularity to obtain the primary alarm data.

[0017] In a specific implementation manner, the running of the QLExpress script to perform refined screening, generate, and push alarm information for the primary alarm data includes:

[0018] Run the QLExpress script to perform refined screening on the primary alarm data according to the preset second threshold condition.

[0019] Generate the alarm information according to the refined - screened data and the preset alarm information generation method.

[0020] Call the preset Application Programming Interface (API) to push the alarm information to the application corresponding to the API.

[0021] In a specific implementation manner, the method further includes:

[0022] Receive the Flink SQL script and the QLExpress script sent by the management console;

[0023] Place the Flink SQL script sent by the management console and the QLExpress script sent by the management console in the database for storage;

[0024] Update the existing Flink SQL script and the existing QLExpress script in the Redis to the Flink SQL script sent by the management console and the QLExpress script sent by the management console, and set a preset expiration time for the Flink SQL script and the QLExpress script sent by the management console.

[0025] In a specific embodiment, the method further includes:

[0026] Real-time monitor the storage time of the existing Flink SQL script and the existing QLExpress script in the Redis;

[0027] If the storage time reaches the preset expiration time, obtain the Flink SQL script and the QLExpress script from the database;

[0028] Update the existing Flink SQL script and the existing QLExpress script in the Redis to the Flink SQL script and the QLExpress script obtained from the database, and set the expiration time for the Flink SQL script and the QLExpress script obtained from the database.

[0029] In a second aspect, the present application provides an alarm device based on Flink, including:

[0030] A data collection and aggregation module, configured to combine the main service field and the sub-service field of the real-time transaction data obtained from the database to obtain combined data, and store the combined data in the message system Kafka;

[0031] A data processing module, configured to read Json format data from the Kafka through the stream processing framework Flink, register the Json format data as an entity, and store the field attribute data of the entity in a custom table;

[0032] The data processing module is further configured to retrieve the pre - stored Flink Structured Query Language (Flink SQL) script from the remote dictionary service Redis. The Flink SQL script is a processing script corresponding to the first threshold condition for initial data screening set through the management console.

[0033] The data processing module is further configured to run the Flink SQL script to perform initial screening and cutting on the field attribute data in the custom table, obtaining primary alarm data.

[0034] The alarm push module is configured to retrieve the pre - stored Rule Engine QLExpress script from Redis. The Rule Engine QLExpress script is a processing script corresponding to the second threshold condition for refined data screening, the alarm information generation method, and the push method customized by the user through the management console.

[0035] The alarm push module is further configured to run the QLExpress script to perform refined screening, generate, and push alarm information for the primary alarm data.

[0036] In a specific embodiment, the data processing module is specifically configured to:

[0037] Run the Flink SQL script to obtain the field data corresponding to the preset fields from the custom table.

[0038] Perform preliminary screening processing on the field data according to the preset first threshold condition.

[0039] Cut the preliminarily screened data according to the preset minute - length granularity to obtain the primary alarm data.

[0040] In a specific embodiment, the alarm push module is specifically configured to:

[0041] Run the QLExpress script to perform refined screening on the primary alarm data according to the preset second threshold condition.

[0042] Generate the alarm information according to the refined - screened data and the preset alarm information generation method.

[0043] Call the preset Application Programming Interface (API) to push the alarm information to the application corresponding to the API.

[0044] In a specific embodiment, the device further includes:

[0045] The data storage module is configured to receive the Flink SQL script and the QLExpress script sent by the management console.

[0046] The data storage module is further configured to store the Flink SQL script sent by the management console and the QLExpress script sent by the management console in a database.

[0047] The data processing module is further configured to update the existing Flink SQL script and the existing QLExpress script in the Redis with the Flink SQL script sent by the management console and the QLExpress script sent by the management console, and set a preset expiration time for the Flink SQL script sent by the management console and the QLExpress script sent by the management console.

[0048] In a specific embodiment, the data processing module is further specifically configured to:

[0049] Real-time monitor the storage time of the existing Flink SQL script and the existing QLExpress script in the Redis;

[0050] If the storage time reaches the preset expiration time, obtain the Flink SQL script and the QLExpress script from the database;

[0051] Update the existing Flink SQL script and the existing QLExpress script in the Redis with the Flink SQL script and the QLExpress script obtained from the database, and set the expiration time for the Flink SQL script and the QLExpress script obtained from the database.

[0052] In a third aspect, the present application provides an alarm system based on Flink, including:

[0053] A server and a management console;

[0054] The server is configured to execute the Flink-based alarm method according to any one of the first aspects;

[0055] The server is further configured to store the pushed alarm information, the Flink SQL script, and the QLExpress script;

[0056] The management console is configured to manage the Flink SQL script, the QLExpress script, and the pushed alarm information.

[0057] In a fourth aspect, the present application provides a server, including:

[0058] A processor, a memory, and a communication interface;

[0059] The memory is used to store executable instructions of the processor;

[0060] Wherein, the processor is configured to execute the Flink-based alarm method according to any one of the first aspect by executing the executable instructions.

[0061] In a fifth aspect, the present application provides a readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the Flink-based alarm method according to any one of the first aspect is implemented.

[0062] The Flink-based alarm method, device, equipment, system and medium provided by the present application obtain real-time transaction data from a database and aggregate it, then push the aggregated data into Kafka, and use the stream processing framework Flink to obtain data from Kafka, register entities and store the field data of the entities into a custom table. Obtain and run a Flink Structured Query Language (Flink SQL) script from Redis, perform preliminary screening and cutting on the field data in the custom table to obtain primary alarm data. Then obtain and run a QLExpress script from Redis, perform refined screening on the primary alarm data, generate and push alarm information. This solution uses Flink SQL scripts and QLExpress scripts for alarming. When wanting to update the threshold conditions, only the Flink SQL script and the QLExpress script need to be updated, effectively improving the maintenance efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0064] Figure 1a It is a schematic diagram of the architecture of the Flink-based alarm system provided by the present application;

[0065] Figure 1b It is a first schematic diagram of the interface for the management console to manage the Flink SQL script provided by the present application;

[0066] Figure 1c It is the schematic diagram of the interface for the management console to manage the Flink SQL script provided by the present application Figure 2 ;

[0067] Figure 1d Schematic diagram 1 of the interface for the management console provided by this application to manage QLExpress scripts

[0068] Figure 1e Schematic diagram of the interface for the management console provided by this application to manage QLExpress scripts Figure 2 ;

[0069] Figure 1f Schematic diagram of the interface for the management console provided by this application to manage the pushed alarm information

[0070] Figure 2 Schematic diagram of the process of Embodiment 1 of the alarm method based on Flink provided by this application

[0071] Figure 3 Schematic diagram of the process of Embodiment 2 of the alarm method based on Flink provided by this application

[0072] Figure 4a Schematic diagram of the process of Embodiment 3 of the alarm method based on Flink provided by this application

[0073] Figure 4b Schematic diagram of two types of alarm information received by the application provided by this application

[0074] Figure 4c Schematic diagram of the interface for the management console provided by this application to display alarm call information

[0075] Figure 5 Schematic diagram of the process of Embodiment 4 of the alarm method based on Flink provided by this application

[0076] Figure 6 Schematic diagram of the process of Embodiment 5 of the alarm method based on Flink provided by this application

[0077] Figure 7 Schematic diagram of the structure of Embodiment 1 of the alarm device based on Flink provided by this application

[0078] Figure 8 Schematic diagram of the structure of Embodiment 2 of the alarm device based on Flink provided by this application

[0079] Figure 9 Schematic diagram of the structure of a server provided by this application Detailed implementation manners

[0080] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the following will clearly and completely describe the technical solutions in the embodiments of this application with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are some, but not all, of the embodiments of this application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of this application under the inspiration of this embodiment belong to the scope of protection of this application.

[0081] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of this application and the above-mentioned accompanying drawings are used to distinguish similar objects and do not necessarily need to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments of this application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products, or devices.

[0082] With the rapid development of technology, people are exposed to more and more various service platforms, and the number of users of each server platform is also increasing. This has led to a growing amount of data on the platform. High efficiency in data processing, real-time alerting, flexibility in alert configuration, timely effectiveness, and diversity of application systems receiving alert information are strong indicator requirements for each enterprise or platform for its own alert system.

[0083] When an alert is issued, the real-time transaction data of the platform needs to be formatted and pushed to the message system Kafka, and then Flink is used to retrieve the data from Kafka and perform screening processing according to preset threshold conditions. Then, the data after screening processing is written into the Remote Dictionary Server (abbreviated as Redis), and then Promethues is used to pull the data from Redis, and Grafana is used for data chart display and alerting. When wanting to update the threshold conditions, only the execution of the method can be stopped, and then the program code corresponding to the threshold conditions is modified, resulting in low maintenance efficiency.

[0084] In view of the problems existing in the prior art, during the research on the alarm method based on the stream processing framework Flink, the inventor found that a log collection tool can be used to obtain real-time transaction data from a database, and then the real-time transaction data is aggregated and stored in Kafka. The data is read from Kafka by Flink, registered as an entity, and the field data of the entity is stored in a custom table. The field data in the custom table is preliminarily screened and cut through the Flink Structured Query Language (Flink SQL) script obtained from Redis to obtain primary alarm data, and the primary alarm data is refined, screened, generated, and alarm information is pushed through the QLExpress script obtained from Redis. When the threshold condition needs to be updated, only the Flink SQL script and the QLExpress script need to be updated, and the alarm can be performed according to the latest script during the execution of the method without stopping the execution of the method. Based on the above inventive concept, the alarm solution based on Flink in this application is designed.

[0085] Exemplarily, Figure 1a is a schematic architecture diagram of the Flink-based alarm system provided by this application, as Figure 1a shown, the Flink-based alarm system includes a server and a management console, and the server includes: a data collection module, a data aggregation module, a data processing module, an alarm push module, and a data storage module.

[0086] The data collection module is used to collect real-time transaction data in the database;

[0087] The data aggregation module is used to combine the real-time transaction data into main service fields and sub-service fields to obtain combined data;

[0088] The data aggregation module is also used to store the combined data in Kafka;

[0089] The data processing module is used to read Json format data from Kafka through Flink, register the Json format data as an entity, and store the field attribute data of the entity in a custom table;

[0090] The data processing module is also used to retrieve the pre-stored Flink SQL script from Redis, and the Flink SQL script is a processing script corresponding to the first threshold condition for preliminary screening of data set through the management console;

[0091] The data processing module is also used to run the Flink SQL script to preliminarily screen and cut the field attribute data in the custom table to obtain primary alarm data;

[0092] An alarm push module, which is used to retrieve the pre-stored rule engine QLExpress script from Redis. The rule engine QLExpress script is a processing script corresponding to the second threshold condition of refined screening customized by users, the alarm information generation method, and the push method set through the management console;

[0093] The alarm push module is also used to run the QLExpress script to perform refined screening on the primary alarm data, generate and push alarm information;

[0094] A data storage module, which is used to store the pushed alarm information, Flink SQL script, and QLExpress script;

[0095] A management console, which is used to manage the Flink SQL script, QLExpress script, and the pushed alarm information.

[0096] Exemplarily, Figure 1b FIG. 1 is a schematic diagram of the interface for the management console provided by this application to manage the Flink SQL script, Figure 1c FIG. 2 is a schematic diagram of the interface for the management console provided by this application to manage the Flink SQL script, Figure 2 , Figure 1d FIG. 3 is a schematic diagram of the interface for the management console provided by this application to manage the QLExpress script, Figure 1e FIG. 4 is a schematic diagram of the interface for the management console provided by this application to manage the QLExpress script, Figure 2 , Figure 1f FIG. 5 is a schematic diagram of the interface for the management console provided by this application to manage the pushed alarm information. As Figure 1b and Figure 1c shown, operations such as querying, adding, modifying, deleting, and publishing the Flink SQL script can be performed. As Figure 1d and Figure 1e shown, operations such as querying, adding, modifying, deleting, and publishing the QLExpress script can be performed. As Figure 1f shown, the content of the alarm information can be viewed in detail, and operations such as fault analysis of the alarm information can also be performed.

[0097] Exemplarily, in combination with Figure 1a , the execution process of this solution will be described below.

[0098] When generating an alarm, first use the data collection tool Canal to collect the real-time transaction data stored in the MySQL database. Then, use an aggregation program to combine the main service fields and sub-service fields of the collected data, and store the combined data in Kafka. Through the stream processing framework Flink, read the Json format data from the Kafka, register the Json format data as an entity, and store the field data of the entity in a custom table. Retrieve the pre-stored Flink SQL script from Redis, and run the Flink SQL script to perform preliminary screening and cutting on the field data in the custom table to obtain primary alarm data. Retrieve the pre-stored QLExpress script from Redis, and run the QLExpress script to perform refined screening, generate, and push alarm information on the primary alarm data. Then, store the alarm information in the MySQL database.

[0099] When updating the threshold conditions, the Flink SQL script and QLExpress script can be updated through the management console. After the script is updated, store the updated script in the MySQL database, and synchronously update the script in Redis.

[0100] The management console can also obtain the pushed alarm information from the MySQL database and display it for users to view.

[0101] Next, the technical solution of the present application will be described in detail through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0102] Figure 2 FIG. is a schematic flowchart of the first embodiment of the Flink-based alarm method provided by the present application. As Figure 2 shown, the Flink-based alarm method specifically includes the following steps:

[0103] S201: Combine the main service fields and sub-service fields of the real-time transaction data obtained from the database to obtain combined data, and store the combined data in the message system Kafka.

[0104] When it is necessary to monitor and alarm data, the project code corresponding to this solution needs to be deployed on the server, and the server can execute the code to achieve alarm.

[0105] In this step, the server uses a log collection tool to obtain real-time transaction data stored in the database. The real-time transaction data includes the name of the capability, version number, transaction reception time, transaction processing end time, platform return code, business return code, main service fields and sub-service fields, and the associated relationship fields of the main and sub-services, etc. After the server obtains the real-time transaction data, it finds the corresponding main service fields and sub-service fields according to the associated relationship fields of the main and sub-services, combines the main service fields and sub-service fields, and pushes the combined data to the target topic in Kafka. Kafka can convert the combined data into Json format data, so that the server can read the Json format data from this topic later.

[0106] It should be noted that this application does not specifically limit the data included in the real-time transaction information, and can be selected according to the actual situation.

[0107] It should be noted that the log collection tool can be Canal, or flume, or filebeat. This application does not limit the log collection tool used by the server and can be selected according to the actual situation.

[0108] S202: Read the Json format data from Kafka through the stream processing framework Flink, register the Json format data as an entity, and store the field data of the entity in a custom table.

[0109] In this step, after the server pushes the combined data to the target topic in Kafka, it can read the Json format data from Kafka through the stream processing framework Flink, register the Json format data as an entity, and store the field data of the entity in a custom table.

[0110] Specifically, there is a custom table stored in the server, and there are fields in the table. After the server registers the Json format data as an entity, it puts the field data of the entity into the position where the field data is written in the corresponding field in the custom table.

[0111] S203: Retrieve the pre-stored Flink SQL script from Redis. The Flink SQL script is a processing script corresponding to the first threshold condition for initial screening of data set through the management console.

[0112] In this step, after the server stores the field data of the entity in the custom table, since there is a Flink SQL script stored in Redis, the pre-stored Flink SQL script can be retrieved from Redis. The Flink SQL script is a processing script corresponding to the first threshold condition for initial screening of data set through the management console.

[0113] It should be noted that before the first execution of this solution, the user needs to send the written Flink SQL script to the server through the management console, and the server stores the Flink SQL script in the database. When this solution is executed for the first time, the server retrieves the Flink SQL script from the database and stores it in Redis, and sets a preset expiration time for the Flink SQL script. Then the server can retrieve the Flink SQL script from Redis.

[0114] It should be noted that during the execution of the solution, if the threshold conditions need to be updated, the user can send the newly written Flink SQL script to the server through the management console. The server stores the new Flink SQL script in the database and updates the Flink SQL script in Redis to the new Flink SQL script. Then the server can retrieve the Flink SQL script from Redis.

[0115] It should be noted that the Flink SQL script in Redis has an expiration time. When the server detects that the storage time of the Flink SQL script in Redis reaches the expiration time, it will retrieve a new Flink SQL script from the database and update the Flink SQL script in Redis to the new Flink SQL script. Then the server can retrieve the Flink SQL script from Redis.

[0116] S204: Run the Flink SQL script to perform preliminary screening and cutting on the field data in the custom table to obtain primary alarm data.

[0117] In this step, after the server retrieves the pre-stored Flink SQL script from Redis, it runs the Flink SQL script to perform preliminary screening and cutting on the field data in the custom table to obtain primary alarm data.

[0118] Specifically, since the Flink SQL script is a processing script corresponding to the first threshold condition for preliminary screening of data set through the management console, running the Flink SQL script can query and obtain the field data corresponding to the preset fields from the custom table, and then preliminarily screen the field data according to the first threshold condition to screen out the field data that meets the first threshold condition. Then, perform cutting processing on the preliminarily screened data to obtain primary alarm data.

[0119] It should be noted that the preset fields are set in the Flink SQL script and are used to find the corresponding field data according to the preset fields. The preset fields can be maxOsnReqRecvTime, and the preset fields can also be avgTime. The present application does not limit the preset fields and can be set according to the actual situation.

[0120] S205: Retrieve the pre-stored QLExpress script from Redis. The QLExpress script is a processing script corresponding to the second threshold condition for refined data screening, the alarm information generation method, and the push method customized by the user through the management console.

[0121] In this step, after the server obtains the primary alarm data, since the QLExpress script is stored in Redis, the pre-stored QLExpress script can be retrieved from Redis. The QLExpress script is a processing script corresponding to the second threshold condition for refined data screening, the alarm information generation method, and the push method customized by the user through the management console.

[0122] It should be noted that before the first execution of this solution, the user needs to send the written QLExpress script to the server through the management console, and the server stores the QLExpress script in the database. When this solution is executed for the first time, the server retrieves the QLExpress script from the database and puts it into Redis, and sets a preset expiration time for the QLExpress script. Then the server can retrieve the QLExpress script from Redis.

[0123] It should be noted that during the execution of the solution, if the threshold condition needs to be updated, the user can send the newly written QLExpress script to the server through the management console. The server stores the new QLExpress script in the database and updates the QLExpress script in Redis to the new QLExpress script. Then the server can retrieve the QLExpress script from Redis.

[0124] It should be noted that the QLExpress script in Redis has an expiration time. When the server detects that the storage time of the QLExpress script in Redis reaches the expiration time, it will retrieve a new QLExpress script from the database and update the QLExpress script in Redis to the new QLExpress script. Then the server can retrieve the QLExpress script from Redis.

[0125] S206: Run the QLExpress script to perform refined screening on the primary alarm data, generate, and push alarm information.

[0126] In this step, after the server retrieves the pre-stored QLExpress script from Redis, it runs the QLExpress script to perform refined screening on the primary alarm data, generate, and push alarm information.

[0127] Specifically, since the QLExpress script is a processing script customized by the user through the management console for the second threshold condition of refined data screening, the alarm information generation method, and the push method, running the QLExpress script can perform refined screening on the primary alarm data according to the second threshold condition, and filter out the data that meets the second threshold condition, thus realizing the user's customized requirements. Furthermore, according to the preset alarm information generation method, the refined screened data is generated into alarm information, and then according to the preset Application Programming Interface (API), the alarm information is pushed to the application corresponding to the API.

[0128] It should be noted that the preset alarm information generation method is set in the QLExpress script and is used to generate alarm information. Exemplarily, the refined screened data is json_china, 5, 30%, and the preset alarm information generation method can be to add "Capability Name: " before the first data, "Timeout Count: " before the second data, and "Timeout Ratio: " before the third data. The generated alarm information is: Capability Name: json_china, Timeout Count: 5, Timeout Ratio: 30%. The embodiments of the present application do not limit the refined screened data, the preset alarm information generation method, and the alarm information, and can be selected and set according to the actual situation.

[0129] It should be noted that the preset API is set in the QLExpress script and is used to call this API to push the alarm information to the application corresponding to this API. The embodiments of the present application do not limit the preset API and can be set according to the actual situation.

[0130] The alarm method based on Flink provided in this embodiment is as follows: The server obtains real-time transaction data from the database, aggregates it, and stores it in Kafka. After using Flink to retrieve the data from Kafka and register it as an entity, the field data of the entity is stored in a custom table. Using the Flink SQL script retrieved from Redis, the field data in the custom table is initially screened and segmented to obtain primary alarm data. Using the QLExpress script retrieved from Redis, the primary alarm data is refined and screened, and alarm information is generated and pushed. When wanting to update the threshold conditions, compared with the prior art where the execution of the solution can only be stopped and then the program code corresponding to the threshold conditions is modified, in this solution, only the Flink SQL script and the QLExpress script need to be modified, without stopping the execution of the solution, effectively improving the maintenance efficiency. At the same time, the real-time performance and immediate effectiveness of the alarm are also improved, the updated alarm data is obtained, and the diversity of the application programs to which the alarm information is pushed and the diversity of the generated alarm information are also increased.

[0131] Figure 3 FIG. is a schematic flowchart of Embodiment 2 of the alarm method based on Flink provided in this application. As Figure 3 shown, based on the above embodiment, the above step S204 can be implemented through the following steps:

[0132] S301: Run the Flink SQL script to obtain the field data corresponding to the preset fields from the custom table.

[0133] In this step, after the server retrieves the Flink SQL script from Redis, it can run this Flink SQL script. According to the logic code in this Flink SQL script, first obtain the field data corresponding to the preset fields from the custom table.

[0134] Optionally, the server can also process the field data corresponding to the preset fields according to the preset field data processing rules stored in the Flink SQL, so as to perform data screening according to the first threshold condition subsequently.

[0135] It should be noted that the preset fields are set in the Flink SQL script and are used to find the corresponding field data according to the preset fields. Exemplarily, the fields in the custom table are time, name, ratio, and the corresponding field data are: 202001171418, json_china, 30%, respectively. If the preset fields are time and name, the corresponding field data found according to the preset fields are 202001171418 and json_china. The preset field can be errorMsg, and the preset field can also be svcName. This application does not limit the preset fields and can be set according to the actual situation.

[0136] It should be noted that the preset field data processing rules are set in the Flink SQL script and are used to process the field data according to the preset field data processing rules. Exemplarily, the field data is 202201171807, which represents 18:07 on January 17, 2022. The preset field data processing rule is to take the first 8 characters, and the processed field data is 20220117. The field data is www.******.com, and the preset field data processing rule is to add https: / / before the field data, and the processed field data is https: / / www.******.com. The embodiments of this application do not limit the field data and the preset field data processing rules, and can be selected and set according to the actual situation.

[0137] S302: Perform preliminary screening processing on the field data according to the preset first threshold condition.

[0138] In this step, after the server obtains the field data, since the preset first threshold condition is stored in the Flink SQL script, the server can perform preliminary screening processing on the field data according to the preset first threshold condition to obtain the field data that meets the threshold condition.

[0139] It should be noted that the preset first threshold condition is set in the Flink SQL script and is used to screen the field data. The thresholds included in the first threshold condition can be 0, 1, or multiple. Exemplarily, there are 2 thresholds included in the first threshold condition, corresponding to the fields of timeout times and timeout ratio, specifically 5 and 5%. After screening, the field data with timeout times exceeding 5 times and timeout ratio greater than 5% can be screened out. The embodiments of this application do not limit the preset first threshold condition, the number of thresholds included in the first threshold condition, the fields, and the field data, and can be selected and set according to the actual situation.

[0140] S303: Cut the data after preliminary screening according to the preset minute length granularity to obtain primary alarm data.

[0141] In this step, after the server preliminarily screens the field data, the preliminarily screened data is cut according to a preset minute - length granularity to obtain primary alarm data, so as to further process the primary alarm data according to the QLExpress script subsequently.

[0142] It should be noted that the preset minute - length granularity is set in the Flink SQL script and is used to cut the preliminarily screened data according to this preset minute - length granularity. The preset minute - length granularity can be 1 minute or 0.5 minute. The embodiments of the present application do not limit the preset minute - length granularity, and it can be set according to the actual situation.

[0143] The alarm method based on Flink provided in this embodiment realizes obtaining field data from a custom table, screening and cutting the field data to obtain primary alarm data by running the Flink SQL script. This solution uses the FlinkSQL script, effectively improving the data - processing rate, enhancing the real - time performance of alarms, and also improving the flexibility of configuring the first threshold condition, and realizing the update of the obtained alarm data.

[0144] Figure 4a It is a schematic flowchart of the third embodiment of the alarm method based on Flink provided by the present application. As Figure 4a shown, on the basis of the above - mentioned embodiment, the above - mentioned step S206 can be implemented through the following steps:

[0145] S401: Run the QLExpress script to finely screen the primary alarm data according to a preset second threshold condition.

[0146] In this step, after the server retrieves the QLExpress script from Redis, it can run this QLExpress script. According to the logical code in this QLExpress script, first, the primary alarm data is finely screened according to a preset second threshold condition. Since the preset second threshold condition is stored in the QLExpress script, and this second threshold condition is a threshold condition customized by the user for fine - screening data, the data screened according to this second threshold condition is more in line with the user's needs. The server can then perform a fine - screening process on the primary alarm data according to the preset second threshold condition to obtain data that meets the threshold condition.

[0147] It should be noted that the preset second threshold condition is set in the QLExpress script and is used to screen the primary alarm data. The thresholds included in the second threshold condition can be 0, 1, or multiple. Exemplarily, the second threshold condition includes 2 thresholds, corresponding to the fields of timeout times and timeout ratio, specifically 7 and 10%. After screening, the field data with the timeout times exceeding 7 and the timeout ratio greater than 10% can be screened out. The embodiments of the present application do not limit the preset second threshold condition, the number of thresholds included in the second threshold condition, the fields, and the field data, and can be selected and set according to the actual situation.

[0148] S402: Generate alarm information according to the refined screened data and the preset alarm information generation method.

[0149] In this step, after the server performs refined screening on the primary alarm data, the preset alarm information generation method is stored in the QLExpress script, and the alarm information can be generated according to the refined screened data and the preset alarm information generation method.

[0150] It should be noted that the preset alarm information generation method is set in the QLExpress script and is used to generate alarm information from the refined screened data. Exemplarily, the refined screened data is json_china, 5, 30%. The preset alarm information generation method can be to add "Capability Name:" before the first data, "Timeout Times:" before the second data, and "Timeout Ratio:" before the third data. The generated alarm information is: Capability Name: json_china, Timeout Times: 5, Timeout Ratio: 30%. The embodiments of the present application do not limit the refined screened data, the preset alarm information generation method, and the alarm information, and can be selected and set according to the actual situation.

[0151] S403: Call the preset API to push the alarm information to the application program corresponding to the API.

[0152] In this step, after the server generates the alarm information, the preset API is stored in the QLExpress script, and the alarm information can be pushed to the application program corresponding to the API.

[0153] It should be noted that the preset API is set in the QLExpress script and is used to call this API to push the alarm information to the application program corresponding to this API. The embodiments of the present application do not limit the preset API and can be set according to the actual situation.

[0154] It should be noted that the server can also call the API corresponding to the call, and inform the user of the alarm information by making a call. Furthermore, the user can view the alarm call information through the management console.

[0155] Exemplarily, Figure 4b is a schematic diagram of two types of alarm information received by the application provided in this application; as Figure 4b shown, in the first type of alarm information, there are granularity, time, timeout interval, initiator, ability name, Chinese name of ability, landing party, timeout quantity, total quantity, timeout ratio, average response time, landing address, landing path, landing timeout threshold, ability platform IP, and error information. In the second type of alarm information, there are granularity, time, timeout interval, initiator, ability name, Chinese name of ability, English name of ability_sub, Chinese name of ability_sub, landing party, timeout quantity, total quantity, timeout ratio, average response time, landing address, landing path, landing timeout threshold, ability platform IP, and error information.

[0156] It should be noted that the above examples are only examples of the alarm information received by the application provided in this application. This application does not limit the alarm information received by the application, and can be set according to actual situations.

[0157] Exemplarily, Figure 4c is a schematic diagram of the interface for the management console provided in this application to display alarm call information. As Figure 4c shown, in the interface, the system, module, level, monitoring time, alarm source, and detailed content can be viewed.

[0158] It should be noted that the above examples are only examples of the interface for the management console provided in this application to display alarm call information. This application does not limit the interface for the management console to display alarm call information, and can be set according to actual situations.

[0159] The alarm method based on Flink provided in this embodiment realizes the refined screening of primary alarm data by running the QLExpress script, generates alarm information based on the refined screened data, and then pushes the alarm information, effectively improving the real-time performance of alarms, improving the diversity of the application for pushing alarm information and the diversity of the generated alarm information, and also meeting the needs of users.

[0160] Figure 5 is a schematic flowchart of the fourth embodiment of the alarm method based on Flink provided in this application. As Figure 5 shown, when wanting to update the Flink SQL script and the QLExpress script, the alarm method based on Flink specifically includes the following steps:

[0161] S501: Receive the Flink SQL script and QLExpress script sent by the management console.

[0162] When wanting to update the threshold condition, it can be achieved by updating the Flink SQL script and QLExpress script.

[0163] In this step, if the user wants to update the threshold condition, they can modify it through the management console or rewrite the Flink SQL script and QLExpress script. The management console then responds to the user's publishing operation and sends the Flink SQL script and QLExpress script to the server, and the server can receive them.

[0164] S502: Place the Flink SQL script sent by the management console and the QLExpress script sent by the management console in the database for storage.

[0165] S503: Update the existing Flink SQL script and existing QLExpress script in Redis to the Flink SQL script sent by the management console and the QLExpress script sent by the management console, and set a preset expiration time for the Flink SQL script sent by the management console and the QLExpress script sent by the management console.

[0166] In the above steps, after the server receives the Flink SQL script and QLExpress script sent by the management console, it places the Flink SQL script sent by the management console and the QLExpress script sent by the management console in the database for storage. At the same time, it updates the existing Flink SQL script and existing QLExpress script in Redis to the Flink SQL script sent by the management console and the QLExpress script sent by the management console, and sets a preset expiration time for the Flink SQL script sent by the management console and the QLExpress script sent by the management console. This realizes the update of the Flink SQL script and QLExpress script, and also realizes the update of the threshold condition.

[0167] It should be noted that the preset expiration time is used for: when the server detects that the storage time of the Flink SQL script and the QLExpress script in Redis reaches the preset expiration time, obtaining new Flink SQL scripts and QLExpress scripts from the database and updating the Flink SQL script and the QLExpress script in Redis. The preset expiration time can be 1 minute or 10 seconds. The embodiments of the present application do not limit the preset expiration time, which can be set according to the actual situation.

[0168] The alarm method based on Flink provided in this embodiment realizes the update of the threshold condition by updating the Flink SQL script and the QLExpress script, without stopping the execution of the solution, realizes the dynamic update of the threshold condition, effectively improves the maintenance efficiency, and also meets the user requirements.

[0169] Figure 6 It is a schematic flowchart of the fifth embodiment of the alarm method based on Flink provided in the present application. As Figure 6 shown, in order to ensure the successful update of the Flink SQL script and the QLExpress script, the alarm method based on Flink specifically includes the following steps:

[0170] S601: Monitor the storage time of the existing Flink SQL script and the existing QLExpress script in Redis in real time.

[0171] To solve the problem that after the user updates the Flink SQL script and the QLExpress script, errors may occur during the process of the server storing the Flink SQL script and the QLExpress script in Redis, resulting in the failure of the script update. The expiration time is set for both the Flink SQL script and the QLExpress script in Redis.

[0172] In this step, when the Flink SQL script and the QLExpress script are stored in Redis, the server will monitor the storage time of the existing Flink SQL script and the existing QLExpress script in Redis in real time, so as to update the Flink SQL script and the QLExpress script when the storage time reaches the preset expiration time.

[0173] S602: If the storage time reaches the preset expiration time, obtain the Flink SQL script and the QLExpress script from the database.

[0174] S603: Update the existing Flink SQL scripts and QLExpress scripts in Redis to the Flink SQL scripts and QLExpress scripts fetched from the database, and set an expiration time for the Flink SQL scripts and QLExpress scripts fetched from the database.

[0175] In the above steps, if the server monitors that the storage time reaches the preset expiration time, it fetches the Flink SQL scripts and QLExpress scripts from the database, and then updates the existing Flink SQL scripts and QLExpress scripts in Redis to the Flink SQL scripts and QLExpress scripts fetched from the database, and sets an expiration time for the Flink SQL scripts and QLExpress scripts fetched from the database, thus realizing the update of the Flink SQL scripts and QLExpress scripts.

[0176] It should be noted that the preset expiration time is used to: when the server monitors that the storage time of the Flink SQL scripts and QLExpress scripts in Redis reaches the preset expiration time, fetch new Flink SQL scripts and QLExpress scripts from the database, and update the Flink SQL scripts and QLExpress scripts in Redis. The preset expiration time can be 1 minute or 10 seconds. The embodiments of the present application do not limit the preset expiration time, which can be set according to actual situations.

[0177] The alarm method based on Flink provided in this embodiment ensures the successful update of the Flink SQL scripts and QLExpress scripts by the server monitoring in real time whether the storage time of the Flink SQL scripts and QLExpress scripts reaches the preset expiration time, and when it reaches the expiration time, updating the Flink SQL scripts and QLExpress scripts in Redis to the new Flink SQL scripts and QLExpress scripts fetched from the database.

[0178] The following is the device embodiment of the present application, which can be used to execute the method embodiment of the present application. For the details not disclosed in the device embodiment of the present application, please refer to the method embodiment of the present application.

[0179] Figure 7 It is the structural schematic diagram of the first embodiment of the alarm device based on Flink provided by the present application; as Figure 7 shown, the alarm device 70 based on Flink includes:

[0180] The data collection and aggregation module 71 is used to combine the main service fields and sub-service fields of the real-time transaction data obtained from the database to obtain combined data, and store the combined data in the message system Kafka;

[0181] The above data collection and aggregation module includes a data collection module and a data aggregation module;

[0182] The data collection module is used to collect real-time transaction data from the database;

[0183] The data aggregation module is used to combine the real-time transaction data with the main service fields and sub-service fields to obtain combined data;

[0184] The data aggregation module is also used to store the combined data in Kafka;

[0185] The data processing module 72 is used to read Json format data from the Kafka through Flink, register the Json format data as an entity, and store the field attribute data of the entity in a custom table;

[0186] The data processing module 72 is also used to retrieve the pre-stored Flink Structured Query Language (Flink SQL) script from the remote dictionary service Redis. The Flink SQL script is a processing script corresponding to the first threshold condition for initial screening of data set through the management console;

[0187] The data processing module 72 is also used to run the Flink SQL script to perform initial screening and cutting on the field attribute data in the custom table to obtain primary alarm data;

[0188] The alarm push module 73 is used to retrieve the pre-stored rule engine QLExpress script from Redis. The rule engine QLExpress script is a processing script corresponding to the second threshold condition for refined screening of data, the alarm information generation method, and the push method customized by the user through the management console;

[0189] The alarm push module 73 is also used to run the QLExpress script to perform refined screening, generate, and push alarm information on the primary alarm data.

[0190] Further, the data processing module 72 is specifically used for:

[0191] Run the Flink SQL script to obtain the field data corresponding to the preset fields from the custom table;

[0192] Perform preliminary screening on the field data according to a preset first threshold condition;

[0193] Cut the preliminarily screened data according to a preset minute - length granularity to obtain the primary alarm data.

[0194] Further, the alarm push module 73 is specifically used for:

[0195] Run the QLExpress script and perform refined screening on the primary alarm data according to a preset second threshold condition;

[0196] Generate the alarm information according to the refined - screened data and a preset alarm information generation method;

[0197] Call a preset application programming interface API to push the alarm information to the application corresponding to the API.

[0198] The alarm device based on Flink provided in this embodiment is used to execute the technical solution of the server in any of the foregoing method embodiments. Its implementation principle and technical effects are similar and will not be elaborated here.

[0199] Figure 8 It is a schematic structural diagram of the second embodiment of the alarm device based on Flink provided in this application; as Figure 8 shown, the alarm device 70 based on Flink further includes:

[0200] A data storage module 74, which is used to receive the Flink SQL script and the QLExpress script sent by the management console.

[0201] Further, the data storage module 74 is also used to place the Flink SQL script sent by the management console and the QLExpress script sent by the management console in a database for storage;

[0202] Further, the data processing module 72 is also used to update the existing Flink SQL script and the existing QLExpress script in the Redis with the Flink SQL script sent by the management console and the QLExpress script sent by the management console, and set a preset expiration time for the Flink SQL script sent by the management console and the QLExpress script sent by the management console.

[0203] Further, the data processing module 72 is specifically further used for:

[0204] Monitor the storage time of the existing Flink SQL scripts and existing QLExpress scripts in the Redis in real time;

[0205] If the storage time reaches the preset expiration time, obtain the Flink SQL script and QLExpress script from the database;

[0206] Update the existing Flink SQL script and existing QLExpress script in the Redis to the Flink SQL script and QLExpress script obtained from the database, and set the expiration time for the Flink SQL script and QLExpress script obtained from the database.

[0207] The alarm device based on Flink provided in this embodiment is used to execute the technical solution of the server in any of the foregoing method embodiments, and its implementation principle and technical effect are similar, which will not be elaborated here.

[0208] This application also provides an alarm system based on Flink, including:

[0209] A server and a management console;

[0210] The server is used to execute the technical solution of the server in any of the foregoing method embodiments;

[0211] The server is also used to store the pushed alarm information, Flink SQL script and QLExpress script;

[0212] The management console is used to manage the Flink SQL script, the QLExpress script and the pushed alarm information.

[0213] Figure 9 This is a schematic structural diagram of a server provided by this application. As Figure 9 shown, the server 90 includes:

[0214] A processor 91, a memory 92, and a communication interface 93;

[0215] The memory 92 is used to store the executable instructions of the processor 91;

[0216] Among them, the processor 91 is configured to execute the technical solution of the server in any of the foregoing method embodiments by executing the executable instructions.

[0217] Optionally, the memory 92 can be either independent or integrated with the processor 91.

[0218] Optionally, when the memory 92 is a device independent of the processor 91, the server 90 may further include:

[0219] A bus for connecting the above-mentioned devices.

[0220] This server is used to execute the technical solutions of the server in any of the foregoing method embodiments. The implementation principles and technical effects are similar and will not be elaborated here.

[0221] An embodiment of the present application also provides a readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the technical solutions provided in any of the foregoing method embodiments.

[0222] An embodiment of the present application also provides a computer program product, including a computer program. When the computer program is executed by a processor, it is used to implement the technical solutions provided in any of the foregoing method embodiments.

[0223] Those of ordinary skill in the art can understand that all or part of the steps of implementing the foregoing method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps including the foregoing method embodiments; and the foregoing storage medium includes: various media such as ROM, RAM, magnetic disk, or optical disc that can store program codes.

[0224] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. An alarm method based on Flink, characterized in that Applied to a server, the method includes: Combining the main service field and the sub-service field of the real-time transaction data obtained from the database to obtain combined data, and storing the combined data into the message system Kafka; Reading the Json format data from the Kafka through the stream processing framework Flink, registering the Json format data as an entity, and storing the field data of the entity into a custom table; Taking out the pre-stored Flink Structured Query Language (Flink SQL) script from the remote dictionary service Redis, where the Flink SQL script is a processing script corresponding to the first threshold condition for initial screening of data set through the management console; Running the Flink SQL script to perform initial screening and cutting on the field data in the custom table to obtain primary alarm data; Taking out the pre-stored rule engine QLExpress script from Redis, where the rule engine QLExpress script is a processing script corresponding to the second threshold condition for refined screening of data, the alarm information generation method, and the push method customized by the user through the management console; Running the QLExpress script to perform refined screening, generate, and push alarm information for the primary alarm data.

2. The method according to claim 1, wherein The running the Flink SQL script to perform initial screening and cutting on the field data in the custom table to obtain primary alarm data includes: Running the Flink SQL script to obtain the field data corresponding to the preset fields from the custom table; Performing preliminary screening processing on the field data according to the preset first threshold condition; Cutting the preliminarily screened data according to the preset minute length granularity to obtain the primary alarm data.

3. The method according to claim 2, characterized in that, The running the QLExpress script to perform refined screening, generate, and push alarm information for the primary alarm data includes: Running the QLExpress script to perform refined screening on the primary alarm data according to the preset second threshold condition; Generating the alarm information according to the refined screened data and the preset alarm information generation method; Invoking the preset application programming interface (API) to push the alarm information to the application corresponding to the API.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Receiving the Flink SQL script and the QLExpress script sent by the management console; Placing the Flink SQL script sent by the management console and the QLExpress script sent by the management console in the database for storage; Updating the existing Flink SQL script and the existing QLExpress script in the Redis to the Flink SQL script sent by the management console and the QLExpress script sent by the management console, and setting a preset expiration time for the Flink SQL script sent by the management console and the QLExpress script sent by the management console.

5. The method according to any one of claims 1 to 3, characterized in that The method further includes: Monitor the storage time of existing Flink SQL scripts and existing QLExpress scripts in Redis in real time; If the storage time reaches the preset expiration time, obtain the Flink SQL script and the QLExpress script from the database; Update the existing Flink SQL script and the existing QLExpress script in Redis to the Flink SQL script and the QLExpress script obtained from the database, and set the expiration time for the Flink SQL script and the QLExpress script obtained from the database.

6. An alarm device based on Flink, characterized in that, It includes: A data collection and aggregation module, which is used to combine the main service field and the sub-service field of the real-time transaction data obtained from the database to obtain combined data, and store the combined data in the message system Kafka; A data processing module, which is used to read the Json format data from the Kafka through the stream processing framework Flink, register the Json format data as an entity, and store the field attribute data of the entity in a custom table; The data processing module is also used to retrieve the pre-stored Flink Structured Query Language (Flink SQL) script from the remote dictionary service Redis. The Flink SQL script is a processing script corresponding to the first threshold condition for initial screening of data set through the management console; The data processing module is also used to run the Flink SQL script to perform initial screening and slicing on the field attribute data in the custom table to obtain primary alarm data; An alarm push module, which is used to retrieve the pre-stored rule engine QLExpress script from Redis. The rule engine QLExpress script is a processing script corresponding to the second threshold condition for refined screening of data, the alarm information generation method, and the push method set through the management console; The alarm push module is also used to run the QLExpress script to perform refined screening, generate, and push alarm information on the primary alarm data.

7. The device according to claim 6, characterized in that The data processing module is specifically used for: Running the Flink SQL script to obtain the field data corresponding to the preset fields from the custom table; Performing preliminary screening processing on the field data according to the preset first threshold condition; Slicing the preliminarily screened data according to the preset minute-length granularity to obtain the primary alarm data.

8. The device according to claim 7, characterized in that, The alarm push module is specifically used for: Running the QLExpress script to perform refined screening on the primary alarm data according to the preset second threshold condition; Generating the alarm information according to the refined screened data and the preset alarm information generation method; Invoking the preset application programming interface (API) to push the alarm information to the application corresponding to the API.

9. The device according to any one of claims 6 to 8, characterized in that, The device further includes: A data storage module, which is used to receive the Flink SQL script and the QLExpress script sent by the management console; The data storage module is further configured to store the Flink SQL script sent by the management console and the QLExpress script sent by the management console in a database. The data processing module is further configured to update the existing Flink SQL script and the existing QLExpress script in the Redis with the Flink SQL script sent by the management console and the QLExpress script sent by the management console, and set a preset expiration time for the Flink SQL script sent by the management console and the QLExpress script sent by the management console.

10. The device according to any one of claims 6 to 8, characterized in that Specifically, the data processing module is further configured to: Real-time monitor the storage time of the existing Flink SQL script and the existing QLExpress script in the Redis. If the storage time reaches the preset expiration time, obtain the Flink SQL script and the QLExpress script from the database. Update the existing Flink SQL script and the existing QLExpress script in the Redis with the Flink SQL script and the QLExpress script obtained from the database, and set the expiration time for the Flink SQL script and the QLExpress script obtained from the database.

11. An alarm system based on Flink, characterized in that, Comprising: A server and a management console; The server is configured to execute the Flink-based alarm method according to any one of claims 1 to 5. The server is further configured to store the pushed alarm information, the Flink SQL script, and the QLExpress script. The management console is configured to manage the Flink SQL script, the QLExpress script, and the pushed alarm information.

12. A server, characterized in that, Comprising: A processor, a memory, and a communication interface; The memory is configured to store executable instructions of the processor. Wherein, the processor is configured to execute the Flink-based alarm method according to any one of claims 1 to 5 by executing the executable instructions.

13. A readable storage medium, on which a computer program is stored, characterized in that, When the computer program is executed by the processor, it implements the Flink-based alarm method according to any one of claims 1 to 5.

Images