Log pushing method, electronic device, storage medium and product

Abstract

The application provides a log pushing method, an electronic device, a storage medium and a product. The method comprises the following steps: acquiring a plurality of kernel crash logs; determining, based on the plurality of kernel crash logs, a plurality of first function information of a plurality of functions associated with a function call stack of a corresponding kernel and kernel state information of the corresponding kernel; the first function information represents a code position feature of a corresponding function when the kernel crashes; determining a topic corresponding to each kernel crash log based on the plurality of first function information and the kernel state information corresponding to each kernel crash log; and pushing the plurality of kernel crash logs to a user who has subscribed to the corresponding topic according to the topics corresponding to the plurality of kernel crash logs. The method can accurately push the kernel crash logs.

Description

Technical Field

[0001] This application relates to kernel technology, and more particularly to a log push method, electronic device, storage medium, and product. Background Technology

[0002] In Linux systems, a kernel crash can refer to an unrecoverable error encountered by the kernel, which may cause the system to stop running or continue running after logging the error. Users can analyze the kernel crash logs generated when a kernel crash occurs to identify the cause and solutions. Therefore, pushing kernel crash logs to users is particularly important.

[0003] Related log push solutions typically extract one or more types of data from kernel memory data, call stack information, and register information from kernel crash logs to determine the kernel crash type. For example, feature vectors of call stack information are extracted from kernel crash logs and matched with the similarity of standard call stack feature vectors for various types of crashes. Based on the matching results, the corresponding kernel crash type is identified, and then the crash type, along with the original kernel crash log, is pushed to the user so that the user knows the specific crash type in the kernel crash log.

[0004] However, this method focuses on determining the crash type of kernel crash logs through the similarity of feature vectors. The crash type pushed is used to inform users of the kernel crash type, but it cannot accurately push kernel crash logs to specific groups of people. Summary of the Invention

[0005] This application provides a log push method, an electronic device, a computer-readable storage medium, and a computer program product that can accurately push kernel crash logs.

[0006] This application provides a log push method, the method including: Retrieve multiple kernel crash logs; Based on multiple kernel crash logs, the first function information of each of the multiple functions associated with the function call stack of the corresponding kernel is determined, as well as the kernel state information of the corresponding kernel; the first function information represents the code location characteristics of the function corresponding to the kernel crash. Based on the multiple first function information and kernel state information corresponding to each kernel crash log, the topic corresponding to each kernel crash log is determined. Based on the topics corresponding to multiple kernel crash logs, push multiple kernel crash logs to users who have subscribed to the corresponding topics.

[0007] In the above scheme, based on the multiple first function information and kernel state information corresponding to each kernel crash log, the topic corresponding to each kernel crash log is determined, including: For each kernel crash log, the first crash feature of the kernel is determined based on multiple first function information; the first crash feature represents the code location characteristics of the target function that caused the kernel crash; The kernel's second crash characteristic is determined based on the kernel state information; the second crash characteristic represents one or more of the kernel's version information, host information, and runtime state information. Based on the first and second crash characteristics, the kernel fusion characteristics are determined; Based on the fusion characteristics, the topic corresponding to the kernel crash log is determined.

[0008] In the above scheme, before pushing multiple kernel crash logs to users who have subscribed to the corresponding topics, the method further includes: Determine the fingerprint corresponding to each kernel crash log; the fingerprint represents the function execution path reflected by the function call stack at the time of the kernel crash; Based on the fingerprint corresponding to each kernel crash log, multiple kernel crash logs are deduplicated.

[0009] In the above scheme, the fingerprint includes a hash identifier; determining the fingerprint corresponding to each kernel crash log includes: For each kernel crash log, determine the second function information for each function associated with the function call stack at the time of the kernel crash; the second function information contains different content from the first function information; the second function information represents the identification characteristics of the corresponding function in the function execution path; Inject multiple second function information into a preset function stack; After all the second function information is injected into the preset function stack, the build identifier in the kernel crash log is hashed with multiple second function information in the preset function stack to obtain the hash identifier corresponding to the kernel crash log; the build identifier is used to distinguish different versions of the kernel.

[0010] In the above scheme, determining the second function information of each function associated with the function call stack at the time of kernel crash includes: For each function, if the function is associated with the kernel source image, the second function information is determined to be the function name and the kernel source image name; the kernel source image is the image file of the compiled kernel. In the case where the function is associated with a module, the second function information is determined to be the function name corresponding to the function and the module name corresponding to the module; the module is the module that is loaded into the kernel's virtual address space during the kernel runtime phase.

[0011] In the above scheme, based on multiple kernel crash logs, the first function information of each of the multiple functions associated with the corresponding kernel function call stack is determined, including: For each kernel crash log, determine the virtual address of each function associated with the function call stack at the time of the kernel crash; Based on multiple virtual addresses, determine the first function information for each function.

[0012] In the above scheme, the kernel state information of the corresponding kernel is determined based on multiple kernel crash logs, including: For each kernel crash log, the corresponding kernel configuration information is determined based on the kernel crash log; the configuration information includes kernel version information and host information; Identify keywords in multiple runtime logs associated with the corresponding kernel; Based on the configuration information and keywords, determine the kernel status information of the corresponding kernel.

[0013] This application provides an electronic device, which includes: Memory is used to store executable instructions or computer programs. When a processor executes computer-executable instructions or computer programs stored in memory, it implements the log push method provided in the embodiments of this application.

[0014] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implements the log push method provided in this application.

[0015] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, the log push method provided in this application is implemented.

[0016] In the above scheme, kernel crash logs from multiple kernels are obtained. For each kernel, based on the kernel crash logs, multiple first function information and kernel state information corresponding to the kernel are determined. The first function information represents the code location characteristics of each function associated with the kernel's function call stack at the time of the kernel crash. Based on the multiple first function information and kernel state information, the topic corresponding to the kernel crash log is determined. At least one kernel crash log corresponding to each topic is pushed to users who have subscribed to the corresponding topic. In this process, compared with related technologies that use feature vector matching of call stack information to determine the crash type, this application considers the code location characteristics of each function associated with the kernel's function call stack at the time of the kernel crash more deeply, and combines the code location characteristics at the function level with the kernel state information to jointly determine the topic of the kernel crash log. This scheme determines the topic dimension with higher granularity. Finally, based on the more granular topics, multiple kernel crash logs can be targeted and categorized for push, and the push method is more accurate, thereby improving the operational efficiency during kernel crashes. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the system architecture of the log push method provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the log push method provided in an embodiment of this application; Figure 3 This is a detailed flowchart of the generation process of the kernel crash log fingerprint StackSig provided in the embodiments of this application; Figure 4 This is a detailed flowchart of determining the topic corresponding to the kernel crash log provided in an embodiment of this application; Figure 5 This is a hardware structure diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] First, the symbols used in this application will be explained as follows: coredump / vmcore (Kernel Core Dump): Kdump (Kernel Dump via Kexec, dump mechanism) captures kernel crash events such as kernel panics and exports the entire physical memory image file. This file contains the complete kernel runtime environment, including all kernel processes, drivers, hardware registers, interrupt context, etc., and is the core raw data for investigating kernel crashes.

[0020] System.map / kallsyms (Kernel Symbol Table): It records the mapping relationship between kernel virtual addresses and function names / global variable names. System.map is a static text file generated when the kernel is compiled, and it is an offline symbol table; kallsyms is a dynamic symbol table compiled into the kernel image.

[0021] Kdump: Kdump is a kernel crash dumping mechanism in Linux systems. When the system crashes (such as a kernel crash, deadlock, or system crash), Kdump allows the system to dump the contents of the current memory to a memory dump file.

[0022] BuildID (Build Identifier): A build identifier used to uniquely identify a specific build version. It typically includes information such as platform version, code branch, and synchronization date, and is used to distinguish different system versions and patch levels.

[0023] Unwind (Stack Unwinding): refers to the process of tracing back the function call chain layer by layer, starting from the current CPU (Central Processing Unit) registers (BP (Base Pointer, stack base address) and IP (Instruction Pointer)).

[0024] Symbolization is the process of converting virtual memory addresses back into function names, file names, and line numbers in the code.

[0025] StackSig (Function-level Signature) is a fixed fingerprint identifier generated by extracting stable function call sequence features after using the function name as the smallest feature unit and ignoring volatile information such as line numbers, addresses, and temporary parameters.

[0026] DSL (Domain-Specific Language): Here it specifically refers to the domain-specific language for subscription strategies. It is a rule expression used to declare which messages / events consumers want to receive. By parsing this expression, message filtering can be performed on the server side, and matching messages can be pushed to subscribers.

[0027] TLS (Transport Layer Security) / mTLS (mutual TLS Transport Layer Security): TLS is a standard encryption protocol used for end-to-end communication encryption on top of TCP. It achieves symmetric encryption of transmitted messages by deploying certificates on the server side and verifying the server's identity on the client side, thus preventing messages from being eavesdropped on or tampered with. mTLS, on the other hand, builds on TLS by having both the client and the server hold certificates and mutually verify each other's identities.

[0028] HASH (HASH Function): A fixed-length digest string obtained by performing a hash operation on a normalized ordered sequence of function calls.

[0029] MTTR (Mean Time To Repair / Resolve): The average time from the detection of a kernel crash to the restoration of normal service.

[0030] Traditional kernel crash push systems based on syslog (a standard logging protocol and system log service) and general monitoring and alarm platforms suffer from drawbacks such as coarse matching of push audiences and rampant alarm noise, which can easily trigger alarm storms and seriously delay the opportunity to handle crashes.

[0031] For example, after a kernel panic, Linux uses Kdump to generate a raw memory dump file called vmcore. This file contains the raw memory addresses, and technicians need to use tools such as Crash (a Linux-specific kernel dump analysis tool) and GDB (GNU Debugger, a debugging tool) to perform stack unrolling and symbolic parsing in order to extract valid call stack information. Then, call stack feature vectors are extracted from the call stack information and compared with the similarity of various preset kernel crash standard feature vectors to automatically determine the crash type. The identified crash type is then associated with the raw crash log and pushed. Pushing the crash type is used to inform users of the kernel crash type, but it cannot accurately push kernel crash logs to specific groups of people.

[0032] To address the shortcomings of the aforementioned related technologies, this application provides a log push method that can accurately push kernel crash logs. To illustrate the technical solution of this application, specific embodiments are described below.

[0033] This application provides a log push method, which is applied to a log push system 1000, such as... Figure 1 As shown, the log push system 1000 includes a server 101, a log collection module 102, and a kernel module 103. The kernel module 103 contains multiple kernels. In order to improve the security of kernel crash log processing, the server 101 can be set to a server with a security level higher than the threshold. The server 101 communicates with the multiple kernels in the kernel module 103 through the log collection module 102.

[0034] When multiple kernels in kernel module 103 crash within a preset time period, log collection module 102 collects kernel crash logs for each crashed kernel and pushes them to server 101. Based on the multiple kernel crash logs, server 101 determines the first function information of each function associated with the function call stack of the corresponding kernel, as well as the kernel state information of the corresponding kernel. The first function information represents the code location characteristics of the function corresponding to the kernel crash. Based on the multiple first function information and kernel state information corresponding to each kernel crash log, the server 101 determines the topic corresponding to each kernel crash log. Further, server 101 pushes the multiple kernel crash logs to users who have subscribed to the corresponding topics according to the topics corresponding to the multiple kernel crash logs.

[0035] Figure 2 A flowchart of a log push method provided in this application embodiment, taking the method applied to a log push system 1000 as an example, the log push method provided in this application includes the following S201~S204: S201, retrieve multiple kernel crash logs.

[0036] The kernel is the core of the operating system, responsible for managing system resources and providing basic services. It is the most fundamental part of the operating system, providing applications with secure access to computer hardware.

[0037] The kernel crash log contains error messages output by the system when the kernel encounters exceptions such as panic or Oops. It includes information about registers, the original call stack, and the hardware and memory context. Oops exceptions are those where the kernel catches the exception, prints an error log, and attempts to salvage the system; panic exceptions are those where the kernel is determined to be unable to continue running and directly halts and restarts.

[0038] Specifically, within each monitoring cycle for kernel crash events in the Linux system, when a kernel crashes, the kernel crash event is captured, the kernel crash log for that event is determined, and then the kernel crash log is uploaded to the server. The server can analyze multiple kernel crash logs collected in that monitoring cycle after the cycle ends, or analyze multiple kernel crash logs collected within that monitoring cycle at a custom analysis interval. It can also analyze a single uploaded kernel crash log in real time. Finally, based on the analysis results, the multiple kernel crash logs collected in that monitoring cycle are pushed to specific users.

[0039] In practical applications, this server can be a high-security server to enhance the security of log analysis performed on it.

[0040] In some embodiments, a log collection module is designed to collect kernel crash events and determine the kernel crash logs for those events. The collection function of the log collection module can be triggered by Kdump / Kexec or an agent after a kernel crash, generating a meta.json file. This file is used to store resources or specific metadata and can be understood as the kernel crash log. Kexec is a patch for the Linux kernel that allows another Linux kernel to be loaded and started directly within the currently running kernel. Kdump, based on the Kexec patch, can quickly capture kernel crash events. The agent is a user-space collection program developed by the operations and maintenance platform and can also be used to determine the kernel crash logs.

[0041] In some embodiments, the kernel crash log includes BuildID, host, Kernel.release, and at least one optional vmcore fragment. BuildID is a build identifier used to uniquely identify a specific build version, typically containing information such as platform version, code branch, and synchronization date, used to distinguish different system versions; Kernel.release is the Linux kernel release information, usually used to identify the kernel version number and compilation information; host is the host information for the Linux kernel; and vmcore fragments are segments of the Linux kernel's kernel dump file, vmcore. Since vmcore is large, it can be split into multiple smaller fragments and stored in parallel on multiple disks to distribute disk I / O (Input / Output) pressure and speed up file dumping.

[0042] In some embodiments, kernel crash logs in related technologies contain sensitive information and pose a high risk of transmission. Therefore, in this application, kernel crash logs can be encrypted and transmitted to a server for analysis and push. In practical applications, encryption methods can include TLS encryption, mTLS encryption, and AES (Advanced Encryption Standard) symmetric encryption. Taking TLS encrypted transmission as an example, the server deploys a certificate and private key, and when connecting with the log collection module, both parties handshake to negotiate the encryption algorithm and generate a session key. Subsequent symmetric encryption of data transmission between the server and the log collection module relies on this session key. Taking AES symmetric encryption as an example, the same key is used to encrypt or decrypt data between the server and the log collection module. Other encryption methods are also possible and are not limited here.

[0043] In some embodiments, kernel crash logs support features such as resume from interruption and retry, meaning that kernel crash log transmission can continue from the point of interruption after an interruption, without having to start from the beginning; at the same time, it allows retrying the transmission of kernel crash logs when the transmission fails, instead of directly reporting an error.

[0044] S202, based on multiple kernel crash logs, determines the first function information of each of the multiple functions associated with the function call stack of the corresponding kernel, as well as the kernel state information of the corresponding kernel.

[0045] Among them, the first function information represents the code location characteristics of the function corresponding to the kernel crash.

[0046] Each thread in the kernel corresponds to a function call stack, which is a memory region used to store function call information during the thread's execution. The multiple functions associated with the function call stack are records of the function call chain when the thread calls those functions. Specifically, whenever a kernel thread calls a kernel function, it allocates a contiguous space in the memory corresponding to the function call stack as the frame for the called function by moving the stack pointer. Therefore, the kernel's function call stack contains multiple frames, each corresponding to a called function. Each frame stores the function's return address, the base address of the upper-level stack frame, and related register information. When the corresponding function completes execution and needs to return to the calling function, the stack pointer rolls back, releasing the stack space occupied by the frame corresponding to the completed function. In practical applications, the functions can be device driver functions, file reading functions, memory management functions, etc., without limitation here.

[0047] Specifically, for each kernel crash log, which records function call stack information and kernel state information for the corresponding kernel, stack backtracking can be performed on the kernel's function call stack based on the kernel crash log. This involves parsing each stacked frame to reconstruct the complete function call chain, thereby obtaining the first function information for each of the multiple functions associated with the corresponding kernel's function call stack. Simultaneously, kernel state information can be extracted from the kernel crash log. When subsequently determining the topic of the kernel crash log based on the first function information of each of the multiple functions associated with the corresponding kernel's function call stack and the corresponding kernel state information, the determined topic dimension achieves a higher degree of granularity.

[0048] In some embodiments, for each kernel crash log, the code location characteristics of each function associated with the function call stack at the time of the kernel crash are determined, such as the function name, module name, and file name of the function, and the code location characteristics of each function are used as the first function information of the function. By determining the first function information of each of the multiple functions associated with the corresponding kernel function call stack, the code location where the kernel crash occurred can be accurately located.

[0049] In some embodiments, kernel state information may include one or more of kernel configuration attribute information and kernel runtime state information. The kernel configuration attribute information includes, but is not limited to, one or more of hardware, CPU information, kernel identifier, and kernel version information. The kernel version information includes, but is not limited to, one or more of kernel version identifier, image version identifier, and module version identifier. The kernel runtime state information includes, but is not limited to, one or more of kernel runtime sequence trace and user operation records. By determining this kernel state information, the multi-dimensional state information at the time of kernel crash can be accurately reconstructed.

[0050] S203, based on the multiple first function information and kernel state information corresponding to each kernel crash log, determine the topic corresponding to each kernel crash log.

[0051] Specifically, to improve the classification accuracy of kernel crash logs, this application combines the first function information of multiple functions associated with the corresponding kernel function call stack to pinpoint the code segment where the kernel crash occurred. It then combines this information with kernel state information to reconstruct multi-dimensional state information at the time of the kernel crash, thus comprehensively describing the kernel crash event from multiple perspectives, including the location of the crashing code and the state information at the time of the crash. Finally, by combining the first function information of multiple functions associated with the corresponding kernel function call stack and the corresponding kernel state information, a topic corresponding to each kernel crash log is determined. This topic can summarize the crash location and crash state of the corresponding kernel crash log.

[0052] In some embodiments, for each kernel crash log, multiple first function information and kernel state information of the kernel crash log can be directly used as the topic corresponding to the kernel crash log. For example, if the multiple first functions are A, B, and C, and the kernel state information is E, then one or more of A, B, C, and E can be used as the topic corresponding to the kernel crash log. Subsequently, the corresponding log can be pushed to users who have subscribed to the topic corresponding to the kernel crash log.

[0053] In some embodiments, for each kernel crash log, the more important TOPN features in each parameter information can be analyzed based on multiple first function information and kernel state information in the kernel crash log, and the topic can be obtained based on these TOPN features. For example, if the multiple first function information is A, B, and C, and the kernel state information is E, then the TOPN features of the multiple first function information can be determined as A1 and B2, and the TOPN features of the kernel state information can be determined as E1 and E2. Then, based on A1, B2, E1, and E2, the topic corresponding to the kernel crash log can be determined.

[0054] In some embodiments, the topic of a kernel crash log can also represent the type of kernel crash. For each kernel crash log, a first type of kernel crash can be determined based on multiple first function information in the kernel crash log, and a second type of kernel crash can be determined based on the corresponding kernel state information. For example, the first type could be a type of exception in a function; the second type could be a type of exception in configuration information or a type of exception in a runtime parameter, etc. Based on the first and second types, the topic corresponding to the kernel crash log is determined. Further, the method for determining the topic corresponding to the kernel crash log based on the first and second types can be to treat both the first and second types as the topic of the kernel crash log, or to collectively refer to the first and second types as a broad range of types and determine the topic of the kernel crash log from this broad range of types. The specific method for determining the topic is not limited here.

[0055] S204 pushes multiple kernel crash logs to users who have subscribed to the corresponding topics, based on the topics corresponding to the multiple kernel crash logs.

[0056] Specifically, multiple kernel crash logs are categorized based on their corresponding topics. These categorized kernel crash logs are then pushed to users who have subscribed to the corresponding topics. This automated log analysis and push process significantly reduces manual intervention and improves response speed.

[0057] In some embodiments, the push function of this application is implemented based on a preset DSL subscription strategy. The DSL subscription strategy relies on a preset subscription model, that is, the subscription model is published in advance on the corresponding page. The subscription model has multiple subscribing topics for kernel crash logs. Users subscribe to the subscribing topics according to the topics they want to follow. Then, according to the subscription model, multiple kernel crash logs are automatically pushed to users who have subscribed to the corresponding topics.

[0058] In some embodiments, after a user subscribes to a relevant topic, when a kernel crash log exists in a certain monitoring period, the topic of the kernel crash log is analyzed, and the kernel crash log is pushed to the user who has subscribed to the corresponding topic according to the corresponding topic; when multiple kernel crash logs exist in a certain monitoring period, multiple kernel crash logs of the same topic can be deduplicated, and then the deduplicated multiple kernel crash logs can be pushed to the user who has subscribed to the corresponding topic.

[0059] In some embodiments, to improve log push efficiency, the monitoring period can be set as short as possible, or the kernel crash log can be pushed to users who have subscribed to the corresponding topic as soon as the topic of a kernel crash log is determined. Further, after determining the topic of each kernel crash log, it can be determined whether a preset database stores a topic identical to the determined topic, and whether the fault of the kernel crash log corresponding to that topic stored in the database is still unresolved. If a topic identical to the determined topic exists in the preset database, and the fault of the kernel crash log corresponding to that topic is still unresolved, then it is unnecessary to push the kernel crash log with the duplicate topic to users who have subscribed to the corresponding topic again.

[0060] In some embodiments, when pushing multiple kernel crash logs to users who have subscribed to the corresponding topics, the priority of each topic can be preset, and multiple kernel crash logs can be pushed to users who have subscribed to the corresponding topics in sequence according to the priority of the topics, so that users can process the high-priority kernel crash logs first.

[0061] In some embodiments, multiple kernel crash logs for the same topic can be stored in the same database, with each database associated with a topic. When a new kernel crash log is added to the database, it can be automatically pushed to users who have subscribed to the corresponding topic. In other embodiments, multiple kernel crash logs for different topics can also be stored in the same database, which can push them to users who have subscribed to the corresponding topic based on the topic of each kernel crash log.

[0062] In some embodiments, for a user who has just subscribed to a topic, all historical kernel crash logs for that topic can be pushed to that user, or only the kernel crash logs collected subsequently can be pushed to that user, which can be configured by the user.

[0063] In some embodiments, the subscription push method of this application can be a multi-channel push method, including but not limited to SMS push, email push, telephone push, etc., which is not limited here.

[0064] In some embodiments, after receiving the corresponding kernel crash log, users can narrow down the scope of the crash location based on the topics they have subscribed to, quickly identify the root cause of the crash, and provide timely and accurate handling suggestions to help users locate and resolve the problem within minutes, greatly shortening the crash handling time (MTTR).

[0065] In the above scheme, kernel crash logs from multiple kernels are obtained. For each kernel, based on the kernel crash logs, multiple first function information and kernel state information corresponding to the kernel are determined. The first function information represents the code location characteristics of each function associated with the kernel's function call stack at the time of the kernel crash. Based on the multiple first function information and kernel state information, the topic corresponding to the kernel crash log is determined. At least one kernel crash log corresponding to each topic is pushed to users who have subscribed to the corresponding topic. In this process, compared with related technologies that use feature vector matching of call stack information to determine the crash type, this application considers the code location characteristics of each function associated with the kernel's function call stack at the time of the kernel crash more deeply, and combines the code location characteristics at the function level with the kernel state information to jointly determine the topic of the kernel crash log. This scheme determines the topic dimension with higher granularity. Finally, based on the more granular topics, multiple kernel crash logs can be targeted and categorized for push, and the push method is more accurate, thereby improving the operational efficiency during kernel crashes.

[0066] In other embodiments of this application, based on multiple first function information and kernel state information corresponding to each kernel crash log, the topic corresponding to each kernel crash log is determined, including: For each kernel crash log, the first crash feature of the kernel is determined based on multiple first function information; the second crash feature of the kernel is determined based on kernel state information; the fusion feature of the kernel is determined based on the first and second crash features; and the topic corresponding to the kernel crash log is determined based on the fusion feature.

[0067] The first crash feature represents the code location of the target function that caused the kernel to crash; the second crash feature represents one or more of the kernel version information, host information, and runtime status information.

[0068] Specifically, for each kernel crash log, the code location characteristics of the target function that caused the kernel crash are determined based on multiple first function information, which are the first crash characteristics. At the same time, based on kernel state information, one or more second crash characteristics are determined from the kernel version information, host information, and runtime state information at the time of the kernel crash. Based on the first and second crash characteristics, the topic corresponding to the kernel crash log is accurately determined from one or more perspectives, including the micro-crash location at the function level and the macro-crash location, crash version, and runtime state of the kernel at the server level.

[0069] More specifically, the method for determining the topic corresponding to the kernel crash log based on the first crash feature and the second crash feature can be: determining the kernel's fusion feature based on the first crash feature and the second crash feature, and determining the topic corresponding to the kernel crash log based on the fusion feature.

[0070] The fusion method can be a simple concatenation of the first and second collapse features; it can also be the extraction of common collapse features from the first and second collapse features; or it can be the determination of the weights of the first and second collapse features, and the weighted fusion of the first and second collapse features based on their respective weights, etc. The specific fusion method is not limited here.

[0071] In some embodiments, the method for determining the topic corresponding to the kernel crash log based on the fusion feature may be to query the topic corresponding to the fusion feature from a standard feature library, wherein the standard feature library stores the mapping relationship between multiple features and corresponding topics.

[0072] When no matching topic can be found in the standard feature library, similarity matching can be performed between the fusion feature and the standard feature corresponding to each topic, and the topic corresponding to the standard feature with the highest similarity to the fusion feature is determined as the topic corresponding to the fusion feature.

[0073] In some embodiments, the topic corresponding to each kernel crash log can be determined based on the fusion features of multiple kernel crash logs. This can be achieved by clustering the fusion features of the multiple kernel crash logs, grouping multiple kernel crash logs with high similarity in their fusion features into a single cluster, identifying keywords for a specific kernel crash log within each cluster, matching them with a standard thesaurus corresponding to each topic, determining the topic matched by that kernel crash log based on the matching results, and then defining the topic matched by that kernel crash log as the topic of other kernel crash logs within the same cluster. In practical applications, dimensionality reduction methods can include K-Means clustering, DBSCAN (Density-Based Spatial Clustering of Applications with Noise), and other density-based clustering algorithms.

[0074] In some embodiments, this embodiment can utilize a large language model to determine the topic corresponding to the kernel crash log. The large language model learns the correspondence between the kernel's fusion features and topics. By inputting a certain kernel's fusion feature into the large language model, the large language model can output the topic corresponding to that fusion feature.

[0075] In some embodiments, the fused features are generally high-dimensional features. Therefore, before determining the topic corresponding to the kernel crash log based on the fused features, the fused features can be reduced in dimensionality, and the topic corresponding to the kernel crash log can be determined based on the dimensionality-reduced fused features.

[0076] In some embodiments, kernel runtime information includes, but is not limited to, the task information executed by the kernel during the period from the time point t0 before the kernel crash to the time point t of the kernel crash, the kernel's task execution methods, the kernel's memory, the kernel crash time, etc. This kernel runtime information can accurately reconstruct the kernel's running mode before the kernel crash and the kernel's runtime state at the time of the kernel crash. At the same time, this information can be combined with other information to comprehensively determine the topic corresponding to the kernel crash log.

[0077] In the above embodiments, by determining a first crash feature that represents the function-level crash location of the kernel, and a second crash feature that represents one or more of the kernel version information, host information, and running status information, the topic corresponding to the kernel crash log can be determined in a more granular manner, so that the kernel crash log can be pushed accurately based on the topic.

[0078] In the above embodiments of this application, before pushing multiple kernel crash logs to users who have subscribed to the corresponding topics, the method further includes: Determine the fingerprint corresponding to each kernel crash log; based on the fingerprint corresponding to each kernel crash log, deduplicate multiple kernel crash logs.

[0079] Among them, fingerprints represent the function execution path reflected in the function call stack when the kernel crashes.

[0080] Specifically, in related technologies, kernel crash log pushes are performed on every single kernel crash log, lacking root cause-level crash information clustering. This often involves aggregation based on file / module / kernel version or the similarity of several text frames, making stable deduplication difficult. Therefore, this application addresses this by performing idempotent storage on multiple kernel crash logs—that is, deduplicating multiple kernel crash logs—and then transmitting the deduplicated logs to the database. This ensures that the database retains only one kernel crash log with the same root cause-level crash information, thus preventing duplication of root cause-level crash information when multiple kernel crash logs are pushed to users who have subscribed to the corresponding topic. Root cause-level crash information refers to data that can directly pinpoint the root cause of a kernel crash.

[0081] This application deduplicates multiple kernel crash logs using function-level fingerprinting. Crashes with the same root cause will generate the same fingerprint. The fingerprint represents the function execution path reflected in the function call stack at the time of the kernel crash. This function execution path is highly robust to noise and is a stable path. Therefore, the fingerprint corresponding to each kernel crash log can be determined, and based on the fingerprint corresponding to each kernel crash log, multiple kernel crash logs can be deduplicated, retaining only one kernel crash log corresponding to each fingerprint. This avoids users receiving multiple kernel crash logs corresponding to the same fingerprint and avoids duplicate analysis of multiple kernel crash logs corresponding to the same fingerprint.

[0082] In some embodiments, for each kernel crash log, a stack backtracking is performed on the function call stack at the time of the kernel crash based on the kernel crash log. The stacked frames are parsed one by one to reconstruct the complete function call chain. This involves unfolding these frames layer by layer on the function call stack from the current crash point, reversing the call relationship, parsing the function symbols and offsets of each layer to obtain a readable call chain, collecting the jump instruction addresses of each frame, and finally determining the function execution path reflected by the function call stack. Based on this function execution path, the fingerprint corresponding to the kernel crash log is determined.

[0083] Furthermore, after determining the function execution path reflected in the function call stack at the time of the kernel crash, the information of multiple second functions in the function execution path can be normalized. Based on the normalized information of multiple second functions, the determined function execution path can be updated. According to the updated function execution path, the fingerprint corresponding to the kernel crash log can be determined. Since the information of multiple kernel crash logs is normalized, this fingerprint can more accurately and quickly deduplicate multiple kernel crash logs compared to the fingerprint generated by the function execution path before the second function information is normalized.

[0084] In some embodiments, for each kernel crash log, the second function information of each function in the function execution path reflected by the function call stack at the time of the kernel crash can be obtained, and the key strings in each second function information can be concatenated in order to obtain the fingerprint corresponding to the kernel crash log. Alternatively, the symbols, crash information, etc. in each second function information can be mapped to numerical codes, and multiple numerical codes can be concatenated in order to obtain the fingerprint corresponding to the kernel crash log. The method of fingerprint determination is not limited here, but the determined fingerprint needs to uniquely identify the function execution path reflected by the function call stack at the time of the kernel crash.

[0085] In some embodiments, the function execution path represented by the fingerprint corresponding to each kernel crash log is a path that distinguishes the order of function execution. However, in other embodiments, the fingerprint corresponding to the kernel crash log can also be determined directly based on the second function information of multiple functions in the function call stack. In this case, the fingerprint does not contain the order of function execution, but rather contains a set of function information.

[0086] In some embodiments, this application may also associate kernel crash log topics with corresponding fingerprints and store them in a database to save storage costs. Subsequently, based on the topics subscribed to by users, at least one fingerprint corresponding to a topic can be determined, and then the kernel crash log corresponding to each fingerprint can be pushed to users who have subscribed to the corresponding topic.

[0087] In some embodiments, when the fingerprint of the kernel crash log needs to be stored in the database, it can also be determined whether the same fingerprint exists in the database and whether the fingerprint is marked as unresolved. If the same fingerprint exists and the fingerprint is marked as unresolved, the information corresponding to the fingerprint does not need to be stored in the database again. If the fingerprint does not exist, or if the fingerprint exists but the fingerprint is marked as resolved, the topic of the kernel crash log is associated with the corresponding fingerprint and stored in the database.

[0088] In some embodiments, users can periodically archive, organize, and review the information stored in the database, further accumulating it into a relevant knowledge base, and using this to build a kernel coredump knowledge graph. Based on this knowledge graph, it is possible to understand the relationship between the kernel fingerprint and the topic corresponding to the kernel crash log, and between the topic corresponding to the kernel crash log and the specific content of the kernel crash log. This has positive guiding value for kernel development and operation and maintenance.

[0089] In the above embodiments, by determining the function-level fingerprint corresponding to the kernel crash log, which is unaffected by noise, multiple kernel crash logs can be deduplicated accurately and reliably, saving storage and analysis costs. At the same time, multiple kernel crash logs with the same root cause level crash information are pushed to only one user who has subscribed to the corresponding topic, reducing interference from invalid information, reducing repetitive work for users, and improving cross-team collaboration efficiency.

[0090] In the above embodiments of this application, the fingerprint includes a hash identifier; determining the fingerprint corresponding to each kernel crash log includes: For each kernel crash log, determine the second function information of each function associated with the function call stack at the time of the kernel crash; inject multiple second function information into a preset function stack; after all second function information has been injected into the preset function stack, perform hash processing on the build identifier in the kernel crash log and multiple second function information in the preset function stack to obtain the hash identifier corresponding to the kernel crash log.

[0091] The preset function stack differs from the function call stack mentioned in the previous embodiment. The function stack is a stack that pushes the second function information of each function onto the stack when determining the fingerprint, while the function call stack is used to store the function call information when the kernel thread executes.

[0092] The second function information differs from the first function information in that it represents the identification characteristics of the corresponding function in the function execution path; the identification is constructed to distinguish different versions of the kernel.

[0093] Specifically, for each kernel crash log, the fingerprint of the kernel crash log is the function execution path reflected by the function call stack when the kernel crashes. In this embodiment, the fingerprint can be a hash identifier after compressing the high-dimensional features of multiple functions in the corresponding function execution path into a lightweight digest, which reduces the computing power and time cost of retrieval and deduplication, and improves the efficiency of subsequent deduplication.

[0094] More specifically, the process involves determining the second function information associated with each function's call stack at the time of a kernel crash, then injecting this second function information into a pre-defined function stack one by one until all second function information is injected. Afterward, elements are popped from the pre-defined function stack, and a hash is generated by combining the build identifier from the kernel crash log with the popped second function information. This hash is the fingerprint (StackSig) corresponding to the kernel crash log. Because it incorporates the build identifier from the kernel crash log, this application can stably deduplicate multiple kernel crash logs across different versions. In practical applications, the pre-defined function stack must retain at least TOPN frames. If this number is exceeded, the remaining functions cannot be processed. Therefore, the size of the pre-defined function stack needs to be configured in advance.

[0095] The second function information corresponds to the identifier of the function in the function execution path. For example, the second function information may include the function name, module name, etc., which are not limited here. By determining the identifier of the corresponding function in the function execution path as the second function information, and injecting multiple pieces of second function information sequentially into a preset function stack, the function execution path reflected by the function call stack at the time of kernel crash can be accurately determined.

[0096] In some embodiments, the host information in the kernel crash log can also be added to the fingerprint StackSig corresponding to the kernel crash log, thereby enabling stable deduplication of multiple kernel crash logs across hosts and improving the deduplication accuracy of kernel crash logs.

[0097] In some embodiments, for each kernel crash log, the virtual address of each function associated with the function call stack at the time of the kernel crash is first determined, and then the second function information of each function is determined based on the virtual address of each function, such as the function name, module name, etc.

[0098] Furthermore, this application pre-defines a first function metadata table, which includes a mapping relationship between virtual address ranges and second function information. The virtual address range includes a start address and an end address. Therefore, based on this first function metadata table, the second function information corresponding to each virtual address can be queried. In practical applications, the first function metadata table includes a mapping relationship between virtual address ranges and the module name and function name to which the function belongs. The obtained second function information is the module name and function name corresponding to the function.

[0099] Alternatively, this application may pre-design a mapping expression, based on which the second function information of the function can be directly determined according to the virtual address of the function.

[0100] Furthermore, the first function metadata table can be generated based on the current kernel's System.map / kallsyms file, vmLinux file, and .ko.debug file. When generating the first function metadata table, this information needs to be aligned with the build identifier to ensure that the second function information corresponding to a certain address range in the first function metadata table is the function information corresponding to the same version.

[0101] Among them, System.map is a kernel symbol text file, a plain text record of kernel function and global variable names and their corresponding virtual address ranges in memory, generated during kernel compilation; kallsyms is a kernel runtime virtual file, similar in content to System.map, which can export kernel symbol addresses in real time; vmLinux is an uncompressed, raw kernel ELF (Executable and Linkable Format) image with complete debug symbols, a kernel compilation product, which can be used to parse vmcore crash dumps and restore complete function call stacks; .ko.debug is a debug file accompanying a kernel module (.ko), which stores the module's debug symbols separately and is used when parsing driver module crash stacks.

[0102] Specifically, based on the System.map / kallsyms file, the kernel function names, global variable names, and their corresponding virtual address ranges in memory are determined; based on the vmLinux file, the kernel's original image information is determined; based on the .ko.debug file, the kernel's module information is determined; the kernel function names, global variable names, kernel original image information, and kernel module information are determined as the kernel's second function information; and a one-to-one mapping relationship is established between the kernel's second function information and the corresponding virtual address ranges in kernel memory. Based on this mapping relationship, a first function metadata table is generated.

[0103] In some embodiments, after determining the second function information of each function associated with the function call stack at the time of a kernel crash, it can also be determined whether the function is a frame-type function, such as functions related to panic / die / ret_from_fork / schedule / interrupt frames, etc. If the function is a frame-type function, it can be skipped, and the processing of the next function can continue. In practical applications, panic is the kernel's fatal crash function, called when an unrecoverable serious error is detected; die is the entry point for minor crash handling, such as Oops, null pointer exceptions, illegal instructions, etc.; ret_from_fork is the return entry point after the child process is created, and its appearance on the stack indicates that the crash occurred in the context of the newly created child process; schedule is the process scheduling function, called when the kernel switches processes; its appearance on the stack indicates that the crash occurred in a process scheduling or context switching scenario; the interrupt frame is the kernel's complete set of general logic for handling hardware interrupts, representing that the crash occurred in the context of a hardware interrupt.

[0104] In some embodiments, the original call stack sequence obtained by unwinding the stack back can also be popped and folded, that is, from the crash point upwards, duplicate / generic underlying stack frames without distinction are identified, compressed and removed, the call chain is simplified, noise is eliminated, and different StackSigs are avoided from being generated by the same type of crash with the same function execution path.

[0105] In some embodiments, the information of multiple second functions in a preset function stack can be initialized by hashing to obtain an initialization hash. Then, the fingerprint algorithm version number SIG_VERSION and the build number of the original kernel image are used. The hash is initialized using one or more of the following identifiers: ID, kernel pollution mark mask TaintedMask, and Build-ID of the de-duplicate and sorted ko driver module appearing in the crash stack. The kernel pollution mark mask TaintedMask is used to mark the pollution state of the kernel, such as an anomaly in a certain aspect. Furthermore, the hash identifier corresponding to the kernel crash log is determined by combining the normalized function name, module name, and relative offset corresponding to each function with the aforementioned initial hash.

[0106] In the above embodiments, by sequentially injecting the identification features of each function associated with the function call stack, i.e., the second function information, into a preset function stack, the function execution path reflected by the function call stack at the time of kernel crash can be accurately reflected. Then, based on the function execution path reflected by the function call stack at the time of kernel crash, multiple second function information in the preset function stack are hashed to accurately obtain the fingerprint corresponding to each kernel crash log. Since this fingerprint is obtained through a lightweight hash algorithm, subsequent deduplication based on this fingerprint can reduce analysis costs and improve analysis efficiency and accuracy.

[0107] In other embodiments of this application, determining the second function information of each function associated with the function call stack at the time of a kernel crash includes: For each function, if the function is associated with the original kernel image, the second function information is determined to be the function name of the function and the original kernel image name of the original kernel image; if the function is associated with a module, the second function information is determined to be the function name corresponding to the function and the module name corresponding to the module.

[0108] The raw kernel image is the compiled kernel image file; modules are modules that are loaded into the kernel's virtual address space during kernel runtime.

[0109] Specifically, the function can be a module function associated with a dynamically loaded module, or a function associated with the raw kernel image. The vmLinux raw kernel image is the compiled kernel core file, which does not depend on dynamic loading; the module (.ko) is an independent file generated during the compilation phase, not generated at runtime, but dynamically loaded into the kernel address space after the Linux system is running.

[0110] When the function is associated with the original kernel image, the virtual address corresponding to the function is the kernel address, which then determines the second function information corresponding to that kernel address. This second function information can be the function name and the original kernel image name. The original kernel image name can be determined based on the vmLinux file.

[0111] When a function is associated with a module, the virtual address corresponding to the function is the module address. This allows us to determine the second function information corresponding to that module address. In this case, the second function information can be the function name and the module name. The module name can be determined based on the ko.debug file.

[0112] In some embodiments, a detailed flowchart of the generation process of the stackSig fingerprint of a kernel crash log is shown below. Figure 3 As shown, specifically: S31, input the current kernel's System.map / kallsyms file, vmLinux file, ko.debug file, etc.

[0113] S32, based on the multiple files input in S31, generate a first function metadata table, wherein the first function metadata table includes the mapping relationship between virtual address ranges and corresponding second function information, and the first function metadata table also includes a construction identifier. Optionally, the first function metadata table also includes the file name of the function.

[0114] S33, based on the kernel crash log, performs stack backtracking frame by frame in the kernel to obtain a Frame(ip, module). Obtaining a Frame(ip, module) means that a frame is described using a tuple of (the virtual address of the corresponding function, ip, and the module name / original kernel image name of the function). Each frame corresponds to one function.

[0115] S341, if the function is represented as a function associated with the original kernel image, then the virtual address corresponding to the function is the kernel address, and module is the name of the original kernel image.

[0116] S342, if a function is represented as a function associated with a module, i.e., module == null, then the virtual address corresponding to the function is the module address, and module is the module name corresponding to the function.

[0117] In step S35, using the first function metadata table generated in step S32, the kernel addresses determined in step S341 and the module addresses determined in step S342 are symbolically mapped to obtain the second function information for each function. If the second function information corresponding to a certain address is not found in the first function metadata table, a rollback action can be performed. Furthermore, the function names in the second function information of each function are normalized.

[0118] S361, if the function corresponding to the frame is a frame-type function, such as panic, die, ret_from_fork, etc., then skip the frame, return to step S33, and continue processing the next frame.

[0119] S362, if the function corresponding to the frame is not a frame-type function, then push the function onto the preset function stack. The function stack can hold at most N frames. Once the pushing is complete, continue processing the next frame.

[0120] S37. After all frames have completed the processing described in S33~S362, the stack backtracking is complete.

[0121] S38, regarding the fingerprint algorithm version number SIG_VERSION and the build of the original kernel image. The kernel crash log fingerprint is obtained by hashing the ID, kernel pollution mark mask TaintedMask, the Build-ID of the de-reordered ko driver module appearing in the crash stack, and multiple second function information in the preset function stack.

[0122] In the above embodiments, by distinguishing between the original kernel image and dynamically loaded modules, the specific content of the second function information of a function can be accurately determined. That is, when the function is associated with a module, the corresponding second function information is the function name and the module name; when the function is associated with the original kernel image, the corresponding second function information is the function name and the original kernel image name. By distinguishing the two branches in this way, the corresponding fingerprint can be generated based on the accurate second function information.

[0123] In other embodiments of this application, based on multiple kernel crash logs, the first function information of each of the multiple functions associated with the function call stack of the corresponding kernel is determined, including: For each kernel crash log, determine the virtual address of each function associated with the function call stack at the time of the kernel crash; based on multiple virtual addresses, determine the first function information for each function.

[0124] Specifically, for each kernel crash log, firstly, the kernel is backtracked to obtain the virtual address of each function associated with the function call stack at the time of the kernel crash. Then, based on the virtual address of each function, the secondary function information of each function is determined, such as the function name, module name, and file name of the function.

[0125] In some embodiments, symbolization is the process of restoring the virtual address of the corresponding memory to information such as the function name and the file name of the function in the code. Therefore, by symbolizing the virtual address of each function, the first function information of each function can be accurately determined.

[0126] In some embodiments, this application pre-sets a second function metadata table, which includes a mapping relationship between virtual address ranges and first function information. The virtual address range includes a start address and an end address. Therefore, based on this function metadata table, the first function information corresponding to each virtual address can be queried. In practical applications, the second function metadata table at least includes a mapping relationship between virtual address ranges and their respective module names, function names, and the filename where the function is located. The obtained first function information is the module name, function name, and filename corresponding to the function.

[0127] Furthermore, the second function metadata table can be the same as or different from the first function metadata table used when obtaining the second function information of a function. When they are the same, the second function metadata table and the first function metadata table are collectively referred to as the function metadata table. The function metadata table includes the mapping relationship between the virtual address range of the function and the related function information of the function. The related function information includes the corresponding content of the first function information and the second function information. Therefore, the first function information of the function can be obtained from the function metadata table, and the second function information of the function can also be obtained from it.

[0128] Alternatively, this application can design a mapping expression, based on which the second function information of the function can be directly determined according to the virtual address of the function.

[0129] In the above embodiments, the virtual address of each function associated with the function call stack at the time of the kernel crash is determined; based on multiple virtual addresses, the first function information of each function can be accurately determined, and then, through the first function information of each function, the code location characteristics of the function corresponding to the kernel crash can be accurately reflected.

[0130] In other embodiments of this application, the kernel state information of the corresponding kernel is determined based on multiple kernel crash logs, including: For each kernel crash log, the configuration information of the corresponding kernel is determined based on the kernel crash log; keywords in multiple runtime logs associated with the corresponding kernel are determined; and the kernel status information of the corresponding kernel is determined based on the configuration information and keywords.

[0131] The configuration information includes kernel version information and host information.

[0132] Specifically, kernel status information includes kernel runtime information and static configuration information.

[0133] Static configuration information can include kernel version information and host information. Therefore, it is necessary to determine the corresponding kernel configuration information based on the kernel crash log.

[0134] Runtime information can include kernel runtime task information, memory, registers, call stack, etc. This runtime information can be determined from multiple runtime logs associated with the kernel. Furthermore, based on these multiple runtime logs, key runtime information can be identified, such as when and which module crashed, detailed kernel version information, and other kernel runtime information. This runtime information can be identified in the form of keywords.

[0135] Finally, based on the configuration information and keywords, the kernel status information of the corresponding kernel is determined.

[0136] In some embodiments, the kernel status information of the corresponding kernel is determined based on the configuration information and keywords. This determination method may be to combine the configuration information and keywords and determine the combination result as the kernel status information of the corresponding kernel; or it may be to analyze the kernel status information of the kernel based on the configuration information and keywords. In this case, the kernel status information may be normal, slightly abnormal, moderately abnormal, severely abnormal, etc. For example, it may be determined whether the corresponding keyword is wrong based on the configured host information. If it is wrong, the level represented by the kernel status information is determined according to the frequency of the wrong keyword.

[0137] In some embodiments, based on kernel crash logs, build information, server information, and other runtime logs corresponding to the kernel are first determined. Then, the kernel version information is determined based on the build information, the host information of the kernel is determined based on the server information, and the keywords in multiple runtime logs associated with the corresponding kernel are determined based on other runtime logs.

[0138] In the above embodiments, by combining static configuration information such as kernel version information and host information with keywords in the kernel's dynamic runtime log, the kernel's state can be accurately analyzed to obtain the corresponding kernel state information.

[0139] In some embodiments, a detailed flowchart for determining the topic corresponding to a kernel crash log in this application is shown below. Figure 4 As shown, specifically: S41. Extract the version information corresponding to the kernel, such as version number and version name, based on the build information in the kernel crash log.

[0140] S42. Extract the host information corresponding to the kernel based on the server information in the kernel crash log, such as the host IP address and hostname. S43. Based on the stack backtracking of all function address information in vmcore Unwind Callstack, and combined with the second function metadata table, extract the function name, module name, and file name of each function.

[0141] S44. Based on the vmcore-txt context information, determine multiple runtime logs associated with the corresponding kernel, and extract keywords from the multiple runtime logs associated with the corresponding kernel.

[0142] S45. Based on all the information extracted in steps S41-S44, determine the topic corresponding to the kernel crash log, establish an association between the topic and StackSig, and then store the information in the database.

[0143] To better facilitate understanding of the log pushing method of this application by those skilled in the art, the kernel crash log pushing process of this application will be described below with a detailed embodiment, as follows: 1. When the kernel panics, Kdump / Kexec or an agent triggers the log collection module. This module collects multiple kernel crash events and generates a kernel crash log for each event. This log is then transmitted to a high-security server via TLS encryption. The kernel crash log includes the fingerprint algorithm version number SIG_VERSION and the build number of the original kernel image. ID, kernel pollution marker mask TaintedMask, Build-ID of the de-sorted ko driver module appearing in the crash stack, host information, and optional vmcore shards, etc.

[0144] 2. The server automatically extracts crash information from each kernel crash log, generates a fingerprint of the corresponding kernel crash log based on the StackSig algorithm, and performs idempotent storage of each kernel crash log based on this fingerprint information.

[0145] Specifically, BuildID is used to align multiple files including vmLinux, System.map / kallsyms, and .ko.debug, perform stack backtracking and function name normalization, and skip frame-type function sets such as panic, die, and ret_from_fork. The core input is the Frame(ip, module) tuple for each function, combined with the fingerprint algorithm version number SIG_VERSION and the Build ID of the original kernel image. StackSig is calculated from information such as ID, kernel pollution marker mask TaintedMask, and Build-ID of the de-sorted ko driver module appearing in the crash stack.

[0146] Multiple kernel crash logs with the same StackSig are deduplicated, and only one kernel crash log corresponding to each StackSig is retained, saving storage and analysis costs and avoiding duplicate analysis.

[0147] More specifically, the generation process of StackSig is as follows: 1) Generate the first function metadata table based on the current kernel's System.map / kallsyms, vmLinux, and .ko.debug. The first function metadata table includes virtual address ranges, the module to which the function belongs, and the function name, etc. 2) Perform stack backtracking on the kernel's function call stack frame by frame to obtain the virtual address of each function in the function call stack. Look up the function name and module name corresponding to the virtual address from the first function metadata table, normalize the function name, and push the found results onto the function stack.

[0148] 3) After the Unwind Callstack completes, pop elements from the function stack one by one, and combine this with the fingerprint algorithm version number SIG_VERSION and the original kernel image's build number. Information such as ID, kernel pollution marker mask TaintedMask, and Build-ID of the de-reordered ko driver module appearing in the crash stack are used to generate a HASH, which is StackSig.

[0149] 3. Classify multiple kernel crash logs based on the topic corresponding to each kernel crash log.

[0150] 1) Extract the kernel version information, such as version number and version name, from the build information in the kernel crash log.

[0151] 2) Extract the host information corresponding to the kernel from the server information in the kernel crash log, such as the host IP address and hostname; 3) Based on the stack backtracking of all function address information in vmcore Callstack, and combined with the second function metadata table, extract the function name, module name, and file name of each function.

[0152] 4) Based on the vmcore-txt context information, identify multiple runtime logs associated with the corresponding kernel, and extract keywords from these logs.

[0153] 5) Based on all the information extracted above, determine the topic corresponding to the kernel crash log, establish an association between the topic and StackSig, and then store the information in the database.

[0154] 4. Relevant personnel subscribe to the topics they need to follow. Once the kernel crash log is generated, it can be pushed to users who have subscribed to the corresponding topics based on the publish-subscribe model.

[0155] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0156] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0157] It should be noted that the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0158] In addition, in the embodiments of this application, "first," "second," etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0159] The log push method in this application embodiment can be implemented by a processor in an electronic device, such as a central processing unit (CPU), a digital signal processor (DSP), a microcontroller unit (MCU), or a field-programmable gate array (FPGA).

[0160] To implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 5 This is a schematic diagram of the hardware composition structure of an electronic device provided in an embodiment of this application, such as... Figure 5 As shown, the electronic device includes: The communication interface 501 enables information exchange with other devices, such as electronic devices. The processor 502 is connected to the communication interface 501 to enable information exchange with other devices and to execute the methods provided by one or more of the above-mentioned technical solutions when running a computer program. The computer program is stored in the memory 503.

[0161] Of course, in practical applications, the various components in an electronic device are coupled together through a bus system 504. It can be understood that the bus system 504 is used to implement communication between these components. In addition to the data bus, the bus system also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 5 The general designated all buses as Bus System 504.

[0162] The memory 503 in this embodiment is used to store various types of data to support the operation of the computer device. Examples of such data include any computer program used to operate on the electronic device.

[0163] It is understood that memory can be volatile or non-volatile, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0164] The methods disclosed in the embodiments of this application can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor may be a general-purpose processor, a DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory. The processor reads the program from the memory and, in conjunction with its hardware, completes the steps of the aforementioned method.

[0165] Optionally, when the processor executes the program, it implements the corresponding processes implemented by the electronic device in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0166] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a first memory storing a computer program, which can be executed by a processor of a computer device to complete the aforementioned method steps. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0167] In the several embodiments provided in this application, it should be understood that the disclosed apparatus, computer devices, and methods can be implemented in other ways. The apparatus embodiments described above are illustrative. For example, the division of units is a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0168] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0169] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0170] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0171] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, electronic device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0172] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by a processor 502 of an electronic device to complete the steps of the log push method in this application embodiment.

[0173] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0174] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0175] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A log push method, characterized in that, The method includes: Retrieve multiple kernel crash logs; Based on the multiple kernel crash logs, the first function information of each of the multiple functions associated with the function call stack of the corresponding kernel is determined, as well as the kernel state information of the corresponding kernel; the first function information represents the code location characteristics of the function corresponding to the kernel crash. Based on the multiple first function information and the kernel state information corresponding to each kernel crash log, the topic corresponding to each kernel crash log is determined; Based on the topics corresponding to the kernel crash logs, the kernel crash logs are pushed to users who have subscribed to the corresponding topics.

2. The method according to claim 1, characterized in that, The step of determining the topic corresponding to each kernel crash log based on the multiple first function information and the kernel state information corresponding to each kernel crash log includes: For each kernel crash log, a first crash feature of the kernel is determined based on multiple pieces of information from the first function; the first crash feature characterizes the code location feature of the target function that caused the kernel to crash. The second crash feature of the kernel is determined based on the kernel state information; the second crash feature represents one or more of the kernel version information, host information, and runtime state information. Based on the first crash feature and the second crash feature, the fusion feature of the kernel is determined; Based on the fusion characteristics, the topic corresponding to the kernel crash log is determined.

3. The method according to claim 1, characterized in that, Before pushing the multiple kernel crash logs to users who have subscribed to the corresponding topics, the method further includes: Determine the fingerprint corresponding to each kernel crash log; the fingerprint represents the function execution path reflected by the function call stack at the time of the kernel crash; Based on the fingerprint corresponding to each kernel crash log, multiple kernel crash logs are deduplicated.

4. The method according to claim 3, characterized in that, The fingerprint includes a hash identifier; determining the fingerprint corresponding to each kernel crash log includes: For each kernel crash log, determine the second function information of each function associated with the function call stack at the time of the kernel crash; the second function information contains different content from the first function information; the second function information represents the identification characteristics of the corresponding function in the function execution path; Inject multiple pieces of information from the second function into a preset function stack; After all the second function information is injected into the preset function stack, the build identifier in the kernel crash log is hashed with multiple second function information in the preset function stack to obtain the hash identifier corresponding to the kernel crash log; the build identifier is used to distinguish different versions of the kernel.

5. The method according to claim 4, characterized in that, The second function information for each function associated with the function call stack at the time of the kernel crash includes: For each of the functions, if the function is associated with the original kernel image, the second function information is determined to be the function name of the function and the original kernel image name of the original kernel image; the original kernel image is the image file of the compiled kernel. In the case where the function is a function associated with a module, the second function information is determined to be the function name corresponding to the function and the module name corresponding to the module; the module is a module that is loaded into the kernel's virtual address space during the kernel runtime phase.

6. The method according to claim 1, characterized in that, The determination of the first function information of each of the multiple functions associated with the function call stack of the corresponding kernel based on the multiple kernel crash logs includes: For each kernel crash log, determine the virtual address of each function associated with the function call stack at the time of the corresponding kernel crash; Based on the multiple virtual addresses, the first function information of each function is determined.

7. The method according to claim 1, characterized in that, Based on the multiple kernel crash logs, the kernel state information of the corresponding kernel is determined, including: For each kernel crash log, the corresponding kernel configuration information is determined based on the kernel crash log; the configuration information includes the kernel version information and host information; Identify keywords in multiple runtime logs associated with the corresponding kernel; Based on the configuration information and the keyword, the kernel status information of the corresponding kernel is determined.

8. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 7.

9. A computer storage medium storing 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 7.

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 as described in any one of claims 1 to 7.

Images