WO2023273529A1 - 业务日志监控方法、装置、存储介质及电子设备 - Google Patents
业务日志监控方法、装置、存储介质及电子设备 Download PDFInfo
- Publication number
- WO2023273529A1 WO2023273529A1 PCT/CN2022/087631 CN2022087631W WO2023273529A1 WO 2023273529 A1 WO2023273529 A1 WO 2023273529A1 CN 2022087631 W CN2022087631 W CN 2022087631W WO 2023273529 A1 WO2023273529 A1 WO 2023273529A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- business
- data
- log
- request
- service
- Prior art date
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 86
- 238000000034 method Methods 0.000 title claims abstract description 80
- 238000012545 processing Methods 0.000 claims abstract description 48
- 239000012634 fragment Substances 0.000 claims description 21
- 238000013467 fragmentation Methods 0.000 claims description 17
- 238000006062 fragmentation reaction Methods 0.000 claims description 17
- 238000004140 cleaning Methods 0.000 claims description 12
- 238000001914 filtration Methods 0.000 claims description 10
- 238000004458 analytical method Methods 0.000 claims description 7
- 238000012806 monitoring device Methods 0.000 claims description 7
- 230000002159 abnormal effect Effects 0.000 abstract description 6
- 230000008569 process Effects 0.000 description 23
- 230000004044 response Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
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/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
- G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
Definitions
- the present invention relates to the technical field of intelligent terminals, in particular to a business log monitoring method, device, storage medium and electronic equipment.
- the monitoring methods in the prior art usually focus on a single service or deployment, and monitor the server as a whole, so as to determine whether an abnormality occurs when the server executes transaction services.
- a huge distributed open system when an exception occurs on a certain server, it is difficult to locate which business in the server caused the exception, so the source of the failure cannot be found, and maintenance personnel need to check each business generated in the server one by one. logs, resulting in very low efficiency in locating faults.
- the present invention provides a business log monitoring method, through which, each newly added business log in the application server can be analyzed and processed, and abnormal business logs found by the application server can be found in time.
- the technical solution is as follows:
- a business log monitoring method comprising:
- the business log When it is detected that the preset business collection component uploads the business log to the preset message queue, the business log is fragmented, so as to obtain each fragment data corresponding to the business log from the message queue;
- the business log contains a plurality of business data, and each of the fragmented data contains at least one business data;
- performing fragmentation processing on the business log to obtain each fragmented data corresponding to the business log from the message queue includes:
- each read channel corresponds to a piece of data
- data cleaning is performed on each business data in each of the fragmented data, and each invalid business data in each of the fragmented data is removed , to obtain various valid business data, including:
- Each invalid service data in each piece of data is removed to obtain each valid service data.
- the determining the invocation relationship between each valid service data in the service log based on the source of the service request and the purpose of the service request of each valid service data includes:
- the above method optionally, also includes:
- the invocation chain is displayed on a preset display interface, the invocation chain includes a plurality of nodes, and each of the nodes is in one-to-one correspondence with each of the effective service nodes.
- a business log monitoring device comprising:
- a fragmentation unit configured to perform fragmentation processing on the business log when it is detected that the preset business collection component uploads the business log to the preset message queue, so as to obtain the information corresponding to the business log from the message queue.
- An identification unit configured to read the transaction ID of each business data in each of the fragmented data, and based on the transaction ID of each of the business data, identify the source of the business request and the purpose of the business request for each of the business data ;
- a processing unit configured to perform data cleaning on each service data in each of the fragmented data based on preset monitoring indicators, remove each invalid service data in each of the fragmented data, and obtain each valid service data;
- a determining unit configured to determine the calling relationship between each valid service data in the service log based on the source of the service request and the purpose of the service request for each of the valid service data, and based on the call relationship, and generate the loopback data corresponding to the business log;
- An analysis unit configured to analyze the loopback data and obtain the core business indicators corresponding to the business logs
- a judging unit configured to judge whether the business log complies with preset business log monitoring rules based on the business core indicators
- An alarm unit configured to perform alarm processing on the business log if the business log does not comply with the business monitoring rule.
- the fragmentation unit includes:
- An identification subunit configured to identify each read channel that has been set in the message queue
- the first processing subunit is configured to determine the number of each of the read channels in the message queue, and use the number of each of the read channels as the number of fragments to split the business log Fragment processing, obtaining each fragmented data corresponding to the business log; wherein, each of the read channels corresponds to a fragmented data;
- the reading subunit is configured to read the pieced data corresponding to each of the reading channels via each reading channel in the message queue.
- the processing unit includes:
- the obtaining subunit is used to obtain the source of the standard service request and the purpose of the standard service request set in the monitoring index;
- the second processing subunit is configured to, for each business data in each of the fragmented data, determine whether the business request source and the business request purpose of the business data conform to the standard business request source and the standard business request purpose ; If the business request source and business request purpose of the business data conform to the standard business request source and standard business request purpose, then determine that the business data is valid business data; if there is any business data request source and business If the purpose of the request does not meet the standard business request source and standard business request purpose, the business data is determined to be invalid business data;
- the filtering subunit is configured to remove each invalid service data in each piece of data, and obtain each valid service data.
- a storage medium where computer-executable instructions are stored in the computer-readable storage medium, and the computer-executable instructions are used to execute the business log monitoring method disclosed in any one of the above-mentioned first aspects of the present invention.
- An electronic device the electronic device includes: at least one memory and at least one processor; the memory stores a program, the processor invokes the program stored in the memory, and the program is used to implement the above-mentioned first method of the present invention On the one hand, any disclosed business log monitoring method.
- the present invention includes the following advantages:
- the present invention provides a business log monitoring method, comprising: when it is detected that the business collection component uploads the business log to the message queue, fragment processing is performed on the business log to obtain each fragment data; and the transaction ID of each business data is read , and based on each transaction ID, identify the business request source and business request purpose of each business data; based on the monitoring indicators, perform data cleaning, remove each invalid business data, and obtain each valid business data; based on each valid business data business
- the source of the request and the purpose of the business request determine the call relationship between each valid business data, and generate the loopback data corresponding to the business log; analyze the loopback data to obtain the core business indicators corresponding to the business log; based on the core business indicators, determine whether the business log meets the Business log monitoring rules; if not in compliance, alarm processing will be performed on the business log.
- Fig. 1 is the method flowchart of a kind of business log monitoring method that the embodiment of the present invention provides;
- Fig. 2 is yet another method flow chart of a kind of business log monitoring method provided by the embodiment of the present invention.
- Fig. 3 is another method flowchart of a business log monitoring method provided by the embodiment of the present invention.
- FIG. 4 is an example diagram of a business log monitoring method provided by an embodiment of the present invention.
- Fig. 5 is a system structure diagram of a business log monitoring system provided by an embodiment of the present invention.
- Fig. 6 is a device structure diagram of a business log monitoring device provided by an embodiment of the present invention.
- FIG. 7 is a schematic structural diagram of an electronic device provided by an embodiment of the present invention.
- the invention is applicable to numerous general purpose or special purpose computing device environments or configurations.
- personal computer server computer, handheld or portable device, tablet type device, multiprocessor device, distributed computing environment including any of the above devices or devices, etc.
- the embodiment of the present invention provides a business log monitoring method, which can be applied to various system platforms, and its execution subject can be a computer terminal or a processor of various mobile devices.
- the method flow chart of the method is shown in Figure 1 , specifically include:
- the business log contains a plurality of business data, and each piece of data contains at least one business data.
- Each business data corresponds to a business request in the application server and the response process to the request.
- the business collection component is deployed in the application server for real-time monitoring of the application server, and when a new business log is added on the application server, it collects the newly added business log and uploads it to the message in queue.
- the message queue can be a message management queue inside Kafka, a distributed application program coordination service Zookeeper or a high-performance key-value database Redis, etc.
- Kafka is mainly used as a message queue for managing business logs.
- each business data in the business log is divided into three parts: control header, extension area, and content area. Each part ends with the character "0x0A". Neither the control header nor the extension area shall contain the character "0x0A" and the character string "[#%&* ⁇ ]". If the extension area or content area is missing, the reserved character "0x0A” is still required.
- the control header includes time, machine information, business information, transaction serial number, etc.
- the content area is the stream of transmitted data. For example, messages of a specific protocol are used when interacting between various business systems.
- each business data may be randomly assigned to different fragmented data.
- S102 Read the transaction ID of each business data in each piece of data, and identify the business request source and business request purpose of each business data based on the transaction ID of each business data.
- the business log contains business data corresponding to multiple requests, such as access requests, query requests, and status requests.
- the ID corresponding to each request is the transaction ID corresponding to each business data.
- each business data contains the source of the business request and the purpose of the business request corresponding to each request.
- the protocol information in the business data is identified through the transaction ID of the business data, and the business request source of the business data is identified through the protocol information. and business request purposes.
- S103 Based on the preset monitoring indicators, perform data cleaning on each service data in each of the fragmented data, remove each invalid service data in each of the fragmented data, and obtain each valid service data.
- the monitoring indicator is a filter condition for filtering service data. According to the filtering condition, each business data in each fragmented data is filtered, and the business data that does not meet the filtering condition is filtered out as invalid business data, and the remaining business data is valid business data.
- S104 Based on the business request source and service request purpose of each of the valid business data, determine the calling relationship between each valid business data in the business log, and based on the calling relationship between each of the valid business data to generate loopback data corresponding to the business log.
- the context matching is performed on each business data, and the call relationship between each business data is determined, so as to generate the loopback corresponding to the business log data.
- the loopback data is analyzed to determine the request success rate between each service request between the contexts corresponding to the service log or the response time corresponding to each request.
- the service core indicator refers to the request success rate or request response time of the service request corresponding to each service data.
- S106 Based on the core business indicators, determine whether the business logs comply with preset business log monitoring rules.
- the service log monitoring rule in the embodiment of the present invention is that the service core index corresponding to the service log satisfies the set monitoring index. By judging whether the core business indicators meet the monitoring indicators, it is determined whether the business log complies with the business log monitoring rules.
- the monitoring indicator is the success rate threshold; if the request success rate exceeds the success rate threshold, it is determined that the business log complies with the business log monitoring rules, otherwise it does not.
- the core business indicator is the request response time
- the monitoring indicator is the maximum allowable response time; if the request response time corresponding to any business data in the business log is less than the maximum allowable response time, it is determined that the business log complies with the business log monitoring rules, and vice versa is not met.
- the business log when it is determined that the business log does not comply with the business monitoring rules, it may be directly determined that the currently abnormal business log is the currently monitored business log, and alarm processing is performed on the business log.
- the business log monitoring method when it is detected that the business collection component uploads the business log to the message queue, the business log is fragmented and then the fragmented data corresponding to the business log is obtained from the message queue. Since the business log contains multiple business data, after the business log is fragmented, each data fragment contains at least one business data. Read the transaction ID of each business data, and identify the business request source and business request purpose of the business data through the transaction ID, and then remove the invalid business data in each business data according to the monitoring indicators, and obtain each valid business data. Apply the business request source and business request purpose of each valid business data, determine the call relationship between each valid business data, and form the loopback data corresponding to the business log. Analyze the loopback data to determine whether the business log complies with the business log monitoring rules, and if not, perform alarm processing.
- the business log is segmented, and various business data in the message queue can be quickly read.
- the context relationship corresponding to the business log is formed, and according to the core business indicators of the context, it is determined whether the business log will cause an exception to the server, and the business log is processed in advance Able to carry out timely alarm processing.
- the business log in the message queue is fragmented.
- the business log Perform fragmentation processing to obtain the process of each fragmented data corresponding to the business log from the message queue, as shown in Figure 2, may include:
- the read channel in the message queue can be set according to the actual application scenario. For business logs with a large amount of business data, the more read channels are set in the message queue, the faster the read of fragmented data will be.
- S202 Determine the number of each of the reading channels in the message queue, and use the number of each of the reading channels as the number of fragments, perform fragmentation processing on the business log, and obtain the Each shard data corresponding to the business log.
- each of the read channels corresponds to one piece of data.
- the number of channels for reading channels is used as the number of fragments for the business log, and according to the number of fragments, the business log is randomly fragmented, so that in each fragmented data Contains at least one business data.
- each piece of data in the message queue when the business log needs to be processed, it is necessary to obtain each piece of data in the message queue to obtain a complete business log.
- multiple data reading threads can be set, and each data reading thread corresponds to a reading channel in the message queue, and reads the fragmented data corresponding to each reading channel at the same time.
- the business collection group uploads the business log to the message queue, it identifies each read channel that has been set in the message queue, and determines the number of read channels, and uses the message queue
- the number of read channels in is used as the number of fragmented data after the business log is fragmented, and the business log is fragmented according to the number of read channels to obtain each fragmented data.
- Each piece of data in the message queue corresponds to each read channel one by one. When the business log needs to be processed, each piece of data in the message queue is read from each read channel.
- the process of reading the business log is accelerated by performing fragmentation processing on the business log.
- the process of reading each piece of data in the message queue may specifically include:
- the source of the standard service request and the purpose of the standard service request can be set by the user according to actual working conditions.
- the standard business request source is set to only process the business of system A, then when filtering the business data, filter the business data of other systems except the business request source is system A. If the source of the standard business request is set to only process the business of all systems other than system A, when filtering the business data, only the business data whose business request source is system A is filtered.
- the process of S302 is executed for each service data in each piece of data.
- S304 Determine that the service data is invalid service data, and execute S305.
- the standard request source and the standard business request purpose have been set in the monitoring index, and the business request source of each business data in each fragmented data is matched with the standard business request source , and match the business request purpose of each business data with the standard business request purpose. If the business request source of the business data conforms to the standard business request source, and the business request purpose of the business data conforms to the standard business request purpose, then the business data is valid business data. Conversely, if the business request source of the business data does not conform to the standard business request source, or the business request purpose of the business data does not meet the standard business request purpose, the business data is invalid business data. After determining each invalid service data in each fragmented data, all invalid service data are deleted.
- the above process from S301 to S305 can be used as a setting condition for filtering invalid business data.
- the monitoring indicators for filtering business data can also be based on The filter conditions corresponding to the specific application environment settings are not limited here.
- the calling relationship between each valid business data is determined. For one business data, when searching for other business data that has a calling relationship with the business data During the process, other business data that has a calling relationship with the business data can be searched according to the business request purpose of the business data.
- the business request purpose of valid business data A is the target business request purpose
- the valid business data B whose business request source is consistent with the target business request purpose is searched in the business log, so that the target business request purpose of valid business data A Associated with the business request source of the valid business data B, determine the calling relationship between the valid business data A and the valid business data B as the valid business data A calls the valid business data B.
- a set of calling information of valid service data A is: the requested source service is MCSS_AVE_NEW, and the requested destination service is AVE_TODE2_C.
- a set of calling information of valid service data B is: the requested source service is AVE_TODE2_C, and the requested destination service is SEA. Therefore, the calling relationship between two valid service data is: MCSS_AVE_NEW-->AVE_TODE2_C-->SEA-->AVE_TODE2_C-->MCSS_AVE_NEW.
- FIG. 4 is a relationship diagram of the calling relationship.
- redundant data corresponding to each fragmented data may also be included in each fragmented data, and the redundant data corresponding to each fragmented data is used to store business data other than each business data in the fragmented data. other business data.
- the context matching process in the business log can be realized by combining redundant data.
- the fragmented data and each redundant data can be temporarily stored in the internal cache of the Spark cluster.
- the invocation chain is displayed on a preset display interface, the invocation chain includes a plurality of nodes, and each of the nodes is in one-to-one correspondence with each of the effective service nodes.
- the loopback data is converted into the form of a call chain for display. Users can read the call relationship between various business data and service monitoring indicator values through the display interface. The display interface is refreshed at a fixed time interval to accurately display the business The operation and invocation of data.
- the present invention provides a service log monitoring system to implement the above-mentioned processes.
- the business log monitoring system includes:
- the business log collection component 501 is configured to deploy a collection program on the application server to obtain business logs in a standard format. This component is a separate process deployed on each business application server, monitors the changes of business logs on the application server, collects business logs in standard format from the application server according to the pre-configured business rules, and stores them in the message queue.
- the service log collection component is the log collection component in S101 above.
- the business log analysis component 502 includes a message manager, business logic and temporary storage.
- the Spark environment based on the native Hadoop or CDH platform is deployed in the message management unit.
- the message manager is used to manage the message queue and read the fragmented data and offset in the message queue, and use the data offset corresponding to the fragmented data read this time as the start position of the next read.
- the business logic device is used to remove invalid data according to the monitoring indicators after consuming fragmented data, analyze and process each valid business data according to the rules, sort out the calling relationship between each valid business data to form loopback data, and analyze the loopback Business core metrics for data.
- the results after analysis and processing are uniformly stored in temporary memory.
- the data in the temporary storage is called by the business relationship presentation component 503 and the business monitoring alarm component 504 in real time.
- the business relationship display component 503 is used to read the call relationship and business core indicators between various business data from the temporary storage of the business log analysis component 502 in real time, and refresh the page display at a fixed time interval. The operation and call status of the business log is accurately displayed on the large screen of the self-developed page.
- the business monitoring and alarm component 504 is used to monitor the analysis results of the business logs from the temporary storage of the business log analysis component 502 in real time according to the business monitoring rules, perform summary calculation on the results, and judge whether the calculation results meet the business monitoring rules. If the preset business monitoring rules are met, the external alarm interface is called to alarm.
- the embodiment of the present invention also provides a business log monitoring device for the specific implementation of the method in Figure 1, the business log monitoring device provided in the embodiment of the present invention can be applied to a computer terminal or Among various mobile devices, their structural schematic diagrams are shown in Figure 6, specifically including:
- the fragmentation unit 601 is configured to perform fragmentation processing on the business log when it is detected that the preset business collection component uploads the business log to the preset message queue, so as to obtain the corresponding information of the business log from the message queue.
- Each fragmented data; the business log contains a plurality of business data, and each of the fragmented data contains at least one business data;
- An identifying unit 602 configured to read the transaction ID of each business data in each of the fragmented data, and identify the business request source and business request of each of the business data based on the transaction ID of each of the business data Purpose;
- the processing unit 603 is configured to perform data cleaning on each business data in each of the fragmented data based on preset monitoring indicators, remove each invalid business data in each of the fragmented data, and obtain each valid business data in each of the fragmented data. business data;
- the determination unit 604 is configured to determine the calling relationship between each valid business data in the business log based on the business request source and the service request purpose of each valid business data, and based on the call relationship among them, and generate the loopback data corresponding to the business log;
- An analyzing unit 605 configured to analyze the loopback data, and obtain the core business indicators corresponding to the business logs;
- a judging unit 606, configured to judge whether the business log complies with preset business log monitoring rules based on the business core index
- the alarm unit 607 is configured to perform alarm processing on the business log if the business log does not comply with the business monitoring rule.
- the business log monitoring device when it is detected that the business collection component uploads the business log to the message queue, the business log is fragmented and then the fragmented data corresponding to the business log is obtained from the message queue. Since the business log contains multiple business data, after the business log is fragmented, each data fragment contains at least one business data. Read the transaction ID of each business data, and identify the business request source and business request purpose of the business data through the transaction ID, and then remove the invalid business data in each business data according to the monitoring indicators, and obtain each valid business data. Apply the business request source and business request purpose of each valid business data, determine the call relationship between each valid business data, and form the loopback data corresponding to the business log. Analyze the loopback data to determine whether the business log complies with the business log monitoring rules, and if not, perform alarm processing.
- the fragmentation unit 601 includes:
- An identification subunit configured to identify each read channel that has been set in the message queue
- the first processing subunit is configured to determine the number of each of the read channels in the message queue, and use the number of each of the read channels as the number of fragments to split the business log Fragment processing, obtaining each fragmented data corresponding to the business log; wherein, each of the read channels corresponds to a fragmented data;
- the reading subunit is configured to read the pieced data corresponding to each of the reading channels via each reading channel in the message queue.
- the processing unit 603 includes:
- the obtaining subunit is used to obtain the source of the standard service request and the purpose of the standard service request set in the monitoring index;
- the second processing subunit is configured to, for each business data in each of the fragmented data, determine whether the business request source and the business request purpose of the business data conform to the standard business request source and the standard business request purpose ; If the business request source and business request purpose of the business data conform to the standard business request source and standard business request purpose, then determine that the business data is valid business data; if there is any business data request source and business If the purpose of the request does not meet the standard business request source and standard business request purpose, the business data is determined to be invalid business data;
- the filtering subunit is configured to remove each invalid service data in each piece of data, and obtain each valid service data.
- the determining unit 604 includes:
- the determining subunit is configured to, for each of the valid business data in the business log, determine that the business request purpose of the valid business data is the target business request purpose; in the business log, find the source of the business request and the The target business requests all valid business data with the same purpose, and associates the target business request purpose with each business request source that is consistent with it, forming a relationship between the valid business data corresponding to the target business request purpose and other associated valid business data. calls between them.
- the device provided by the embodiment of the present invention, it also includes:
- a display unit configured to generate a call chain corresponding to each of the valid business data based on the loopback data; display the call chain on a preset display interface, the call chain includes a plurality of nodes, and each of the nodes is connected to the There is a one-to-one correspondence between each of the effective service nodes.
- FPGAs Field Programmable Gate Arrays
- ASICs Application Specific Integrated Circuits
- ASSPs Application Specific Standard Products
- SOCs System on Chips
- CPLD Complex Programmable Logical device
- the electronic device may be a server.
- an electronic device may include a processing device (such as a central processing unit, a graphics processing unit, etc.) (RAM) 703 to execute various appropriate actions and processing.
- RAM 703 various programs and data necessary for the operation of the electronic device are also stored.
- the processing device 701 , ROM 702 , and RAM 703 are connected to each other through a bus 704 .
- An input/output (I/O) interface 705 is also connected to the bus 704 .
- the following devices can be connected to the I/O interface 705: input devices 706 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; including, for example, a liquid crystal display (LCD), speaker, vibration an output device 707 such as a computer; a storage device 708 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 709.
- the communication means 709 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. While FIG. 7 shows an electronic device having various means, it is to be understood that implementing or having all of the means shown is not a requirement. More or fewer means may alternatively be implemented or provided.
- the embodiment of the present application also provides a storage medium, where computer-executable instructions are stored in the storage medium, and the computer-executable instructions are used to implement the above-mentioned flight sales control method.
- the above-mentioned storage medium carries one or more programs, and when the above-mentioned one or more programs are executed by the electronic device, the electronic device: when detecting that the preset service collection component uploads the service log to the preset message queue, Perform fragmentation processing on the business log to obtain each fragmented data corresponding to the business log from the message queue; the business log contains a plurality of business data, and each fragmented data contains at least one Business data; read the transaction ID of each business data in each of the fragmented data, and identify the business request source and business request purpose of each of the business data based on the transaction ID of each of the business data; based on Pre-set monitoring indicators, performing data cleaning on each business data in each of the fragmented data, removing each invalid business data in each of the fragmented data, and obtaining each valid business data; based on each The source of the business request and the purpose of the business request for the valid business data, determine the calling relationship between each valid business data in the business log, and generate the business log based on the calling
- each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments.
- the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment.
- the systems and system embodiments described above are only illustrative, and the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is It can be located in one place, or it can be distributed to multiple network elements. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. It can be understood and implemented by those skilled in the art without creative effort.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Quality & Reliability (AREA)
- Mathematical Physics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Debugging And Monitoring (AREA)
Abstract
提供了一种业务日志监控方法、装置、存储介质及电子设备，该方法包括：当业务采集组件向消息队列上传业务日志时，对其进行分片处理获取各个分片数据；读取每个分片数据中业务数据的交易ID，以获得每个业务数据的业务请求来源及业务请求目的；基于监控指标，去除无效的业务数据，获得有效业务数据；基于每个有效业务数据的业务请求来源以及业务请求目的，确定各个有效业务数据间的调用关系，生成业务日志对应的回环数据；分析回环数据，获得业务核心指标；判断业务日志是否符合业务日志监控规则；若不符合，则进行报警处理。应用该方法，可以对应用服务器中每次新增的业务日志进行分析和处理，及时发现应用服务器出现异常的业务日志。
Description
本申请要求于2021年6月30日提交中国专利局、申请号为202110741707.8、发明名称为“业务日志监控方法、装置、存储介质及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
本发明涉及智能终端技术领域，特别是涉及一种业务日志监控方法、装置、存储介质及电子设备。
在各种应用设备和系统的运行过程中，为提高系统性能以及用户体验，需要对系统中的关键业务进行监控、测试以及优化等一系列操作。随着民航信息系统的快速发展，民航信息系统主要是应用分布式开放式系统执行大量的核心交易业务，因此对分布式开放系统中的应用进行监控也尤为重要。
现有技术中的监控方式通常都是针对单一的服务或部署，针对服务器整体进行监控，以确定服务器在执行交易业务时过程中是否发生异常。但是在庞大的分布式开放系统中，某个服务器该发生异常时，很难定位到该服务器中哪个业务导致异常的发生，因此无法故障的来源，需要维护人员逐一排查服务器内产生的每个业务日志，导致对故障进行定位的效率十分低下。
发明内容
有鉴于此，本发明提供一种业务日志监控方法，通过该方法，可以对应用服务器中每次新增的业务日志进行分析和处理，及时发现发现应用服务器发现异常的业务日志。技术方案如下：
一种业务日志监控方法，包括：
当检测到预先设置的业务采集组件向预先设置的消息队列上传业务日志时，对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对 应的各个分片数据；所述业务日志中包含多个业务数据，每个所述分片数据包含至少一个业务数据；
读取每个所述分片数据中每个业务数据的交易ID，并基于每个所述业务数据的交易ID，识别每个所述业务数据的业务请求来源以及业务请求目的；
基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据；
基于每个所述有效业务数据的业务请求来源以及业务请求目的，确定所述业务日志中各个有效业务数据之间的调用关系，并基于所述各个所述有效业务数据之间的调用关系，生成所述业务日志对应的回环数据；
分析所述回环数据，获得所述业务日志对应的业务核心指标；
基于所述业务核心指标，判断所述业务日志是否符合预设的业务日志监控规则；
若所述业务日志不符合所述业务监控规则，则对所述业务日志进行报警处理。
上述的方法，可选的，所述对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对应的各个分片数据，包括：
识别所述消息队列中已设定的各个读取通道；
确定所述消息队列中各个所述读取通道的个数，并以各个所述读取通道的个数作为分片的个数，对所述业务日志中进行分片处理，获得所述业务日志对应的各个分片数据；其中，每个所述读取通道对应一个分片数据；
经由所述消息队列中的各个读取通道，读取每个所述读取通道对应的分片数据。
上述的方法，可选的，所述基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据，包括：
获取所述监控指标中已设定的标准业务请求来源以及标准业务请求目的；
对于每个所述分片数据中的每个业务数据，判断所述业务数据的业务请求来源及业务请求目的，是否符合所述标准业务请求来源及标准业务请求目的； 若所述业务数据的业务请求来源及业务请求目的，符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为有效业务数据；若存在任意的业务数据的请求来源及业务请求目的，不符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为无效业务数据；
去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据。
上述的方法，可选的，所述基于每个所述有效业务数据的业务请求来源以及业务请求目的，确定所述业务日志中各个有效业务数据之间的调用关系，包括：
对于所述业务日志中每个所述有效业务数据，确定所述有效业务数据的业务请求目的为目标业务请求目的；在所述业务日志中，查找业务请求来源与所述目标业务请求目的一致的所有有效业务数据，并将所述目标业务请求目的与其一致的各个业务请求来源进行关联，形成所述目标业务请求目的对应的有效业务数据与其他已关联的有效业务数据之间的调用关系。
上述的方法，可选的，还包括：
基于所述回环数据，生成各个所述有效业务数据对应的调用链；
在预先设置的展示界面上展示所述调用链，所述调用链包含多个节点，各个所述节点与各个所述有效业务节点一一对应。
一种业务日志监控装置，包括：
分片单元，用于当检测到预先设置的业务采集组件向预先设置的消息队列上传业务日志时，对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对应的各个分片数据；所述业务日志中包含多个业务数据，每个所述分片数据包含至少一个业务数据；
识别单元，用于读取每个所述分片数据中每个业务数据的交易ID，并基于每个所述业务数据的交易ID，识别每个所述业务数据的业务请求来源以及业务请求目的；
处理单元，用于基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据；
确定单元，用于基于每个所述有效业务数据的业务请求来源以及业务请求 目的，确定所述业务日志中各个有效业务数据之间的调用关系，并基于所述各个所述有效业务数据之间的调用关系，生成所述业务日志对应的回环数据；
分析单元，用于分析所述回环数据，获得所述业务日志对应的业务核心指标；
判断单元，用于基于所述业务核心指标，判断所述业务日志是否符合预设的业务日志监控规则；
报警单元，用于若所述业务日志不符合所述业务监控规则，则对所述业务日志进行报警处理。
上述的装置，可选的，所述分片单元，包括：
识别子单元，用于识别所述消息队列中已设定的各个读取通道；
第一处理子单元，用于确定所述消息队列中各个所述读取通道的个数，并以各个所述读取通道的个数作为分片的个数，对所述业务日志中进行分片处理，获得所述业务日志对应的各个分片数据；其中，每个所述读取通道对应一个分片数据；
读取子单元，用于经由所述消息队列中的各个读取通道，读取每个所述读取通道对应的分片数据。
上述的装置，可选的，所述处理单元，包括：
获取子单元，用于获取所述监控指标中已设定的标准业务请求来源以及标准业务请求目的；
第二处理子单元，用于对于每个所述分片数据中的每个业务数据，判断所述业务数据的业务请求来源及业务请求目的，是否符合所述标准业务请求来源及标准业务请求目的；若所述业务数据的业务请求来源及业务请求目的，符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为有效业务数据；若存在任意的业务数据的请求来源及业务请求目的，不符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为无效业务数据；
过滤子单元，用于去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据。
一种存储介质，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令用于执行如上述本发明第一方面任意一项公开的业务日 志监控方法。
一种电子设备，所述电子设备包括：至少一个存储器和至少一个处理器；所述存储器存储有程序，所述处理器调用所述存储器存储的程序，所述程序用于实现如上述本发明第一方面任意一项公开的业务日志监控方法。
与现有技术相比，本发明包括以下优点：
本发明提供了一种业务日志监控方法，包括：当检测到业务采集组件向消息队列上传业务日志时，对业务日志进行分片处理，获取各个分片数据；读取每个业务数据的交易ID，并基于各个交易ID，识别每个业务数据的业务请求来源以及业务请求目的；基于监控指标，进行数据清洗，去除各个无效的业务数据，获得各个有效业务数据；基于每个有效业务数据的业务请求来源以及业务请求目的，确定各个有效业务数据之间的调用关系，并生成业务日志对应的回环数据；分析回环数据，获得业务日志对应的业务核心指标；基于业务核心指标，判断业务日志是否符合业务日志监控规则；若不符合，则对业务日志进行报警处理。应用本发明提供的方法，可以对应用服务器中每次新增的业务日志进行分析和处理，及时发现发现应用服务器发现异常的业务日志。
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本发明式实施例提供的一种业务日志监控方法的方法流程图；
图2为本发明式实施例提供的一种业务日志监控方法的又一方法流程图；
图3为本发明式实施例提供的一种业务日志监控方法的再一方法流程图；
图4为本发明式实施例提供的一种业务日志监控方法的一示例图；
图5为本发明式实施例提供的一种业务日志监控系统的系统结构图；
图6为本发明式实施例提供的一种业务日志监控装置的装置结构图；
图7为本发明式实施例提供的一种电子设备结构示意图。
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
在本申请中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本发明可用于众多通用或专用的计算装置环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。
本发明实施例提供了一种业务日志监控方法，该方法可以应用在多种系统平台，其执行主体可以为计算机终端或各种移动设备的处理器，所述方法的方法流程图如图1所示，具体包括：
S101：当检测到预先设置的业务采集组件向预先设置的消息队列上传业务日志时，对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对应的各个分片数据。
其中，所述业务日志中包含多个业务数据，每个所述分片数据包含至少一个业务数据。每个业务数据对应在应用服务器中的一次业务请求以及对请求的响应过程。
在本发明实施例中，业务采集组件部署于应用服务器中，用于对应用服务器进行实时的监控，并在监控到应用服务器上新增业务日志时，采集新增的业务日志，并上传至消息队列中。该消息队列可以是Kafka内部的消息管理队列、 分布式应用程序协调服务Zookeeper或高性能的key-value数据库Redis等，本发明中主要以Kafka作为管理业务日志的消息队列。
需要说明的是，业务日志中的每个业务数据分为三个部分：控制头、扩展区、内容区。每部分都以字符“0x0A”结尾。控制头和扩展区均不得含有字符“0x0A”和字符串“[#％&*^]”。如果扩展区或内容区缺失，仍然需要保留字符“0x0A”。控制头中包括了时间、机器信息、业务信息、交易流水号等。扩展区是一组(Key，Value)的集合，采用“Key＝Value；”形式，以“；”分隔，Key和Value成对出现的。其中关键必填Key值为Protocol，值为1-7的数字。每个数字代表了内容区记录文本的协议类型。内容区是传输的数据流。比如各个业务系统之间交互时使用某种特定协议的报文等。
还需要说明的是，在对业务日志进行分片的过程中，各个业务数据可以是随机分配到不同的分片数据中。
S102：读取每个所述分片数据中每个业务数据的交易ID，并基于每个所述业务数据的交易ID，识别每个所述业务数据的业务请求来源以及业务请求目的。
在本发明实施例中，在业务日志中包含了多个请求对应的业务数据，例如访问请求、查询请求以及状态请求等。每一个请求对应的ID均为每个业务数据对应的交易ID。同时，每个业务数据中均包含每个请求对应的业务请求来源和业务请求目的，通过业务数据的交易ID，识别出业务数据内的协议信息，并通过协议信息识别出业务数据的业务请求来源和业务请求目的。
S103：基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据。
在本发明实施例中，该监控指标是对业务数据进行过滤的过滤条件。根据该过滤条件对分别对每个分片数据中的各个业务数据进行过滤，筛选出不符合过滤条件的业务数据作为无效的业务数据剔除，剩下的各个业务数据则为有效业务数据。
S104：基于每个所述有效业务数据的业务请求来源以及业务请求目的，确定所述业务日志中各个有效业务数据之间的调用关系，并基于所述各个所述有 效业务数据之间的调用关系，生成所述业务日志对应的回环数据。
在本发明实施例中，通过每个有效业务数据的业务请求来源以及业务请求目的，对各个业务数据进行上下文匹配，确定每个业务数据之间的调用关系，以此生成该业务日志对应的回环数据。
S105：分析所述回环数据，获得所述业务日志对应的业务核心指标。
在本发明实施例中，分析该回环数据，确定业务日志对应的上下文之间每个业务请求之间的请求成功率或者对应每个请求进行响应的响应时间。
具体的，该业务核心指标指的是各个业务数据对应的业务请求的请求成功率或者请求响应时间。
S106：基于所述业务核心指标，判断所述业务日志是否符合预设的业务日志监控规则。
可以理解的是，本发明实施例的业务日志监控规则是业务日志对应的业务核心指标满足设定的监控指标。通过判断业务核心指标是否满足监控指标，以确定该业务日志是否符合该业务日志监控规则。
具体的，当该业务核心指标是请求成功率时，监控指标则为成功率阈值；若请求成功率超出成功率阈值，则判定业务日志符合业务日志监控规则，反之则不符合。当业务核心指标是请求响应时间时，监控指标则为允许响应最大时间；若业务日志中任意一个业务数据对应的请求响应时间小于该允许响应最大时间，则判定业务日志符合业务日志监控规则，反之则不符合。
S107：若所述业务日志不符合所述业务监控规则，则对所述业务日志进行报警处理。
在本发明实施例中，在确定业务日志不符合业务监控规则时，可以直接确定当前发现异常的业务日志为当前监控的业务日志，并对该业务日志进行报警处理。
本发明实施例提供的业务日志监控方法中，在检测到业务采集组件向消息队列上传业务日志时，对业务日志进行分片处理后从该消息队列中获取该业务日志对应的各个分片数据。由于业务日志中包含多个业务数据，对业务日志进行分片处理后，每个分片数据中包含至少一个业务数据。读取每个业务数据的交易ID，并通过交易ID识别业务数据的业务请求来源以及业务请求目的，再根 据监控指标去除各个业务数据中的无效业务数据，获得各个有效业务数据。应用每个有效业务数据的业务请求来源以及业务请求目的，确定每个有效业务数据之间的调用关系，形成该业务日志对应的回环数据。分析该回环数据，判断该业务日志是否符合业务日志监控规则，若不符合则进行报警处理。
应用本发明实施例提供的方法，对业务日志进行分片，可以快速读取消息队列中的各个业务数据。同时，通过确定各个业务数据之间的调用关系，以形成该业务日志对应的上下文关系，并根据该上下文的业务核心指标，确定该业务日志是否会造成服务器发生异常，提前对业务日志进行处理后能够进行及时的报警处理。
本发明实施例提供的方法中，基于上述S101的内容，在业务采集组件将业务日志上传至消息队列中后，对该消息队列中的业务日志进行分片处理，具体的，对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对应的各个分片数据的过程如图2所示，可以包括：
S201：识别所述消息队列中已设定的各个读取通道。
在本发明实施例中，该消息队列中的读取通道可以根据实际应用场景进行设置。对于业务数据量大的业务日志，该消息队列中读取通道设置的数量越多，对分片数据的读取就越快。
S202：确定所述消息队列中各个所述读取通道的个数，并以各个所述读取通道的个数作为分片的个数，对所述业务日志中进行分片处理，获得所述业务日志对应的各个分片数据。
其中，每个所述读取通道对应一个分片数据。
在本发明实施例中，以读取通道的通道个数作为对业务日志进行分片的个数，并按照该分片个数，随机对业务日志进行分片处理，使得每个分片数据中包含至少一个业务数据。
S203：经由所述消息队列中的各个读取通道，读取每个所述读取通道对应的分片数据。
在本发明实施例中，当需要对业务日志进行处理时，需要获取消息队列中的各个分片数据，以获得完整的业务日志。其中，可以设置多个数据读取线程，每个数据读取线程分别对应该消息队列中的一个读取通道，同时读取每个读取 通道对应的分片数据。
本发明实施例提供的业务日志监控方法中，业务采集组将业务日志上传至该消息队列后，识别该消息队列内已设置的各个读取通道，并确定读取通道的个数，以消息队列中读取通道的个数作为对业务日志进行分片处理后分片数据的个数，按照该读取通道的个数对业务日志进行分片处理，获得各个分片数据。该消息队列中的各个分片数据与各个读取通道一一对应。当需要对业务日志进行处理时，从各个读取通道中读取该消息队列中的各个分片数据。
应用本发明实施例提供的方法，通过对业务日志进行分片处理，加快对业务日志的读取过程。
进一步地，在本发明中，读取消息队列中各个分片数据的过程，具体还可以包括：
确定各个分片数据的读取顺序，并按照读取顺序依次读取各个分片数据。其中，在读取当前的分片数据时，获取当前的分片数据对应的起始偏移量和结束偏移量。判断当前的分片数据是否首个分片数据，若是首个分片数据，则将该结束偏移量作为下一个分片数据的起始偏移量。若非首个分片数据，则判断是否为业务日志的最后一个分片数据；若是最后一个分片数据，则记录结束偏移量，并将该结束偏移量作为历史偏移量存入临时存储单元中，以该历史偏移量作为下一个业务日志的首个分片数据的初始偏移量。本发明实施例通过同时读取偏移量的方式读取分片数据，以保证分片数据之间的连续性。
本发明实施例提供的方法中，基于上述S103的内容，在对业务日志内的各个业务数据进行处理的过程中，需要应用监控指标对各个业务数据进行数据清洗。其中，所述基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据的过程如图3所示，具体可以包括：
S301：获取所述监控指标中已设定的标准业务请求来源以及标准业务请求目的。
本发明中，标准业务请求来源和标准业务请求目的可以是用户按照实际工作条件进行设置。
例如，若设定标准业务请求来源的为仅处理系统A的业务，则在对业务 数据进行过滤时，过滤除业务请求来源是系统A之外的其他系统的业务数据。若设定标准业务请求来源为仅处理出系统A之外的所有系统的业务，则对业务数据进行过滤时，仅过滤业务请求来源为系统A的业务数据。
S302：对于每个业务数据，判断所述业务数据的业务请求来源及业务请求目的，是否符合所述标准业务请求来源及标准业务请求目的；若是，则执行S303；若否，则执行S304。
在本发明中，对于每个分片数据中的每个业务数据，均执行S302的过程。
S303：确定所述分片数据中的各个业务数据均为有效业务数据。
S304：确定所述业务数据为无效业务数据，并执行S305。
S305：去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据。
本发明实施例提供的业务日志监控方法中，监控指标中已设定标准请求来源以及标准业务请求目的，将每个分片数据中的每个业务数据的业务请求来源与标准业务请求来源进行匹配，以及将每个业务数据的业务请求目的与标准业务请求目的进行匹配。若业务数据的业务请求来源符合标准业务请求来源，且业务数据的业务请求目的符合标准业务请求目的，则该业务数据为有效业务数据。反之，若业务数据的业务请求来源不符合标准业务请求来源，或业务数据的业务请求目的不符合标准业务请求目的，则该业务数据为无效的业务数据。在确定每个分片数据中的各个无效的业务数据后，将所有无效的业务数据进行删除。
可选的，上述S301至S305的过程可以作为对无效的业务数据进行过滤的一种设定条件，对业务数据进行过滤的监控指标除了标准业务请求来源以及标准业务请求目的之外，还可以根据具体的应用环境设置对应的过滤条件，此处将不做限定。
本发明实施例提供的方法中，基于上述S104的内容，所述基于每个所述有效业务数据的业务请求来源以及业务请求目的，确定所述业务日志中各个有效业务数据之间的调用关系，具体可以包括：
对于所述业务日志中每个所述有效业务数据，确定所述有效业务数据的业务请求目的为目标业务请求目的；在所述业务日志中，查找业务请求来源与所 述目标业务请求目的一致的所有有效业务数据，并将所述目标业务请求目的与其一致的各个业务请求来源进行关联，形成所述目标业务请求目的对应的有效业务数据与其他已关联的有效业务数据之间的调用关系。
可以理解的是，基于每个有效业务数据的业务请求来源和业务请求目的，确定各个有效业务数据之间的调用关系，对于一个业务数据，在查找与该业务数据存在调用关系的其他业务数据的过程中，可以根据该业务数据业务请求目的查找与该业务数据存在调用关系的其他业务数据。例如，有效业务数据A的业务请求目的为目标业务请求目的，在业务日志中查找业务请求来源与该目标业务请求目的一致的有效业务数据B，以此将该有效业务数据A的目标业务请求目的与该有效业务数据B的业务请求来源关联，确定有效业务数据A与有效业务数据B之间的调用关系为有效业务数据A调用有效业务数据B。
参考图4，以上述有效业务数据A和有效业务数据B为例，有效业务数据A的一组调用信息为：请求的来源业务为MCSS_AVE_NEW，请求的目的业务为AVE_TODE2_C。有效业务数据B的一组调用信息为：请求的来源业务为AVE_TODE2_C，请求的目的业务为SEA。因此，两个有效业务数据之间的调用关系为：MCSS_AVE_NEW-->AVE_TODE2_C-->SEA-->AVE_TODE2_C-->MCSS_AVE_NEW。图4为该调用关系的关系图。
进一步地，在每个分片数据中还可以包括每个分片数据对应的冗余数据，每个分片数据对应的冗余数据用于存储除该分片数据中的各个业务数据之外的其他业务数据。在确定各个有效业务数据之间的调用关系时，可以通过结合冗余数据实现业务日志中上下文的匹配过程。
需要说明的是，若获取到各个分片数据及其对应的冗余数据后，可以将分片数据及各个冗余数据临时存放在Spark集群的内部缓存中。
应用本发明实施例提供的方法，通过确定业务日志中各个业务数据之间的调用关系，以确定在各个业务数据之间对应的业务请求的请求成功率以及响应时间，以此判定业务日志是否为异常。
在本发明中，在确定各个有效业务数据之间的调用关系并获得回环数据后，具体还可以包括：
基于所述回环数据，生成各个所述有效业务数据对应的调用链；
在预先设置的展示界面上展示所述调用链，所述调用链包含多个节点，各个所述节点与各个所述有效业务节点一一对应。
可以理解的，将回环数据转换成调用链的形式进行展示，用户可以通过展示界面读取各个业务数据间的调用关系和业务监控指标值，该展示界面以固定的时间间隔刷新进行，准确展示业务数据的运行调用情况。
参考图5，基于上述各个实施例提供的方法，本发明提供了一种业务日志监控系统，用以实现上述的各个过程。其中，业务日志监控系统包括：
业务日志采集组件501，用于在应用服务器上部署采集程序，获取标准格式的业务日志。该组件为部署在各个业务应用服务器上的单独进程，监控应用服务器上的业务日志变化，按照预先配置的业务规则，从应用服务器上采集标准格式的业务日志，并存入消息队列。其中，该业务日志采集组件为上述S101中的日志采集组件。
业务日志分析组件502包括消息管理器、业务逻辑器和临时存储器。其中消息管理单元内部署上基于原生Hadoop或者CDH平台的Spark环境。其中，消息管理器用于管理消息队列并读取消息队列中的分片数据和偏移量，将本次读取的分片数据对应的数据偏移量作为下一次读取的开始位置。业务逻辑器，用于在消费到分片数据后，根据监控指标去除无效的数据，并按照规则对各个有效业务数据进行分析处理，梳理各个有效业务数据间的调用关系形成回环数据，并分析回环数据的业务核心指标。分析处理后的结果统一存入临时存储器。临时存储器中的数据供业务关系展示组件503和业务监控报警组件504实时调用。
业务关系展示组件503，用于实时从业务日志分析组件502的临时存储器，读取各个业务数据间的调用关系和业务核心指标，以固定的时间间隔刷新页面展示。将业务日志的运行调用情况，准确的展示在自主开发的页面大屏上。
业务监控报警组件504，用于根据业务监控规则，实时从业务日志分析组件502的临时存储器监控业务日志的分析结果，对结果进行汇总计算，判断计算结果是否满足业务监控规则。如果满足预设业务监控规则规则，则调用外部报警接口进行报警。
上述各个实施例的具体实施过程及其衍生方式，均在本发明的保护范围之 内。
与图1所述的方法相对应，本发明实施例还提供了一种业务日志监控装置，用于对图1中方法的具体实现，本发明实施例提供的业务日志监控装置可以应用计算机终端或各种移动设备中，其结构示意图如图6所示，具体包括：
分片单元601，用于当检测到预先设置的业务采集组件向预先设置的消息队列上传业务日志时，对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对应的各个分片数据；所述业务日志中包含多个业务数据，每个所述分片数据包含至少一个业务数据；
识别单元602，用于读取每个所述分片数据中每个业务数据的交易ID，并基于每个所述业务数据的交易ID，识别每个所述业务数据的业务请求来源以及业务请求目的；
处理单元603，用于基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据；
确定单元604，用于基于每个所述有效业务数据的业务请求来源以及业务请求目的，确定所述业务日志中各个有效业务数据之间的调用关系，并基于所述各个所述有效业务数据之间的调用关系，生成所述业务日志对应的回环数据；
分析单元605，用于分析所述回环数据，获得所述业务日志对应的业务核心指标；
判断单元606，用于基于所述业务核心指标，判断所述业务日志是否符合预设的业务日志监控规则；
报警单元607，用于若所述业务日志不符合所述业务监控规则，则对所述业务日志进行报警处理。
本发明实施例提供的业务日志监控装置中，在检测到业务采集组件向消息队列上传业务日志时，对业务日志进行分片处理后从该消息队列中获取该业务日志对应的各个分片数据。由于业务日志中包含多个业务数据，对业务日志进行分片处理后，每个分片数据中包含至少一个业务数据。读取每个业务数据的 交易ID，并通过交易ID识别业务数据的业务请求来源以及业务请求目的，再根据监控指标去除各个业务数据中的无效业务数据，获得各个有效业务数据。应用每个有效业务数据的业务请求来源以及业务请求目的，确定每个有效业务数据之间的调用关系，形成该业务日志对应的回环数据。分析该回环数据，判断该业务日志是否符合业务日志监控规则，若不符合则进行报警处理。
应用本发明实施例提供的装置，可以对应用服务器中每次新增的业务日志进行分析和处理，及时发现发现应用服务器发现异常的业务日志。
本发明实施例提供的装置中，所述分片单元601，包括：
识别子单元，用于识别所述消息队列中已设定的各个读取通道；
第一处理子单元，用于确定所述消息队列中各个所述读取通道的个数，并以各个所述读取通道的个数作为分片的个数，对所述业务日志中进行分片处理，获得所述业务日志对应的各个分片数据；其中，每个所述读取通道对应一个分片数据；
读取子单元，用于经由所述消息队列中的各个读取通道，读取每个所述读取通道对应的分片数据。
本发明实施例提供的装置中，所述处理单元603，包括：
获取子单元，用于获取所述监控指标中已设定的标准业务请求来源以及标准业务请求目的；
第二处理子单元，用于对于每个所述分片数据中的每个业务数据，判断所述业务数据的业务请求来源及业务请求目的，是否符合所述标准业务请求来源及标准业务请求目的；若所述业务数据的业务请求来源及业务请求目的，符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为有效业务数据；若存在任意的业务数据的请求来源及业务请求目的，不符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为无效业务数据；
过滤子单元，用于去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据。
本发明实施例提供的装置中，所述确定单元604，包括：
确定子单元，用于对于所述业务日志中每个所述有效业务数据，确定所述有效业务数据的业务请求目的为目标业务请求目的；在所述业务日志中，查找 业务请求来源与所述目标业务请求目的一致的所有有效业务数据，并将所述目标业务请求目的与其一致的各个业务请求来源进行关联，形成所述目标业务请求目的对应的有效业务数据与其他已关联的有效业务数据之间的调用关系。
本发明实施例提供的装置中，还包括：
展示单元，用于基于所述回环数据，生成各个所述有效业务数据对应的调用链；在预先设置的展示界面上展示所述调用链，所述调用链包含多个节点，各个所述节点与各个所述有效业务节点一一对应。
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。
以上本发明实施例公开的业务日志监控装置中各个单元及子单元的具体工作过程，可参见本发明上述实施例公开的业务日志监控方法中的对应内容，这里不再进行赘述。
本申请实施例中，该电子设备可以为服务器。
如图7所示，电子设备可以包括处理装置(例如中央处理器、图形处理器等)701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储装置708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM703中，还存储有电子设备操作所需的各种程序和数据。处理装置701、ROM702以及RAM703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。
通常，以下装置可以连接至I/O接口705：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置706；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置707；包括例如磁带、硬盘等的存储装置708；以及通信装置709。通信装置709可以允许电子设备与其他设备进行无线或有线通信以交换数据。虽然图7示出了具有各种装置的电子设备，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。
进一步的，本申请实施例还提供一种存储介质，该存储介质中存储有计算机可执行指令，该计算机可执行指令用于执行上述航班销售控制方法。
上述存储介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：当检测到预先设置的业务采集组件向预先设置的消息队列上传业务日志时，对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对应的各个分片数据；所述业务日志中包含多个业务数据，每个所述分片数据包含至少一个业务数据；读取每个所述分片数据中每个业务数据的交易ID，并基于每个所述业务数据的交易ID，识别每个所述业务数据的业务请求来源以及业务请求目的；基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据；基于每个所述有效业务数据的业务请求来源以及业务请求目的，确定所述业务日志中各个有效业务数据之间的调用关系，并基于所述各个所述有效业务数据之间的调用关系，生成所述业务日志对应的回环数据；分析所述回环数据，获得所述业务日志对应的业务核心指标；基于所述业务核心指标，判断所述业务日志是否符合预设的业务日志监控规则；若所述业务日志不符合所述业务监控规则，则对所述业务日志进行报警处理。
尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。
虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本发明公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。
以上描述仅为本发明公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本发明公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况 下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本发明公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现。
为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (10)
- 一种业务日志监控方法，其特征在于，包括：当检测到预先设置的业务采集组件向预先设置的消息队列上传业务日志时，对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对应的各个分片数据；所述业务日志中包含多个业务数据，每个所述分片数据包含至少一个业务数据；读取每个所述分片数据中每个业务数据的交易ID，并基于每个所述业务数据的交易ID，识别每个所述业务数据的业务请求来源以及业务请求目的；基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据；基于每个所述有效业务数据的业务请求来源以及业务请求目的，确定所述业务日志中各个有效业务数据之间的调用关系，并基于所述各个所述有效业务数据之间的调用关系，生成所述业务日志对应的回环数据；分析所述回环数据，获得所述业务日志对应的业务核心指标；基于所述业务核心指标，判断所述业务日志是否符合预设的业务日志监控规则；若所述业务日志不符合所述业务监控规则，则对所述业务日志进行报警处理。
- 根据权利要求1所述的方法，其特征在于，所述对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对应的各个分片数据，包括：识别所述消息队列中已设定的各个读取通道；确定所述消息队列中各个所述读取通道的个数，并以各个所述读取通道的个数作为分片的个数，对所述业务日志中进行分片处理，获得所述业务日志对应的各个分片数据；其中，每个所述读取通道对应一个分片数据；经由所述消息队列中的各个读取通道，读取每个所述读取通道对应的分片数据。
- 根据权利要求1所述的方法，其特征在于，所述基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所 述分片数据中各个无效的业务数据，获得各个有效业务数据，包括：获取所述监控指标中已设定的标准业务请求来源以及标准业务请求目的；对于每个所述分片数据中的每个业务数据，判断所述业务数据的业务请求来源及业务请求目的，是否符合所述标准业务请求来源及标准业务请求目的；若所述业务数据的业务请求来源及业务请求目的，符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为有效业务数据；若存在任意的业务数据的请求来源及业务请求目的，不符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为无效业务数据；去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据。
- 根据权利要求1所述的方法，其特征在于，所述基于每个所述有效业务数据的业务请求来源以及业务请求目的，确定所述业务日志中各个有效业务数据之间的调用关系，包括：对于所述业务日志中每个所述有效业务数据，确定所述有效业务数据的业务请求目的为目标业务请求目的；在所述业务日志中，查找业务请求来源与所述目标业务请求目的一致的所有有效业务数据，并将所述目标业务请求目的与其一致的各个业务请求来源进行关联，形成所述目标业务请求目的对应的有效业务数据与其他已关联的有效业务数据之间的调用关系。
- 根据权利要求1所述的方法，其特征在于，还包括：基于所述回环数据，生成各个所述有效业务数据对应的调用链；在预先设置的展示界面上展示所述调用链，所述调用链包含多个节点，各个所述节点与各个所述有效业务节点一一对应。
- 一种业务日志监控装置，其特征在于，包括：分片单元，用于当检测到预先设置的业务采集组件向预先设置的消息队列上传业务日志时，对所述业务日志进行分片处理，以从所述消息队列中获取所述业务日志对应的各个分片数据；所述业务日志中包含多个业务数据，每个所述分片数据包含至少一个业务数据；识别单元，用于读取每个所述分片数据中每个业务数据的交易ID，并基于每个所述业务数据的交易ID，识别每个所述业务数据的业务请求来源以及业务请求目的；处理单元，用于基于预先设置的监控指标，对所述每个所述分片数据中的各个业务数据进行数据清洗，去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据；确定单元，用于基于每个所述有效业务数据的业务请求来源以及业务请求目的，确定所述业务日志中各个有效业务数据之间的调用关系，并基于所述各个所述有效业务数据之间的调用关系，生成所述业务日志对应的回环数据；分析单元，用于分析所述回环数据，获得所述业务日志对应的业务核心指标；判断单元，用于基于所述业务核心指标，判断所述业务日志是否符合预设的业务日志监控规则；报警单元，用于若所述业务日志不符合所述业务监控规则，则对所述业务日志进行报警处理。
- 根据权利要求6所述的装置，其特征在于，所述分片单元，包括：识别子单元，用于识别所述消息队列中已设定的各个读取通道；第一处理子单元，用于确定所述消息队列中各个所述读取通道的个数，并以各个所述读取通道的个数作为分片的个数，对所述业务日志中进行分片处理，获得所述业务日志对应的各个分片数据；其中，每个所述读取通道对应一个分片数据；读取子单元，用于经由所述消息队列中的各个读取通道，读取每个所述读取通道对应的分片数据。
- 根据权利要求6所述的装置，其特征在于，所述处理单元，包括：获取子单元，用于获取所述监控指标中已设定的标准业务请求来源以及标准业务请求目的；第二处理子单元，用于对于每个所述分片数据中的每个业务数据，判断所述业务数据的业务请求来源及业务请求目的，是否符合所述标准业务请求来源及标准业务请求目的；若所述业务数据的业务请求来源及业务请求目的，符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为有效业务数据；若存在任意的业务数据的请求来源及业务请求目的，不符合所述标准业务请求来源及标准业务请求目的，则确定所述业务数据为无效业务数据；过滤子单元，用于去除每个所述分片数据中各个无效的业务数据，获得各个有效业务数据。
- 一种存储介质，其特征在于，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求1-5任意一项所述的业务日志监控方法。
- 一种电子设备，所述电子设备包括：至少一个存储器和至少一个处理器；所述存储器存储有程序，所述处理器调用所述存储器存储的程序，所述程序用于实现如权利要求1-5任意一项所述的业务日志监控方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110741707.8A CN113485891A (zh) | 2021-06-30 | 2021-06-30 | 业务日志监控方法、装置、存储介质及电子设备 |
| CN202110741707.8 | 2021-06-30 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2023273529A1 true WO2023273529A1 (zh) | 2023-01-05 |
Family
ID=77937310
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2022/087631 WO2023273529A1 (zh) | 2021-06-30 | 2022-04-19 | 业务日志监控方法、装置、存储介质及电子设备 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN113485891A (zh) |
| WO (1) | WO2023273529A1 (zh) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113485891A (zh) * | 2021-06-30 | 2021-10-08 | 中国民航信息网络股份有限公司 | 业务日志监控方法、装置、存储介质及电子设备 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012088857A (ja) * | 2010-10-18 | 2012-05-10 | Nec Corp | ログ情報収集システム、ログ情報収集方法、及びログ情報収集プログラム |
| CN107612740A (zh) * | 2017-09-30 | 2018-01-19 | 武汉光谷信息技术股份有限公司 | 一种分布式环境下的日志监控系统及方法 |
| CN110442641A (zh) * | 2019-08-06 | 2019-11-12 | 中国工商银行股份有限公司 | 一种链路拓扑图展示方法、装置、存储介质及设备 |
| CN111782621A (zh) * | 2020-06-30 | 2020-10-16 | 中国民航信息网络股份有限公司 | 一种业务应用日志处理方法及装置 |
| CN112416708A (zh) * | 2020-11-17 | 2021-02-26 | 中国工商银行股份有限公司 | 异步调用链路监控方法及系统 |
| CN113485891A (zh) * | 2021-06-30 | 2021-10-08 | 中国民航信息网络股份有限公司 | 业务日志监控方法、装置、存储介质及电子设备 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107992398B (zh) * | 2017-12-22 | 2021-04-27 | 宜人恒业科技发展（北京）有限公司 | 一种业务系统的监控方法和监控系统 |
| CN109327353B (zh) * | 2018-09-29 | 2022-01-11 | 创新先进技术有限公司 | 业务流量确定方法、装置及电子设备 |
| CN110245035A (zh) * | 2019-05-20 | 2019-09-17 | 平安普惠企业管理有限公司 | 一种链路跟踪方法及装置 |
| CN110297738A (zh) * | 2019-05-21 | 2019-10-01 | 深圳壹账通智能科技有限公司 | 系统服务的监控方法、装置、设备及存储介质 |
| CN110333983A (zh) * | 2019-05-31 | 2019-10-15 | 口口相传(北京)网络技术有限公司 | 业务监控及搜索业务监控方法及装置 |
-
2021
- 2021-06-30 CN CN202110741707.8A patent/CN113485891A/zh active Pending
-
2022
- 2022-04-19 WO PCT/CN2022/087631 patent/WO2023273529A1/zh active Application Filing
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012088857A (ja) * | 2010-10-18 | 2012-05-10 | Nec Corp | ログ情報収集システム、ログ情報収集方法、及びログ情報収集プログラム |
| CN107612740A (zh) * | 2017-09-30 | 2018-01-19 | 武汉光谷信息技术股份有限公司 | 一种分布式环境下的日志监控系统及方法 |
| CN110442641A (zh) * | 2019-08-06 | 2019-11-12 | 中国工商银行股份有限公司 | 一种链路拓扑图展示方法、装置、存储介质及设备 |
| CN111782621A (zh) * | 2020-06-30 | 2020-10-16 | 中国民航信息网络股份有限公司 | 一种业务应用日志处理方法及装置 |
| CN112416708A (zh) * | 2020-11-17 | 2021-02-26 | 中国工商银行股份有限公司 | 异步调用链路监控方法及系统 |
| CN113485891A (zh) * | 2021-06-30 | 2021-10-08 | 中国民航信息网络股份有限公司 | 业务日志监控方法、装置、存储介质及电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113485891A (zh) | 2021-10-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11789943B1 (en) | Configuring alerts for tags associated with high-latency and error spans for instrumented software | |
| EP4099170B1 (en) | Method and apparatus of auditing log, electronic device, and medium | |
| US9665420B2 (en) | Causal engine and correlation engine based log analyzer | |
| WO2021129367A1 (zh) | 一种监控分布式存储系统的方法及装置 | |
| WO2019133763A1 (en) | System and method of application discovery | |
| US12001275B2 (en) | Data processing method, apparatus, database system, electronic device, and storage medium | |
| CN109379390B (zh) | 一种基于全流量的网络安全基线生成方法 | |
| CN112351024B (zh) | 一种公网通信安全监测系统及方法 | |
| CN111258847B (zh) | 一种文件句柄监控及分析方法、装置、介质和设备 | |
| WO2020015092A1 (zh) | 实例监控方法、装置、终端设备及介质 | |
| CN111162950A (zh) | 故障事件处理方法、装置及系统 | |
| CN112306700A (zh) | 一种异常rpc请求的诊断方法和装置 | |
| CN111400361A (zh) | 数据实时存储方法、装置、计算机设备和存储介质 | |
| WO2023273529A1 (zh) | 业务日志监控方法、装置、存储介质及电子设备 | |
| US10775751B2 (en) | Automatic generation of regular expression based on log line data | |
| CN109831358A (zh) | 一种客户端流量统计方法、装置、服务器及可读存储介质 | |
| US10915510B2 (en) | Method and apparatus of collecting and reporting database application incompatibilities | |
| WO2022237506A1 (zh) | 在线问诊业务监控方法、装置、设备及存储介质 | |
| CN107885634B (zh) | 监控中异常信息的处理方法和装置 | |
| US20230344840A1 (en) | Method, apparatus, system, and non-transitory computer readable medium for identifying and prioritizing network security events | |
| WO2021097713A1 (zh) | 分布式安全检测系统、方法、设备及存储介质 | |
| WO2023134285A1 (zh) | 风险管理方法和风险管理装置 | |
| CN115941441A (zh) | 系统链路自动化监控运维方法、系统、设备以及介质 | |
| CN114625763A (zh) | 用于数据库的信息分析方法、装置、电子设备和可读介质 | |
| CN109542662B (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: 22831360 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: 22831360 Country of ref document: EP Kind code of ref document: A1 |