User query history real-time alarm method, device and equipment and medium

By acquiring and processing log data from the Presto and Druid query systems in real time, and using preset rules to manage and judge abnormal queries, the problem of low efficiency in real-time monitoring and alarm rule iteration in existing technologies is solved, and real-time alarms and dynamic updates are realized.

CN120910084APending Publication Date: 2025-11-07HANGZHOU FUYUN NETWORK TECHNOLOGY CO LTD
4 Cites 0 Cited by

Patent Information

Application Number
CN202511086555.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-08-04
Publication Date
2025-11-07

Smart Images

  • Figure CN120910084A_ABST
    Figure CN120910084A_ABST
Patent Text Reader

Abstract

The invention discloses a user query history real-time alarm method and device, equipment and a medium, and relates to the technical field of computers. Comprising the steps of obtaining log data generated by a target query system in real time; the target query system comprises a Presto query system and a Ruid query system; determining a corresponding analysis rule according to the specific type of the log data, and performing real-time data processing on the log data based on the analysis rule to obtain a corresponding log data processing result; judging whether an abnormal query condition exists or not based on the log data processing result by utilizing a preset alarm rule, if the abnormal query condition exists, executing an alarm operation, and storing the log data so as to execute a data traceability operation; wherein the preset alarm rule is an alarm rule formulated by using a preset rule management system. Therefore, the query request data can be obtained in real time, the traceability time is shortened, the alarm rule logic is simplified, and dynamic updating is supported.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer technology, and in particular to a user query history real-time alarm method, device, equipment and medium. BACKGROUND

[0002] In a big data query system, real-time monitoring of abnormal query behavior is a key requirement for ensuring system stability and security. The current mainstream solution mainly realizes query monitoring through the following two ways:

[0003] The log analysis-based solution: the Apache Druid (an open-source data storage and query system designed for online real-time analysis and high-capacity data workloads) system outputs query request logs in text form, and extracts query features by analyzing log content. However, Druid logs are semi-structured text, and require customized analysis logic (such as regular expressions); log files need to be collected after being written to disk, which has inherent delay, resulting in high analysis complexity and inability to achieve second-level real-time monitoring

[0004] The system table polling-based solution: Presto (an open-source distributed SQL query engine suitable for fast real-time analysis of large-scale data) can obtain historical query records by periodically querying metadata tables, and then analyze the results. However, the Presto system table needs to pull data through periodic SQL queries, which is essentially a polling mechanism. The system table is designed for metadata storage rather than real-time streaming. High-frequency queries increase system load and have minute-level delay, making it impossible to capture transient abnormal queries.

[0005] In order to trigger an alarm for abnormal query behavior, existing technologies usually need to write hard-coded rule logic (such as developing an alarm service based on Java / Python), but when the rules change, the service needs to be redeployed. Rule iteration is inefficient, and restarting the service causes monitoring to be interrupted, violating business continuity requirements.

[0006] As can be seen from the above, how to real-time obtain query request data, shorten the trace time, and simplify the alarm rule logic to support dynamic update is a problem to be solved. SUMMARY

[0007] Therefore, the purpose of the present application is to provide a user query history real-time alarm method, device, equipment and medium, which can real-time obtain query request data, shorten the trace time, and simplify the alarm rule logic to support dynamic update. The specific scheme is as follows:

[0008] In a first aspect, the present application discloses a user query history real-time alarm method, comprising:

[0009] obtaining log data generated by a target query system in real time; the target query system comprises a Presto query system and a Druid query system; the log data comprises first log data for the Presto query system and second log data for the Druid query system;

[0010] determining a corresponding parsing rule according to a specific type of the log data, and performing real-time data processing on the log data based on the parsing rule to obtain a corresponding log data processing result; the log data processing result comprises user information data, query record data, query table data, query time data, and target query system information data;

[0011] judging whether there is an abnormal query condition based on the log data processing result by using a preset alarm rule, and if there is an abnormal query condition, performing an alarm operation and storing the log data to perform a data trace operation;

[0012] The preset alarm rule is an alarm rule formulated by using a preset rule management system.

[0013] Optionally, if the target query system is the Presto query system, the real-time obtaining of the log data generated by the target query system comprises:

[0014] obtaining request data and response data of the Presto query system by using a preset presto event listener;

[0015] performing a splicing operation on the request data and the response data to obtain first log data in json format.

[0016] Optionally, if the target query system is the Druid query system, the real-time obtaining of the log data generated by the target query system comprises:

[0017] adjusting related parameters of the Druid query system, and obtaining second log data based on a preset data stream processing plug-in.

[0018] Optionally, if the specific type of the log data is the first log data, the determining of the corresponding parsing rule according to the specific type of the log data and the performing of the real-time data processing on the log data based on the parsing rule to obtain the corresponding log data processing result comprise:

[0019] performing sql statement analysis on the first log data by using a preset real-time analysis database to obtain the corresponding log data processing result.

[0020] Optionally, if the specific type of the log data is second log data, the corresponding parsing rule is determined according to the specific type of the log data, and real-time data processing is performed on the log data based on the parsing rule to obtain a corresponding log data processing result, which includes:

[0021] The second log data is filtered, and the filtered second log data is spliced to obtain json format second log data;

[0022] The json format second log data is parsed by a preset real-time analysis database through an sql statement to obtain a corresponding log data processing result.

[0023] Optionally, the preset alarm rule is used to determine whether there is an abnormal query condition based on the log data processing result, which includes:

[0024] Based on the user information data, the query record data, the query table data, the query time data and the target query system information data in the log data processing result, the number of table queries, the query frequency and the user authority are determined by using a preset big data processing framework;

[0025] The preset alarm rule is used to determine whether there is an abnormal query condition based on the number of table queries, the query frequency and the user authority.

[0026] Optionally, the user query history real-time alarm method further includes:

[0027] The preset rule management system is used to modify the rule file to complete dynamic updating of the preset alarm rule.

[0028] In a second aspect, the application discloses a user query history real-time alarm device, which includes:

[0029] A log data acquisition module is configured to acquire log data generated by a target query system in real time; the target query system includes a Presto query system and a Druid query system; the log data includes first log data for the Presto query system and second log data for the Druid query system;

[0030] A log data processing module is configured to determine a corresponding parsing rule according to the specific type of the log data, and perform real-time data processing on the log data based on the parsing rule to obtain a corresponding log data processing result; the log data processing result includes user information data, query record data, query table data, query time data and target query system information data;

[0031] An abnormal query condition alarm module is configured to determine whether an abnormal query condition exists based on the log data processing result by using a preset alarm rule, and if the abnormal query condition exists, an alarm operation is performed, and the log data is stored to facilitate a data trace operation.

[0032] The preset alarm rule is an alarm rule formulated by using a preset rule management system.

[0033] In a third aspect, the present application discloses an electronic device, comprising:

[0034] A memory is configured to save a computer program.

[0035] A processor is configured to execute the computer program to implement the user query history real-time alarm method.

[0036] In a fourth aspect, the present application discloses a computer readable storage medium configured to save a computer program, wherein the computer program is executed by a processor to implement the user query history real-time alarm method.

[0037] The present application provides a user query history real-time alarm method, which first acquires log data generated by a target query system in real time; the target query system comprises a Presto query system and a Druid query system; the log data comprises first log data for the Presto query system and second log data for the Druid query system; then a corresponding analysis rule is determined according to the specific type of the log data, and real-time data processing is performed on the log data based on the analysis rule to obtain a corresponding log data processing result; the log data processing result comprises user information data, query record data, query table data, query time data, and target query system information data; finally, a preset alarm rule is used to determine whether an abnormal query condition exists based on the log data processing result, and if the abnormal query condition exists, an alarm operation is performed, and the log data is stored to facilitate a data trace operation; wherein the preset alarm rule is an alarm rule formulated by using a preset rule management system.

[0038] As can be seen from the above, the present application can acquire query request data in real time, shorten the trace time length, and simplify the alarm rule logic to support dynamic updating by acquiring log data generated by a target query system in real time, performing real-time data processing on different types of log data by using an analysis rule, and using an alarm rule formulated by a preset rule management system. BRIEF DESCRIPTION OF DRAWINGS

[0039] 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 needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only a part of the present application, and for those skilled in the art, other drawings can be obtained based on the provided drawings without any creative effort.

[0040] Figure 1 A user query history real-time alarm method flow chart disclosed by the present application;

[0041] Figure 2 A user query data traceability timing chart disclosed by the present application;

[0042] Figure 3 A user query history real-time alarm device schematic diagram disclosed by the present application;

[0043] Figure 4 An electronic device structure diagram disclosed by the present application. DETAILED DESCRIPTION

[0044] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort are within the protection scope of the present application.

[0045] In a big data query system, real-time monitoring of abnormal query behavior is a key requirement to ensure system stability and security. The current mainstream solution mainly realizes query monitoring in the following two ways: a log analysis-based solution: such as Apache Druid, an open-source data storage and query system designed for online real-time analysis and high-capacity data workloads, the system outputs query request logs in text form, and extracts query features by analyzing log content. But Druid logs are semi-structured text, and customized parsing logic (such as regular expressions) is required; log files need to be collected after being written to disk, which has inherent delay, resulting in high complexity of analysis and inability to achieve real-time monitoring at the second level. A system table polling-based solution: such as Presto, an open-source distributed SQL query engine suitable for fast real-time analysis of large-scale data, historical query records can be obtained by periodically querying metadata tables, and the results can be analyzed. But the Presto system table needs to pull data through periodic SQL queries, which is essentially a polling mechanism, and the system table is designed for metadata storage rather than real-time streaming. High-frequency queries increase system load and have a delay of minutes, making it impossible to capture transient abnormal queries. To be able to trigger alarms for abnormal query behavior, existing technologies usually require hard-coded rule logic (e.g., Java / Python-based alarm services), but when the rules change, the service needs to be redeployed. Rule iteration is inefficient, and restarting the service disrupts monitoring, violating business continuity requirements. To this end, the present application provides a user query history real-time alarm solution that can obtain query request data in real time, shorten the trace length, and simplify alarm rule logic to support dynamic updates.

[0046] Referring to Figure 1 The embodiments of the present application disclose a user query history real-time alarm method, which comprises:

[0047] Step S11, real-time log data generated by the target query system is obtained.

[0048] In this embodiment, a corresponding data acquisition method is selected according to the specific type of the target query system. The target query system includes a Presto query system and a Druid query system. In some specific embodiments, the request and response parameters of the Presto query system can be obtained in real time by listening, thereby obtaining the log data of the target query system. Specifically, if the target query system is the Presto query system, the real-time log data generated by the target query system can include: obtaining the request data and response data of the Presto query system through a preset presto event listener; and splicing the request data and the response data to obtain first log data in json format.

[0049] Further, in some embodiments, the log data can be obtained by a data stream processing plug-in by modifying a corresponding parameter of the Druid query system. Specifically, if the target query system is the Druid query system, the real-time obtaining of the log data generated by the target query system can include adjusting a druid.emitter parameter of the Druid query system and obtaining second log data based on a preset data stream processing plug-in. The preset data stream processing plug-in can include but is not limited to a kafka-emitter market plug-in, and the specific plug-in type can be determined according to actual application conditions.

[0050] In step S12, a corresponding parsing rule is determined according to the specific type of the log data, and real-time data processing is performed on the log data based on the parsing rule to obtain a corresponding log data processing result.

[0051] In this embodiment, a corresponding parsing rule is determined according to the specific type of the log data. The log data includes first log data for the Presto query system and second log data for the Druid query system. Specifically, if the specific type of the log data is the first log data, the corresponding parsing rule is determined according to the specific type of the log data, and real-time data processing is performed on the log data based on the parsing rule to obtain a corresponding log data processing result, which can include performing sql statement parsing on the first log data by using Alibaba druid (an open source high-performance real-time analysis database capable of quickly ingesting a large amount of data) to obtain a corresponding log data processing result. Further, if the specific type of the log data is the second log data, the corresponding parsing rule is determined according to the specific type of the log data, and real-time data processing is performed on the log data based on the parsing rule to obtain a corresponding log data processing result, which can include filtering the second log data and performing a splicing operation on the filtered second log data to obtain json format second log data; performing sql statement parsing on the json format second log data by using Alibaba druid to obtain a corresponding log data processing result. It is worth mentioning that the log data processing result includes user information data, query record data, query table data, query time data, and target query system information data. Real-time monitoring and processing of target log data can be achieved by using the Alibaba druid, thereby ensuring the timeliness of data processing.

[0052] Step S13, determining whether there is an abnormal query condition based on the log data processing result by using a preset alarm rule, if there is an abnormal query condition, performing an alarm operation, and storing the log data to perform a data trace operation.

[0053] In this embodiment, the alarm rule formulated by the preset rule management system is used, and it is determined whether there is an abnormal query condition based on the log data processing result by using the preset alarm rule. In some specific embodiments, the preset rule management system can be Drools (an open source business rule management system based on Java, which uses a rule-based method to implement business logic). Specifically, determining whether there is an abnormal query condition based on the log data processing result by using the preset alarm rule can include: determining the table query times, query frequency based on the user information data, query record data, query table data, query time data, target query system information data in the log data processing result, and determining the user authority by using Flink (an open source big data processing framework, which can perform stateful computing in a distributed environment); determining whether there is an abnormal query condition based on the table query times, the query frequency and the user authority by using the preset alarm rule. Wherein, the table query times is the number of times the user queries the table in a day; the query frequency is the number of times the user queries the table per minute. That is, the user authority data is queried by flink at regular intervals and broadcasted, and then it is determined whether the user has the authority to query the table data, and it is determined whether there is an abnormal condition such as frequent query request of a single person in a short time or multiple query of a single person to a high-level table in a period of time based on the table query times, the query frequency and the corresponding data. Further, if the above abnormal condition occurs, the embodiment can send an alarm information to the relevant personnel by a preset alarm mode, for example, calling a communication interface to send an alarm SMS to the relevant personnel.

[0054] It should be noted that the Drools rule engine framework can simply implement rule limitation, and supports hot deployment and hot update, so that the embodiment can dynamically update the alarm rule. Specifically, the user query history real-time alarm method can also include: modifying the.drl file by using Drools, and recreating kieContainer to load the new rule file to implement alarm rule hot update.

[0055] Referring to Figure 2 As shown in the figure, after the abnormal query, the query history data also needs to be stored in the preset storage space to perform trace tracking. For example, in one specific embodiment, the user uses presto or druid to query data through the platform or code

[0056] Presto and apache druid normally respond to user requests while sending service logs to Kafka (an open source stream processing platform designed for processing real-time data streams and having the characteristics of high throughput, scalability and persistence) for subsequent monitoring; the valid data in the log data is extracted, and the user query sql statement is parsed using an open source tool class; some abnormal rules are alarmed, and the processed data is stored persistently for user statistical analysis.

[0057] As can be seen from the above, the embodiment of the application can obtain query request data in real time, shorten the traceability time length, and simplify the alarm rule logic and support dynamic updating by using the alarm rules formulated by the drools rule engine by real-time acquisition of log data generated by a target query system and real-time data processing of different types of log data using parsing rules.

[0058] Referring to Figure 3 The embodiment of the application discloses a user query history real-time alarm device, which comprises:

[0059] A log data acquisition module 11 is configured to acquire log data generated by a target query system in real time; the target query system comprises a Presto query system and a Druid query system; the log data comprises first log data for the Presto query system and second log data for the Druid query system;

[0060] A log data processing module 12 is configured to determine a corresponding parsing rule according to the specific type of the log data, and perform real-time data processing on the log data based on the parsing rule to obtain a corresponding log data processing result; the log data processing result comprises user information data, query record data, query table data, query time data, and target query system information data.

[0061] An abnormal query condition alarm module 13 is configured to determine whether there is an abnormal query condition based on the log data processing result by using a preset alarm rule, and if there is an abnormal query condition, perform an alarm operation and store the log data for performing a data traceability operation.

[0062] The preset alarm rule is an alarm rule formulated by using a preset rule management system.

[0063] As can be seen from the above, the embodiment of the application can obtain query request data in real time, shorten the traceability time length, and simplify the alarm rule logic and support dynamic updating by using the alarm rules formulated by the drools rule engine by real-time acquisition of log data generated by a target query system and real-time data processing of different types of log data using parsing rules.

[0064] In some embodiments, the log data acquisition module 11 can specifically include:

[0065] A data monitoring unit is configured to acquire request data and response data of the Presto query system through a preset presto event listener.

[0066] A first log data acquisition unit is configured to splice the request data and the response data to obtain first log data in json format.

[0067] A second log data acquisition unit is configured to adjust related parameters of the Druid query system and acquire second log data based on a preset data stream processing plug-in.

[0068] In some embodiments, the log data processing module 12 can specifically include:

[0069] A first log data processing unit is configured to parse the first log data using a preset real-time analysis database through an sql statement to obtain a corresponding log data processing result.

[0070] A second log data filtering unit is configured to filter the second log data and splice the filtered second log data to obtain second log data in json format.

[0071] A second log data processing unit is configured to parse the second log data in json format using a preset real-time analysis database through an sql statement to obtain a corresponding log data processing result.

[0072] In some embodiments, the abnormal query condition alarm module 13 can specifically include:

[0073] A user permission determination unit is configured to determine table query times and query frequencies based on user information data, query record data, query table data, query time data, and target query system information data in the log data processing result, and determine user permissions using a preset big data processing framework.

[0074] An abnormal query condition judgment unit is configured to determine whether there is an abnormal query condition based on the table query times, the query frequencies, and the user permissions using a preset alarm rule.

[0075] In some embodiments, the user query history real-time alarm apparatus can further include:

[0076] An alarm rule updating unit is configured to modify a rule file using the preset rule management system to complete dynamic updating of the preset alarm rule.

[0077] Further, the embodiment of the present application further discloses an electronic device, Figure 4 is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the content in the figure cannot be considered as any limitation on the use range of the present application. The electronic device 20 can specifically include at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25 and a communication bus 26. Wherein, the memory 22 is used for storing a computer program, the computer program is loaded and executed by the processor 21, so as to realize the related steps in the user query history real-time alarm method disclosed in any of the foregoing embodiments. In addition, the electronic device 20 in the embodiment can be an electronic computer.

[0078] In the embodiment, the power supply 23 is used for providing working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol followed by the communication interface 24 can be any communication protocol applicable to the technical solution of the present application, which is not limited here; the input / output interface 25 is used for obtaining external input data or outputting data to the outside, and the specific interface type can be selected according to the specific application needs, which is not limited here.

[0079] In addition, the memory 22 as a carrier of resource storage can be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage mode can be temporary storage or permanent storage.

[0080] Wherein, the operating system 221 is used for managing and controlling each hardware device on the electronic device 20 and the computer program 222, and can be Windows Server, Netware, Unix, Linux, etc. In addition to the computer program capable of completing the user query history real-time alarm method executed by the electronic device 20 disclosed in any of the foregoing embodiments, the computer program 222 can further include a computer program capable of completing other specific work.

[0081] Further, the present application further discloses a computer readable storage medium for storing a computer program; wherein the computer program is executed by the processor to realize the user query history real-time alarm method disclosed above. The specific steps of the method can refer to the corresponding content disclosed in the foregoing embodiments, which will not be repeated here.

[0082] The various embodiments described in the specification are progressive in nature, and each embodiment highlights the differences from other embodiments. The same or similar parts among the various embodiments can be mutually referred to. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method part.

[0083] Those skilled in the art will further appreciate that the individual steps of the examples described in connection with the embodiments disclosed herein can be embodied in electronic hardware, computer software, or combinations of both. The various examples have been described in relation to the described embodiments, as a means of generalizing the interchangeability of hardware and software. Whether employing hardware or software, the described functionality is implemented as desired by the particular application and design constraints. Skilled artisans appreciate that the design choices made will depend on the specific implementation and constraints presented by the particular application.

[0084] The steps of a method or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in random access memory (RAM), flash memory, read-only memory (ROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0085] Finally, it needs to be pointed out that in this document, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0086] The above describes the technical solutions provided by the present application in detail. The principles and implementation manners of the present application are described by using specific examples. The above description of the embodiments is only used to help understand the method and core idea of the present application; meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation manner and application range can be changed. In summary, the content of the specification should not be understood as limiting the present application.

Claims

1. A user query history real-time alerting method, characterized in that, The method comprises the following steps: Real-time acquisition of log data generated by a target query system; the target query system comprises a Presto query system and a Druid query system; The log data comprises first log data for the Presto query system and second log data for the Druid query system; According to the specific type of the log data, a corresponding analysis rule is determined, and real-time data processing is performed on the log data based on the analysis rule to obtain a corresponding log data processing result; the log data processing result comprises user information data, query record data, query table data, query time data and target query system information data; Utilizing a preset alarm rule, it is judged whether there is an abnormal query condition based on the log data processing result; if there is an abnormal query condition, an alarm operation is performed, and the log data is stored for performing a data tracing operation; The preset alarm rule is an alarm rule formulated by a preset rule management system.

2. The method of claim 1, wherein, If the target query system is the Presto query system, the real-time acquisition of log data generated by the target query system comprises the following steps: The request data and response data of the Presto query system are acquired through a preset presto event listener; The request data and the response data are spliced to obtain first log data in json format.

3. The method of claim 1, wherein, If the target query system is the Druid query system, the real-time acquisition of log data generated by the target query system comprises the following steps: The related parameters of the Druid query system are adjusted, and second log data is acquired based on a preset data stream processing plug-in.

4. The method of claim 1, wherein, If the specific type of the log data is the first log data, according to the specific type of the log data, a corresponding analysis rule is determined, and real-time data processing is performed on the log data based on the analysis rule to obtain a corresponding log data processing result, which comprises the following steps: The first log data is parsed by a preset real-time analysis database through a sql statement to obtain a corresponding log data processing result.

5. The method of claim 1, wherein, If the specific type of the log data is the second log data, according to the specific type of the log data, a corresponding analysis rule is determined, and real-time data processing is performed on the log data based on the analysis rule to obtain a corresponding log data processing result, which comprises the following steps: The second log data is filtered, and the filtered second log data is spliced to obtain second log data in json format; The second log data in json format is parsed by a preset real-time analysis database through a sql statement to obtain a corresponding log data processing result.

6. The method of claim 1, wherein, The utilization of a preset alarm rule to judge whether there is an abnormal query condition based on the log data processing result comprises the following steps: Based on the user information data, query record data, query table data, query time data and target query system information data in the log data processing result, the number of table queries, the query frequency and the user authority are determined by utilizing a preset big data processing framework; The preset alarm rule is used to determine whether there is an abnormal query condition based on the table query times, the query frequency and the user permission.

7. The method of claim 1 to 6, wherein, Further comprising: The preset rule management system is used to modify the rule file to complete dynamic update of the preset alarm rule.

8. A user query history real-time warning device, characterized in that, Further comprising: A log data acquisition module is configured to acquire log data generated by a target query system in real time; the target query system includes a Presto query system and a Druid query system; the log data includes first log data for the Presto query system and second log data for the Druid query system; A log data processing module is configured to determine a corresponding analysis rule according to a specific type of the log data, and perform real-time data processing on the log data based on the analysis rule to obtain a corresponding log data processing result; the log data processing result includes user information data, query record data, query table data, query time data and target query system information data; An abnormal query condition alarm module is configured to determine whether there is an abnormal query condition based on the log data processing result by using a preset alarm rule, and if there is an abnormal query condition, perform an alarm operation and store the log data to perform a data trace operation; The preset alarm rule is an alarm rule formulated by using a preset rule management system.

9. An electronic device, comprising: Further comprising: A memory is configured to save a computer program; A processor is configured to execute the computer program to implement the user query history real-time alarm method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A memory is configured to save a computer program; the computer program is executed by a processor to implement the user query history real-time alarm method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • Method and device for determining exception query request

    CN110674014A

  • Abnormal log alarm method and device and electronic equipment

    CN110830438A

  • Method and device for detecting and protecting diversified traffic alarm logs

    CN117097609A

  • Large task searching and killing method, system and device based on OLAP component and medium

    CN119201345A