WO2019223155A1 - Sql性能监控方法、装置、计算机设备及存储介质 - Google Patents

Sql性能监控方法、装置、计算机设备及存储介质 Download PDF

Info

Publication number
WO2019223155A1
WO2019223155A1 PCT/CN2018/102473 CN2018102473W WO2019223155A1 WO 2019223155 A1 WO2019223155 A1 WO 2019223155A1 CN 2018102473 W CN2018102473 W CN 2018102473W WO 2019223155 A1 WO2019223155 A1 WO 2019223155A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
execution time
database log
log
logs
Prior art date
Application number
PCT/CN2018/102473
Other languages
English (en)
French (fr)
Inventor
黄度新
王翼
李双灵
杨雨芬
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019223155A1 publication Critical patent/WO2019223155A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3438—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment monitoring of user actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3452—Performance evaluation by statistical analysis

Definitions

  • the present application relates to the technical field of performance monitoring, and in particular, to a SQL performance monitoring method, device, computer equipment, and storage medium.
  • SQL performance is an important technical factor that affects the user experience. If the user clicks on the Internet page for a long time, it will cause the user to give up logging in to this page. At present, the performance monitoring of Internet pages only increases the pressure on web pages by increasing the number of users who cannot log in normally. It is not possible to issue early warning messages to operators by monitoring server performance.
  • This application provides a SQL performance monitoring method, device, computer equipment, and storage medium.
  • the purpose is to solve the problem that in the prior art, Internet pages can only be logged in when a large number of users cannot log in normally, and the pressure of reducing the use of web pages is increased by adding a server , And can not issue early warning messages to operators by monitoring server performance.
  • the present application provides a SQL performance monitoring method, which includes: acquiring at least one database log generated by a server to be monitored; consuming the at least one database log to obtain a respective execution time of each database log; Any one of the at least one database log is described, and it is determined whether the execution time of the database log exceeds the base interval obtained from training of historical database log data; if the execution time of the database log exceeds the base interval, The information receiving end corresponding to the monitoring server sends a warning message.
  • a SQL performance monitoring device which includes:
  • a database log acquisition unit is configured to acquire at least one database log generated by the server to be monitored; a log consumption unit is configured to consume the at least one database log to obtain the respective execution time of each database log; a judgment unit is configured to Describe any database log in at least one database log, and determine whether the execution time of the database log exceeds a base interval obtained from training of historical database log data; and a warning information sending unit is used to execute the database log if the execution time of the database log exceeds the base time. Sending warning information at a corresponding level to the information receiving end corresponding to the server to be monitored.
  • the present application further provides a computer device including a memory, a processor, and a computer program stored on the memory and executable on the processor.
  • the processor is implemented when the computer program is executed.
  • the SQL performance monitoring method according to any one of the present application.
  • the present application further provides a storage medium, wherein the storage medium stores a computer program, where the computer program includes program instructions, and the program instructions, when executed by a processor, cause the processor to execute the application The SQL performance monitoring method according to any one of the provided.
  • the application provides a SQL performance monitoring method, device, computer equipment and storage medium. This method effectively monitors the SQL execution time and system access, and can real-time find SQL statements and abnormal accesses that promptly exceed the baseline threshold.
  • FIG. 1 is a schematic flowchart of a SQL performance monitoring method according to an embodiment of the present application
  • FIG. 2 is another schematic flowchart of a SQL performance monitoring method according to an embodiment of the present application.
  • FIG. 3 is a schematic diagram of a sub-process of a SQL performance monitoring method according to an embodiment of the present application.
  • FIG. 4 is a schematic diagram of another sub-process of a SQL performance monitoring method according to an embodiment of the present application.
  • FIG. 5 is a schematic block diagram of a SQL performance monitoring device according to an embodiment of the present application.
  • FIG. 6 is another schematic block diagram of a SQL performance monitoring device according to an embodiment of the present application.
  • FIG. 7 is a schematic block diagram of a subunit of a SQL performance monitoring device according to an embodiment of the present application.
  • FIG. 8 is a schematic block diagram of another subunit of a SQL performance monitoring device according to an embodiment of the present application.
  • FIG. 9 is a schematic block diagram of a computer device according to an embodiment of the present application.
  • FIG. 1 is a schematic flowchart of a SQL performance monitoring method according to an embodiment of the present application. This method is applied to terminals such as desktop computers, laptop computers, and tablet computers. As shown in FIG. 1, the method includes steps S101 to S104.
  • a framework system consisting of a log collection server (that is, Flume), a distributed publish and subscribe message server (that is, Kafka), and a streaming processing framework server (that is, Spark Streaming (abbreviated as SS)) is pre-built.
  • a log collection server that is, Flume
  • a distributed publish and subscribe message server that is, Kafka
  • a streaming processing framework server that is, Spark Streaming (abbreviated as SS)
  • Flume provides the ability to perform simple processing of data and write to various data receivers (customizable). Flume provides from the console (console), RPC (Thrift-RPC, that is, the remote procedure call protocol using the interface definition language), text (file), tail (UNIX tail, tail instruction is the instruction to view the end of file information in UNIX) , Syslog (syslog log system), support TCP and UDP 2 modes), the ability to collect data on data sources such as exec (command execution).
  • Kafka is a high-throughput distributed publish-subscribe messaging system that can process all action flow data in consumer-scale websites. Spark Streaming is a streaming processing framework on Spark (Spark is a fast and general-purpose computing engine designed for large-scale data processing).
  • SS supports multiple types of data sources, including Kafka, Flume, and TCP sockets.
  • SS receives the data stream in real time, and splits the continuous data stream into batches of discrete data sets according to a certain time interval; then applies rich APIs such as map, reduce, join, and window for complex data processing; and finally submits to The Spark engine performs operations to obtain batch result data, so it is also called a quasi-real-time processing system.
  • the results can also be stored in many places, such as HDFS, databases, etc.
  • SS can also be perfectly integrated with MLlib (machine learning) and GraphX (graph computing).
  • the log collection server is used to obtain at least one database log generated by the server to be monitored.
  • the database log is a SQL full log, and the SQL full log includes all SQL statements executed by the database server cluster.
  • the log collection server can efficiently collect database logs generated by each of the servers to be monitored, and send the obtained database logs to the distributed publish and subscribe message server. That is, the log collection server monitors the disk that writes to the database log in real time. As long as a new database log is written, the log collection server will pass the database log to the distributed publish and subscribe message server as a message. After the distributed publish and subscribe message server receives the database log in the form of message, it immediately sends it to the streaming processing framework server, and the streaming processing framework server further processes the database log in the form of message.
  • the method further includes:
  • S101a Obtain a continuous data stream corresponding to the database log
  • S101b Split the continuous data stream to obtain a discretized database log.
  • the database log is collected by the log collection server from the server to be monitored, it is sent to the distributed publish and subscribe message server, and the database log is converted into a continuous data stream in the distributed publish and subscribe message server, and the distributed publish and subscribe
  • the message server sends the continuous data stream to the streaming framework server.
  • the continuous data stream is split in a streaming processing framework server to obtain a discrete database log. Only after the data is discretized can it be sent from the streaming framework server to the Hive database for storage, and the stored discretized data can be used for SQL performance analysis.
  • the step S102 includes:
  • S1023 Analyze the preset specified keywords included in the discretized database log, and obtain the execution time of the database log corresponding to the specified keywords.
  • the database logs are consumed by the streaming processing framework server to ensure that no data is lost, and the database logs collected by the log collection server can be transmitted to the distributed publish and subscribe message server in time, and then distributed publish and subscribe The message server is sent to the streaming framework server.
  • Kafka is a distributed message queue. There are two ways to operate Kafka on Spark streams:
  • the first is a high-level API implementation using receivers and Kafka.
  • the second is to use Kafka's underlying API without using a receiver (imported after spark1.3).
  • a receiver that is:
  • the stream processing framework server receives the discrete database logs output by the distributed publish and subscribe message system; the stream processing framework server receives the database logs through:
  • the database log is as follows:
  • 6.503033 millis after the executed keyword indicates that the execution time of the database log is 6.503033 milliseconds.
  • the streaming processing framework server can accurately consume the at least one database log, and obtain the respective execution time of each database log.
  • the base interval obtained by training from the historical database log data in step S103 includes:
  • S1032 Aggregate multiple database logs to obtain the summarized database logs
  • S1033 Analyze the execution time of each database log in the summarized database log, and obtain the average execution time average and standard deviation of the average execution time corresponding to multiple database logs in the summarized database log;
  • S1034 Set a base interval correspondingly according to the average execution time and the standard deviation of the average execution time.
  • step S1033 according to Get the average execution time corresponding to multiple database logs, according to Obtain the standard deviation of the average execution time corresponding to multiple database logs; where ⁇ represents the average execution time corresponding to multiple database logs, ⁇ represents the standard deviation of average execution time corresponding to multiple database logs, and xi is the i-th standby
  • the execution time of the SQL corresponding to the database log uploaded by the monitoring server, and the value of i ranges from [1, N], where N is the total number of servers to be monitored.
  • the log collection server collects and obtains the database logs sent by multiple servers to be monitored, and sends them to the distributed publish and subscribe message server; after the distributed publish and subscribe message server aggregates multiple database logs, it obtains the aggregated database logs and aggregates them.
  • the subsequent database logs are sent to the streaming framework server; the streaming framework server parses the execution time of each database log in the summarized database logs, and obtains the average execution time corresponding to multiple database logs in the summarized database logs.
  • ⁇ and execution time mean standard deviation ⁇ .
  • the first base interval may be set to [ ⁇ - ⁇ , ⁇ + ⁇ ]
  • the second base interval is set to [ ⁇ -2 ⁇ , ⁇ + 2 ⁇ ]
  • the third base interval is set to Set it to [ ⁇ -3 ⁇ , ⁇ + 3 ⁇ ].
  • the information receiving end when the information receiving end receives the first level of warning information, it needs to complete the maintenance of the server to be monitored within half an hour, and when the information receiving end receives the second level of warning information, it must complete the maintenance of the server to be monitored within 20 minutes.
  • the receiving end needs to complete the maintenance of the server to be monitored within 10 minutes when receiving the third-level warning message.
  • the method further includes:
  • the execution time of the database log may be set to send a normal operation prompt message to the corresponding information receiving end every hour to remind each server to be monitored that the operation is normal.
  • this method achieves effective monitoring of SQL execution time and system access, and real-time detection of SQL statements and abnormal access times that exceed the baseline threshold in real time.
  • the embodiment of the present application further provides a SQL performance monitoring device, which is configured to execute any one of the foregoing SQL performance monitoring methods.
  • a SQL performance monitoring device which is configured to execute any one of the foregoing SQL performance monitoring methods.
  • FIG. 4 is a schematic block diagram of a SQL performance monitoring device according to an embodiment of the present application.
  • the SQL performance monitoring device 100 may be configured in a terminal such as a desktop computer, a tablet computer, a laptop computer, or the like.
  • the SQL performance monitoring device 100 includes a database log acquisition unit 101, a log consumption unit 102, a determination unit 103, and a warning information sending unit 104.
  • the database log obtaining unit 101 is configured to obtain at least one database log generated by a server to be monitored.
  • a framework system consisting of a log collection server (that is, Flume), a distributed publish and subscribe message server (that is, Kafka), and a streaming processing framework server (that is, Spark Streaming (abbreviated as SS)) is pre-built.
  • a log collection server that is, Flume
  • a distributed publish and subscribe message server that is, Kafka
  • a streaming processing framework server that is, Spark Streaming (abbreviated as SS)
  • Flume provides the ability to perform simple processing of data and write to various data receivers (customizable). Flume provides from the console (console), RPC (Thrift-RPC, that is, the remote procedure call protocol using the interface definition language), text (file), tail (UNIX tail, tail instruction is the instruction to view the end of file information in UNIX) , Syslog (syslog log system), support TCP and UDP 2 modes), the ability to collect data on data sources such as exec (command execution).
  • Kafka is a high-throughput distributed publish-subscribe messaging system that can process all action flow data in consumer-scale websites. Spark Streaming is a streaming processing framework on Spark (Spark is a fast and general-purpose computing engine designed for large-scale data processing).
  • SS supports multiple types of data sources, including Kafka, Flume, and TCP sockets.
  • SS receives the data stream in real time, and splits the continuous data stream into batches of discrete data sets according to a certain time interval; then applies rich APIs such as map, reduce, join, and window for complex data processing; and finally submits to The Spark engine performs operations to obtain batch result data, so it is also called a quasi-real-time processing system.
  • the results can also be stored in many places, such as HDFS, databases, etc.
  • SS can also be perfectly integrated with MLlib (machine learning) and GraphX (graph computing).
  • the log collection server is used to obtain at least one database log generated by the server to be monitored.
  • the database log is a full SQL log, and the full SQL log includes all SQL statements executed by the database server cluster.
  • the log collection server can efficiently collect the database logs generated by each server to be monitored, and send the obtained database logs to the distributed publication and subscription message server. That is, the log collection server monitors the disk that writes to the database log in real time. As long as a new database log is written, the log collection server will pass the database log to the distributed publish and subscribe message server as a message. After the distributed publish and subscribe message server receives the database log in the form of message, it immediately sends it to the streaming processing framework server, and the streaming processing framework server further processes the database log in the form of message.
  • the SQL performance monitoring device 100 further includes:
  • a continuous data stream obtaining unit 101a configured to obtain a continuous data stream corresponding to the database log
  • a splitting unit 101b is configured to split the continuous data stream to obtain a discretized database log.
  • the database log is collected by the log collection server from the server to be monitored, it is sent to the distributed publish and subscribe message server.
  • the database log is converted into a continuous data stream in the distributed publish and subscribe message server, and the distributed publish and subscribe The message server sends the continuous data stream to the streaming framework server.
  • the continuous data stream is split in a streaming processing framework server to obtain a discrete database log. Only after the data is discretized can it be sent from the streaming framework server to the Hive database for storage, and the stored discretized data can be used for SQL performance analysis.
  • the log consumption unit 102 is configured to consume the at least one database log, and obtain the execution time of each database log.
  • the log consumption unit 102 includes:
  • a dependency adding unit 1021 is used to add a dependency between the distributed publish and subscribe message system and the streaming processing framework server; a discrete log receiving unit 1022 is used to receive the discrete database logs; a log parsing unit 1023 is used to analyze all The preset specified keywords included in the discretized database log are described to obtain the execution time of the database log corresponding to the specified keywords.
  • the database logs are consumed by the streaming processing framework server to ensure that no data is lost, and the database logs collected by the log collection server can be transmitted to the distributed publish and subscribe message server in time, and then distributed publish and subscribe The message server is sent to the streaming framework server.
  • Kafka is a distributed message queue. There are two ways to operate Kafka on Spark streams:
  • the first is a high-level API implementation using receivers and Kafka.
  • the second is to use Kafka's underlying API without using a receiver (introduced after Spark 1.3).
  • a receiver that is:
  • the stream processing framework server receives the discrete database logs output by the distributed publish and subscribe message system; the stream processing framework server receives the database logs through:
  • the streaming processing framework server can accurately consume the at least one database log to obtain the respective execution time of each database log.
  • a judging unit 103 is configured to judge, for any database log in the at least one database log, whether an execution time of the database log exceeds a base interval obtained by training from historical database log data.
  • the determining unit 103 includes:
  • a parallel monitoring unit 1031 is configured to obtain database logs sent by multiple servers to be monitored; a log summary unit 1032 is configured to summarize multiple database logs to obtain a summarized database log; a calculation unit 1033 is configured to analyze the database logs The execution time of each database log in the summarized database log, and obtaining the average execution time average and standard deviation of the execution time corresponding to the multiple database logs in the summarized database log; the base interval setting unit 1034, It is used to set the base interval correspondingly according to the average execution time and the standard deviation of the average execution time.
  • ⁇ represents the average execution time corresponding to multiple database logs
  • ⁇ represents the standard deviation of average execution time corresponding to multiple database logs
  • x i is the i-th station
  • the execution time of the SQL corresponding to the database log uploaded by the server to be monitored, and the value of i ranges from [1, N], where N is the total number of servers to be monitored.
  • the log collection server collects and obtains the database logs sent by multiple servers to be monitored, and sends them to the distributed publish and subscribe message server; after the distributed publish and subscribe message server aggregates multiple database logs, it obtains the aggregated database logs and aggregates them.
  • the subsequent database logs are sent to the streaming framework server; the streaming framework server parses the execution time of each database log in the summarized database logs, and obtains the average execution time corresponding to multiple database logs in the summarized database logs.
  • ⁇ and execution time mean standard deviation ⁇ .
  • the first base interval may be set to [ ⁇ - ⁇ , ⁇ + ⁇ ]
  • the second base interval is set to [ ⁇ -2 ⁇ , ⁇ + 2 ⁇ ]
  • the third base interval is set to Set it to [ ⁇ -3 ⁇ , ⁇ + 3 ⁇ ].
  • the warning information sending unit 104 is configured to send a corresponding level of warning information to the information receiving end corresponding to the server to be monitored if the execution time of the database log exceeds the base interval.
  • the information receiving end when the information receiving end receives the first level of warning information, it needs to complete the maintenance of the server to be monitored within half an hour, and when the information receiving end receives the second level of warning information, it must complete the maintenance of the server to be monitored within 20 minutes.
  • the receiving end needs to complete the maintenance of the server to be monitored within 10 minutes when receiving the third-level warning message.
  • the SQL performance monitoring apparatus 100 further includes:
  • the prompt information sending unit 105 is configured to send normal running prompt information to the corresponding information receiving end according to a preset prompt period if the execution time of the database log does not exceed the base interval.
  • the execution time of the database log may be set to send a normal operation prompt message to the corresponding information receiving end every hour to remind each server to be monitored that the operation is normal.
  • the device achieves effective monitoring of SQL execution time and system access, and can real-time find out SQL statements and abnormal access times prompting when the execution time exceeds the baseline threshold.
  • the above SQL performance monitoring device can be implemented in the form of a computer program, which can be run on a computer device as shown in FIG. 9.
  • the computer device 500 may be a terminal.
  • the terminal may be an electronic device such as a tablet computer, a notebook computer, a desktop computer, a personal digital assistant, and the like.
  • the computer device 500 includes a processor 502, a memory, and a network interface 505 connected through a system bus 501.
  • the memory may include a non-volatile storage medium 503 and an internal memory 504.
  • the non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032.
  • the computer program 5032 includes program instructions. When the program instructions are executed, the processor 502 can execute a SQL performance monitoring method.
  • the processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500.
  • the internal memory 504 provides an environment for running the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a SQL performance monitoring method.
  • the network interface 505 is used for network communication, such as sending assigned tasks.
  • the processor 502 is configured to run a computer program 5032 stored in a memory to achieve the following functions: obtaining at least one database log generated by a server to be monitored; consuming the at least one database log, and obtaining each database log separately.
  • any database log in the at least one database log determine whether the execution time of the database log exceeds a base interval obtained from training of historical database log data; if the database log execution time exceeds the base interval, Send a corresponding level of warning information to the information receiving end corresponding to the server to be monitored.
  • the processor 502 further performs the following operations: obtaining a continuous data stream corresponding to the database log; splitting the continuous data stream to obtain a discrete database log.
  • the processor 502 further performs the following operations: adding a dependency between the distributed publish and subscribe message system and the streaming processing framework server; receiving a discrete database log; and parsing preset presets included in the discrete database log Specify a keyword to obtain the execution time of the database log corresponding to the specified keyword.
  • the processor 502 further performs the following operations: obtaining database logs sent by multiple servers to be monitored; summarizing multiple database logs to obtain a summarized database log; analyzing each of the summarized database logs The execution time of the database log, and obtain the execution time average and execution time average standard deviation corresponding to multiple database logs in the summarized database log; according to the execution time average and the execution time average standard deviation, correspondingly set a base interval .
  • the processor 502 further performs the following operations: Get the average execution time corresponding to multiple database logs, according to Obtain the standard deviation of the average execution time corresponding to multiple database logs; where ⁇ represents the average execution time corresponding to multiple database logs, ⁇ represents the standard deviation of average execution time corresponding to multiple database logs, and x i is the i-th station
  • the execution time of the SQL corresponding to the database log uploaded by the server to be monitored, and the value of i ranges from [1, N], where N is the total number of servers to be monitored.
  • the embodiment of the computer device shown in FIG. 9 does not constitute a limitation on the specific configuration of the computer device.
  • the computer device may include more or fewer components than shown in the figure. Either some parts are combined or different parts are arranged.
  • the computer device may include only a memory and a processor. In such an embodiment, the structures and functions of the memory and the processor are consistent with the embodiment shown in FIG. 9, and details are not described herein again.
  • the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSPs), Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • the general-purpose processor may be a microprocessor, or the processor may be any conventional processor.
  • a storage medium may be a computer-readable storage medium.
  • the storage medium stores a computer program, where the computer program includes program instructions.
  • the program instructions are executed by the processor, the SQL performance monitoring method in the embodiment of the present application is implemented.
  • the storage medium may be an internal storage unit of the foregoing device, such as a hard disk or a memory of the device.
  • the storage medium may also be an external storage device of the device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, and a flash memory card provided on the device. (Flash Card), etc.
  • the storage medium may further include both an internal storage unit of the device and an external storage device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Probability & Statistics with Applications (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例公开了一种SQL性能监控方法、装置、计算机设备及存储介质。该方法包括：获取待监测服务器所产生的至少一条数据库日志；消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间；针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间；若数据库日志的执行时间超出基限区间，向待监测服务器所对应的信息接收端发送相应级别的警告信息。该方法实现对SQL执行时间和系统访问量的有效监控，并能实时发现执行时间超出基线阈值的SQL语句和异常访问量以及时提示。

Description

SQL性能监控方法、装置、计算机设备及存储介质
本申请要求于2018年5月25日提交中国专利局、申请号为201810560805.X、申请名称为“SQL性能监控方法、装置、计算机设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及性能监控技术领域，尤其涉及一种SQL性能监控方法、装置、计算机设备及存储介质。
背景技术
SQL性能是影响用户体验的一个重要的技术因素，如果用户点开互联网页面需要等待较长时间，会导致用户放弃登录这一页面。目前互联网页面的性能监测，只是在大量的用户都无法正常登录，才会通过增加服务器来增加缓解网页使用的压力，而不能尽早的通过监控服务器性能来对运营商发出警告信息。
发明内容
本申请提供了一种SQL性能监控方法、装置、计算机设备及存储介质，旨在解决现有技术中互联网页面只是在大量的用户都无法正常登录，才会通过增加服务器来增加缓解网页使用的压力，而不能尽早的通过监控服务器性能来对运营商发出警告信息的问题。
第一方面，本申请提供了一种SQL性能监控方法，其包括：获取待监测服务器所产生的至少一条数据库日志；消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间；针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间；若所述数据库日志的执行时间超出基限区间，向所述待监测服务器所对应的信息接收端发送警告信息。
第二方面，本申请提供了一种SQL性能监控装置，其包括：
数据库日志获取单元，用于获取待监测服务器所产生的至少一条数据库日 志；日志消费单元，用于消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间；判断单元，用于针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间；警告信息发送单元，用于若所述数据库日志的执行时间超出基限区间，向所述待监测服务器所对应的信息接收端发送相应级别的警告信息。
第三方面，本申请又提供了一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现本申请提供的任一项所述的SQL性能监控方法。
第四方面，本申请还提供了一种存储介质，其中所述存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行本申请提供的任一项所述的SQL性能监控方法。
本申请提供一种SQL性能监控方法、装置、计算机设备及存储介质。该方法实现对SQL执行时间和系统访问量的有效监控，并能实时发现执行时间超出基线阈值的SQL语句和异常访问量以及时提示。
附图说明
为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种SQL性能监控方法的示意流程图；
图2为本申请实施例提供的一种SQL性能监控方法的另一示意流程图；
图3为本申请实施例提供的一种SQL性能监控方法的子流程示意图；
图4为本申请实施例提供的一种SQL性能监控方法的另一子流程示意图；
图5为本申请实施例提供的一种SQL性能监控装置的示意性框图；
图6为本申请实施例提供的一种SQL性能监控装置的另一示意性框图；
图7为本申请实施例提供的一种SQL性能监控装置的子单元示意性框图；
图8为本申请实施例提供的一种SQL性能监控装置的另一子单元示意性框图；
图9为本申请实施例提供的一种计算机设备的示意性框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参阅图1，图1是本申请实施例提供的一种SQL性能监控方法的示意流程图。该方法应用于台式电脑、手提电脑、平板电脑等终端中。如图1所示，该方法包括步骤S101～S104。
S101、获取待监测服务器所产生的至少一条数据库日志。
在本实施例中，预先构建好由日志收集服务器(即Flume)、分布式发布订阅消息服务器(即Kafka)、及流式处理框架服务器(即Spark Streaming，简记为SS)的框架系统。
其中，Flume提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。Flume提供了从console(控制台)、RPC(Thrift-RPC，即使用接口定义语言的远程过程调用协议)、text(文件)、tail(UNIX tail，tail指令即UNIX中查看文件结尾信息的指令)、syslog(syslog日志系统)，支持TCP和UDP等2种模式)，exec(命令执行)等数据源上收集数据的能力。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。Spark Streaming是Spark(Spark是专为大规模数据处理而设计的快速通用的计算引擎)上的一个流式处理框架，可以面向海量数据实现高吞吐量、高容错的实时计算。SS支持多种类型数据源，包括Kafka、Flume以及TCP sockets等。SS实时接收数据流，并按照一定的时间间隔将连续的数据流拆分成一批批离散的数据集；然后应用诸如map、reduce、join和window等丰富的API进行复杂的数据处理；最后提交给Spark引擎进行运算，得到批量结果数据，因此其也被称为准实时处理系统。而结果也能保存在很多地方，如HDFS，数据库等。另外SS也能和MLlib(机器学习)以及GraphX(图计算)完美融合。
在本实施例中，通过日志收集服务器获取待监测服务器所产生的至少一条数据库日志。所述数据库日志即为SQL全量日志，SQL全量日志中包括数据库 服务器集群执行过的所有SQL语句。通过日志收集服务器能高效的收集各取待监测服务器所产生的数据库日志，将所获取的数据库日志发送至分布式发布订阅消息服务器。也即日志收集服务器实时监控写入数据库日志的磁盘，只要有新的数据库日志写入，日志收集服务器就会将数据库日志以消息的形式传递给分布式发布订阅消息服务器。分布式发布订阅消息服务器接收了消息形式的数据库日志后，立即发送至流式处理框架服务器，由流式处理框架服务器对消息形式的数据库日志进行进一步处理。
在一实施例中，如图2所示，在所述步骤S101之后还包括：
S101a、获取与所述数据库日志对应的连续数据流；
S101b、将所述连续数据流进行拆分，得到离散化数据库日志。
在本实施例中，将由日志收集服务器从待监测服务器收集到数据库日志后，发送至分布式发布订阅消息服务器，在分布式发布订阅消息服务器中将数据库日志转化为连续数据流，分布式发布订阅消息服务器再将连续数据流发送至流式处理框架服务器。在流式处理框架服务器中将所述连续数据流进行拆分，得到离散化数据库日志。只有将数据离散化后，才能由流式处理框架服务器发送至Hive数据库中进行存储，而且所存储的离散化处理的数据能被用于进行SQL性能分析。
S102、消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间。
在一实施例中，如图3所示，在所述步骤S102包括：
S1021、添加分布式发布订阅消息系统与流式处理框架服务器之间的依赖；
S1022、接收所述离散化数据库日志；
S1023、解析所述离散化数据库日志中所包括的预设的指定关键词，获取与所述指定关键词相对应的数据库日志的执行时间。
在本实施例中，通过流式处理框架服务器消费数据库日志，可以确保不丢失数据，且由日志收集服务器所收集的数据库日志可及时被传到分布式发布订阅消息服务器，再由分布式发布订阅消息服务器发送至流式处理框架服务器。
Kafka为一个分布式的消息队列，Spark流操作kafka有两种方式：
第一种是利用接收器(receiver)和Kafka的高层API实现。
第二种是不利用接收器，直接用Kafka底层的API来实现(spark1.3以后引 入)。
在本实施例中采用利用接收器的方式，即：
1)添加分布式发布订阅消息系统与流式处理框架服务器之间的依赖；所添加的依赖如下：spark-streaming-kafka_2.10-1.3.0；
2)流式处理框架服务器接收由分布式发布订阅消息系统输出的离散化数据库日志；流式处理框架服务器接收数据库日志通过：
import org.apache.spark.streaming.kafka._来实现；
3)解析离散化数据库日志中的executed关键字所对应的执行时间；
例如，数据库日志如下：
[03/01/18 11：56：03：003 CST]http-nio-8080-exec-2 DEBUG sql.Statement：{conn-10001，pstmt-20025}executed.6.503031 millis.
select*from t_paic_life_XXX WHERE 1＝1  and create_time＞＝？  order by create_time desc limit？，？
其中，executed关键字后的6.503031 millis表示该条数据库日志的执行时间为6.503031毫秒。通过利用接收器的方式，流式处理框架服务器能精确消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间。
S103、针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间。
在一实施例中，如图4所示，在所述步骤S103中由历史数据库日志数据训练得到基限区间包括：
S1031、获取多个待监控服务器所发送的数据库日志；
S1032、将多条数据库日志进行汇总，得到汇总后的数据库日志；
S1033、解析所述汇总后的数据库日志中每一数据库日志的执行时间，并获取所述汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差；
S1034、根据执行时间平均值与执行时间平均值标准差，对应设置基限区间。
在一实施例中，在所述步骤S1033中根据
Figure PCTCN2018102473-appb-000001
获取多条数据库日志对应的执行时间平均值，根据
Figure PCTCN2018102473-appb-000002
获取多条数据库日志对应的执行时间平均值标准差；其中，μ表示多条数据库日志对应的执行时间平均值，σ表示多条数据库日志对应的执行时间平均值标准差，xi是第i台待监控服务器 所上传数据库日志对应的SQL的执行时间，且i的取值范围为[1，N]，N为待监控服务器的总台数。
即日志收集服务器采集获取多个待监控服务器所发送数据库日志，并发送至分布式发布订阅消息服务器；分布式发布订阅消息服务器将多条数据库日志汇总后，得到汇总后的数据库日志，并将汇总后的数据库日志发送至流式处理框架服务器；流式处理框架服务器解析汇总后的数据库日志中每一数据库日志的执行时间，并获取汇总后的数据库日志中多条数据库日志对应的执行时间平均值μ和执行时间平均值标准差σ。其中，在本实施例中可将第一基限区间设置为[μ-σ，μ+σ]，将第二基限区间设置为[μ-2σ，μ+2σ]，将第三基限区间设置为[μ-3σ，μ+3σ]。
S104、若数据库日志的执行时间超出基限区间，向待监测服务器所对应的信息接收端发送警告信息。
在本实施例中，若数据库日志的执行时间位于第一基限区间内，则不发出任何警告信息；若数据库日志的执行时间超出了第一基限区间，但又位于第二基限区间内，则发出第一等级警告信息；若数据库日志的执行时间超出了第二基限区间，但又位于第三基限区间内，则发出第二等级警告信息；若数据库日志的执行时间超出了第三基限区间，则发出第三等级警告信息。
例如信息接收端接收到第一等级警告信息时需要在半小时内去完成对待监控服务器的维护，信息接收端接收到第二等级警告信息时需要在20分钟内去完成对待监控服务器的维护，信息接收端接收到第三等级警告信息时需要在10分钟内去完成对待监控服务器的维护。通过设置分级别的基限区间，及阶梯式的基限区间，能有效的通过数据库日志对待监控服务器的性能进行监测。
在一实施例中，如图1所示，在所述步骤S104之后还包括：
S105、若数据库日志的执行时间未超出基限区间，按预设的提示周期向对应的信息接收端发送运行正常的提示信息。
在本实施例中，若数据库日志的执行时间未超出基限区间，可设置每一小时向对应的信息接收端发送运行正常的提示信息，以提示各待监测服务器均运行正常。
可见，该方法实现对SQL执行时间和系统访问量的有效监控，并能实时发现执行时间超出基线阈值的SQL语句和异常访问量以及时提示。
本申请实施例还提供一种SQL性能监控装置，该SQL性能监控装置用于执行前述SQL性能监控方法的任一实施例。具体地，请参阅图4，图4是本申请实施例提供的一种SQL性能监控装置的示意性框图。SQL性能监控装置100可以配置于台式电脑、平板电脑、手提电脑、等终端中。
如图5所示，SQL性能监控装置100包括数据库日志获取单元101、日志消费单元102、判断单元103及警告信息发送单元104。
数据库日志获取单元101，用于获取待监测服务器所产生的至少一条数据库日志。
在本实施例中，预先构建好由日志收集服务器(即Flume)、分布式发布订阅消息服务器(即Kafka)、及流式处理框架服务器(即Spark Streaming，简记为SS)的框架系统。
其中，Flume提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。Flume提供了从console(控制台)、RPC(Thrift-RPC，即使用接口定义语言的远程过程调用协议)、text(文件)、tail(UNIX tail，tail指令即UNIX中查看文件结尾信息的指令)、syslog(syslog日志系统)，支持TCP和UDP等2种模式)，exec(命令执行)等数据源上收集数据的能力。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。Spark Streaming是Spark(Spark是专为大规模数据处理而设计的快速通用的计算引擎)上的一个流式处理框架，可以面向海量数据实现高吞吐量、高容错的实时计算。SS支持多种类型数据源，包括Kafka、Flume以及TCP sockets等。SS实时接收数据流，并按照一定的时间间隔将连续的数据流拆分成一批批离散的数据集；然后应用诸如map、reduce、join和window等丰富的API进行复杂的数据处理；最后提交给Spark引擎进行运算，得到批量结果数据，因此其也被称为准实时处理系统。而结果也能保存在很多地方，如HDFS，数据库等。另外SS也能和MLlib(机器学习)以及GraphX(图计算)完美融合。
在本实施例中，通过日志收集服务器获取待监测服务器所产生的至少一条数据库日志。所述数据库日志即为SQL全量日志，SQL全量日志中包括数据库服务器集群执行过的所有SQL语句。通过日志收集服务器能高效的收集各取待监测服务器所产生的数据库日志，将所获取的数据库日志发送至分布式发布订 阅消息服务器。也即日志收集服务器实时监控写入数据库日志的磁盘，只要有新的数据库日志写入，日志收集服务器就会将数据库日志以消息的形式传递给分布式发布订阅消息服务器。分布式发布订阅消息服务器接收了消息形式的数据库日志后，立即发送至流式处理框架服务器，由流式处理框架服务器对消息形式的数据库日志进行进一步处理。
在一实施例中，如图6所示，所述SQL性能监控装置100还包括：
连续数据流获取单元101a，用于获取与所述数据库日志对应的连续数据流；
拆分单元101b，用于将所述连续数据流进行拆分，得到离散化数据库日志。
在本实施例中，将由日志收集服务器从待监测服务器收集到数据库日志后，发送至分布式发布订阅消息服务器，在分布式发布订阅消息服务器中将数据库日志转化为连续数据流，分布式发布订阅消息服务器再将连续数据流发送至流式处理框架服务器。在流式处理框架服务器中将所述连续数据流进行拆分，得到离散化数据库日志。只有将数据离散化后，才能由流式处理框架服务器发送至Hive数据库中进行存储，而且所存储的离散化处理的数据能被用于进行SQL性能分析。
日志消费单元102，用于消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间。
在一实施例中，如图7所示，所述日志消费单元102包括：
依赖添加单元1021，用于添加分布式发布订阅消息系统与流式处理框架服务器之间的依赖；离散日志接收单元1022，用于接收所述离散化数据库日志；日志解析单元1023，用于解析所述离散化数据库日志中所包括的预设的指定关键词，获取与指定关键词相对应的数据库日志的执行时间。
在本实施例中，通过流式处理框架服务器消费数据库日志，可以确保不丢失数据，且由日志收集服务器所收集的数据库日志可及时被传到分布式发布订阅消息服务器，再由分布式发布订阅消息服务器发送至流式处理框架服务器。
Kafka为一个分布式的消息队列，Spark流操作kafka有两种方式：
第一种是利用接收器(receiver)和Kafka的高层API实现。
第二种是不利用接收器，直接用Kafka底层的API来实现(spark1.3以后引入)。
在本实施例中采用利用接收器的方式，即：
1)添加分布式发布订阅消息系统与流式处理框架服务器之间的依赖；所添加的依赖如下：spark-streaming-kafka_2.10-1.3.0；
2)流式处理框架服务器接收由分布式发布订阅消息系统输出的离散化数据库日志；流式处理框架服务器接收数据库日志通过：
import org.apache.spark.streaming.kafka._来实现；
3)解析离散化数据库日志中的executed关键字所对应的执行时间；通过利用接收器的方式，流式处理框架服务器能精确消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间。
判断单元103，用于针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间。
在一实施例中，如图8所示，所述判断单元103包括：
并行监控单元1031，用于获取多个待监控服务器所发送的数据库日志；日志汇总单元1032，用于将多条数据库日志进行汇总，得到汇总后的数据库日志；计算单元1033，用于解析所述汇总后的数据库日志中每一数据库日志的执行时间，并获所述取汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差；基限区间设置单元1034，用于根据执行时间平均值与执行时间平均值标准差，对应设置基限区间。
在一实施例中，根据
Figure PCTCN2018102473-appb-000003
获取多条数据库日志对应的执行时间平均值，根据
Figure PCTCN2018102473-appb-000004
获取多条数据库日志对应的执行时间平均值标准差；其中，μ表示多条数据库日志对应的执行时间平均值，σ表示多条数据库日志对应的执行时间平均值标准差，x i是第i台待监控服务器所上传数据库日志对应的SQL的执行时间，且i的取值范围为[1，N]，N为待监控服务器的总台数。
即日志收集服务器采集获取多个待监控服务器所发送数据库日志，并发送至分布式发布订阅消息服务器；分布式发布订阅消息服务器将多条数据库日志汇总后，得到汇总后的数据库日志，并将汇总后的数据库日志发送至流式处理框架服务器；流式处理框架服务器解析汇总后的数据库日志中每一数据库日志的执行时间，并获取汇总后的数据库日志中多条数据库日志对应的执行时间平均值μ和执行时间平均值标准差σ。其中，在本实施例中可将第一基限区间设置为[μ-σ，μ+σ]，将第二基限区间设置为[μ-2σ，μ+2σ]，将第三基限区间设 置为[μ-3σ，μ+3σ]。
警告信息发送单元104，用于若数据库日志的执行时间超出基限区间，向待监测服务器所对应的信息接收端发送相应级别的警告信息。
在本实施例中，若数据库日志的执行时间位于第一基限区间内，则不发出任何警告信息；若数据库日志的执行时间超出了第一基限区间，但又位于第二基限区间内，则发出第一等级警告信息；若数据库日志的执行时间超出了第二基限区间，但又位于第三基限区间内，则发出第二等级警告信息；若数据库日志的执行时间超出了第三基限区间，则发出第三等级警告信息。
例如信息接收端接收到第一等级警告信息时需要在半小时内去完成对待监控服务器的维护，信息接收端接收到第二等级警告信息时需要在20分钟内去完成对待监控服务器的维护，信息接收端接收到第三等级警告信息时需要在10分钟内去完成对待监控服务器的维护。通过设置分级别的基限区间，及阶梯式的基限区间，能有效的通过数据库日志对待监控服务器的性能进行监测。
在一实施例中，如图5所示，SQL性能监控装置100还包括：
提示信息发送单元105，用于若数据库日志的执行时间未超出基限区间，按预设的提示周期向对应的信息接收端发送运行正常的提示信息。
在本实施例中，若数据库日志的执行时间未超出基限区间，可设置每一小时向对应的信息接收端发送运行正常的提示信息，以提示各待监测服务器均运行正常。
可见，该装置实现对SQL执行时间和系统访问量的有效监控，并能实时发现执行时间超出基线阈值的SQL语句和异常访问量以及时提示。
上述SQL性能监控装置可以实现为一种计算机程序的形式，该计算机程序可以在如图9所示的计算机设备上运行。
请参阅图9，图9是本申请实施例提供的一种计算机设备的示意性框图。该计算机设备500设备可以是终端。该终端可以是平板电脑、笔记本电脑、台式电脑、个人数字助理等电子设备。
参阅图9，该计算机设备500包括通过系统总线501连接的处理器502、存储器和网络接口505，其中，存储器可以包括非易失性存储介质503和内存储器504。
该非易失性存储介质503可存储操作系统5031和计算机程序5032。该计算 机程序5032包括程序指令，该程序指令被执行时，可使得处理器502执行一种SQL性能监控方法。该处理器502用于提供计算和控制能力，支撑整个计算机设备500的运行。该内存储器504为非易失性存储介质503中的计算机程序5032的运行提供环境，该计算机程序5032被处理器502执行时，可使得处理器502执行一种SQL性能监控方法。该网络接口505用于进行网络通信，如发送分配的任务等。本领域技术人员可以理解，图9中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备500的限定，具体的计算机设备500可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。其中，所述处理器502用于运行存储在存储器中的计算机程序5032，以实现如下功能：获取待监测服务器所产生的至少一条数据库日志；消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间；针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间；若数据库日志的执行时间超出基限区间，向待监测服务器所对应的信息接收端发送相应级别的警告信息。
在一实施例中，处理器502还执行如下操作：获取与所述数据库日志对应的连续数据流；将所述连续数据流进行拆分，得到离散化数据库日志。
在一实施例中，处理器502还执行如下操作：添加分布式发布订阅消息系统与流式处理框架服务器之间的依赖；接收离散化数据库日志；解析离散化数据库日志中所包括的预设的指定关键词，获取与指定关键词相对应的数据库日志的执行时间。
在一实施例中，处理器502还执行如下操作：获取多个待监控服务器所发送的数据库日志；将多条数据库日志进行汇总，得到汇总后的数据库日志；解析汇总后的数据库日志中每一数据库日志的执行时间，并获取汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差；根据执行时间平均值与执行时间平均值标准差，对应设置基限区间。
在一实施例中，处理器502还执行如下操作：根据
Figure PCTCN2018102473-appb-000005
获取多条数据库日志对应的执行时间平均值，根据
Figure PCTCN2018102473-appb-000006
获取多条数据库日志对应的执行时间平均值标准差；其中，μ表示多条数据库日志对应的执行时间平均值，σ表示多条数据库日志对应的执行时间平均值标准差，x i是第i台待 监控服务器所上传数据库日志对应的SQL的执行时间，且i的取值范围为[1，N]，N为待监控服务器的总台数。
本领域技术人员可以理解，图9中示出的计算机设备的实施例并不构成对计算机设备具体构成的限定，在其他实施例中，计算机设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。例如，在一些实施例中，计算机设备可以仅包括存储器及处理器，在这样的实施例中，存储器及处理器的结构及功能与图9所示实施例一致，在此不再赘述。
应当理解，在本申请实施例中，处理器502可以是中央处理单元(Central Processing Unit，CPU)，该处理器502还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
在本申请的另一实施例中提供一种存储介质。该存储介质可以为计算机可读存储介质。该存储介质存储有计算机程序，其中计算机程序包括程序指令。该程序指令被处理器执行时实现本申请实施例的SQL性能监控方法。
所述存储介质可以是前述设备的内部存储单元，例如设备的硬盘或内存。所述存储介质也可以是所述设备的外部存储设备，例如所述设备上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储介质还可以既包括所述设备的内部存储单元也包括外部存储设备。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的设备、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (20)

  1. 一种SQL性能监控方法，其特征在于，包括：
    获取待监测服务器所产生的至少一条数据库日志；
    消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间；
    针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间；
    若所述数据库日志的执行时间超出基限区间，向所述待监测服务器所对应的信息接收端发送警告信息。
  2. 根据权利要求1所述的SQL性能监控方法，其特征在于，所述获取待监测服务器所产生的至少一条数据库日志之后，还包括：
    获取与所述数据库日志对应的连续数据流；
    将所述连续数据流进行拆分，得到离散化数据库日志。
  3. 根据权利要求2所述的SQL性能监控方法，其特征在于，所述消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间，包括：
    添加分布式发布订阅消息系统与流式处理框架服务器之间的依赖；
    接收所述离散化数据库日志；
    解析所述离散化数据库日志中所包括的预设的指定关键词，获取与所述指定关键词相对应的数据库日志的执行时间。
  4. 根据权利要求1所述的SQL性能监控方法，其特征在于，所述由历史数据库日志数据训练得到基限区间，包括：
    获取多个待监控服务器所发送的数据库日志；
    将多条数据库日志进行汇总，得到汇总后的数据库日志；
    解析所述汇总后的数据库日志中每一数据库日志的执行时间，并获取所述汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差；
    根据执行时间平均值与执行时间平均值标准差，对应设置基限区间。
  5. 根据权利要求4所述的SQL性能监控方法，其特征在于，所述获取汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差中，根据
    Figure PCTCN2018102473-appb-100001
    获取多条数据库日志对应的执行时间平均值，根据
    Figure PCTCN2018102473-appb-100002
    获取多条数据库日志对应的执行时间平均值标准差；其中，μ表示多条数据库日志对应的执行时间平均值，σ表示多条数据库日志对应的执行时间平均值标准差，x i是第i台待监控服务器所上传数据库日志对应的SQL的执行时间，且i的取值范围为[1，N]，N为待监控服务器的总台数。
  6. 一种SQL性能监控装置，其特征在于，包括：
    数据库日志获取单元，用于获取待监测服务器所产生的至少一条数据库日志；
    日志消费单元，用于消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间；
    判断单元，用于针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间；
    警告信息发送单元，用于若所述数据库日志的执行时间超出基限区间，向待监测服务器所对应的信息接收端发送警告信息。
  7. 根据权利要求6所述的SQL性能监控装置，其特征在于，还包括：
    连续数据流获取单元，用于获取与所述数据库日志对应的连续数据流；
    数据拆分单元，用于将所述连续数据流进行拆分，得到离散化数据库日志。
  8. 根据权利要求7所述的SQL性能监控装置，其特征在于，所述日志消费单元，包括：
    依赖添加单元，用于添加分布式发布订阅消息系统与流式处理框架服务器之间的依赖；
    离散日志接收单元，用于接收所述离散化数据库日志；
    日志解析单元，用于解析所述离散化数据库日志中所包括的预设的指定关键词，获取与指定关键词相对应的数据库日志的执行时间。
  9. 根据权利要求6所述的SQL性能监控装置，其特征在于，所述判断单元，包括：
    并行监控单元，用于获取多个待监控服务器所发送的数据库日志；
    日志汇总单元，用于将多条数据库日志进行汇总，得到汇总后的数据库日志；
    计算单元，用于解析所述汇总后的数据库日志中每一数据库日志的执行时间，并获所述取汇总后的数据库日志中多条数据库日志对应的执行时间平均值 和执行时间平均值标准差；
    基限区间设置单元，用于根据执行时间平均值与执行时间平均值标准差，对应设置基限区间。
  10. 根据权利要求9所述的SQL性能监控装置，其特征在于，所述获取汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差中，根据
    Figure PCTCN2018102473-appb-100003
    获取多条数据库日志对应的执行时间平均值，根据
    Figure PCTCN2018102473-appb-100004
    获取多条数据库日志对应的执行时间平均值标准差；其中，μ表示多条数据库日志对应的执行时间平均值，σ表示多条数据库日志对应的执行时间平均值标准差，x i是第i台待监控服务器所上传数据库日志对应的SQL的执行时间，且i的取值范围为[1，N]，N为待监控服务器的总台数。
  11. 一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现以下步骤：
    获取待监测服务器所产生的至少一条数据库日志；
    消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间；
    针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间；
    若所述数据库日志的执行时间超出基限区间，向所述待监测服务器所对应的信息接收端发送警告信息。
  12. 根据权利要求11所述的计算机设备，其特征在于，所述获取待监测服务器所产生的至少一条数据库日志之后，还包括：
    获取与所述数据库日志对应的连续数据流；
    将所述连续数据流进行拆分，得到离散化数据库日志。
  13. 根据权利要求12所述的计算机设备，其特征在于，所述消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间，包括：
    添加分布式发布订阅消息系统与流式处理框架服务器之间的依赖；
    接收所述离散化数据库日志；
    解析所述离散化数据库日志中所包括的预设的指定关键词，获取与所述指定关键词相对应的数据库日志的执行时间。
  14. 根据权利要求11所述的计算机设备，其特征在于，所述由历史数据库日志数据训练得到基限区间，包括：
    获取多个待监控服务器所发送的数据库日志；
    将多条数据库日志进行汇总，得到汇总后的数据库日志；
    解析所述汇总后的数据库日志中每一数据库日志的执行时间，并获取所述汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差；
    根据执行时间平均值与执行时间平均值标准差，对应设置基限区间。
  15. 根据权利要求14所述的计算机设备，其特征在于，所述获取汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差
    Figure PCTCN2018102473-appb-100005
    中，μ表示多条数据库日志对应的执行时间平均值，σ表示多条数据库日志对应的执行时间平均值标准差，x i是第i台待监控服务器所上传数据库日志对应的SQL的执行时间，且i的取值范围为[1，N]，N为待监控服务器的总台数。
  16. 一种存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行以下操作：
    获取待监测服务器所产生的至少一条数据库日志；
    消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间；
    针对所述至少一条数据库日志中的任一数据库日志，判断所述数据库日志的执行时间是否超出由历史数据库日志数据训练得到基限区间；
    若所述数据库日志的执行时间超出基限区间，向所述待监测服务器所对应的信息接收端发送警告信息。
  17. 根据权利要求16所述的存储介质，其特征在于，所述获取待监测服务器所产生的至少一条数据库日志之后，还包括：
    获取与所述数据库日志对应的连续数据流；
    将所述连续数据流进行拆分，得到离散化数据库日志。
  18. 根据权利要求17所述的存储介质，其特征在于，所述消费所述至少一条数据库日志，得到每条数据库日志各自的执行时间，包括：
    添加分布式发布订阅消息系统与流式处理框架服务器之间的依赖；
    接收所述离散化数据库日志；
    解析所述离散化数据库日志中所包括的预设的指定关键词，获取与所述指定关键词相对应的数据库日志的执行时间。
  19. 根据权利要求16所述的存储介质，其特征在于，所述由历史数据库日志数据训练得到基限区间，包括：
    获取多个待监控服务器所发送的数据库日志；
    将多条数据库日志进行汇总，得到汇总后的数据库日志；
    解析所述汇总后的数据库日志中每一数据库日志的执行时间，并获取所述汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差；
    根据执行时间平均值与执行时间平均值标准差，对应设置基限区间。
  20. 根据权利要求19所述的存储介质，其特征在于，所述获取汇总后的数据库日志中多条数据库日志对应的执行时间平均值和执行时间平均值标准差中，
    Figure PCTCN2018102473-appb-100006
    中，μ表示多条数据库日志对应的执行时间平均值，σ表示多条数据库日志对应的执行时间平均值标准差，xi是第i台待监控服务器所上传数据库日志对应的SQL的执行时间，且i的取值范围为[1，N]，N为待监控服务器的总台数。
PCT/CN2018/102473 2018-05-25 2018-08-27 Sql性能监控方法、装置、计算机设备及存储介质 WO2019223155A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810560805.XA CN108874642A (zh) 2018-05-25 2018-05-25 Sql性能监控方法、装置、计算机设备及存储介质
CN201810560805.X 2018-05-25

Publications (1)

Publication Number Publication Date
WO2019223155A1 true WO2019223155A1 (zh) 2019-11-28

Family

ID=64336918

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/102473 WO2019223155A1 (zh) 2018-05-25 2018-08-27 Sql性能监控方法、装置、计算机设备及存储介质

Country Status (2)

Country Link
CN (1) CN108874642A (zh)
WO (1) WO2019223155A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111563022A (zh) * 2020-05-12 2020-08-21 中国民航信息网络股份有限公司 一种集中式存储器监控方法和装置
CN115599656A (zh) * 2022-12-12 2023-01-13 深圳联友科技有限公司（Cn） 基于Java自定义SQL监控告警实现的方法

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109299132B (zh) * 2018-11-29 2021-08-06 中国人民财产保险股份有限公司 Sql数据处理方法、系统以及电子设备
CN109359930A (zh) * 2018-12-20 2019-02-19 上海德启信息科技有限公司 物流作业资源监控方法、装置和计算机设备
CN110309110A (zh) * 2019-05-24 2019-10-08 深圳壹账通智能科技有限公司 一种大数据日志监控方法及装置、存储介质和计算机设备
CN110502581B (zh) * 2019-08-27 2022-07-08 中国联合网络通信集团有限公司 分布式数据库系统监测方法及装置
CN112653567B (zh) * 2019-10-12 2022-03-04 上海哔哩哔哩科技有限公司 监控方法、装置、计算机设备及存储介质
CN110750425A (zh) * 2019-10-25 2020-02-04 上海中通吉网络技术有限公司 数据库监控方法、装置、系统和存储介质
CN110941541B (zh) * 2019-11-06 2023-06-23 北京百度网讯科技有限公司 对数据流服务进行问题定级的方法以及装置
CN111124839A (zh) * 2019-12-31 2020-05-08 中国银行股份有限公司 分布式日志数据监控方法及装置
CN112749410B (zh) * 2021-01-08 2022-02-25 广州锦行网络科技有限公司 一种数据库安全保护方法及装置
CN116662059B (zh) * 2023-07-24 2023-10-24 上海爱可生信息技术股份有限公司 MySQL数据库CPU故障诊断及自愈方法及可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103793526A (zh) * 2014-02-24 2014-05-14 浪潮电子信息产业股份有限公司 一种监控sql语句性能的方法
CN105808413A (zh) * 2016-03-02 2016-07-27 上海新炬网络信息技术有限公司 基于业务流程可视化的sql性能监控方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103854064B (zh) * 2012-11-29 2017-01-25 中国科学院计算机网络信息中心 一种面向特定区域的事件发生风险预测并预警方法
CN104572391B (zh) * 2013-10-16 2019-03-15 深圳市腾讯计算机系统有限公司 监控告警策略配置方法及装置、监控告警方法及装置
CN107038669A (zh) * 2015-07-28 2017-08-11 平安科技（深圳）有限公司 异常结算数据预警提示系统及方法
US10255313B2 (en) * 2015-09-17 2019-04-09 International Business Machines Corporation Estimating database modification
CN105610647A (zh) * 2015-12-30 2016-05-25 华为技术有限公司 一种探测业务异常的方法和服务器
CN106407085B (zh) * 2016-11-24 2019-03-15 中国银行股份有限公司 一种性能监控方法及装置
CN107705149A (zh) * 2017-09-22 2018-02-16 平安科技（深圳）有限公司 数据实时监控方法、装置、终端设备及存储介质
CN108063699B (zh) * 2017-12-28 2020-08-28 携程旅游信息技术（上海）有限公司 网络性能监控方法、装置、电子设备、存储介质

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103793526A (zh) * 2014-02-24 2014-05-14 浪潮电子信息产业股份有限公司 一种监控sql语句性能的方法
CN105808413A (zh) * 2016-03-02 2016-07-27 上海新炬网络信息技术有限公司 基于业务流程可视化的sql性能监控方法

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111563022A (zh) * 2020-05-12 2020-08-21 中国民航信息网络股份有限公司 一种集中式存储器监控方法和装置
CN111563022B (zh) * 2020-05-12 2023-09-05 中国民航信息网络股份有限公司 一种集中式存储器监控方法和装置
CN115599656A (zh) * 2022-12-12 2023-01-13 深圳联友科技有限公司（Cn） 基于Java自定义SQL监控告警实现的方法

Also Published As

Publication number Publication date
CN108874642A (zh) 2018-11-23

Similar Documents

Publication Publication Date Title
WO2019223155A1 (zh) Sql性能监控方法、装置、计算机设备及存储介质
EP3234776B1 (en) Data stream processing language for analyzing instrumented software
US9804951B2 (en) Quantization of data streams of instrumented software
Chen et al. CauseInfer: Automated end-to-end performance diagnosis with hierarchical causality graph in cloud environment
US11057502B2 (en) Cloud assisted behavioral automated testing
US9438493B2 (en) Monitoring network entities via a central monitoring system
US9965327B2 (en) Dynamically scalable data collection and analysis for target device
WO2021151312A1 (zh) 一种确定服务间依赖关系的方法及相关装置
US10091110B2 (en) Edge-based load shedding system for fast data analysis and operating method thereof
US20200073982A1 (en) Federated chatbots
CN112306700A (zh) 一种异常rpc请求的诊断方法和装置
CN111193633A (zh) 异常网络连接的检测方法及装置
Cohen et al. Introducing new deformable surfaces to segment 3D images
CN113760677A (zh) 异常链路分析方法、装置、设备及存储介质
WO2021155683A1 (zh) 日志打印方法、装置、电子设备和存储介质
CN112313627A (zh) 事件到无服务器函数工作流实例的映射机制
US10248508B1 (en) Distributed data validation service
US8296262B1 (en) Systems and methods for real-time online monitoring of computing devices
CN113778818A (zh) 优化系统的方法、装置、设备和计算机可读介质
CN111130882A (zh) 网络设备的监控系统及方法
Gao et al. Study on data acquisition solution of network security monitoring system
CN115220131A (zh) 气象数据质检方法及系统
CN114356713A (zh) 线程池监控方法、装置、电子设备及存储介质
CN114625763A (zh) 用于数据库的信息分析方法、装置、电子设备和可读介质
CN113157475A (zh) 日志处理方法、装置、存储介质及电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18919870

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18919870

Country of ref document: EP

Kind code of ref document: A1