Kernel log management method, system, device, storage medium and program product
By deploying a log processing module in the operating system kernel and coordinating it with the management server, the problems of easy loss and low collection efficiency of kernel logs are solved, achieving efficient and stable kernel log management and supporting fault analysis in multi-device scenarios.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING LINX SOFTWARE CORP
- Filing Date
- 2026-06-18
- Publication Date
- 2026-07-21
AI Technical Summary
In existing technologies, the way operating system kernel logs are obtained is greatly affected by the user-mode operation, which leads to easy loss of log data and low collection efficiency, especially in multi-device scenarios where effective log management is difficult to achieve.
A log processing module is deployed in the operating system kernel to generate log data packets and send them asynchronously to the management server. By combining sorted linked lists and log file management mechanisms, the orderliness and stability of log data are ensured, and remote control is achieved through kernel-level protocol hook functions.
It improves the stability and completeness of kernel log collection, enhances the efficiency of multi-device log management, and ensures the accuracy and real-time performance of fault analysis.
Smart Images
Figure CN122431990A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a kernel log management method, system, device, storage medium, and program product. Background Technology
[0002] Operating system kernel logs are crucial for operating system fault analysis, and their completeness and real-time performance significantly impact the efficiency and accuracy of fault location. Currently, operating system kernel log data is commonly obtained through methods such as viewing via local serial ports, command-based log reading, and log collection using user-space log services.
[0003] However, the aforementioned methods of obtaining kernel logs are highly dependent on the operating system's user-mode operation, resulting in issues such as easy data loss and low log collection efficiency leading to poor log real-time performance. Especially in centralized log management scenarios involving multiple devices, logging into devices to collect log data is required. Combined with the aforementioned log acquisition methods, this leads to similar problems in multi-device log management, including easy data loss, inability to achieve multi-device log management, and low management efficiency. Summary of the Invention
[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a kernel log management method, system, device, storage medium and program product that can improve the stability and integrity of kernel log collection and improve the log management efficiency of multiple target devices.
[0005] Firstly, this application provides a kernel log management method. This method is applied to a kernel log management system, which includes at least one target device and a management server. The target device's operating system kernel has a log processing module deployed within it. The log processing module collects kernel log data from the target device, generates log data packets based on the log data and sequence identifiers, and sends the log data packets to the management server; the sequence identifiers represent the sending order of the log data. The management server receives and parses log data packets, caches the log data into the sorted list corresponding to the target device according to the sequence identifier, and stores the log data in the sorted list into the log file corresponding to the target device based on the log data reception attributes.
[0006] In conjunction with the first aspect, in one possible implementation, the receiving attributes include the number of log data in the sorted list and the idle receiving duration of the log data. Based on the receiving attributes of the log data, the log data in the sorted list is stored in the log file corresponding to the target device, including: if the number of log data in the sorted list reaches the storage limit of the sorted list, then the log data in the sorted list is stored in the log file corresponding to the target device; if the idle receiving duration exceeds a preset idle duration threshold, then the log data in the sorted list is stored in the log file corresponding to the target device; the idle receiving duration is the duration between the receiving time of the previous log data and the current time.
[0007] In conjunction with the first aspect, in one possible implementation, the kernel log management method further includes: adjusting the storage limit of the sorted linked list based on the attribute information of the log data storage operation corresponding to the log file; the attribute information of the log data storage operation includes storage frequency and idle storage duration; the idle storage duration is the duration between the time of the previous log data storage operation and the current time.
[0008] In conjunction with the first aspect, in one possible implementation, the kernel log management method further includes: if the file size of the log file corresponding to the target device reaches a preset threshold, then the log file is updated to a historical log file, and a new log file corresponding to the target device is created, and the log data in the sorted list is stored in the newly created log file.
[0009] In conjunction with the first aspect, in one possible implementation, the kernel log management method further includes: a log processing module, which is also used to intercept packets sent by other target devices based on hook functions of the network layer protocol pre-set in the kernel, query user instructions in a pre-configured instruction mapping table based on the length of the packet, and execute the user instructions; the instruction mapping table includes the correspondence between different packet lengths and user instructions, and the user instructions include at least one of log level adjustment instructions, log collection start instructions, and log collection stop instructions.
[0010] In conjunction with the first aspect, in one possible implementation, the kernel log data of the target device is collected, and a log data packet is generated based on the log data and the sequence identifier. This includes: obtaining log data based on a callback function pre-set in the kernel and storing the log data in the kernel buffer; reading log data from the buffer based on a kernel thread; and generating a log data packet based on the log data, the sequence number of the log data, and the identifier of the target device.
[0011] In conjunction with the first aspect, in one possible implementation, the kernel log management method also includes adjusting the buffer storage limit based on changes in the number of log data packets sent and the number of log bytes discarded from the buffer.
[0012] Secondly, this application also provides a kernel log management system, characterized in that the system includes at least one target device and a management server, wherein the operating system kernel of the target device has a log processing module deployed therein. The log processing module is used to collect kernel log data from the target device, generate log data packets based on the log data and sequence identifiers, and send the log data packets to the management server; the sequence identifiers represent the sending order of the log data. The management server receives and parses log data packets, caches the log data into the sorted list corresponding to the target device according to the sequence identifier, and stores the log data in the sorted list into the log file corresponding to the target device based on the log data reception attributes.
[0013] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method described in the first aspect.
[0014] Fourthly, this application also provides a computer-readable storage medium. This computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the method described in the first aspect.
[0015] Fifthly, this application also provides a computer program product. This computer program product includes a computer program that, when executed by a processor, implements the method described in the first aspect.
[0016] This application provides a kernel log management method, system, device, storage medium, and program product. A log processing module that collects log data from the kernel of a target device can be deployed within the kernel of the target device. This avoids the impact of the target device's user-mode operation on kernel log collection, improving the stability and integrity of kernel log collection. Furthermore, the log processing module can generate a sequence number for the log data and package it together with the log data before sending it to a management server. This allows the management server to manage log data from different target devices in an orderly manner, improving the orderliness of log data stored on the management server and increasing the efficiency of log management across multiple target devices. Attached Figure Description
[0017] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of the architecture of a kernel log management system in one embodiment; Figure 2 This is a flowchart illustrating a kernel log management method in one embodiment; Figure 3 This is another flowchart illustrating the kernel log management method in one embodiment; Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0018] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.
[0019] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.
[0020] Operating system kernel logs are crucial for analyzing operating system faults (such as system startup anomalies, deadlocks, soft lockouts, OOM errors, panics, etc.). Their completeness and real-time performance significantly impact the efficiency and accuracy of fault location. Currently, operating system kernel log data is commonly obtained through methods such as viewing via local serial ports, reading logs using the dmesg command, and collecting logs using user-space logging services (such as syslog, rsyslog, systemd-journal, etc.).
[0021] However, the aforementioned methods of obtaining kernel logs are highly dependent on the operating system's user-mode operation. When severe anomalies such as panics or deadlocks occur, the operating system's user-mode often fails first, resulting in the inability to retain or forward critical kernel logs before and after the failure in a timely manner, making it impossible to trace the cause of the failure. Furthermore, current methods often require maintenance personnel to log into the device to view logs, making it impossible to obtain kernel logs promptly when the operating system fails. This leads to low log collection efficiency and poor log real-time performance, hindering timely troubleshooting. Especially in scenarios involving centralized log management across multiple devices (such as server clusters and embedded device networks), logging into the device to collect log data, combined with the aforementioned log acquisition methods, results in similar issues of easy log data loss, inability to achieve multi-device log management, or low management efficiency.
[0022] Based on this, embodiments of this application provide a kernel log management method, system, device, storage medium, and program product, which can improve the stability and integrity of kernel log collection and improve the log management efficiency of multiple target devices.
[0023] The kernel log management method provided in this application embodiment can be applied to, for example, Figure 1 The kernel log management system shown includes at least one target device 10 and a management server 20. The operating system kernel of the target device 10 has a log processing module 11 deployed therein, which can collect kernel log data and send it to the management server 20 for unified management. The target device 10 can be a server, embedded device, virtual machine, or other device requiring kernel log management; the management server 20 can be a standalone server or a server cluster consisting of multiple servers.
[0024] In one embodiment, such as Figure 2 As shown, a kernel log management method is provided, which can be applied to... Figure 1 Taking the kernel log management system in Windows as an example, the following steps are included: Step 101: The log processing module 11 collects the kernel log data of the target device 10, generates a log data packet based on the log data and sequence identifier, and sends the log data packet to the management server 20.
[0025] In this embodiment, a log processing module 11, such as klog_sync.ko, can be pre-built in the kernel of the target device 10. This allows the log processing module 11 to directly collect kernel log data within the operating system kernel, avoiding the influence of the operating system's user space and preventing log data loss. After collecting the log data, the log processing module 11 can generate a sequence identifier according to the log data's generation time. The log data and the sequence identifier are then encapsulated into a log data packet and sent to the management server 20. The sequence identifier can also represent the sending order of the log data; for example, it can be the sequence identifier of the previous log data + 1. This allows the management server 20 to sort and organize the log data, preventing log data corruption and ensuring the identification of log data during the operating system failure period, thus hindering fault analysis of the operating system. The operating system can be a Linux operating system.
[0026] Specifically, the log processing process of the log processing module 11 deployed in the operating system kernel may include, for example: Figure 3 The steps shown are as follows: Step 201: Obtain log data based on a pre-set callback function in the kernel and store the log data in the kernel's buffer.
[0027] In this embodiment, a callback function can be set at the `printk()` function, the log output function of the operating system kernel, using `register_console(&klog_console)`. When the kernel code reaches this callback function, it is invoked to retrieve the log data output by `printk()` and store the log data in the kernel's buffer, such as a kfifo circular buffer. This embodiment takes into account that `printk()` is the most critical log output function in the Linux operating system; therefore, setting the callback function at `printk()` ensures timely and complete retrieval of all log data generated by the operating system, preventing log data omissions and losses.
[0028] Step 202: Read log data from the buffer based on the kernel thread, and generate a log data packet based on the log data, the serial number of the log data, and the identifier of the target device.
[0029] In this embodiment, after the log data is stored in the buffer, an independent kernel thread can be allocated to read the log data from the buffer, encapsulate the log data, its sequence number, and the target device identifier into a log data packet, and send it to the management server 20. That is, the operating system kernel can obtain log data based on a callback function and send log data packets based on a kernel thread, achieving asynchronous transmission of log data with the buffer as an intermediate node. This asynchronous transmission method eliminates the need to wait for the log data to be sent to the management server before obtaining it, ensuring the real-time nature of the log data and the stable operation of the kernel. Furthermore, it avoids excessive network processing operations (log data packaging and sending) on the printk()-based kernel printing chain, preventing blockage of the kernel printing chain. Even if network transmission problems occur, it will not affect the collection and caching (storage in the buffer) of log data, effectively preventing log data loss and ensuring the integrity of the log data.
[0030] The sequence number can be a 64-bit incrementing sequence number seq, meaning that the sequence number of the current log data is monotonically increasing relative to the sequence number of the previous log data, for example, it can be +1.
[0031] In one possible implementation, the kernel-mode function kernel_sendmsg() can be used to send log data packets to the management server 20 via UDP multicast, eliminating the need for user-mode protocols and further improving the efficiency of log data transmission.
[0032] In one possible implementation, the log processing module 11 can also pre-create a virtual file / proc / klog_sync in the kernel to map the relevant running parameters of the log processing module 11 into user-readable text and send it to the operating system user space for users to view, so that operation and maintenance personnel can intuitively and timely determine the running status of the operating system kernel (log processing module 11) based on the running parameters.
[0033] The runtime parameters may include the multicast address MULTICAST_GROUP, the multicast port MULTICAST_PORT, the buffer storage limit LOG_FIFO_SIZE, the number of log bytes dropped in the buffer (drop_bytes, the number of log data bytes dropped when the buffer is full), and the number of log packets sent by the kernel (packet_count).
[0034] In one possible implementation, the buffer storage limit can be adjusted based on changes in the number of log data packets sent and the number of log bytes discarded from the buffer.
[0035] In this implementation, the log data caching pressure of the buffer can be predicted based on the changes in the number of sent log data packets and the number of discarded log bytes in the buffer. This allows for the adjustment of the buffer's storage limit, i.e., the maximum amount of log data that can be cached, to prevent log data from being discarded and to ensure the integrity of the log data.
[0036] Specifically, the growth rate can be calculated based on the number of log data packets sent in real time. If the growth rate is too high (e.g., greater than or equal to the preset growth rate), it indicates that the number of sent log data packets is growing rapidly, and the buffer may not be able to store the rapidly generated log data. Therefore, the storage limit of the buffer can be increased to prevent log data from being discarded. If the growth rate is low (e.g., greater than or equal to 0 and less than the preset growth rate), it indicates that the number of sent log data packets is growing steadily or not at all, and the buffer does not have the pressure to store log data. Therefore, it is not necessary to adjust the storage limit of the buffer.
[0037] The multicast address, multicast port, and buffer storage limit can have default values. For example, the multicast address can be 239.255.255.250, the multicast port can be 9090, and the buffer storage limit can be 128KB, so that the operating system kernel can directly collect and send log data based on the default values during startup. These operating parameters can also be adjusted by operations and maintenance personnel based on actual conditions.
[0038] Step 102: The management server 20 receives and parses the log data packets, caches the log data in the sorted list corresponding to the target device 10 according to the sequence identifier, and stores the log data in the sorted list in the log file corresponding to the target device based on the log data reception attributes.
[0039] In this embodiment of the application, the management server 20 can pre-construct the client context client_ctx of each target device 10 based on the identifier of each target device 10 in the kernel management system (e.g., the IP of the target device 10), and maintain the sorted linked list of the target device 10 and the log file client_logs / in the client context client_ctx of each target device 10.
[0040] Therefore, the management server 20 (user space) can allocate IO threads to receive log data packets. After receiving the log data packet sent by the target device 10, it can first parse the log data packet to determine the identifier of the target device 10 that sent the log data packet, as well as the order of the log data among all the log data sent by the target device 10 (i.e., the sequence number of the log data). Then, based on the identifier of the target device 10, it determines the client context of the target device 10, and caches the log data in the sorted list in the client context based on the sequence number, that is, the sorted list corresponding to the target device 10. It can be understood that the log data in the sorted list is arranged in sequence number order. The above log data storage method can avoid data mixing between different target devices 10 in the scenario of kernel log management for multiple target devices 10, ensuring that a large amount of received log data can be accurately and effectively matched to the client context of the corresponding target device 10. In addition, performing log data packet receiving and writing operations based on different threads can improve the efficiency of log data packet receiving, especially for the case of a large number of log data packets, and can ensure the orderly reception of log data packets.
[0041] For log data cached in the sorted list, the management server 20 can allocate worker threads to write (flush) the log data in the sorted list to the corresponding log file of the target device 10, thus achieving long-term stable storage of the log data. Specifically, the log data in the sorted list can be stored in the corresponding log file of the target device based on the log data's reception attributes. These reception attributes can include the number of log data items in the sorted list and the idle reception duration of the log data. The idle reception duration is the time between the reception time of the previous log data and the current time, that is, the time since the management server 20 received the previous log data packet that it has not received any log data packets.
[0042] The above embodiments illustrate that the timing of writing log data to the log file is related to the log data reception attributes. In one possible implementation, if the amount of log data in the sorted list reaches the storage limit of the sorted list, then the log data in the sorted list is stored in the log file corresponding to the target device; if the idle reception duration exceeds a preset idle duration threshold, then the log data in the sorted list is stored in the log file corresponding to the target device. The idle duration threshold can be 1 second.
[0043] In this implementation, considering the storage limit of the sorted list—that is, the maximum amount of log data that can be cached—the log data in the sorted list can be stored in the corresponding log file on the target device when the amount of log data in the sorted list reaches the storage limit. This avoids frequent writing of log data to the log file, which would otherwise consume worker thread resources, and also ensures timely writing of log data, preventing subsequent log data loss due to the inability to cache it in the sorted list.
[0044] If the management server 20 does not receive log data packets for more than the idle time threshold (e.g., 1 second), it indicates that the kernel of the target device 10 generates less log data. To avoid the security risks caused by the long-term caching of log data in the sorted list, the log data in the sorted list can be written to the log file when the idle reception time exceeds the preset idle time threshold, regardless of whether the amount of log data has reached the storage limit, so as to achieve long-term stable storage of log data.
[0045] In one possible implementation, the storage limit of the sorted linked list is adjusted based on the attribute information of the log data storage operation corresponding to the log file.
[0046] The attribute information for log data storage operations includes storage frequency and idle storage duration. Log data storage operation is the operation of writing log data from a sorted list to a log file. Storage frequency represents the number of times log data is written to the log file within 1 second. Idle storage duration is the time between the last log data storage operation and the current time, that is, the time since the last time log data from the sorted list was written to the log file, during which no data has been written to the log file.
[0047] In this implementation, if the storage frequency exceeds a preset frequency threshold, it indicates that the number of log data packets from the target device 10 currently received by the management server 20 is large. Therefore, the storage limit of the sorted list can be increased (e.g., by 1) to allow the sorted list to cache more log data, thereby reducing the number of log data storage operations and improving log data storage efficiency. If the idle storage time exceeds a preset time threshold (e.g., 2 seconds), meaning no log data storage operation occurs for more than 2 seconds, it indicates that the number of log data packets from the target device 10 currently received by the management server 20 is small. Therefore, the storage limit of the sorted list can be decreased (e.g., by 1) to increase the rate at which log data in the sorted list is stored into the log file, avoiding security risks caused by long-term caching of log data in the sorted list. When adjusting the storage limit of the sorted list, it is necessary to ensure that the storage limit is within a preset range (e.g., within the range of 5-128) to avoid caching anomalies caused by excessively large or small storage limits.
[0048] In one possible implementation, during system runtime, the management server 20 can be started first, followed by the log processing module 11 of the target device 10. This ensures that the log data packets sent by the log processing module 11 after startup can be received by the management server 20 immediately, thus preventing log data loss due to the management server 20 not starting.
[0049] The kernel log management method provided in this application can deploy a log processing module that collects log data from the target device's kernel within the target device's kernel. This avoids the impact of the target device's user-mode operation on kernel data collection, improving the stability and completeness of kernel log collection. Furthermore, the log processing module can generate a sequence number for the log data and package it together with the log data before sending it to the management server. This allows the management server to manage log data from different target devices in an orderly manner, improving the orderliness of the log data stored on the management server and increasing the efficiency of log management across multiple target devices.
[0050] In one embodiment, after the management server 20 stores the log data from the sorted list into a log file, it needs to further manage the log file to avoid storage resource consumption issues caused by the log file. This embodiment may include the following steps: if the file size of the log file corresponding to the target device 10 reaches a preset threshold, the log file is updated to a historical log file, and a new log file corresponding to the target device 10 is created, storing the log data from the sorted list into the newly created log file.
[0051] In this embodiment, a storage limit (i.e., a preset threshold, such as 10MB) for the log file can be preset. During the process of writing log data to the log file, the management server 20 can monitor the size of the log file kern.log in real time. If the log file size reaches the preset threshold, a log rotation operation is performed. That is, the current log file kern.log is updated to a historical log file (e.g., kern.log.1), and then a new log file corresponding to the target device 10 is created with the original name of the log file kern.log. This ensures that when writing log data from the sorted list later, the log data can be written to the newly created log file with free storage space.
[0052] In one possible implementation, when the size of the newly created log file kern.log reaches a preset threshold again, it can be updated to another historical log file (e.g., kern.log.2), and a new log file can be created again based on the original name kern.log to write log data. If the number of historical log files reaches a preset number (e.g., 5), to avoid consuming storage resources on the management server 20, the historical log files with earlier creation times can be deleted, ensuring that the number of historical log files remains at the preset number.
[0053] The method provided in this application can update the log file to a historical log file and create a new log file with free storage space when the log file size reaches a preset threshold, ensuring the storage location for subsequent log data. This log file rotation method can retain a fixed amount of log data, facilitating backtracking and troubleshooting of operating system failures, and can also avoid storage resource occupation issues on the management server.
[0054] In one embodiment, considering that logging into a target device to view or obtain log data can easily lead to the inability to log in or obtain log data when the operating system malfunctions, thus making it impossible to troubleshoot system faults, this application embodiment can realize remote log processing based on other target devices. That is, the log processing module 11 is also used to intercept messages sent by other target devices 10 based on hook functions of the network layer protocol pre-set in the kernel, query user instructions in a pre-configured instruction mapping table based on the length of the message, and execute the user instructions.
[0055] In this embodiment, a hook function can be pre-set in the ICMP network layer protocol of the kernel to capture packets sent by other target devices. An instruction mapping table can also be pre-built and stored in the target device 10. The instruction mapping table includes the correspondence between different packet lengths and user instructions. User instructions include at least one of log level adjustment instructions, log collection start instructions, and log collection stop instructions. For example, when the packet length is 4, the control instruction can be a log level adjustment instruction, specifically setting the target device 10's log level `console_loglevel` to 4, instructing the target 10 to only send log data with alarm levels above level 4; this instruction is suitable for scenarios where the operating system is running normally and invalid log data transmission is reduced. When the packet length is 8, the control instruction can also be a log level adjustment instruction, specifically setting the target device 10's log level `console_loglevel` to 8, instructing the target 10 to send log data with alarm levels above level 8 (i.e., all log data); this instruction is suitable for scenarios where the operating system is malfunctioning and full log data is obtained for comprehensive fault diagnosis. When the message length is 10, the control command can be a log collection start command to instruct the target device 10 to start collecting kernel logs and generate log data packets to send to the management server 20; when the message length is 11, the control command can be a log collection stop command to instruct the target device 10 to stop collecting kernel logs.
[0056] In this embodiment, when target device 10 malfunctions and cannot log in, and cannot collect log data, maintenance personnel can log in to other target devices and generate messages (e.g., ping messages) based on the ICMP protocol and send them to the malfunctioning target device, for example, by sending "ping -s 10". <client-ip>"," where client-ip is the identifier of the faulty target device. A hook function in the network layer protocol pre-configured in the kernel of the faulty target device can capture the packet, parse the packet, determine the packet length, look up the corresponding user instruction in the pre-configured instruction mapping table based on the packet length, and execute the user instruction.
[0057] This application embodiment enables remote control of log data collection from a target device based on pre-set hook functions and instruction mapping tables. This avoids the problem of being unable to collect log data or troubleshoot due to target device malfunction. Furthermore, this application embodiment establishes a relationship between message length and instructions, enabling remote control of the target device based on simple message length characteristics, thus improving the efficiency of log management.
[0058] It should be noted that although the operations of the method of the present invention are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.
[0059] The following is for reference. Figure 4 It shows a schematic diagram of the structure of a computer system 400 suitable for implementing terminal devices or servers in the embodiments of this application.
[0060] like Figure 4 As shown, the computer system 400 includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 402 or programs loaded from storage section 408 into random access memory (RAM) 403. The RAM 403 also stores various programs and data required for the operation of the system 400. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.
[0061] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from them can be installed into storage section 408 as needed.
[0062] In particular, according to embodiments of this disclosure, the above references Figure 2 The described process can be implemented as a computer software program. For example, embodiments of this disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program containing instructions for performing... Figure 2 The program code for the method. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable media 411.
[0063] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0064] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0065] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not, in certain circumstances, constitute a limitation on the unit or module itself.
[0066] On the other hand, this application also provides a computer-readable storage medium, which may be included in the computer device described in the above embodiments, or may exist independently and not assembled into the computer device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figure 2 The steps of the method shown.
[0067] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figure 2 The steps of the method shown.
[0068] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.
[0069] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.
Claims
1. A kernel log management method, characterized in that, This is applied to a kernel log management system, which includes at least one target device and a management server. The target device's operating system kernel has a log processing module deployed in it. The log processing module collects the kernel log data of the target device, generates a log data packet based on the log data and sequence identifier, and sends the log data packet to the management server. The sequence identifier indicates the sending order of the log data; The management server receives and parses the log data packets, caches the log data in the sorted list corresponding to the target device according to the sequence identifier, and stores the log data in the sorted list in the log file corresponding to the target device based on the receiving attributes of the log data.
2. The method according to claim 1, characterized in that, The receiving attributes include the number of log data in the sorted list and the idle receiving duration of the log data. The step of storing the log data in the sorted list to the log file corresponding to the target device based on the receiving attributes of the log data includes: If the number of log data in the sorted list reaches the storage limit of the sorted list, then the log data in the sorted list will be stored in the log file corresponding to the target device. If the idle reception duration exceeds a preset idle duration threshold, the log data in the sorted list will be stored in the log file corresponding to the target device; the idle reception duration is the duration between the reception time of the previous log data and the current time.
3. The method according to claim 2, characterized in that, The method further includes: The storage limit of the sorted linked list is adjusted based on the attribute information of the log data storage operation corresponding to the log file; the attribute information of the log data storage operation includes storage frequency and idle storage duration; the idle storage duration is the duration between the time of the previous log data storage operation and the current time.
4. The method according to claim 2, characterized in that, The method further includes: If the file size of the log file corresponding to the target device reaches a preset threshold, the log file is updated to a historical log file, and a new log file corresponding to the target device is created, storing the log data in the sorted list into the newly created log file.
5. The method according to claim 1, characterized in that, The method further includes: The log processing module is further configured to intercept packets sent by other target devices based on hook functions of the network layer protocol pre-configured in the kernel, query user instructions in a pre-configured instruction mapping table based on the length of the packet, and execute the user instructions; the instruction mapping table includes the correspondence between different packet lengths and user instructions, and the user instructions include at least one of log level adjustment instructions, log collection start instructions, and log collection stop instructions.
6. The method according to claim 1, characterized in that, The process of collecting kernel log data from the target device and generating log data packets based on the log data and sequence identifiers includes: The log data is obtained based on a pre-set callback function in the kernel, and the log data is stored in the kernel's buffer. The kernel thread reads log data from the buffer and generates the log data packet based on the log data, the serial number of the log data, and the identifier of the target device.
7. A kernel log management system, characterized in that, The system includes at least one target device and a management server. The target device's operating system kernel has a log processing module deployed in it. The log processing module is used to collect the kernel log data of the target device, generate a log data packet based on the log data and sequence identifier, and send the log data packet to the management server. The sequence identifier indicates the sending order of the log data; The management server is configured to receive and parse the log data packets, cache the log data in the sorted list corresponding to the target device according to the sequence identifier, and store the log data in the sorted list in the log file corresponding to the target device based on the receiving attributes of the log data.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.