A log collection method, device and server

Abstract

The application discloses a log collection method, relates to the computer field, and is applied to a server, obtains identity information of a target host after determining that the target host needs to be subjected to log collection, completes determination of a log file and subsequent display and other operations after logging in the target host according to the identity information, and the whole log collection process is controlled and completed by the server, manual operation is not needed, the number of log files does not have a great influence on the operation process, human and material resources and time and other costs consumed in the whole test process are saved, test efficiency is improved, the accuracy of a test result is guaranteed, and the log collection process of multiple target hosts can be realized by the server, the log information of multiple hosts is managed in an overall way, and a large amount of host management access overhead is saved. The application further discloses a log collection device and a server, which have the same beneficial effects as the log collection method.

Description

Technical Field

[0001] This invention relates to the field of computers, and in particular to a log collection method. The invention also relates to a server and a log collection apparatus. Background Technology

[0002] With the continuous development of the network, users have increasingly higher requirements for the reliability of related network software. Currently, before software is officially and widely used, a software testing process is usually conducted. Generally, these testing processes are completed through automated scripts. During the software testing phase, testers will conduct large-scale script stress tests, including whole-machine power-on / off tests, batch upgrade tests, production testing process tests, traffic stress tests, etc. During the software operation, the CPU system and BMC in the host will each record their own software operation logs, including on-site information of abnormal events, state change information, operation information, etc. In the entire testing process, the scripts can only determine whether the test process is completed. Whether the software can pass the test normally still requires the collection of logs during the software operation process for further analysis and judgment by the testers.

[0003] In existing technologies, the collection of logs during software operation is mainly done manually. After several rounds of testing, it is necessary to manually log in to each host to collect the logs generated during the software operation for subsequent screening and judgment. This method consumes a lot of manpower and resources and has very low operational efficiency. In particular, when the number of log files generated by the tested software is large, it will consume a lot of time and cost. Summary of the Invention

[0004] The purpose of this invention is to provide a log collection method, device, and server. The entire process is controlled by the server and does not require manual operation, saving manpower, material resources, and time costs in the entire testing process, improving testing efficiency, ensuring the accuracy of test results, and enabling the collection of logs from multiple target hosts through the server, as well as the overall management of log information from multiple hosts, saving a significant amount of host management and access overhead.

[0005] To address the aforementioned technical problems, this invention provides a log collection method applied to a server, the method comprising:

[0006] Identify the target hosts from which logs need to be collected;

[0007] Obtain the identity information of the target host;

[0008] Log in to the target host based on the identity information and determine the target host's log files;

[0009] The log files are displayed on a page in a preset manner for subsequent viewing by testers.

[0010] Preferably, the target host for which log collection needs to be performed is determined, including:

[0011] Detect all hosts in the network segment of the server and select the hosts that can communicate with the server as backup hosts;

[0012] The identity verification service interface sends an identity verification request and identity verification content to the candidate host, so that the candidate host can perform identity verification based on the identity verification content after receiving the identity verification request.

[0013] Determine whether any of the candidate hosts have passed the identity verification;

[0014] If so, the host that passes the identity verification is determined to be the target host for which log collection is required.

[0015] Preferably, an identity verification request and identity verification content are sent to the candidate host through an identity verification service interface, so that the candidate host performs identity verification based on the identity verification content after receiving the identity verification request, including:

[0016] The identity verification service interface sends an identity verification request and a message encrypted with a private key to the candidate host, so that the candidate host can decrypt the message after receiving the identity verification request.

[0017] Correspondingly, determining whether there is a host among the candidate hosts that has passed identity verification includes:

[0018] Determine whether any of the candidate hosts successfully decrypted the message using the public key corresponding to the private key;

[0019] If so, the host that successfully decrypted the message is determined to be a host that has passed identity verification.

[0020] Preferably, the log file is displayed on a page in a preset manner, including:

[0021] The log files are divided into N categories according to priority, where N is a positive integer;

[0022] Sort the log files in each category in chronological order;

[0023] Sort the N categories in descending order of priority;

[0024] The log files in the highest priority category are displayed on the page in chronological order.

[0025] Preferably, before determining the log file of the target host, the method further includes:

[0026] Determine whether new logs are still being added within the preset time period;

[0027] If no new logs are added within the preset time period, proceed to the step of determining the log files of the target host.

[0028] Preferably, determining the log file of the target host includes:

[0029] Determine whether the log files of the target host need to be compressed;

[0030] If so, control the target host to compress the target host's log files;

[0031] Get the compressed log file;

[0032] Correspondingly, the log files are displayed on a page in a preset manner for subsequent viewing by testers, including:

[0033] The compressed log files are displayed on the server's page in a preset manner for subsequent viewing by testers.

[0034] Preferably, it further includes:

[0035] Identify the logs in the target host that need to be monitored;

[0036] Determine whether a preset keyword exists in the content of the log;

[0037] If so, the log is determined to be abnormal, and the corresponding prompting strategy is executed.

[0038] Preferably, after determining that the log has an abnormality, the method further includes:

[0039] Determine whether there are any services on the target host that need to be stopped corresponding to the abnormal situation;

[0040] If so, control the corresponding script to stop the service.

[0041] To address the aforementioned technical problems, the present invention also provides a log collection device, comprising:

[0042] Memory, used to store computer programs;

[0043] A processor for executing the computer program to implement the steps of the log collection method as described above.

[0044] To address the aforementioned technical problems, the present invention also provides a server, comprising: a server body and a log collection device as described above, wherein the log collection device is connected to the server body.

[0045] This invention provides a log collection method applied to a server. After identifying the target host for log collection, the method obtains the target host's identity information, logs are accessed based on this information, and the log files are determined and subsequently displayed. The entire log collection process is controlled by the server, eliminating the need for manual intervention. The number of log files does not significantly impact the process, saving manpower, resources, and time costs associated with the testing process, improving testing efficiency, ensuring the accuracy of test results, and enabling the collection of logs from multiple target hosts through the server. This allows for the unified management of log information from multiple hosts, significantly reducing host management and access overhead.

[0046] The present invention also provides a log collection device and server, which have the same beneficial effects as the log collection method described above. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the prior art and embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 A flowchart illustrating a log collection method provided by the present invention;

[0049] Figure 2 A schematic diagram of the structure of a log collection device provided by the present invention;

[0050] Figure 3 A schematic diagram of the structure of a server provided by the present invention;

[0051] Figure 4 This is a schematic diagram of the structure of a log collection system provided by the present invention. Detailed Implementation

[0052] The core of this invention is to provide a log collection method, device, and server. The entire process is controlled by the server and does not require manual operation, saving manpower, material resources, and time costs in the entire testing process, improving testing efficiency, ensuring the accuracy of test results, and enabling the collection of logs from multiple target hosts through the server, as well as the overall management of log information from multiple hosts, saving a significant amount of host management access overhead.

[0053] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] This invention provides a log collection method applied to servers, primarily suitable for collecting logs generated by various hosts in a switch system during software testing. It can also be used in other applications. This application does not impose any special limitations on the application scenario or the software object corresponding to the logs. Generally, the main log collection object is the BMC (Baseboard Management Controller), but logs generated by host systems, etc., can also be collected. This application does not impose any special limitations on the collection object, how the logs are generated, or where they originate.

[0055] Taking a white-box switch architecture as an example, the white-box switch architecture mainly includes two software components: the CPU (central processing unit) system and the BMC (Board Management Controller). The CPU system typically installs a sonic system, used to manage the switch's switching network and port control, and run various network management applications and services. The BMC, as a board-level management module, is responsible for collecting sensor information, hot-swappable device insertion / removal times, CPLD (Complex Programmable Logic Device) register anomaly alarm information, etc., during the white-box switch's operation. During the operation of both software components, they each record their own software operation logs, including on-site information of abnormal events, state transition information, operation information, etc. This log information can conveniently provide a reliable basis for fault location and system maintenance. It is understandable that the software operation information in the CPU system is used as an important basis for judgment and testing by collecting the logs generated by the BMC. This application does not specifically limit the switch architecture, host, and server; detailed implementation methods are described below.

[0056] Please refer to Figure 1 , Figure 1 A flowchart illustrating a log collection method provided by the present invention;

[0057] A log collection method applied to a server, the method comprising:

[0058] S11: Determine the target host for which log collection is required;

[0059] It is understood that when this method is applied in the software testing process, the target host for log collection refers to the host where the software to be tested is located. The log collection method provided in this application can be applied to a variety of work scenarios. The target host for log collection is different for different work scenarios. This application does not make any special restrictions here and can be adjusted at any time according to the actual application.

[0060] Generally, in the application process, there can be one or more target hosts. This application does not make any special restrictions on the type, number, or size of the target hosts. In the process of determining the target hosts, the hosts to be determined can be determined sequentially, or all hosts can be detected at the same time to determine the target hosts. The determination can be made in real time or according to a preset period or preset time period. This application does not make any special restrictions on the frequency of determination or the number of objects.

[0061] Specifically, there are many ways to determine the target host. It can be done through identity verification, where the server and the target host are paired directly through identity verification commands. Alternatively, all hosts can be assigned address numbers in advance, and the target host's address number can be directly entered into the server to determine the target host. The method of determining the target host can be manual or pre-set automatic. This application does not make any special restrictions on the specific implementation method of determining the target host.

[0062] S12: Obtain the target host's identity information;

[0063] It should be noted that the target host's identity information includes IP (Internet Protocol) address information, user login account information, etc. After the target host is determined, the server needs to obtain the target host's identity information from the target host for subsequent data transmission. An acquisition command can be set in the server, and after the target host is determined, the acquisition command is sent to it. After receiving the acquisition command, the target host will transmit the identity information to the server. If a data connection has been established during the process of determining the target host, the identity information can also be sent directly through the data connection. This application does not make any special restrictions on the method of transmitting the identity information to the server.

[0064] Generally, when a target host sends identity information, it needs to encrypt the identity information before transmitting it to the server to avoid the risk of attack and data loss, thereby improving the security and reliability of the entire process. This application does not make any special restrictions on the specific encryption method.

[0065] S13: Log in to the target host based on identity information and determine the target host's log files;

[0066] It is understood that when logging into the target host, protocols such as SSH (Secure Shell) and SCP (Secure Copy) can be used. This application does not impose any specific restrictions on the login method. The log files on the target host are generally generated by the BMC, but can also be generated by other systems; this application does not impose any specific restrictions on these methods.

[0067] In practical applications, log files are generally files with the .log extension. This application does not make any special restrictions on the specific storage method of log files. Determining the log file of the target host can be done by directly selecting the log file on the target host, copying the log file of the target host to the server, or other determination operations. The specific operation performed depends on the application environment and testing requirements, etc., and this application does not make any special restrictions here.

[0068] During the process of determining log files, target hosts can be determined sequentially or simultaneously. Log file determination can be performed in real-time or according to preset periods or time intervals. This application does not impose specific limitations on the frequency or number of targets determined. It should be noted that during the log file determination process, there may be situations where the logs of a target host are continuously being added. For logs that are still being added, they will not be included in this collection process but can be collected in subsequent collection stages. Alternatively, a long-lived connection can be established with the host via a socket to monitor the log's growth in real time. Once it is determined that the log has stopped growing, it can then be collected to obtain the most complete log file. There are many ways to handle newly added logs, and this application does not impose any specific limitations here.

[0069] S14: Display the log files on the page in a preset manner for subsequent testing personnel to view.

[0070] Understandably, there are multiple options for displaying log files. All log files can be displayed directly on the page, or they can be sorted by time or priority before display. Only a portion of the log files can be displayed, or all of them can be shown. Logs can be highlighted and / or categorized by priority, or only high-priority logs can be viewed after using priority categorization. These can all be considered preset methods. This application does not impose any specific limitations on the content of the preset methods or the sorting of log files. Generally, preset methods are pre-configured on the server or target host and can be adjusted at any time according to factors such as the application target.

[0071] In practical applications, the log files can be directly displayed on the target host's page in a preset manner, allowing users to read them online and obtain relevant log information. Alternatively, the log files can be obtained from the server and displayed on the server's page. The server's page can display the log files of a single target host or the log files of all target hosts in the entire system. This application does not impose any special restrictions on the specific display medium and content.

[0072] Considering that when log files contain too much content and are very large, it is difficult to display them all on a single page, a pagination function for viewing large log files can be set up. The content of large log files can be paginated according to relevant content or priority, and the content information corresponding to each page can be determined. Testers can retrieve and view the log file corresponding to the page number of the information they want to view. This application does not impose any special restrictions on the specific settings and implementation methods of the pagination function for large log files, and other solutions can be adopted.

[0073] Specifically, the server can be one of the hosts in the switch architecture where the target host is located, or it can be a remote device, as long as it can exchange data with the target host. Generally, the server and other hosts are set up in the same network segment. A network segment can be specified in advance, or it can be ensured to be in the same network segment during setup, or other setup methods can be used; this application does not impose any particular limitations. Generally, a log monitoring system can be set up on the server to complete the above collection steps. This application does not impose any particular limitations on the specific setup method and program content of the log monitoring system.

[0074] It is understood that the entire log collection process can be performed in real time, or according to a preset cycle or time period. This application does not impose any special limitations on the collection frequency or the number of objects. After the log files are collected, testers can use the contents of the obtained log files to determine whether the software test has passed or to perform other subsequent operations. This application does not impose any special limitations on these operations.

[0075] This invention provides a log collection method applied to a server. After identifying the target host for log collection, the method obtains the target host's identity information, logs are accessed based on this information, and the log files are determined and subsequently displayed. The entire log collection process is controlled by the server, eliminating the need for manual intervention. The number of log files does not significantly impact the process, saving manpower, resources, and time costs associated with the testing process, improving testing efficiency, ensuring the accuracy of test results, and enabling the collection of logs from multiple target hosts through the server. This allows for the unified management of log information from multiple hosts, significantly reducing host management and access overhead.

[0076] Based on the above embodiments,

[0077] As a preferred embodiment, determining the target host for which log collection is required includes:

[0078] Detect all hosts in the server's network segment and select hosts that can communicate with the server as backup hosts;

[0079] The identity verification service interface sends an identity verification request and identity verification content to the backup host, so that the backup host can perform identity verification based on the identity verification content after receiving the identity verification request.

[0080] Determine if any of the candidate hosts have passed the identity verification;

[0081] If so, the host that passes the identity verification is determined to be the target host for which log collection is required.

[0082] Generally, the ping command is used to determine whether open hosts in the network segment are reachable. Other methods can also be used to detect reachable hosts; this application does not impose any special limitations on this. During the detection, each open host can be detected sequentially, or all open hosts in the network segment can be detected simultaneously. Detection can be performed in real time, or according to a preset period or time period. This application does not impose any special limitations on the detection frequency or the number of targets.

[0083] Understandably, after identifying candidate hosts, identity verification can be used to further determine the target hosts for log collection. There are many methods for identity verification; an identity verification interface can be pre-configured on the server and host, and then sent to the candidate hosts via this interface along with the verification request and content. The result of the identity verification is then evaluated. This application does not impose specific limitations on the specific implementation of the identity verification interface, the identity verification request, and the identity verification content. It can be implemented through a handshake or a key-based peering mechanism. Considering that the logs primarily targeted are those generated by the BMC, and that the BMC is generally configured with RESTful services, a RESTful service interface can be selected for the identity verification, eliminating the need for additional configuration and further reducing costs. The corresponding identity verification request can be a RESTful request.

[0084] During the judgment process, each candidate host can be judged sequentially, or all candidate hosts can be judged simultaneously. Judgments can be made in real time, or according to a preset period or time period. This application does not impose any specific limitations on the frequency or number of judgments. If no host passes identity verification, a second check and judgment can be performed after a preset time period, or the collection process can be terminated directly; this application does not impose any specific limitations on this either.

[0085] Using an identity verification interface to determine the target host is a specific way to identify the target host for log collection. The identity verification process is highly efficient, fast, and reliable, ensuring the accuracy and reliability of subsequent log files.

[0086] As a preferred embodiment,

[0087] The identity verification service interface sends an identity verification request and identity verification content to the backup host, so that the backup host can perform identity verification based on the identity verification content after receiving the identity verification request, including:

[0088] The identity verification service interface sends an identity verification request and a message encrypted with a private key to the backup host, so that the backup host can decrypt the message after receiving the identity verification request.

[0089] Correspondingly, determining whether there are any hosts among the candidate hosts that have passed identity verification includes:

[0090] Determine if any of the candidate hosts has successfully decrypted the message using the public key corresponding to the private key;

[0091] If so, the host that successfully decrypted the message is determined to be a host that has passed identity verification.

[0092] Specifically, identity verification can be achieved using key pairs. The server can generate a 2048-bit key pair using the RSA algorithm. The private key is stored in the server's log monitoring system, and the public key is added to the target host's software key store. This means that each host in the switch architecture already contains this public key information when its OS (operating system) or BMC system is installed, for communication with the server. When the server sends an identity verification request, it encrypts its IP address information using the private key and sends the encrypted message to a backup host. If the backup host can successfully decrypt the message using the public key, then that backup host is the target host, and the target host can directly transmit its identity information to the server via the returned message.

[0093] It is understood that this application does not impose any special restrictions on the type of key pair, the specific setting method, or the generation method; other methods may also be used. During the judgment process, each candidate host can be judged sequentially, or all candidate hosts can be judged simultaneously. Judgments can be made in real time, or according to a preset period or time period. This application does not impose any special restrictions on the frequency of judgments or the number of objects. If no host successfully decrypts the message, a second check and judgment can be performed after a preset time period, or the collection process can be directly terminated; this application does not impose any special restrictions on this.

[0094] This embodiment is a specific implementation method for identity verification between the server and the backup host. It uses key pairs to achieve identity verification. The generation and setting of key pairs are relatively easy, the encryption and decryption processes are fast, the data throughput is high, and the security is high, which further ensures the accuracy and reliability of subsequent log files and improves the security of the entire collection process.

[0095] As a preferred embodiment, the log file is displayed on a page in a preset manner, including:

[0096] The log files are divided into N categories according to priority, where N is a positive integer;

[0097] Sort the log files in each category in chronological order;

[0098] Sort the N categories in descending order of priority;

[0099] Log files in the highest priority category are displayed on the page in chronological order.

[0100] In practical applications, log files are prioritized according to their importance. Therefore, log files can be divided into N categories based on priority, such as critical, normal, minor, etc. This application does not impose any specific limitations on how to distinguish these categories or the specific classification methods. Within the same category, log files can be further sorted chronologically, or other sorting methods can be chosen; this application does not impose any specific limitations on these methods. After sorting, log files in the highest priority category can be displayed sequentially, or several high-priority categories can be displayed; this application does not impose any specific limitations on these methods.

[0101] This embodiment is a specific implementation of displaying log files on a page in a preset manner. First, the log files are classified by priority and then sorted by time order. Then, the log files in the highest priority category are displayed in sequence. Only high-priority log files are displayed, which can ensure that testers can prioritize the processing of more important log files, improve work efficiency, save time and unnecessary resource waste, and ensure the reliability and security of the server and each target host.

[0102] As a preferred embodiment, before determining the log file of the target host, the method further includes:

[0103] Determine whether new logs are still being added within the preset time period;

[0104] If no new logs are added within the preset time period, proceed to the step of determining the log files of the target host.

[0105] Considering the possibility that log files on the target host may be in a state of being newly created and the log file cannot be identified, a scheduled collection module is set up. This module can collect log files that were not identified during the initial log file identification process, or it can pre-set some log files as targets for scheduled collection. Based on the log file list, the module selects the log files to be collected. Generally, a long-lived connection is established with the log files to be collected to monitor their creation status. Parameters such as changes in log size are used to determine whether log creation is still occurring. This can be done while monitoring and determining the status, or after a preset monitoring period. This application does not impose specific limitations on how to monitor and determine log creation for the scheduled collection targets.

[0106] Specifically, log collection can be performed on a pre-set schedule or at a fixed time. This application does not impose any specific limitations on the frequency or implementation method of the pre-set collection. During the judgment process, each log to be collected can be judged sequentially, or all logs to be collected can be judged simultaneously. Judgment can be performed in real-time or at a pre-set schedule. This application does not impose any specific limitations on the frequency or number of judgments. If logs are still being added within the pre-set time period, a second judgment can be performed after the pre-set time period, or the pre-set collection process can be terminated directly. This application does not impose any specific limitations on this.

[0107] A timed collection module was set up to address the situation where log files on the target host are in the process of being added and the log file cannot be identified. This ensures that the log file can be monitored after it is added and that subsequent identification and display operations are performed, thus guaranteeing the integrity of the log files obtained by the server and improving the accuracy and reliability of the entire log collection process.

[0108] As a preferred embodiment, determining the log file of the target host includes:

[0109] Determine whether the target host's log files need to be compressed;

[0110] If so, control the target host to compress the target host's log files;

[0111] Get the compressed log file;

[0112] Correspondingly, the log files will be displayed on the page in a preset manner for subsequent viewing by testers, including:

[0113] The compressed log files are displayed on the server's page in a preset manner for subsequent viewing by testers.

[0114] When determining the log files of the target host, if it is necessary to copy the log files to the server, it is necessary to first determine whether the log files need to be compressed. It is possible to pre-determine which types of log files need to be compressed, or the server can make its own judgment based on priority, etc. This application does not make any special restrictions on the criteria for determining whether compression is required. If compression is required, the server needs to control the target host to perform the compression operation and send the compressed log files directly to the server. Alternatively, after the log collection is completed, the compressed log files can be summarized and saved periodically, and a remote log push function can be provided to send the summarized logs to the server for storage.

[0115] Specifically, during the judgment process, the log files of each target host can be judged sequentially, or the log files of all target hosts can be judged simultaneously. The judgment can be performed in real time or at preset intervals. This application does not impose any special limitations on the frequency or number of targets judged. If the log files of the target hosts do not need to be compressed, they can be directly copied to the server, or copied after a preset time period. This application does not impose any special limitations on this either.

[0116] Correspondingly, displaying log files on a page in a preset manner for subsequent testers to view can include displaying compressed log files on a server-side page in a preset manner for subsequent testers to view.

[0117] Determining whether a log file needs to be compressed before copying it to the server can reduce the size of the file to be transferred, speed up the transfer process, save storage space, and make the compressed log file less susceptible to corruption. This improves collection efficiency while ensuring the security and reliability of the entire collection process.

[0118] As a preferred embodiment, it further includes:

[0119] Identify the logs on the target host that need to be monitored;

[0120] Determine if the log content contains a preset keyword;

[0121] If so, the log is determined to contain an anomaly, and the corresponding prompting strategy is executed.

[0122] Considering that existing technologies require manual screening of logs for business-related error information, and that some faults during testing are fleeting and can be overwhelmed or updated by other running services, requiring testers to monitor the situation and maintain order, coupled with the dramatic increase in log files during large-scale problem reproduction scenarios, significantly increasing the difficulty of log screening for testers, this application adds a log monitoring and alerting process to achieve automatic log alerts. Specific log files can be pre-set as those requiring monitoring, or a baseline can be set for the server to automatically determine which logs need monitoring; this application does not impose any specific limitations here. After determining the logs on the target host that need monitoring, the content of the logs is evaluated to determine if there are any abnormal situations corresponding to faults, and the corresponding alerting strategy is executed.

[0123] It is understandable that the object of judgment can be the entire content of the log, or it can be judged only for newly added log content. This application does not make any special restrictions here. For example, when the newly added log content contains preset keyword information, the server can notify the testers via email or DingTalk.

[0124] Specifically, there are many ways to determine whether there is an abnormal situation corresponding to the fault in the log. One can choose to determine whether there is a preset keyword in the content of the log. The preset keyword can be a conditional match or a field match, etc. This application does not make any special restrictions here.

[0125] Specifically, during the judgment process, each log that needs to be monitored can be judged sequentially, or all logs that need to be monitored can be judged simultaneously. Judgments can be made in real time or at preset intervals. This application does not impose any specific limitations on the frequency or number of objects judged. If no abnormalities are found in the logs, the monitoring process can be exited directly, or judgments can be made on other logs that need to be monitored after a preset time period. This application does not impose any specific limitations on this either.

[0126] Specifically, the notification module can be one or more combinations of indicator lights, speakers, and voice modules, as well as online notifications. Different notification strategies can be set for different faults, or none can be set. Differentiating notification strategies can be achieved by setting different notification sub-modules or different notification methods within the notification module. For example, differentiating notification strategies can be achieved by one or more combinations of indicator light flashing frequency, indicator light color changes, and speaker volume. This application does not impose any special limitations on the specific implementation method of the notification module or the method of distinguishing notification strategies. Furthermore, this application does not impose any special limitations on the location and size of the notification module; adjustments can be made based on different server structures.

[0127] After the prompt is given, the server can also perform data statistics based on the contents of the log file, including information such as the time, frequency, number of logs, and log growth curve of the fault log occurrence, so that testers can carry out subsequent data analysis. The specific statistical methods are not specifically limited in this application.

[0128] To address the need for automatic log alerts, a log monitoring and notification process has been added. This process can monitor and alert on anomalies in the logs, and can be applied to scenarios such as fault reproduction and stress testing. It ensures that testers can be quickly notified of fault reproduction or test anomalies without the need for testers to manually log in to view and filter log anomaly information, greatly saving manpower and resources. It also preserves the fault scene to a certain extent, significantly improving the efficiency of testing and R&D in troubleshooting and ensuring data accuracy.

[0129] As a preferred embodiment, after determining that there is an anomaly in the log, the method further includes:

[0130] Determine if any services on the target host correspond to the abnormal situation and need to be stopped.

[0131] If so, control the corresponding script to stop the service.

[0132] Considering the need to protect certain services or programs in the event of a failure, after detecting an anomaly, the services corresponding to the anomaly and requiring shutdown are checked and judged. If any exist, the corresponding scripts or programs need to be controlled to stop the service. Stopping the service can be done by shutting down the corresponding business service or executing specific on-site protection actions, etc., which are not specifically limited in this application. Generally, services corresponding to keyword information are set, but the correspondence between anomalies and services can also be achieved in other ways, which are not specifically limited in this application.

[0133] Specifically, during the judgment process, each service can be judged sequentially, or all services can be judged simultaneously. Judgments can be made in real-time or at preset intervals. This application does not impose any specific limitations on the frequency or number of judgments. If no service corresponding to the abnormal situation needs to be stopped, the process can exit directly, or other services can be judged after a preset time period, or a second judgment can be made on the same service. This application does not impose any specific limitations on these options.

[0134] After an anomaly is detected, further determination is made as to whether there are corresponding services that need to be stopped, and corresponding operations are performed. This can prevent other processes from damaging the fault scene and ensure the accuracy and integrity of the fault scene. With the help of script programs, the log monitoring and management architecture can further realize the automatic termination of testing or reproduction process, preserve the fault scene to the greatest extent, greatly improve the efficiency of testing and R&D positioning, and ensure the accuracy of data.

[0135] Please refer to Figure 2 , Figure 2 This is a schematic diagram of the structure of a log collection device 22 provided by the present invention;

[0136] To address the aforementioned technical problems, the present invention also provides a log collection device 22, comprising:

[0137] Memory 1 is used to store computer programs;

[0138] Processor 2 is used to implement the steps of the log collection method described above when executing computer programs.

[0139] The processor 2 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 2 may be implemented using at least one hardware form selected from DSP (Digital Signal Processor), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 2 may also include a main processor and a coprocessor. The main processor, also known as the central processing unit, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 2 may integrate a GPU (graphics processing unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 2 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0140] The memory 1 may include one or more computer-readable storage media, which may be non-transitory. The memory 1 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 1 is used to store at least the following computer program, which, after being loaded and executed by the processor 2, is capable of implementing the relevant steps of the log collection method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 1 may also include an operating system and data, and the storage method may be temporary or permanent storage. The operating system may include Windows, Unix, Linux, etc. The data may include, but is not limited to, data related to the log collection method.

[0141] In some embodiments, the log collection device 22 may further include a display screen, an input / output interface, a communication interface, a power supply, and a communication bus.

[0142] It will be understood by those skilled in the art that Figure 2 The structure shown does not constitute a limitation on the log collection device 22 and may include more or fewer components than shown.

[0143] For a description of the log collection device 22 provided by the present invention, please refer to the above method embodiments; the present invention will not be described again here.

[0144] Please refer to Figure 3 , Figure 3A schematic diagram of the structure of a server provided by the present invention;

[0145] To solve the above-mentioned technical problems, the present invention also provides a server, including: a server body 21 and a log collection device 22 as described above, wherein the log collection device 22 is connected to the server body 21.

[0146] This application does not impose any special restrictions on the type of server, the connection method between the log collection device 22 and the server body 21, etc. It can adopt the Tornado full-stack web framework and asynchronous network library, support non-congestion IO, handle tens of thousands of open connections, and support long-connection applications.

[0147] For an introduction to the server provided by this invention, please refer to the above method embodiments; the invention itself will not be described in detail here.

[0148] To address the aforementioned technical problems, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the log collection method described above.

[0149] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. Specifically, the computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, and portable hard drives, or any type of media or device suitable for storing instructions or data, etc., and this application does not make any special limitations here.

[0150] For a description of the computer-readable storage medium provided by the present invention, please refer to the above method embodiments; the present invention will not be described again here.

[0151] Please refer to Figure 4 , Figure 4 A schematic diagram of the structure of a log collection system provided by the present invention;

[0152] To address the aforementioned technical problems, this invention also provides a log collection system applied to a server; the system includes:

[0153] The host unit 31 is used to determine the target host for which log collection is required.

[0154] Acquisition unit 32 is used to acquire the identity information of the target host;

[0155] Login unit 33 is used to log in to the target host based on identity information and determine the log file of the target host;

[0156] Display unit 34 is used to display log files on a page in a preset manner for subsequent viewing by testers.

[0157] Login unit 33 includes:

[0158] The login host unit is used to log in to the target host based on identity information;

[0159] Identify log units, used to determine the log files of the target host;

[0160] In a preferred embodiment, determining the host unit 31 includes:

[0161] The detection unit is used to detect all hosts in the server's network segment and select hosts that can communicate with the server as backup hosts.

[0162] The identity verification unit is used to send an identity verification request and identity verification content to the backup host through the identity verification service interface, so that the backup host can perform identity verification based on the identity verification content after receiving the identity verification request.

[0163] The first judgment unit is used to determine whether there is a host among the candidate hosts that has passed the identity verification. If so, the first judgment unit is triggered.

[0164] The first determination unit is used to determine whether a host that has passed identity verification is the target host for which log collection is required.

[0165] In one preferred embodiment, the identity verification unit includes:

[0166] The identity verification subunit is used to send an identity verification request and a message encrypted with a private key to the backup host through the identity verification service interface, so that the backup host can decrypt the message after receiving the identity verification request.

[0167] Correspondingly, the first judgment unit includes:

[0168] The first judgment subunit is used to determine whether there is a host among the candidate hosts that has successfully decrypted the message using the public key corresponding to the private key. If so, the first judgment subunit is triggered.

[0169] The first determination subunit is used to determine whether the host that successfully decrypted the message is a host that has passed the identity verification.

[0170] As a preferred embodiment, the display unit 34 includes:

[0171] The classification unit is used to divide log files into N categories according to priority, where N is a positive integer;

[0172] The first sorting unit is used to sort the log files in each category in chronological order.

[0173] The second sorting unit is used to sort the N categories in descending order of priority;

[0174] The sequential display unit is used to display log files in the highest priority category in chronological order on the page.

[0175] As a preferred embodiment, it further includes:

[0176] The second judgment unit is used to determine whether the logs to be collected are still being added within the preset time period. If not, the log determination unit is triggered.

[0177] In one preferred embodiment, determining the log unit includes:

[0178] The third judgment unit is used to determine whether the log files of the target host need to be compressed. If so, the compression unit is triggered.

[0179] The compression unit is used to control the target host to compress the target host's log files;

[0180] Get log unit, used to retrieve compressed log files;

[0181] Correspondingly, display unit 34 includes:

[0182] The display sub-unit is used to display the compressed log files on the server's page in a preset manner for subsequent viewing by testers.

[0183] As a preferred embodiment, it further includes:

[0184] The monitoring unit is used to determine the logs on the target host that need to be monitored.

[0185] The fourth judgment unit is used to determine whether a preset keyword exists in the log content. If so, the second judgment unit is triggered.

[0186] The second determination unit is used to determine if there are any abnormalities in the logs and to execute the corresponding prompting strategy.

[0187] As a preferred embodiment, it further includes:

[0188] The fifth judgment unit is used to determine whether there is a service on the target host that needs to be stopped corresponding to the abnormal situation. If so, the service stop unit is triggered.

[0189] The Stop Service unit is used to control the corresponding script to stop the service.

[0190] For a description of the log collection system provided by this invention, please refer to the above method embodiments; the invention itself will not be described in detail here.

[0191] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0192] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A log collection method characterized by, Applied to a server, the method includes: Identify the target host for log collection; the target host for log collection is the host where the software to be tested is located, and the logs collected are those generated by the host during the software testing process; there may be one or more target hosts. Obtain the identity information of the target host from the target host; Log in to the target host based on the identity information and determine the log file of the target host, then copy the determined log file of the target host to the server; The log files are displayed on a page in a preset manner for subsequent viewing by testers; Also includes: Identify the logs in the target host that need to be monitored; Determine whether a preset keyword exists in the content of the log; If so, the log is determined to be abnormal, and the corresponding prompting strategy is executed; Identify the target hosts for which log collection is required, including: Detect all hosts in the network segment of the server and select the hosts that can communicate with the server as backup hosts; The identity verification service interface sends an identity verification request and identity verification content to the candidate host, so that the candidate host can perform identity verification based on the identity verification content after receiving the identity verification request. Determine whether any of the candidate hosts have passed the identity verification; If so, the host that passes the identity verification is determined to be the target host for which log collection is required; The identity verification service interface sends an identity verification request and identity verification content to the candidate host, so that the candidate host can perform identity verification based on the identity verification content after receiving the identity verification request, including: The identity verification service interface sends an identity verification request and a message encrypted with a private key to the candidate host, so that the candidate host can decrypt the message after receiving the identity verification request. Correspondingly, determining whether there is a host among the candidate hosts that has passed identity verification includes: Determine whether any of the candidate hosts successfully decrypted the message using the public key corresponding to the private key; If so, the host that successfully decrypted the message is determined to be a host that has passed identity verification; Before determining the log files of the target host, the process also includes: Determine whether new logs are still being added within the preset time period; If no new logs are added within the preset time period, proceed to the step of determining the log files of the target host; After determining that the log contains an anomaly, the process also includes: Determine whether there are any services on the target host that need to be stopped corresponding to the abnormal situation; If so, control the corresponding script to stop the service.

2. The log collection method of claim 1, wherein, The log files are displayed on a page in a preset manner, including: The log files are divided into N categories according to priority, where N is a positive integer; Sort the log files in each category in chronological order; Sort the N categories in descending order of priority; The log files in the highest priority category are displayed on the page in chronological order.

3. The log collection method as described in claim 1, characterized in that, Determine the log files of the target host, including: Determine whether the log files of the target host need to be compressed; If so, control the target host to compress the target host's log files; Get the compressed log file; Correspondingly, the log files are displayed on a page in a preset manner for subsequent viewing by testers, including: The compressed log files are displayed on the server's page in a preset manner for subsequent viewing by testers.

4. A log collection device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the log collection method as described in any one of claims 1 to 3.

5. A server, characterized in that, include: The server body and the log collection device as described in claim 4 are connected to the server body.

Images