A method and device for reporting and warning kernel faults

Abstract

The application provides a kind of kernel fault report and early warning method and device, belong to computer kernel fault processing technical field, including early warning message generation layer, early warning message transmission layer and early warning message processing layer connected in turn information, wherein, early warning message generation layer includes each subsystem of kernel and early warning message collection and release program;Early warning message transmission layer is connected with early warning message generation layer and early warning message processing layer respectively and is communicated, including a kernel Kalert Core module;Early warning message processing layer is communicated with early warning message transmission layer and is used for receiving early warning message and processing.The application realizes the efficient real-time early warning of unified kernel fault event, complements the current various kernel fault detection tools, enhances the reliability and maintainability of system, reduces operation and maintenance cost.

Description

TECHNICAL FIELD

[0001] The present application relates to kernel faults, in particular to a kernel fault reporting and early warning method and device, belonging to the technical field of computer kernel fault processing. BACKGROUND

[0002] With the rapid development of cloud computing, big data and distributed architecture, Linux servers are increasingly widely used in enterprises and Internet services. However, the high concurrency, large-scale data processing and continuous running characteristics of servers pose unprecedented challenges to the stability and reliability of operating systems.

[0003] The Linux kernel is the core of stable system operation, which manages hardware resources, provides system call interfaces, and supports the efficient operation of upper-layer applications. Kernel faults not only can cause single node performance degradation, system downtime and other problems, but also can affect the entire distributed system, causing data loss, service interruption and even economic losses. Therefore, building an efficient kernel fault detection and early warning framework is crucial to ensuring system high availability.

[0004] Currently, traditional kernel fault detection methods mainly rely on the kernel to throw out dmesg logs, and then analyze the logs in the user state; or actively analyze kernel events through various debugging tools. Although with the development of debugging technologies such as ebpf, the efficiency of kernel fault detection and analysis has been greatly improved; but there are still the following problems:

[0005] ① Lack of timeliness: it is difficult to capture sudden faults of kernel critical paths through log analysis and active detection.

[0006] ② Serious fragmentation: different formats and mechanisms are used by various subsystems of the kernel and various debugging tools to throw out fault information, making it difficult for the user state to implement automated fault handling.

[0007] ③ Poor compatibility: most debugging tools need to be frequently adapted with the change of kernel version. SUMMARY

[0008] To solve the above problems, the present application provides a kernel fault reporting and early warning method and device.

[0009] To achieve the above purpose, the technical scheme of the present application is as follows: a kernel fault reporting and early warning device, comprising a warning message generation layer, a warning message transmission layer and a warning message processing layer connected in sequence, wherein,

[0010] The early warning message generation layer includes various subsystems of the kernel and an early warning message collection and publishing program. The early warning message generation layer reports the fault events that have occurred in various subsystems of the kernel related to the key path of the kernel to the early warning message transmission layer through a unified interface, or analyzes the early warning messages of potential faults generated by the kernel by the early warning message collection and publishing program, and also reports the early warning messages to the early warning message transmission layer through the unified interface.

[0011] The early warning message transmission layer is in communication connection with the early warning message generation layer and the early warning message processing layer, and includes a kernel Kalert Core module, which is responsible for efficient and real-time classification and forwarding of the received early warning messages, and processing of the user state commands transmitted by the early warning message processing layer.

[0012] The early warning message processing layer is in communication connection with the early warning message transmission layer, and is used for receiving and processing the early warning messages.

[0013] Further, the early warning message collection and publishing program and various subsystems of the kernel publish the early warning messages in the manner of "type + severity level + specific event" when publishing the early warning messages to the early warning message transmission layer.

[0014] Further, the types of the early warning messages include memory, IO, file system and general type when the early warning message collection and publishing program and various subsystems of the kernel publish the early warning messages to the early warning message transmission layer.

[0015] Further, the early warning message processing layer includes a libkalert library, a management daemon, a trusted subscriber and a web front end.

[0016] The libkalert library is connected with the management daemon and the trusted subscriber, and at the same time, establishes a Netlink high-speed early warning channel with the Kalert Core module of the early warning message transmission layer through the Netlink communication protocol, so that the management daemon and the trusted subscriber receive the early warning messages forwarded by the Kalert Core module in the Netlink high-speed early warning channel through the libkalert library, and at the same time, the management daemon and the trusted subscriber also transmit the user state commands to the Kalert Core module in the Netlink high-speed early warning channel through the libkalert library, to realize full-duplex communication.

[0017] The trusted subscriber is connected with the web front end at the same time, and is used for analyzing and processing the early warning messages, and displaying the early warning messages through the web front end.

[0018] Further, the management daemon is responsible for parameter configuration of the Netlink high-speed early warning channel, and records the logs of the early warning messages to the hard disk; and the trusted subscriber is a plurality of user state kernel fault processing programs.

[0019] Further, the Kalert Core module provides a sysfs interface for trusted subscribers and debuggers to quickly obtain the runtime state and parameters of the Netlink high-speed early warning channel.

[0020] Further, the Kalert Core module also reserves a tracepoint for debuggers to bypass the original early warning message through ebpf.

[0021] The device and method for reporting and warning of kernel faults described above include the following steps:

[0022] Step S1, netlink high-speed early warning channel establishment: the kernel initializes the kalert core module, the management daemon initializes the channel parameters, the management daemon initiates a request to establish a netlink high-speed early warning channel, the libkalert library receives the request and creates a socket connection and sends a setting request, and the kalert Core module creates a socket connection and saves the connection according to the request;

[0023] Step S2, early warning rule setting: trusted subscribers subscribe to kernel fault types and are recorded in the subscriber hash table in the kalert core module;

[0024] Step S3, early warning message dispatching: the early warning message generation layer sends the early warning message to the notification backlog queue of the kalert core module, and the Kalert Core module classifies and dispatches the early warning message through the libkalert library according to the early warning rules of the management daemon and trusted subscribers;

[0025] Step S4, early warning message processing: the management daemon and trusted subscribers classify and process kernel faults, and send the analysis and processing results to the Web front end for display or take corresponding decisions according to actual conditions.

[0026] Further, in step S3, when the kalert core module classifies and dispatches the early warning message through the libkalert library according to the early warning rules of the management daemon and trusted subscribers, the early warning notification thread maintained therein is used to continuously take the early warning message from the notification backlog queue for classification and dispatching.

[0027] Further, if the early warning notification thread fails more than 5 times during the transmission of a certain early warning message, the connection is cleared, and if the failure is less than 5 times, the transmission is re-performed.

[0028] The kernel fault reporting and warning method and device have the following advantages:

[0029] The application realizes unified kernel fault event efficient real-time early warning, complements current various kernel fault detection tools, enhances system reliability and maintainability, and reduces operation and maintenance cost.

[0030] The application adopts a netlink multicast communication framework based on a subscription and publication model, can realize a unified kernel fault event classification and hierarchical reporting mechanism, solves fragmentation problems, greatly reduces the difficulty of user state intelligent early warning processing, and enhances the timeliness of fault early warning and the accuracy of message publishing. BRIEF DESCRIPTION OF DRAWINGS

[0031] The application will be further described below in combination with the drawings and specific embodiments.

[0032] Figure 1 is a general framework diagram of the kernel fault reporting and early warning device of the application;

[0033] Figure 2 is a netlink communication framework diagram in the kernel fault reporting and early warning method of the application;

[0034] Figure 3 is a schematic diagram of a traditional netlink multicast in the prior art;

[0035] Figure 4 is a subscription and publication model diagram in the kernel fault reporting and early warning method of the application. DETAILED DESCRIPTION

[0036] The technical solutions in the embodiments of the application will be described clearly and completely below in combination with the drawings in the embodiments of the application. In the following description, many specific details are set forth in order to provide a thorough understanding of the application, but the application can also be implemented in other ways different from those described herein, and those skilled in the art can make similar generalizations without departing from the connotation of the application, so the application is not limited to the specific embodiments disclosed below.

[0037] Embodiment 1

[0038] The method and device for kernel fault reporting and early warning of the application adopt a netlink multicast communication framework based on a subscription and publication model, and the following specific kernel fault reporting and early warning device is described in detail. Referring to Figure 1 The device adopts a layered design, and specifically includes an early warning message generation layer, an early warning message transmission layer and an early warning message processing layer connected in sequence, wherein the running state of the early warning message generation layer and the early warning message transmission layer is a kernel state, and the running state of the early warning message processing layer is a user state.

[0039] The early warning message generation layer includes various subsystems of the kernel (not directly shown in the figure) and an early warning message collection and publishing program. The early warning message generation layer reports the fault event that has occurred in each subsystem of the kernel related to the kernel critical path to the early warning message transmission layer through a unified interface, or analyzes the early warning message of the potential fault generated by the kernel by the early warning message collection and publishing program, and also reports to the early warning message transmission layer through a unified interface.

[0040] As shown in Figure 1 In order to solve the problem of fault reporting fragmentation, the kernel fault type in the application is divided into: memory / IO / file system / general type (general type Figure 1 not shown).

[0041] At the same time, one fault type may have multiple events, such as memory leakage, memory allocation failure, etc. for memory fault; and each early warning message can be divided into debug / warn / error / fatal according to the severity level.

[0042] Therefore, in the application, the early warning message collection and publishing program and each subsystem of the kernel publish the early warning message to the early warning message transmission layer in the manner of "type + severity level + specific event".

[0043] The early warning message transmission layer is in communication connection with the early warning message generation layer and the early warning message processing layer, mainly including a kernel Kalert Core module, which is responsible for efficiently and timely classifying and forwarding the received early warning messages, and processing the user state command transmitted by the early warning message processing layer. The Kalert Core module realizes a custom netlink multicast protocol based on the subscription and publishing model, and provides a sysfs interface for trusted subscribers and debuggers to quickly obtain the runtime state, parameters, etc. of some channels (i.e. Netlink high-speed early warning channel); the Kalert Core module also reserves a tracepoint for ebpf bypassing the original early warning message, so that the debugger can directly debug the fault.

[0044] The early warning message processing layer is composed of libkalert library, management daemon, trusted subscriber and web front end.

[0045] Wherein, the libkalert library implements encapsulation of the underlying Netlink communication protocol, and the libkalert library is connected downward with the Kalert Core module through the jointly agreed Netlink communication protocol to establish a Netlink high-speed early warning channel; the libkalert library also provides a simple and efficient interface upward to the management daemon and the trusted subscriber. That is, the libkalert library provides an interface for data exchange between the Kalert Core module and the management daemon and the trusted subscriber: the management daemon and the trusted subscriber receive the kernel fault early warning messages forwarded by the Kalert Core module in the Netlink high-speed early warning channel through the libkalert library; at the same time, the management daemon and the trusted subscriber also transmit user state commands to the Kalert Core module in the Netlink high-speed early warning channel through the libkalert library, to realize full-duplex communication.

[0046] The management daemon is responsible for parameter configuration of the Netlink high-speed early warning channel, and recording logs of early warning messages to a hard disk, etc. The management daemon accepts all types of events by default, but can adjust the severity level to filter unimportant messages.

[0047] The trusted subscriber is a plurality of user state kernel fault handlers, which subscribes to one or more types of kernel fault early warning messages through the Netlink high-speed early warning channel. In principle, one subscriber is responsible for analyzing and processing one type of kernel fault event, and it can adjust the severity level of the subscribed event, or specify a specific event, such as subscribing only to memory allocation failure events.

[0048] The Web front end is responsible for displaying the kernel fault early warning results analyzed and processed by the trusted subscriber, or taking corresponding decisions according to actual conditions.

[0049] In addition, the early warning message processing layer also includes a sysfs submodule and a debugging submodule. The sysfs submodule is connected in communication with the Kalert Core module through a sysfs auxiliary debugging channel, and the sysfs submodule is also connected in communication with the debugging submodule and the trusted subscriber, so as to facilitate the kernel fault handlers in the trusted subscriber and the debugging submodule to quickly obtain some runtime states and parameters of the channel from the sysfs auxiliary debugging channel through the sysfs interface provided by the sysfs submodule; the debugging submodule is connected in communication with the ebpf in the early warning message transmission layer, so that the debugger can directly obtain the original early warning message through the ebpf-based tool to perform fault debugging.

[0050] In addition, it should be noted that the management daemon is named kalertd, which is the user state default management daemon responsible for controlling the kalert Core module and the user state Netlink high-speed early warning channel.

[0051] Embodiment 2

[0052] Reference Figure 2 As shown in the embodiment 1, on the basis, further refine the implementation details and data flow of kernel failure and early warning message from the user state receiving, the core function is completed by the kalert core module and the user state program jointly established Netlink high-speed early warning channel, through the self-defined Netlink communication protocol realizes full duplex real-time communication, solves the problem of real-time insufficiency of fault time detection, the specific process is as follows:

[0053] 1、 in the application, it is agreed that the user state can send subscription / configuring command to the kernel kalert Core module, specifically, the management daemon sends configuration rules, establishes connection and the like command, and the trusted subscriber sends respective subscription configuration; the subscription / configuring command is sent to the kernel socket acceptance queue in the Netlink high-speed early warning channel through the Netlink communication protocol;

[0054] 2、 the kalert Core module obtains the command of setting early warning rules from the kernel socket acceptance queue, then sets early warning rules, if the command needs to reply, then generates an instant reply work queue, and the asynchronous reply message to the user state is realized in the work queue;

[0055] 3、 then, the kalert Core module transmits the early warning rules to the early warning message generation layer, for generating customized early warning events (kernel default early warning events not reported) according to the rules;

[0056] 4、 the early warning message generation layer generates kernel failure early warning message according to the set early warning rules, publishes the message through a unified interface, and the kernel failure early warning message is queued in turn and enters the notification backlog queue maintained in the kalert Core module, in the case that the notification backlog queue is full, the early warning message is discarded actively and the packet loss is counted;

[0057] 5、 the kalert Core module maintains an early warning notification thread, which takes out the kernel failure early warning message from the notification backlog queue and sends it to the user socket acceptance queue through the Netlink communication protocol, so as to realize the real-time notification of the kernel failure to the user state;

[0058] The early warning notification thread is cleared after more than 5 times of failure in the process of transmitting a kernel failure early warning message, if the failure is less than 5 times, the transmission is re-performed; when the notification backlog queue is full, the kernel failure early warning message is discarded actively, and the system automatically counts the packet loss.

[0059] 6、Trusted subscriber and management daemon accept the early warning message from the user socket accept queue, the trusted subscriber feedback to the web front-end after further analysis and processing of the accepted early warning message, the management daemon accept the early warning message and save the log;

[0060] 7、When the user state needs to change the subscription rules, and issue some messages such as Figure 1 messages, the user state initiates communication actively, sends commands to the kernel socket accept queue through the netlink communication protocol; the kernel processes the messages (such as setting the early warning rules) after receiving the messages, and according to whether the messages need to be replied, an instant reply work queue may be generated to asynchronously reply the success or failure of the execution of the command of the user state program this time;

[0061] Based on the above function, the present application solves the problem of insufficient real-time performance of kernel fault event detection.

[0062] Embodiment 3

[0063] Referring to Figure 4 , the netlink multicast communication is further refined on the basis of the foregoing embodiment, specifically:

[0064] The kernel kalert core module maintains a subscriber hash table to save the user state subscription connection; in addition, it also maintains a message dispatcher bucket chain table to save the reference count of each subscription connection and their atomic subscription rules (when subscribing to multiple type topics, they are split into multiple atomic subscriptions); the fault early warning message publisher publishes the messages to the notification backlog queue; the kernel notification thread continuously takes the early warning messages from the notification backlog queue, and then traverses the dispatcher bucket chain table corresponding to the current message type to complete the message dispatching according to the atomic subscription rules.

[0065] Among them, the message subscriber, i.e. the trusted subscriber, Figure 4 shows four subscribers and the kernel fault types they subscribe to. The message publisher, i.e. the early warning message collection and publishing program in the early warning message generation layer and each kernel subsystem, adds the generated early warning messages to the notification backlog queue, and the notification backlog queue records each early warning message in the form of "type + severity level + specific event", Figure 4 shows four types of kernel faults. The subscriber hash table maintained by the kalert core module sorts the subscribers according to the kernel fault type; the message dispatcher bucket chain table maintained by the kalert core module saves the reference count of each subscription connection and their atomic subscription rules; the notification thread created by the Kalert Core module continuously takes the early warning messages from the notification backlog queue, and then traverses the dispatcher bucket chain table corresponding to the current message type to complete the message dispatching according to the atomic subscription rules.

[0066] Figure 4 In the table, "NA" means that the subscriber does not specify a specific event to be subscribed or does not specify a specific type of a specific event to be subscribed. No specification means subscribing to all types or subscribing to all events of the type. Subscriber 1 subscribes to all kernel fault events of fatal level and above; subscriber 2 subscribes to all mem and gen events of error level and above, wherein the mem event only subscribes to the memleak type event, and the gen event only subscribes to the softlockup type event; subscriber 3 subscribes to all mem memory fault events of warn level and above; and subscriber 4 subscribes to all gen general events of fatal level and above. The alloc failed means an allocation memory failure event, which belongs to a subclass of the memory type event; similarly, the memleak means a memory leak event, which also belongs to a subclass of the mem memory event.

[0067] Figure 4 In the table, the events in the notification backlog queue are dispatched according to the dispatching rule, dispatched to the corresponding position in the dispatcher bucket linked list according to the event type, and then the subscribers are inserted into the corresponding position in the dispatcher bucket linked list according to the event type subscribed by each subscriber, as shown in Figure 4 Since subscriber 2 and subscriber 4 subscribe to GEN type events, subscriber 2 and subscriber 4 are inserted into the GEN position of the dispatcher bucket linked list (Disp2 and Disp4 are connected with GEN in the figure), and similarly, subscriber 2 and subscriber 3 are inserted into the MEM position of the dispatcher bucket linked list (Disp2 and Disp3 are connected with MEM in the figure), and subscriber 1 is inserted into the ALL position of the dispatcher bucket linked list (Disp1 is connected with ALL in the figure).

[0068] Finally, the message receiving situation of each subscriber is counted according to the level and specific event corresponding to the event type subscribed by each subscriber; the first column of the notification backlog queue, notification 1, notification 2, notification 3, and notification 4 represent the messages in the four notification backlog queues. The message receiving situation table stores the number of specific events in the notification backlog queue and the matching subscriber. For a specific event, if no subscriber corresponding to the event is matched, "NA" is used to represent it. For example, subscriber 1 subscribes to all events of fatal level and above, and finally subscriber 1 receives the warning message 3 as shown in the table, and similarly, subscriber 2 receives the warning messages 3 and 4, subscriber 3 receives the warning messages 1 and 4, and subscriber 4 receives the warning message 3.

[0069] In addition, Figure 4The number in the notification backlog queue represents the "nth notification"; the number in the subscriber hash table is a hash value, which can be understood as the "nth subscriber". The maximum length of the hash table is 1024 by default (a suitable value can be changed according to actual needs). If it exceeds 1024, such as the 1025th subscriber, it may be hashed into the same hash bucket as the first subscriber.

[0070] Figure 3 For an example of the traditional netlink multicast communication mode: subscriber 1 subscribes to all types of MEN, FS, and GEN fault types, subscriber 2 subscribes to MEN and GEN types, subscriber 3 subscribes to MEM type, and subscriber 4 subscribes to GEN type; the notification backlog queue of the message publisher has accumulated 4 fault warning notifications: MEM_warn_allocfailed (memory allocation failure event of warn level), FS_warn_ext4warn (ext4 file system warning of warn level), GEN_fatal_softlockup (softlockup event of fatal level), and MEM_error_memleak (memory leak event of error level), respectively. According to the subscription rules of each subscriber, MEM_warn_allocfailed will be sent to: subscriber 1, subscriber 2, and subscriber 3; FS_warn_ext4warn will be sent to: subscriber 1; GEN_fatal_softlockup will be sent to: subscriber 1, subscriber 2, and subscriber 4. MEM_error_memleak will be sent to: subscriber 1, subscriber 2, and subscriber 3.

[0071] In fact, the message can be various, but all are type_level_event (i.e., the event combination of event type + event severity level + specific event mentioned above). For example, Figure 3 The notification backlog queue of the warning message generation layer generates four messages and puts them into the notification backlog queue. From the dispatch result statistics, it can be found that the subscriber can only subscribe to all events of a certain type such as mem, and cannot subscribe to only memleak memory leak events or fatal / error... level events. That is, it is not possible to select a fine subscription target, and a lot of redundant information will be received, which leads to frequent wake-up of the user process and reduces the message processing efficiency.

[0072] From Figure 3 and Figure 4It can be found that the traditional netlink multicast communication mode has the following problems: ① When the kernel state publishes a message, it can only be forwarded to all members in the multicast group, and the user state subscriber will receive a large number of redundant multicast messages, which will cause the user process to be frequently awakened, reducing the communication efficiency. ② The user state subscriber cannot finely control the subscription topic and can only subscribe to the topic type, and cannot implement complex filtering logic such as severity level and subscription to only one sub-event.

[0073] The subscription and publication model of the application can realize fine control of the publication object, improve the accuracy and efficiency of the user state receiving messages, and greatly reduce the difficulty of the user state processing kernel fault warning messages.

[0074] Embodiment 4

[0075] The method for reporting and warning kernel faults by using the device described in the above embodiments includes the following steps:

[0076] Step S1, netlink high-speed warning channel establishment: the kernel initializes the kalert core module and completes the socket creation of the NETLINK_KALERT protocol number; the management daemon initiates a request to the kernel Kalert Core module through the interface provided by the libkalert library to establish a netlink high-speed warning channel, and initializes the channel parameters, and the kernel kalert core module accepts the request and completes the channel establishment after successful verification;

[0077] Step S2, warning rule setting: the trusted subscriber subscribes to the kernel fault event type that the user wants to focus on through the interface provided by the libkalert library, and sets the warning rule and other operations, and the kalert core module records the subscriber information in the subscriber hash table of the module;

[0078] Step S3, warning message dispatching: the warning message generation layer sends the kernel fault warning message to the notification backlog queue of the kalert core module, the kalert core module first dispatches the event to the management daemon; then finds the corresponding dispatcher bucket (such as memory / file system, etc.) according to the notification type, and finally traverses all trusted subscribers in the bucket, and dispatches the kernel fault notification in real time according to the subscription rules set by the trusted subscriber;

[0079] Step S4, warning message processing: the management daemon and the trusted subscriber accept the kernel fault warning message based on the libkalert library and analyze it, and then send the analysis processing result to the Web front end to display the result or take corresponding decisions according to the actual situation.

[0080] Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

Claims

1. A kernel fault reporting and early warning device, characterized in that, The early warning message generation layer, the early warning message transmission layer and the early warning message processing layer are connected in sequence, wherein The early warning message generation layer comprises a kernel each subsystem and an early warning message collection and publishing program, the early warning message generation layer reports the fault event occurred in each subsystem of the kernel related to the kernel critical path to the early warning message transmission layer through a unified interface, or analyzes the early warning message of the potential fault generated by the kernel through the early warning message collection and publishing program, and also reports to the early warning message transmission layer through the unified interface; The early warning message transmission layer is in communication connection with the early warning message generation layer and the early warning message processing layer, and comprises a kernel Kalert Core module, the early warning message generation layer sends the early warning message to the notification backlog queue of the Kalert Core module, the Kalert Core module is responsible for efficient and real-time classification and forwarding of the received early warning message, and processing of the user state command transmitted by the early warning message processing layer; The early warning message processing layer is in communication connection with the early warning message transmission layer, and is used for receiving and processing the early warning message; The early warning message collection and publishing program and each subsystem of the kernel publish the early warning message in the manner of "type + severity level + specific event" when publishing the early warning message to the early warning message transmission layer; The early warning message processing layer comprises a libkalert library, a management daemon, a trusted subscriber and a web front end; The libkalert library is connected with the management daemon and the trusted subscriber, and simultaneously establishes a Netlink high-speed early warning channel with the KalertCore module of the early warning message transmission layer through the Netlink communication protocol, so that the management daemon and the trusted subscriber receive the early warning message forwarded by the Kalert Core module in the Netlink high-speed early warning channel through the libkalert library, and simultaneously transmit the user state command to the Kalert Core module in the Netlink high-speed early warning channel through the libkalert library, to realize full-duplex communication; the trusted subscriber subscribes to the kernel fault type and is recorded in a subscriber hash table in the Kalert Core module, and the Kalert Core module classifies and distributes the early warning message according to the early warning rules of the management daemon and the trusted subscriber through the libkalert library; The trusted subscriber is connected with the web front end, and is used for analyzing and processing the early warning message, and displaying through the web front end.

2. The kernel fault reporting and early warning device of claim 1, wherein, The type of the early warning message includes memory, IO, file system and general type when the early warning message collection and publishing program and each subsystem of the kernel publish the early warning message to the early warning message transmission layer.

3. The kernel fault reporting and early warning device according to claim 1, characterized in that, The management daemon is responsible for parameter configuration of the Netlink high-speed early warning channel, and recording the log of the early warning message to the hard disk; The trusted subscriber is a plurality of user state kernel fault processing programs.

4. The kernel fault reporting and early warning device of claim 1, wherein, The KalertCore module simultaneously provides a sysfs interface for the trusted subscriber and a debugger to quickly obtain the runtime state and parameters of the Netlink high-speed early warning channel.

5. The kernel fault reporting and early warning device of claim 1, wherein, The KalertCore module also reserves tracepoints for debuggers to bypass the original alert message through ebpf.

6. The method for reporting and warning of kernel faults by the apparatus according to any one of claims 1-5, characterized in that, The method comprises the following steps: Step S1, netlink high-speed alert channel establishment: the kernel initializes the kalert core module, the management daemon initializes the channel parameters, the management daemon initiates a request to establish a netlink high-speed alert channel, the libkalert library receives the request, creates a socket connection and sends a setting request, and the kalert Core module creates a socket connection and saves the connection according to the request; Step S2, setting of an alert rule: a trusted subscriber subscribes to a kernel fault type and is recorded in a subscriber hash table in the kalert core module; Step S3, dispatching of an alert message: an alert message generation layer sends an alert message to a notification backlog queue of the kalert core module, the Kalert Core module classifies and dispatches the alert message through the libkalert library according to the alert rules of the management daemon and the trusted subscriber; Step S4, processing of the alert message: the management daemon and the trusted subscriber classify and process the kernel fault, and send the analysis and processing result to a Web front end to display the result or take corresponding decisions according to actual conditions.

7. The method for reporting and warning of core faults according to claim 6, characterized in that, In step S3, when the kalertcore module classifies and dispatches the alert message through the libkalert library according to the alert rules of the management daemon and the trusted subscriber, an alert notification thread maintained therein continuously takes the alert message from the notification backlog queue to classify and dispatch the alert message.

8. The method for reporting and warning of core faults according to claim 7, characterized in that, The alert notification thread clears the connection after a failure in transmitting a certain alert message for more than 5 times, and retransmits the alert message if the failure is less than 5 times.

Images