Data outgoing verification method and system, electronic equipment and storage medium

Abstract

The invention provides a data outgoing verification method and system, electronic equipment and a storage medium, and the method comprises the steps: obtaining a standard test message which is a preset format test data packet corresponding to a log type; sending the standard test message to the tested system to enable the tested system to analyze the standard test message and generate log data; verifying a tested system and a first verification item of the standard test message for the first time to generate an initial verification result; under the condition that the initial verification result is successful, sending the log data to an outgoing server through the tested system; and verifying a second verification item of the log data of the outgoing server and the tested system to generate a verification result. According to the method, through automatic verification and three-party cooperative verification, the problems of low verification accuracy and long time consumption are solved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method, system, electronic device and storage medium for verifying data outbound transmission. Background Art

[0002] In the communications testing area, full-flow products are configured with a data export module, which sends system-generated log data to an external server via a Kafka or Syslog client. This log data includes dozens of categories, and supports two standardized export formats: JSON and CSV. To simulate a real-world network environment, the test system must access actual, continuously generated office network egress traffic, resulting in random timing and uncontrollable log generation.

[0003] The test of the data outbound module is conducted manually, configuring outbound parameters for each type of log one by one. The test relies on real traffic to passively trigger log generation, and cannot actively control the test progress. The log generation status of the tested system is manually queried, and the Kafka / Syslog server is logged in to sample and check the data reception status. The test results are manually compiled and lack a standardized report generation mechanism.

[0004] However, it is impossible to systematically verify the field consistency, format compliance, and number matching of outgoing logs. Dozens of log types need to be manually configured and verified one by one, making it difficult to cover all test scenarios. Random traffic causes some log types to not be triggered, and manual sampling inspections are prone to missing abnormal data, resulting in low verification accuracy and long time consumption. Summary of the Invention

[0005] The present application provides a data outbound verification method, system, electronic device and storage medium to solve the problems of low verification accuracy and long verification time.

[0006] In a first aspect, the present application provides a method for verifying data outbound transmission, comprising:

[0007] Obtain a standard test message, which is a test data packet in a preset format corresponding to the log type;

[0008] Sending the standard test message to the system under test, so that the system under test parses the standard test message and generates log data;

[0009] Verifying the system under test and a first verification item of the standard test message to generate an initial verification result;

[0010] If the initial verification result is successful, sending the log data to an outbound server through the system under test;

[0011] Verify the second verification item of the log data of the outgoing server and the system under test to generate a verification result.

[0012] The beneficial effects of this embodiment are:

[0013] In some feasible embodiments, obtaining a standard test message includes:

[0014] Loading a message storage queue of a test directory based on a configuration loader, wherein the test directory is a logical partition for storing test data packets in a preset format;

[0015] Acquire a test mode, where the test mode includes a first test mode and a second test mode;

[0016] Parsing the message to be tested in the message storage queue based on the test mode to generate a parsing result, the parsing result including a message name and a message content;

[0017] When the message name and the message content are verified to be successful, a standard test message is obtained, where the standard test message is the message to be tested.

[0018] The beneficial effects of this embodiment are: managing test messages of different log types through test directory classification, combining sequential or batch test modes, ensuring strict matching of test cases and log types, and reducing manual configuration errors.

[0019] In some feasible embodiments, sending the standard test message to the system under test includes:

[0020] According to the message content of the standard test message, calling the outbound configuration interface of the system under test to load outbound parameters, the outbound parameters including the server address, log type and format identifier;

[0021] The message sending tool is triggered to send the standard test message to the traffic collection port so that the system under test receives the test message through the traffic collection port. The message sending tool performs data packet transmission through a timestamp replay mechanism.

[0022] The beneficial effects of this embodiment are: automatically switching the outgoing server configuration according to the message type, simulating the real traffic timing to send messages, and solving the problem of outgoing parameters being out of sync with the environment.

[0023] In some feasible embodiments, the sending of the standard test message to the system under test so as to enable the system under test to parse the standard test message may then include:

[0024] Calling the log query interface of the system under test to enable the log query interface to query log data and generate a log generation result;

[0025] If the log data is not obtained, the log query interface is called again at a preset interval and the number of log acquisitions is recorded;

[0026] When the acquisition times reaches the acquisition threshold and no log data is acquired, a log generation failure result is generated.

[0027] The beneficial effect of this embodiment is that, for scenarios with delayed log generation or asynchronous processing, multiple queries and delayed waiting are performed to reduce misjudgments caused by timing differences.

[0028] In some feasible embodiments, after sending the standard test message to the system under test so that the system under test parses the standard test message and generates log data, the method further includes:

[0029] When the log data is obtained, or when the query number reaches a query threshold and the log data is obtained, obtaining a first query result, where the first query result is a first log data query result returned by the outgoing server, and the outgoing server includes a first server and a second server;

[0030] If the first query result is a failure, obtain a second query result and record the number of log queries, where the second query result is a second log data query result returned by the outgoing server after a preset delay time of the first query result;

[0031] If the number of log queries reaches the query threshold and the log data is not found, a log reception failure result is generated;

[0032] When the first query result is successful, or when the number of log queries reaches a query threshold and the log data is found, a log reception success result is generated.

[0033] The beneficial effects of this embodiment are: performing independent verification on the sending server, supporting cross-server log data consistency comparison, and identifying data non-reception problems caused by network fluctuations or configuration errors.

[0034] In some feasible embodiments, the test data packet includes a unique identifier, the unique identifier includes four-tuple data, message name, message content, message content and number of log entries, and the four-tuple data includes source IP, destination IP, source port and destination port;

[0035] The first verification item of verifying the system under test and the standard test message to generate an initial verification result includes:

[0036] When the system under test generates log data, obtaining a first verification item of the log data, the first verification item including four-tuple data, message name, message content, message content, and number of log entries;

[0037] Verifying the four-tuple data of the system under test and the four-tuple data of the standard test message;

[0038] If the four-tuple data verification passes, verify the message name and message content of the log data with the message name and message content of the standard test message;

[0039] When the message name and the message content are verified to be successful, an initial verification result indicating successful verification is generated.

[0040] The beneficial effects of this embodiment are: through unique identifiers such as quadruple and message content code, the consistency of log data and original message is verified step by step, and specific problems such as tampering, field missing or protocol parsing abnormalities are located.

[0041] In some feasible embodiments, the outgoing server includes a first server and a second server, and the second verification item includes log content and the number of log entries;

[0042] The second verification item of verifying the log data of the outgoing server and the system under test to generate a verification result includes:

[0043] If the initial verification result is successful, sending the log data to the first server and / or the second server through the device under test;

[0044] Verifying the second verification item and data format of the first server and / or the second server;

[0045] When the second verification item is consistent with the second verification item of the log data on the system under test, and the data format is consistent with the data format of the target configuration, a verification result is generated. The target configuration is the configuration corresponding to the outgoing server loaded by the configuration loader, and the verification result indicates that the verification is successful.

[0046] The beneficial effects of this embodiment are: supporting syntax and field verification of log formats such as JSON and Syslog, ensuring that the format of outgoing data matches the requirements of the target server, and avoiding storage failures due to format errors.

[0047] In a second aspect, the present application provides a data outbound verification system, comprising:

[0048] An acquisition module is used to acquire a standard test message, where the standard test message is a test data packet in a preset format corresponding to a log type;

[0049] A management module is used to send the standard test message to the system under test so that the system under test parses the standard test message and generates log data; verify the first verification item of the system under test and the standard test message to generate an initial verification result; if the initial verification result is successful, send the log data to an external server through the system under test; verify the second verification item of the log data of the external server and the system under test to generate a verification result.

[0050] In a third aspect, the present application provides an electronic device, the device comprising a processor and a memory:

[0051] The memory is used to store program code and transmit the program code to the processor;

[0052] The processor is used to execute the data outbound verification method according to the instructions in the program code.

[0053] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store program code, and the program code is used to execute the data outbound verification method.

[0054] As can be seen from the above technical solutions, the present application provides a data outbound verification method, system, electronic device and storage medium, the method comprising: obtaining a standard test message, wherein the standard test message is a test data packet in a preset format corresponding to a log type; sending the standard test message to the system under test to enable the system under test to parse the standard test message and generate log data; first verifying the first verification item of the system under test and the standard test message to generate an initial verification result; if the initial verification result is successful, sending the log data to an outbound server through the system under test; and then verifying the second verification item of the outbound server and the log data of the system under test to generate a verification result. The method solves the problem of low verification accuracy and long time consumption through automated verification and three-party collaborative verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the technical solution of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0056] Figure 1 A flowchart of a method for verifying data outbound transmission provided in an embodiment of the present application;

[0057] Figure 2A schematic diagram of a scenario for a data outbound verification method provided in an embodiment of the present application;

[0058] Figure 3 A schematic diagram of the process of sending a standard test message to a collection port provided in an embodiment of the present application;

[0059] Figure 4 A schematic diagram of the process of receiving log data provided in an embodiment of the present application;

[0060] Figure 5 A schematic diagram of the Kafka configuration provided in this application embodiment;

[0061] Figure 6 This is a diagram of the Syslog configuration provided in this application embodiment. DETAILED DESCRIPTION

[0062] The following embodiments are described in detail, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numbers in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following embodiments are not intended to represent all possible implementations consistent with the present application. They are merely examples of systems and methods consistent with certain aspects of the present application, as detailed in the claims.

[0063] To address the random timing and uncontrollable quantity of log generation, some embodiments use a predefined log format rule base, such as JSON Schema or regular expressions, to automatically check compliance of outgoing log content. However, this approach fails to verify the consistency of log generation logic with message parsing, for example, to detect protocol header tampering. Furthermore, rule maintenance is costly and difficult to cover the dynamic combination of 34 log types.

[0064] You can also mirror production traffic to a test system and compare the differences in outbound logs between the tested system and the production system. However, relying on the authenticity of production traffic makes it impossible to construct abnormal test cases, such as malicious attack packets. Furthermore, mirrored traffic may contain sensitive data, violating compliance requirements.

[0065] In other embodiments, scripting tools, such as Postman and JMeter, are used to write scripts to simulate log generation and verify outbound results. However, these tools have poor adaptability. For example, they do not support the industrial control protocol Modbus, requiring custom plug-ins to be developed, and are difficult to integrate into multi-server collaborative testing processes.

[0066] To solve the above problems, some embodiments of the present application provide a method for verifying outbound data. This embodiment actively triggers log generation through standard test messages, instead of passively waiting for real traffic; through verification of the first verification item and the second verification item, it ensures that the outbound data is consistent with the original message; automatically executes configuration loading, message sending, and result verification, reducing manual operations.

[0067] like Figure 1 、 Figure 2 As shown, the method includes the following steps:

[0068] S100: Obtain a standard test message.

[0069] Standard test packets are pre-formatted test packets based on the log type, used to simulate real network traffic. They include a log type identifier, a pre-formatted format, and a unique identifier.

[0070] The log type identifier uniquely identifies the log category, for example, operation audit log, protocol log, security log, industrial control log, alarm log, and backtracking log. It is defined by the file name suffix, for example, audit.pcap indicates an audit log.

[0071] The preset format is a data format defined based on the log type. For example, the JSON format includes the timestamp, event_type, and user_id fields. Another example is the CSV format, which includes the src_ip, dst_ip, and protocol fields.

[0072] Each message is uniquely identified by a four-tuple consisting of the source IP address, destination IP address, source port number, destination port number, and message name. For example, syslog_001.pcap. Messages of different log types are distinguished by the four-tuple. For example, the source ports for operation audit logs and protocol logs are different: 443 and 12345.

[0073] The management PC loads a pre-generated .pcap file queue, which is a standard test message. Each file is identified by the file name, such as syslog.pcap, which indicates a system log, and is associated with preset quadruple groups and protocol features.

[0074] First, the configuration loader is called to load the message storage queue for the test directory. The test directory is a logical partition for storing test messages. The file structure is categorized by log type. The management PC uploads all log messages to be tested, namely, pcap data packet files, to a designated directory on the data packet sending device. For example, / home / kafka_test stores test messages to be sent via Kafka; / home / syslog_test stores test messages to be sent via Syslog. Each subdirectory contains pre-generated .pcap files and corresponding mapping tables.

[0075] The mapping table is a predefined rule table that stores the association rules between message names and message content. For example, the content corresponding to the message name audit.pcap must include the operation_type and user_id fields; the content corresponding to the message name protocol.pcap must include the src_port and dst_port fields. The mapping table is stored in JSON format in the config / mapping_table.json file on the management PC.

[0076] The message storage queue is a list of test messages generated by the management PC according to the test mode. Its data structure includes a sequential mode queue and a batch mode queue. The sequential mode queue is a linked list arranged in file name order, for example, [syslog1.pcap,syslog2.pcap,...]. The batch mode queue contains a collection of all messages, which are loaded at once using the wildcard *.pcap.

[0077] Then, a test mode is acquired, where the test mode includes a first test mode and a second test mode. The first test mode is a sequential test, and the second test mode is a batch test.

[0078] The management PC schedules the sending order based on the selected test mode. Sequential test mode sends test messages one by one in the order of the message storage queue, suitable for log type verification scenarios. Batch test mode sends all test messages in the queue at once, suitable for full-scale stress testing scenarios. Exemplarily, the test mode is selected through the management PC's configuration file or user interface. For example, entering --mode=sequential in the command line indicates sequential mode.

[0079] When sending, you can choose whether to send test messages in queue order or send all test messages at once according to the test scenario. Sending tests in sequence can avoid sending one type of logs and causing data accuracy interference to other logs, and can verify data accuracy. If you are only testing the function and do not want to verify accuracy, you can send all test messages at once.

[0080] Parsing the messages to be tested in the message storage queue is performed based on the test mode to generate a parsing result.

[0081] The management PC calls the message parsing program to parse the message name and message content of each message to be tested in the queue and generate a parsing result. The parsing result is structured data output by the message parsing program, including the message name and message content.

[0082] Parsing the message name involves extracting the log type identifier from the file name, for example, audit.pcap identifies the operation audit log; parsing the message content involves reading the four-tuple, protocol field, and signature, for example, checksum = 0x1A2B3C4D.

[0083] If the message name and content verification pass, a standard test message is obtained. After obtaining the parsing results, the mapping between the message name and content in the parsing results is verified, specifically to ensure that the message content and / or message name match the definitions in the mapping table. For example, if the user_id field is missing from audit.pcap, the verification is marked as failed and the message is removed from the queue.

[0084] If the message content and / or message name are consistent with those in the mapping relationship table, the characterization verification passes, and the message to be tested is used as a standard test message.

[0085] Among them, the message to be tested is the unverified original .pcap file in the test directory, which includes the message header and protocol data. The message header is a four-tuple data, namely source IP, destination IP, source port, and destination port; the protocol data includes HTTP header, TCP payload, and log feature field, for example, log_type=security.

[0086] For packets that pass verification, the packets to be tested that pass verification are marked as standard test packets and stored in the / validated_pcaps directory.

[0087] S200: Sending a standard test message to the system under test, so that the system under test parses the standard test message and generates log data.

[0088] The system under test is a network device or server deployed with data outbound function. The system under test includes a traffic collection port, a parsing module and a log generation module. The traffic collection port is a physical or virtual network port used to receive test messages and is directly connected to the sending port of the management PC to ensure that the message transmission path is correct; the parsing module parses the protocol fields of the message, such as the HTTP header and TCP port, and extracts the metadata required for log generation; the log generation module generates structured logs according to the message type. For example, the operation log contains the operation time and operation type fields.

[0089] Exemplarily, the syslog.pcap message triggers the system log generation logic to generate a log entry containing timestamp and message fields.

[0090] Before sending the standard test message to the system under test, the outbound configuration interface of the system under test is called according to the message content of the standard test message to load outbound parameters.

[0091] The outbound configuration interface is an API provided by the system under test, which is used to dynamically load outbound parameters. For example, Figure 5 As shown, the Kafka configuration interface ( / api / kafka_config): receives parameters {"server":"10.0.0.1:9092","topic":"audit_logs"}; for example, Figure 6 As shown, the Syslog configuration interface ( / api / syslog_config): receives parameters {"server":"192.168.1.20:514","protocol":"RFC5424"}.

[0092] The outbound parameters are settings loaded into the system under test through the configuration interface, including the server address, log type, and format identifier. The server address is the Broker list of the Kafka cluster, for example, 10.0.0.1:9092, 10.0.0.2:9092 or the IP and port of the Syslog server; the log type is the outbound log classification, for example, operation audit log, security log; the format identifier is an identifier in JSON or CSV format.

[0093] For example, audit.pcap triggers the loading of Kafka configuration (server address 10.0.0.1:9092, topic audit_logs); for another example, protocol.pcap triggers the loading of Syslog configuration (server address 192.168.1.20:514, protocol version RFC5424).

[0094] Get the outbound server type based on the message name. For example, syslog.pcap corresponds to the Syslog server. Load the outbound parameters through the REST API of the system under test, and then call the outbound switch of the system under test to ensure that the log is automatically pushed to the outbound server after it is generated.

[0095] Then trigger the message sending tool to send the standard test message to the traffic collection port, so that the system under test receives the test message through the traffic collection port.

[0096] A packet sending tool is a software module used to send test packets, such as the tcpreplay tool in Linux. You can specify a specific network port for sending packets, such as specifying the traffic collection port of the system under test using the -i LAN4 parameter. You can also send packets in the order of the original packet's timestamps to simulate real-world traffic timing.

[0097] The timestamp replay mechanism is used to replay packets in the order of their original timestamps. For example, it maintains the timestamps in the packets during transmission. High-precision timing control is achieved through the --timer=accurate parameter of tcpreplay.

[0098] For example, Figure 3 As shown in the figure, the system log message tcpreplay-iLAN4 syslog.pcap is sent. If it is a verification function, all data needs to be sent at once, and the execution script can be modified to (tcpreplay-i LAN4*.pcap). After successful sending, the traffic will reach the traffic collection port through the network cable direct connection port LAN4.

[0099] Due to reasons such as the physical link and message format, the test message may not be correctly sent to the system under test, or the system under test may fail to parse and the system under test may not be able to generate log data. To verify the generation of log data, in some embodiments, the log query interface of the system under test is called to enable the log query interface to query the log data and generate a log generation result.

[0100] The log query interface is an API provided by the system under test. It allows you to query the log generation status. It allows you to retrieve log status and obtain log details. Retrieving log status returns the number of log entries generated within a specified time range, while obtaining log details returns log field data, such as a quadruple or protocol type.

[0101] For example, the interface GET / api / logs?start_time=20231001T120000&end_time=20231001T120500 returns the log list within the time window.

[0102] The log generation result is a data structure returned by the log query interface, which can include the number of log entries and log detail fields. The number of log entries is the number of logs generated by the tested system; the log detail is a set of fields for a single log entry, for example, {"src_ip":"192.168.1.1","protocol":"HTTP"}.

[0103] If no log data is obtained, the log query interface is called again at a preset interval and the number of log acquisitions is recorded. The preset interval is the time interval for waiting for the next query after the first query fails. For example, if it is set to 10 seconds, if no log data is obtained in the first query, the interface will be called again after waiting 10 seconds.

[0104] That is to say, two queries are performed in total. The number of queries and waiting time can be configured in the script. Multiple queries are performed here because it takes time from data log generation to data parsing and storage. This prevents the log from being stored in the database when the program queries, thereby increasing fault tolerance.

[0105] If the acquisition count reaches the acquisition threshold and no log data is obtained, a log generation failure result is generated.

[0106] The number of log acquisitions is the total number of log queries, recorded by a counter. For example, if the acquisition threshold is 2, the query is terminated and a failure result is generated when the threshold is reached.

[0107] Log generation failure results are verification result types generated by the management PC and indicate that the system under test failed to generate logs correctly. The data structure for log generation failure results can include an error code and a failure reason. For example, the error code is ERR_LOG_GEN_FAILED, and the failure reason is, for example, "Two queries failed to obtain log data."

[0108] Exemplarily, the log query interface of the system under test is called to request log data. If the number of log entries returned by the interface is greater than 0, the log generation is determined to be successful and the outbound verification phase is entered; if the number of returned entries is 0, the current query number is recorded as 1, and a preset interval time is waited, for example, 10 seconds; query again, and after the waiting is over, call the log query interface again; if the second query is successful, the number of log entries > 0, and a log generation success result is generated; if the second query still fails, the number of log entries = 0, and the number of queries reaches the acquisition threshold, for example, 2 times, and a log generation failure result is generated.

[0109] Traditional testing methods suffer from high false positive rates due to delayed or asynchronous log generation. For example, if the first query fails, it will be considered an anomaly, and they lack fault tolerance. This embodiment mitigates log generation delays by performing multiple queries, reducing false positives. The number of queries and intervals can be adjusted based on the performance of the system under test, increasing testing flexibility.

[0110] If the log data is generated successfully, the log data is sent to the outgoing server. Due to various reasons, the outgoing server may not receive the log data. To verify whether the outgoing server has received the log data, in some embodiments, when the log data is obtained, or when the query number reaches the query threshold and the log data is obtained, the first query result is obtained.

[0111] The outgoing server includes a first server and a second server. The outgoing server is a remote device that receives log data pushed by the system under test. The first server is a Kafka server. The Kafka server receives structured logs, for example, in JSON format, and stores them in a specified topic, for example, audit_logs; the second server is a Syslog server. The Syslog server receives standardized protocol logs, for example, in RFC 5424 format, and stores them in a specified log file, for example, / var / log / syslog.

[0112] It is understandable that when log data is obtained, or when the number of queries reaches the query log and log data is obtained, the log data may be sent to the first server and / or the second server.

[0113] like Figure 4 As shown, the first query result is the first log data query result returned by the outgoing server, wherein the first query result can be the first log data query result returned by the first server, or the first log data query result returned by the second server, or two first log data query results returned by the first server and the second server respectively.

[0114] The first query result is the log reception status obtained by querying the outgoing server for the first time. The data structure of the first query result includes the reception status, the number of log entries, and the timestamp range. The reception status can be success or failure, the number of log entries is the number of logs actually received by the outgoing server, and the timestamp range is the earliest and latest timestamps of the received logs.

[0115] If the receiving status is failed, it indicates that the outgoing server has not received the log data. In the case where the first query result is failed, the second query result is obtained and the number of log queries is recorded.

[0116] The second query result is the second log data query result returned by the outgoing server after a preset delay time of the first query result, that is, the second query result is the result obtained by querying the outgoing server again after the first query fails after waiting for a preset delay time. Except for the updated timestamp range, the second query result is the same as the first query result and will not be repeated here.

[0117] Each time an outbound task is executed, log data generated in real time is not sent. Instead, the accumulated log data from the past period is sent. For example, if the current time is 12:00:00, the outbound task will send log data generated between 11:55:00 and 12:00:00. This time range is called a time window. The window span, for example, 5 minutes, and the offset from the current time are configurable.

[0118] Therefore, queries are performed at least twice. The number of queries can be configured based on the actual situation. The number of log queries is the total number of outbound server queries executed, recorded by a counter. For example, a maximum of two queries is preset. When this threshold is reached, the query is terminated and a failure result is generated. The query threshold is the maximum number of outbound server queries allowed, which is used to determine whether logs have been successfully received. For example, if the threshold is two, if no logs are retrieved after two queries, the log is marked as received unsuccessfully.

[0119] The preset delay time is the time interval to wait for the next query after the first query fails. For example, if it is set to 60 seconds, if the first query does not obtain logs, the outbound server interface will be called again after 60 seconds. If the number of log queries reaches the query threshold and no log data is found, a log reception failure result is generated;

[0120] The log reception failure result is a verification result type, indicating that the outgoing server failed to correctly receive logs. The data structure of the log reception failure result includes an error code (for example, ERR_LOG_RECV_FAILED) and a failure reason (for example, "Two queries failed to retrieve outgoing log data").

[0121] If the first query result is successful, or if the number of log queries reaches the query threshold and log data is found, a log reception success result is generated. The log reception success result is a verification result type used to indicate that the outgoing server correctly received the log. The data structure of the log reception success result includes the number of received logs and time window compliance. The number of received logs indicates the number of logs actually received by the outgoing server; the time window compliance indicates whether the timestamp of the received log is within a preset window pushed forward from the message sending time.

[0122] Taking the Kafka server as an example, for the first query, the log query interface of the Kafka server is called, the Kafka topic and time window are specified, and the first query is executed. If the number of log entries returned by the interface is greater than 0 and the timestamp meets the window requirements, the first query success result is generated; if the number of returned log entries is equal to 0, the delayed retry mechanism is started.

[0123] If the first query fails, the current query count is recorded as 1 and a 60-second wait is performed. After the delay, a second query is executed and the query interface of the Kafka server is called again. If the second query succeeds, a log of successful reception is generated. If the second query fails and the query count does not reach 2, the waiting and querying are repeated. If the threshold is reached and the query still fails, a log of failed reception is generated.

[0124] The preset delay time adapts to the log processing delay of the outgoing server. The number of queries and delay time can be dynamically adjusted through the configuration file to adapt to different network environments. For example, cross-computer room testing requires extending the delay time. The whole process of log generation and outgoing reception is verified to ensure end-to-end data consistency.

[0125] S300: Verify the first verification item of the system under test and the standard test message to generate an initial verification result.

[0126] When the log is generated and the result is received successfully, the consistency between the system under test and the standard test message is verified first. The first verification item is the verification rules of the log generation stage, including four-tuple data, message name, message content, message content and number of log entries.

[0127] The message name is the log type identified by the file name, for example, syslog.pcap indicates a system log. The message content is the protocol header and payload data, for example, the Content-Type field in the HTTP header. The number of log entries is the number of log entries generated by the system under test for a single test message, for example, 1.

[0128] The management PC generates a standard test packet, for example, audit.pcap. Its unique identifier contains the four-tuple: src_ip = 192.168.1.1, dst_ip = 10.0.0.1, src_port = 8080, dst_port = 80; packet name: audit.pcap; and packet content: HTTP protocol header with the operation_type = delete field. The management PC uses the tcpreplay tool to send the packet to the traffic collection port of the system under test.

[0129] In some embodiments, when the system under test generates log data, obtaining a first verification item of the log data;

[0130] Verifying the four-tuple data of the system under test and the four-tuple data of the standard test message;

[0131] If the four-tuple data verification passes, verify the message name and message content of the log data with the message name and message content of the standard test message;

[0132] When the message name and the message content are verified to be successful, an initial verification result indicating successful verification is generated.

[0133] The system under test parses the received test message, extracts the operation_type field in the HTTP header, generates an operation audit log containing a four-tuple, operation_type, and timestamp, and stores it in the local database.

[0134] Then call the log query interface of the system under test and perform hierarchical verification. First, perform four-tuple verification. If the four-tuple verification passes, proceed to the next step to verify the message content. The four-tuple verification is to extract the source IP, target IP, source port, and target port in the log, and compare the four-tuple data in the test message. If they are inconsistent, it is marked as verification failure.

[0135] If the verification is successful, check whether the protocol type in the message content in the log is consistent with the test message, for example, HTTP protocol, and whether the operation_type field in the log is consistent with the definition in the message content, for example, delete.

[0136] If the four-tuple, message name, and message content all pass verification, an initial verification result of success is generated; if any verification item fails, a failure result is generated. It should be noted that the four-tuple data may have the same situation. The additional message name and message content verification mechanism is added. These two fields are already present when the message is sent, and they uniquely correspond to the test message, which can increase the accuracy of the verification result data.

[0137] The log source can be locked by the basic information of both communicating parties to avoid misjudgment due to IP / port configuration errors.

[0138] S400: When the initial verification result is successful, the log data is sent to the outbound server through the system under test.

[0139] The system under test automatically pushes logs to the outbound server based on configured outbound parameters, such as the Kafka topic and Syslog server address. The outbound server is the remote service node that receives the system under test's logs. Since the outbound server can be the first server and / or the second server, if there are two initial verification results, the outbound server to which the system under test sends the log data will be determined based on the initial verification result that is successful.

[0140] Exemplarily, if the initial verification result of the first server is success and the initial verification result of the second server is failure, the log data is sent to the first server through the system under test.

[0141] For example again, if the initial verification results of the first server and the second server are both successful, the log data is sent to the first server and the second server respectively through the system under test.

[0142] S500: Verify the second verification item of the log data of the outgoing server and the system under test to generate a verification result.

[0143] The second verification item is the validation rules for the outbound log, including log content and log number. For log content, the field data in the outbound log must be identical to the log generated by the system under test. For log number, since the corresponding pcap only generates one log, the default value of 1 is sufficient for verification.

[0144] In some embodiments, if the initial verification result is successful, the log data is sent to the first server and / or the second server via the device under test;

[0145] Verifying the second verification item and data format of the first server and / or the second server;

[0146] When the second verification item is consistent with the second verification item of the log data on the system under test, and the data format is consistent with the data format of the target configuration, a verification result is generated.

[0147] Taking the Kafka server as an example, the system under test pushes logs to the Kafka server and verifies whether the log_type field of the log is security. The number of log entries in the Kafka topic is counted to confirm that they are consistent with the log generated by the system under test, and the data format is verified.

[0148] The data format is a structured definition of outgoing logs, including JSON, CSV, and Syslog formats. JSON fields are key-value pairs, for example, {"log_type":"security","src_port":8080}; CSV fields are comma-delimited, for example, security,192.168.1.1,8080; Syslog follows RFC 5424 and includes fields such as priority, version, timestamp, and host name.

[0149] The target configuration is the configuration corresponding to the outgoing server loaded by the configuration loader. The configuration loader is a module used to dynamically configure the system under test. It is used to determine the target outgoing server type based on the test message name, and to load the server address, log type, and format identifier through the REST API of the system under test.

[0150] The target configuration is the set of parameters corresponding to the outgoing server loaded by the system under test, including the server type, log type identifier, and format identifier; the server type is Kafka or Syslog; the log type identifier is, for example, operation log or security log; the format identifier is, for example, JSON, CSV, or Syslog protocol version.

[0151] Taking the Kafka server as an example, the system under test pushes security logs to the Kafka server, calls the Kafka consumer API, and pulls logs from the security_logs topic. The system checks whether the log_type field of the outgoing log is security. The system counts the number of log entries in the Kafka topic to confirm that it matches the single log entry generated by the system under test. The system also checks the JSON field order and data type, for example, whether src_port is an integer.

[0152] When the second verification item is consistent with the second verification item of the log data on the system under test and the data format is consistent with the data format of the target configuration, a verification result representing a successful verification is generated. When the second verification item is consistent with the second verification item of the log data on the system under test and the data format is inconsistent with the data format of the target configuration, a verification result representing a failed verification is generated. When the second verification item is inconsistent with the second verification item of the log data on the system under test and the data format is inconsistent with the data format of the target configuration, a verification result representing a failed verification is generated.

[0153] The data outbound verification method provided in this embodiment uses three-party collaborative verification, namely verification of the standard test message, the system under test, and the outbound server. Every link from message generation to outbound reception is verified, thereby improving accuracy.

[0154] Based on the above-mentioned data outbound verification method, some embodiments of the present application further provide a data outbound verification system, including:

[0155] An acquisition module is used to acquire a standard test message, where the standard test message is a test data packet in a preset format corresponding to a log type;

[0156] A management module is used to send the standard test message to the system under test so that the system under test parses the standard test message and generates log data; verify the first verification item of the system under test and the standard test message to generate an initial verification result; if the initial verification result is successful, send the log data to an external server through the system under test; verify the second verification item of the log data of the external server and the system under test to generate a verification result.

[0157] The management module may be a management PC.

[0158] The effects of the above system embodiment during operation can be found in the effects of the above method embodiment, which will not be described in detail here.

[0159] Some embodiments of the present application further provide an electronic device, the device comprising a processor and a memory:

[0160] The memory is used to store program code and transmit the program code to the processor;

[0161] The processor is used to execute the above-mentioned data outbound verification method according to the instructions in the program code.

[0162] Some embodiments of the present application also provide a computer-readable storage medium, which is used to store program code, and the program code is used to execute the above-mentioned data outbound verification method.

[0163] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0164] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0165] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, apparatus, or computer program products. Thus, embodiments of the present invention may take the form of a fully hardware embodiment, a fully software embodiment, or an embodiment combining software and hardware. Furthermore, embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0166] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the process in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0167] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0168] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0169] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0170] Similar parts between the embodiments provided in this application can be referenced to each other. The specific implementation methods provided above are only a few examples under the overall concept of this application and do not constitute a limitation on the scope of protection of this application. For those skilled in the art, any other implementation methods expanded based on the scheme of this application without expending creative work shall fall within the scope of protection of this application.

Claims

1. A data outbound verification method, characterized in that: include: Obtain a standard test message, which is a test data packet in a preset format corresponding to the log type; Sending the standard test message to the system under test, so that the system under test parses the standard test message and generates log data; Verifying the system under test and a first verification item of the standard test message to generate an initial verification result; If the initial verification result is successful, sending the log data to an outbound server through the system under test; Verify the second verification item of the log data of the outgoing server and the system under test to generate a verification result.

2. The data outbound verification method according to claim 1, characterized in that: The obtaining of the standard test message includes: Loading a message storage queue of a test directory based on a configuration loader, wherein the test directory is a logical partition for storing test data packets in a preset format; Acquire a test mode, where the test mode includes a first test mode and a second test mode; Parsing the message to be tested in the message storage queue based on the test mode to generate a parsing result, the parsing result including a message name and a message content; When the message name and the message content are verified to be successful, a standard test message is obtained, where the standard test message is the message to be tested.

3. The data outbound verification method according to claim 2, characterized in that: The sending of the standard test message to the system under test includes: According to the message content of the standard test message, calling the outbound configuration interface of the system under test to load outbound parameters, the outbound parameters including the server address, log type and format identifier; The message sending tool is triggered to send the standard test message to the traffic collection port, so that the system under test receives the test message through the traffic collection port. The message sending tool performs data packet transmission through a timestamp replay mechanism.

4. The data outbound verification method according to claim 1, characterized in that: The step of sending the standard test message to the system under test so as to enable the system under test to parse the standard test message may then include: Calling the log query interface of the system under test to enable the log query interface to query log data and generate a log generation result; If the log data is not obtained, the log query interface is called again at a preset interval and the number of log acquisitions is recorded; When the acquisition times reaches the acquisition threshold and no log data is acquired, a log generation failure result is generated.

5. The data outbound verification method according to claim 4, characterized in that: After sending the standard test message to the system under test so that the system under test parses the standard test message and generates log data, the method further includes: When the log data is obtained, or when the query number reaches a query threshold and the log data is obtained, obtaining a first query result, where the first query result is a first log data query result returned by the outgoing server, and the outgoing server includes a first server and a second server; If the first query result is a failure, obtain a second query result and record the number of log queries, where the second query result is a second log data query result returned by the outgoing server after a preset delay time of the first query result; If the number of log queries reaches the query threshold and the log data is not found, a log reception failure result is generated; When the first query result is successful, or when the number of log queries reaches a query threshold and the log data is found, a log reception success result is generated.

6. The data outbound verification method according to claim 1, characterized in that: The test data packet includes a unique identifier, which includes four-tuple data, message name, message content, message content and number of log entries, and the four-tuple data includes source IP, target IP, source port and target port; The first verification item of verifying the system under test and the standard test message to generate an initial verification result includes: When the system under test generates log data, obtaining a first verification item of the log data, the first verification item including four-tuple data, message name, message content, message content, and number of log entries; Verifying the four-tuple data of the system under test and the four-tuple data of the standard test message; If the four-tuple data verification passes, verify the message name and message content of the log data with the message name and message content of the standard test message; When the message name and the message content are verified to be successful, an initial verification result indicating successful verification is generated.

7. The data outbound verification method according to claim 6, characterized in that: The outgoing server includes a first server and a second server, and the second verification item includes log content and the number of log entries; The second verification item of verifying the log data of the outgoing server and the system under test to generate a verification result includes: If the initial verification result is successful, sending the log data to the first server and / or the second server through the device under test; Verifying the second verification item and data format of the first server and / or the second server; When the second verification item is consistent with the second verification item of the log data on the system under test, and the data format is consistent with the data format of the target configuration, a verification result is generated. The target configuration is the configuration corresponding to the outgoing server loaded by the configuration loader, and the verification result indicates that the verification is successful.

8. A data outbound verification system, characterized in that: include: An acquisition module is used to acquire a standard test message, where the standard test message is a test data packet in a preset format corresponding to a log type; A management module, configured to send the standard test message to the system under test, so that the system under test parses the standard test message and generates log data; verify the system under test and the first verification item of the standard test message to generate an initial verification result; When the initial verification result is successful, the log data is sent to an outbound server through the system under test; and a second verification item of the log data of the outbound server and the system under test is verified to generate a verification result.

9. An electronic device, characterized in that: The device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the data outbound verification method according to any one of claims 1 to 7 according to the instructions in the program code.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium is used to store program code, and the program code is used to execute the data outbound verification method according to any one of claims 1 to 7.

Images