Core dump data processing method and core dump analysis system

Abstract

The invention discloses a core dump data processing method and a core dump analysis system, which can obtain detailed core dump information which can be obtained by an intrusive scheme in a non-intrusive mode without increasing the load of a developer, and comprises the following steps: obtaining a core dump file, the core dump file comprises a memory snapshot formed by an exception when the application program runs in a user container attached with a mirror image version tag, and the user container is created based on a released mirror image; transmitting the core dump file as a standard input to a pipeline command script; the mirror image label and the core dump related parameters are used as command line parameters to be transmitted to a pipeline command script; the pipeline command script uploads the core dump file, the mirror image label and the core dump related parameters; according to the mirror image version label, pulling a version solidification mirror image with the same mirror image version label, and constructing an analysis container based on the version solidification mirror image; and the analysis container performs analysis according to the core dump file and the core dump related parameters.

Description

Technical Field

[0001] The present application relates to the field of software engineering, and in particular to a core dump data processing method and a core dump analysis system. Background Art

[0002] As we all know, program crashes are a common and serious problem in software development and maintenance. To effectively diagnose and fix these problems, developers often rely on core dump files. Core dump files are a complete snapshot of the current runtime memory when an unrecoverable exception occurs in the program. These files provide rich memory data, allowing developers to deeply analyze the specific reasons that caused the program to crash.

[0003] However, in order to analyze a core dump file, there must be a corresponding binary executable file, and the binary executable file must completely match the program version in the core dump file, otherwise the analysis result will be inaccurate or even extremely biased. In addition, in order to analyze a core dump file, a source code file with a completely matching version is also required. In other words, if a binary executable file and a source code file that completely matches it are not found, even if a core dump file is generated, it will be difficult to analyze and locate the problem.

[0004] Currently, the core dump analysis systems in the industry can be divided into two types: intrusive and non-intrusive.

[0005] On the one hand, the advantage of the non-intrusive core dump analysis system is that it can be decoupled from development and does not require the introduction of additional SDKs, etc., but the disadvantage is that it cannot analyze more detailed crash information.

[0006] On the other hand, the advantage of the intrusive core dump analysis system is that it integrates analysis and collection functions, but the disadvantage is that it affects the development process. In addition, once the SDK version is connected, its analysis capabilities are fixed and cannot be dynamically adjusted or upgraded. Summary of the invention

[0007] Technical problem to be solved by the invention

[0008] The present application is developed in consideration of the above situation, and its purpose is to provide a core dump data processing method and a core dump analysis system, which can obtain the detailed core dump information that can be obtained by an intrusive solution in a non-intrusive manner without increasing the burden on developers.

[0009] Technical solutions adopted to solve technical problems

[0010] A technical solution of the present application provides a core dump data processing method, characterized by comprising:

[0011] Acquire a core dump file, wherein the core dump file includes a memory snapshot formed when an exception occurs when the application is running in a user container with an image version tag, wherein the user container is created based on a release image for deployment to a production environment;

[0012] Passing the core dump file as standard input to a pipeline command script called by the operating system kernel of the host machine on which the user container is built;

[0013] Passing the image tag and core dump related parameters as command line parameters to the pipeline command script;

[0014] The pipeline command script uploads the core dump file, the image tag, and core dump related parameters, where the core dump related parameters are parameters generated when the core dump file is generated and used to provide context information;

[0015] Pulling a version-cured image with the same image version tag according to the image version tag, and building an analysis container based on the version-cured image, wherein the version-cured image is used for version control; and

[0016] The analysis container performs analysis based on the analysis script and according to the core dump file and the core dump related parameters to form an analysis result.

[0017] In addition, the present application also provides a core dump analysis system, which is characterized by comprising:

[0018] A file acquisition module, the file acquisition module acquires a core dump file, the core dump file including a memory snapshot formed when an exception occurs when an application is running in a user container with an image version tag, the user container is created based on a release image for deployment to a production environment;

[0019] a data transfer module, wherein the data transfer module transfers the core dump file as a standard input to a pipeline command script called by an operating system kernel of a host machine on which the user container is constructed, and transfers the image tag and core dump related parameters as command line parameters to the pipeline command script, wherein the core dump related parameters are parameters generated when the core dump file is generated and used to provide context information;

[0020] An upload module, wherein the upload module uploads the core dump file, the image tag, and core dump related parameters through the pipeline command script;

[0021] An image pulling workflow, wherein the image pulling workflow pulls a version-cured image having the same image version tag according to the image version tag;

[0022] A container building workflow, wherein the container building workflow builds an analysis container based on the version-cured image, and the version-cured image is used for version control; and

[0023] An analysis module is configured to cause the analysis container to run an analysis script and to perform analysis according to the core dump file and the core dump related parameters to form an analysis result.

[0024] Effects of the Invention

[0025] According to the core dump data processing method and core dump analysis system described in the technical solution, by adopting containerization technology, detailed core dump information that can be obtained by intrusive solutions can be obtained in a non-intrusive manner without increasing the burden on developers. In addition, the core dump data processing method and core dump analysis system described in the technical solution have intelligent analysis capabilities that can be upgraded at any time and convenient dynamic analysis capabilities that are not available in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a diagram showing the architecture of Docker and Jenkins integration.

[0027] Figure 2 The flowchart shows the main steps of the core dump data processing method according to one embodiment of the present application.

[0028] Figure 3 This is a flowchart showing a first variation of the core dump data processing method according to an embodiment of the present application.

[0029] Figure 4 This is a flowchart showing a first variation of the core dump data processing method according to an embodiment of the present application.

[0030] Figure 5 It is a main functional architecture diagram of a core dump analysis system according to one embodiment of the present application. DETAILED DESCRIPTION

[0031] First, in order to facilitate understanding and clear description, before describing the embodiments of the present application and its preferred examples in detail, several technical terms involved in the present application are described first.

[0032] The English name of the "core dump (file)" described in this application is core dump, which is sometimes also called core dump or core file. It is a debugging technique in which the operating system writes the content of the process address space at this time and other information about the process status into a disk file when the process receives certain signals and stops running. The core dump file is usually generated by the operating system when the system receives a specific signal. The signal can be triggered by an exception in the program execution process, or it can be sent by an external program. The result of the action is generally to generate a memory dump file of a certain process, and the file contains the memory snapshot, register status, and running stack information when the process crashes. Sometimes the program has not been thoroughly tested, which makes the program accidentally damaged during execution, which will lead to the occurrence of core dumps. The core dump file generated by the core dump can usually be used to analyze where the program is running and where an error occurred.

[0033] The "memory snapshot" described in this application records the memory state when the application crashes, including the contents of the data segment, heap, stack and other areas, and provides all the data of the application at the time of the crash.

[0034] The "container" described in this application involves containerization technology, which is a lightweight operating system-level virtualization solution that allows users to run applications and their dependencies in a resource-isolated process. Specifically, the components necessary to run the application will be packaged into an image and can be reused. Each container running on the host machine runs in an isolated environment, logically isolated from each other, and does not share the host machine's memory, CPU, and disk. The process in the container cannot monitor any process outside the container.

[0035] The "image" described in this application also involves containerization technology, which is a template of the above-mentioned "container" and a read-only file. The image contains the application and the dependent environment required for the application to run. In addition, the image can use a layered file system, and each modification to the image will be added to the template of the original read-only file in the form of a "read-write layer".

[0036] The "pipeline command (script)" described in this application is a way of connecting multiple commands in an operating system. Two or more commands can be connected together so that the output (standard output) of one command becomes the input (standard input) of the next command. Two or more commands connected in this way form a pipeline.

[0037] The "Version Control System (VCS)" described in this application is a software tool for managing file and directory changes, helping members of the development team to collaborate on projects, track historical versions of files, restore old versions, merge changes, and resolve conflicts. The main functions of the version control system include version control, branch management, merging and conflict resolution, tag management, permission management, and backup and recovery. Version control systems include locally deployed version control systems and online version control systems deployed based on the network. Online version control systems deployed based on the network include centralized version control systems and distributed version control systems. As a common version control system, for example, Git is included, which is a distributed version control system.

[0038] Next, refer to Figure 1 First, the system architecture of Docker and CI / CD integration involved in this application is explained.

[0039] First of all, it should be noted that the technical solution involved in this application can operate under the infrastructure architecture of cloud services (for example, public cloud, private cloud, hybrid cloud, etc.). In addition, the technical solution involved in this application is a composite technical solution based on containerization technology and continuous integration technology. On the one hand. The technical solution involved in this application encapsulates and runs applications and their dependencies through containers to ensure the consistency and portability of applications. On the other hand, the technical solution involved in this application realizes the automatic construction, testing and deployment of codes through continuous integration tools (for example, Jenkins, Github Actions, etc.), improves development efficiency, and ensures the quality of code and high availability of applications. Here, the integration of Docker and Jenkins is used as an example for explanation.

[0040] Figure 1 The following is a schematic diagram showing the architecture of Docker and Jenkins integration. Figure 1 As shown, after completing the development of the application, the developer (or the development end) submits the source code of the application to the code repository (for example, Git or SVN), thereby storing the source code of the application in the code repository. On the other hand, Jenkins detects the storage status of the code repository at regular intervals or in real time, specifically, whether there is a new source code of the application stored in the code repository. If it is detected that a new source code of the application is stored in the code repository, the pipeline is triggered.

[0041] When the pipeline is triggered, Jenkins first pulls the source code of the new application stored in the code repository from the code repository. Then, after pulling the source code of the new application, on the one hand, Jenkins builds the release image by calling the Dockerfile file for release and executing the Docker build command, and on the other hand, Jenkins builds the image for version fixation by calling the Dockerfile file for version fixation and executing the Docker build command. Docker image is a special layered file system that contains applications and necessary dependent environments, but does not contain any dynamic information. More specifically, Docker image includes kernel (bootfs), root image, and one or more layers of applications superimposed on the root image. The root image can be understood as an operating system, such as CentOS, Redhat, Ubuntu. Dockerfile is a text file that contains instructions, each of which is used to build a layer in the Docker image.

[0042] Specifically for this application, the Dockerfile file for release is a Dockerfile file used to build a release image, including a compile phase code segment and a release image build phase code segment. The compile phase code segment includes a compile-time base image pull instruction, a working directory setting instruction, a dependency download instruction, a source code copy instruction, and a compile instruction for compiling the source code of the new application pulled above, etc. By executing the compile phase code segment, a binary executable file corresponding to the source code of the application can be formed. On the other hand, the release image build phase code segment includes a runtime base image pull instruction, a working directory setting instruction, a binary executable file copy instruction, a port exposure instruction, and a program running instruction, etc. By executing the release image build phase code segment, a release image that only includes a binary executable file and runtime dependencies can be formed.

[0043] On the other hand, the version-fixed Dockerfile is a Dockerfile file used to build a version-fixed image, including the compilation stage code and the version-fixed image building stage code segment. The version-fixed image building stage code segment includes runtime base image pull instructions, working directory setting instructions, binary executable file copy instructions, source code copy instructions, debugging tool installation instructions, port exposure instructions, and program running instructions, etc. By executing the version-fixed image building stage code segment, a version-fixed image including the above-mentioned binary executable file, dependencies for rebuilding the same version of the application, debugging tools, application source code, configuration files, and image version tags can be formed.

[0044] However, the construction of the version-fixed image is not limited to the above method. It can also be that Jenkins builds the Debug image by calling the Dockerfile file for Debug and executing the Docker build command, and then builds the version-fixed image based on the Debug image.

[0045] Next, after building the above-mentioned release image and version-fixed image, pass the image version tag of the version-fixed image to the release image through a specific command, so that the release image has the same image version tag as the version-fixed image. Then, push the release image and the version-fixed image with the same image version tag to the release image warehouse and the version-fixed image warehouse respectively.

[0046] In the above, the corresponding release image and version-fixed image are built and pushed for a certain application. In this way, the corresponding release image and version-fixed image can be built and pushed for all applications, and the release image warehouse and version-fixed image warehouse respectively store the release image and version-fixed image corresponding to each application.

[0047] On the other hand, a container orchestration cluster, such as a Kubernetes cluster (hereinafter referred to as K8s cluster), is deployed on the host. In the following, for ease of understanding, the creation and operation of the container are described by taking the K8s cluster as an example.

[0048] Specifically, a deployment configuration file (for example, deployment.yaml) is written in advance. The image, number of replicas, environment variables, etc. of the application are defined in the deployment configuration file. Then, a specific command (the kubectl apply-fdeployment.yaml command in the K8s cluster) is used to apply the deployment to the K8s cluster. In this case, when the Controller-Manager of the K8s cluster receives the definition of the new Deployment, it will create a ReplicaSet to manage the container set (Pod). ReplicaSet ensures that the container set is always in a running state. ReplicaSet creates a container set based on the template part (template) in the deployment configuration file, and sends the definition of the container set to the K8s scheduler (Scheduler). The scheduler will select a suitable node to run the container set. The Kubelet on the node where the container set runs is responsible for creating and managing the container set. Specifically, Kubelet calls the container runtime (for example, Docker) to create and start a user container. Kubelet pulls the specified release image according to the definition in the specification information of the container set, and creates and starts the user container based on the release image to enable the application to run in the user container.

[0049] In addition, a Job is created in the K8s cluster, which has the following functions:

[0050] (1) Before a specific process corresponding to an application of a user container of a container set is started, an image version tag of a release image for building the user container is pre-stored in a working directory folder of the workload;

[0051] (2) assisting in the generation of core dump files; and

[0052] (3) Add an image version tag to the core dump file when the core dump is generated.

[0053] In addition, a scanning script is pre-written, and the core dump folder on the host machine for storing core dump files is regularly scanned by executing the scanning script to detect whether there is a new core dump file. In addition, when a new core dump file is detected, the core dump file is uploaded to the Object Storage Service (OSS) and the occurrence of a new core dump event is reported through the pipeline provided by the server.

[0054] It is particularly important to note that, as described in (3) above, when an application is running in a user container and an exception occurs that causes a core dump, under the action of the above-mentioned Job, the image version label of the release image corresponding to the above-mentioned user container that is pre-stored is read from the working directory folder of the workload and added to the core dump file (or, spliced ​​with the core dump file).

[0055] Below, refer to Figure 2 , an implementation method of the core dump data processing method described in this application is described.

[0056] Figure 2 A flowchart showing the main steps of a core dump data processing method according to an embodiment of the present application.

[0057] First, in step ST1, a newly detected core dump file is acquired, which includes a memory snapshot formed when an exception occurs when the application is running in a user container, and also includes the image tag information of the published image corresponding to the user container. It should be noted that not all exceptions will trigger a signal to notify the generation of a core dump file. Taking the Linux system as an example, only when a floating point exception, a tracking trap, an abort signal from an abort function, an invalid memory reference (i.e., a segment fault) occurs, will a signal (SIGTRAP signal, SIGABRT signal, SIGFPE signal, SIGSEGV signal) be sent to the corresponding user to terminate and perform a core dump, and only then will a core dump file (memory snapshot at the current moment) be generated. After completing step ST1, enter step ST2.

[0058] In step ST2, a pipeline command script called by the operating system kernel of the host machine built with the above-mentioned user container is used to pass the obtained core dump file as standard input to the pipeline command script, and the core dump related parameters and the image version label of the user container are passed to the pipeline command script as command line parameters, wherein the core dump related parameters are parameters generated when the core dump file is generated and used to provide context information. Under the infrastructure architecture of cloud services, the core_pattern that controls the core dump file generation rule is the configuration of the host machine, and the container set and the container cannot modify it. The host machine is shared by a large number of cloud services, so the traditional method of modifying the core_pattern does not work. For this reason, a solution based on a pipeline command script (i.e., the piping core_pattern solution) is introduced in this application. An example of a pipeline command script is shown below, but is not limited to this.

[0059] echo" / path / to / handle_coredump.sh%p‰u%g%s%t%h%e$IMAGE_TAG"> / proc / sys / kernel / core_pattern

[0060] Among them, %p, %u, %g, %s, %t, %h, and %e are core dump related parameters that are generated when the core dump file is generated and are used to provide context information. $IMAGE_TAG represents the image version tag of the released image. More specifically:

[0061] %p represents the process ID (PID);

[0062] %u represents the user ID (UID);

[0063] %g represents the group ID (GID);

[0064] %s represents the signal number that caused the core dump;

[0065] %t indicates a timestamp;

[0066] %h represents the host name;

[0067] %e represents the executable file name (without the path).

[0068] In particular, since the core_pattern file itself does not support direct transmission of image version tags, the image version tags are passed here through environment variables. However, image version tags can also be passed through other methods.

[0069] The core dump file, core dump related parameters, and the image version label corresponding to the user container are transmitted in the above manner, which has high customizability.

[0070] In addition, preferably, as auxiliary information, the log information until the application knows that a core dump has occurred is also passed to the pipeline command script. For example, 50 log information until a core dump occurs can be intercepted and passed to the pipeline command script.

[0071] After completing step ST2, proceed to step ST3.

[0072] In step ST3, the pipeline command script uploads the collected core dump files, image version labels, and core dump related parameters (optionally, log information) to the object storage service (e.g., OSS, S3, etc.), and issues a "core dump file generated" notification, thereby starting the analysis of the core dump event processing pipeline.

[0073] As the first pipeline stage, the core dump event processing pipeline pulls the version-cured image with the same image version tag from the version-cured image warehouse according to the uploaded image version tag (i.e., step ST4). Since in the construction phase, the corresponding release image and version-cured image are built for the same application respectively and the image version tag of the version-cured image is passed to the release image, it is certain that the version-cured image that uniquely corresponds to the release image can be found from the version-cured image warehouse.

[0074] As the second pipeline stage, based on the pulled version solidified image, a container for analysis is created and started by, for example, the Docker run command (ie, step ST5).

[0075] As the third pipeline level (i.e., step ST6), the core dump file and core dump related parameters are passed to the analysis container. On the one hand, the directory where the core dump file is located is mounted to a working directory (e.g., named coredump working directory) in the analysis container by means of volume hanging, so that the script in the analysis container can directly access the core dump file. On the other hand, the core dump related parameters are passed to the analysis container as environment variables. More specifically, a script is pre-set, which runs when the analysis container is started, accesses the core dump file in the above manner, and receives the core dump related parameters as environment variables.

[0076] As the fourth pipeline stage (i.e., step ST7), the analysis container analyzes the cause of the core dump by using a debugging tool (e.g., gdb) and an automated analysis script. The automated analysis script mainly includes a code segment for initialization and environment settings, a code segment for generating backtrace information, a code segment for determining relevance, a code segment for obtaining responsibility information, a code segment for filtering invalid core dumps, and a code segment for generating analysis results.

[0077] The initialization and environment setup code segment is used to read the core dump related parameters mentioned above as environment variables, set the working directory, and record the information of the start of analysis into a log file for subsequent auditing and debugging.

[0078] The code segment that generates backtrace information generates complete backtrace information for all threads by calling the debugging tool, which can provide a detailed understanding of the application's state at the time of the crash, including the call stack, local variables, and register values ​​of each thread.

[0079] The code segment for determining the correlation is used to verify from multiple angles whether the problem in the core dump file is directly related to the above-mentioned application. The above-mentioned code segment includes verifying the binary executable file, specifically, checking the file path to confirm whether the binary executable file path in the core dump file matches the path in the application, checking the file name to determine whether the name of the binary executable file is consistent with the binary executable file name in the application, checking the version number of the binary executable file to verify whether it belongs to a specific version of the application, and calculating the hash value of the binary executable file and comparing it with the corresponding version in the version control system to ensure the consistency of the file. In addition, the above-mentioned code segment also includes analyzing the program crash stack (backtrace), extracting the program crash stack information from the core dump file through debugging tools such as gdb, traversing each line in the program crash stack, and finding whether it contains the function name or file path of the source code of the application.

[0080] The execution prerequisite of the code segment for obtaining responsibility information is to clone the code repository into the analysis container, or to mount the code repository into the analysis container by other means, and to install the version control system in the analysis container. For example, when building a version-cured image, the version control system used at that time is packaged together in a read-only form. In this code segment, the commit information of the code line can be obtained by using the git blame command. The commit information includes the commit hash, committer, commit time, commit text, commit summary, and commit ID. In this way, while locating the problem code line, the commit information of the problem code line, that is, the responsibility information, can also be obtained at the same time.

[0081] The code segments filtering invalid core dumps are used to not deliver analysis results (eg, analysis reports) when no problematic code lines are found or when problematic code lines are found but the corresponding submitter information is not obtained.

[0082] The code segment that generates the analysis result combines the extracted problematic code lines and their responsibility information and other information to form an analysis result in a specific format and delivers the analysis result. The analysis result includes the program crash stack, log, responsible person (i.e., the submitter of the problematic code line), submission text, submission ID, and image version tag, etc. In addition, if the problematic code line is not found or the problematic code line is found but the corresponding submitter information is not obtained, the code segment does not generate an analysis result or generates an analysis result indicating information such as "the submitter of the problematic code line cannot be determined".

[0083] According to the core dump data processing method described in this embodiment, by adopting containerization technology, the detailed core dump information that can be obtained by the intrusive solution can be obtained in a non-intrusive way without increasing the burden on developers. Specifically, the traditional intrusive solution usually requires adding additional logging, exception capture and other codes in the source code, which not only increases the burden on developers, but also may introduce new bugs. In this embodiment, there is no need to add any additional code to the source code. By preparing the release image and the version-cured image with the same image version label in advance, it is possible to use the release image to build a user container to run the application. When the application has a core dump due to an exception, the corresponding version-cured image can be accurately pulled through the image version label and a container for analysis including debugging tools can be built. It is possible to reproduce the same version of the operating environment without making any modifications to the source code, thereby performing accurate analysis.

[0084] In addition, according to the core dump data processing method described in this embodiment, compared with the prior art, by making the release image contain only the components and dependencies necessary for runtime, the size of the release image can be reduced, saving storage and transmission resources. Moreover, the lightweight release image can be started and stopped faster, improving resource utilization.

[0085] In addition, according to the core dump data processing method described in this embodiment, by passing a number of log information before the core dump occurs as core dump-related parameters to the pipeline command script and further passing it to the analysis container, these log information can be used as auxiliary information to help locate the problem code line, thereby improving the speed and accuracy of the analysis.

[0086] In addition, according to the core dump data processing method described in this embodiment, by filtering invalid core dump files, unnecessary data transmission can be reduced.

[0087] Figure 3 A flowchart showing the main steps of a first variant of a core dump data processing method according to an embodiment of the present application is shown. In order to avoid repeated description, only the differences between this variant and the above embodiment are described.

[0088] like Figure 3As shown, compared with the above-mentioned embodiment, the difference of this variation is that it also includes step ST8 and step ST9. In step ST8, the analysis results (for example, analysis reports) are delivered to the Web backend through the pipeline, and the "web backend" mentioned here refers to a server that provides a certain web service. Specifically, first, the above analysis results are organized into a format suitable for transmission (for example, JSON format or XML format). Then, an HTTP POST request is sent to the web backend, and the HTTP request containing the analysis results organized into a format suitable for transmission is sent to the specified URL of the web backend. After completing step ST8, proceed to step ST9.

[0089] In step ST9, after receiving the analysis results, the web backend directly passes the analysis results to the web frontend according to the actual situation, or converts the analysis results into a format that is suitable for the web frontend and then passes the analysis results in this format to the web frontend, so that the web frontend can display the above analysis results. The "web frontend" mentioned here refers to a web page that can be seen by opening it through a browser. Specifically, the web frontend is provided with a control, for example, and a request for obtaining the analysis results is generated by the user clicking the control. The web frontend delivers the request to the web backend through the URL, and after receiving the request, the web backend sends the analysis results to the web frontend in a format that is suitable for the web. After receiving the above analysis results, the web frontend displays these analysis results in a specific manner.

[0090] According to the core dump data processing method described in this variant, by displaying information such as the program crash stack, log, responsible person (i.e., the submitter of the problem code line), submission text, submission ID, and image version label, developers, operation and maintenance personnel, or debuggers can easily and quickly determine the cause of the core dump.

[0091] Figure 4 A flowchart showing the main steps of a second variant of the core dump data processing method according to an embodiment of the present application is shown. In order to avoid repeated description, only the differences between this variant and the above embodiment are described below.

[0092] like Figure 4 As shown, compared with the above-mentioned embodiment, the difference of this variation example is that it also includes step ST100, step ST110, step ST120, step ST130, step ST140 and step ST150.

[0093] In step ST100, it is determined whether the cause of the core dump can be analyzed based on the transmitted analysis results. If it is determined to be possible, the entire process ends or the process proceeds to step ST8. If it is determined not to be possible, the process proceeds to step ST110.

[0094] In step ST110, the core dump file is downloaded by using the oss cp command. After completing step ST110, the process proceeds to step ST120.

[0095] In step ST120, the Docker run command is executed for the pulled version solidified image to create and start a debugging container, and the downloaded core dump file is mounted to the debugging container by configuring volume mapping. After completing step ST120, step ST130 is entered.

[0096] In step ST130, a remote terminal or remote command line interface is started in the debugging container by remote access. For example, an SSH Shell is started in the debugging container by using the Docker remote API or shellinabox. After completing step ST130, step ST140 is entered.

[0097] In step ST140, a debugger is started in the debugging container by operating a remote terminal or a remote command line interface. The debugger includes, for example, gdb, dlv, etc. After completing step ST140, the process proceeds to step ST150.

[0098] In step ST150, the web backend generates a URL pointing to the web frontend after starting the debugger. Thus, the user can open the web-based debugging frontend through the URL, thereby being able to debug online.

[0099] According to the data processing method of the core dump described in this variation, for some complex core dumps, by introducing the remote Shell solution, a safe, flexible and efficient debugging environment can be provided. Complex core dump files usually contain a large amount of memory data, which needs to be loaded and parsed in the debugging environment. In addition, complex core dump files often need to be debugged step by step to check the values ​​of specific variables, call stacks and memory status. For this reason, in this variation, by introducing the remote Shell solution, the debugging environment can be quickly started, reducing the time for environment preparation. In addition, users can access the debugging environment through the Web interface and use debugging tools such as gdb, lldb, delve, etc. to debug step by step.

[0100] Based on the data processing method of the core dump in the above-mentioned embodiment and its modified example, Figure 5, the main functional architecture of the core dump analysis system of one embodiment of the present application is described.

[0101] Figure 5 FIG. 1 shows the main functional architecture of a core dump analysis system S according to an embodiment of the present application. Figure 5 As shown, the core dump analysis system S mainly involves a production work node S1, a container orchestration platform S2, and an analysis work node S3. That is, in this embodiment, the production environment and the analysis environment are set on different work nodes (host machines), but it is not limited to this. In other words, depending on the actual situation, sometimes, the production environment and the analysis environment can also be set on the same work node (the same host machine).

[0102] The production work node S1 includes a user container, a text acquisition module, a data transfer module, and a pipeline command module. The user container is used for application operation, and when a core dump occurs due to an abnormality in the operation of the application, the core dump file is saved to a pre-set working directory (for example, the working directory of the application). In addition, when a core dump occurs, the operating system kernel of the production work node S1 will generate corresponding core dump related parameters (for example, PID, etc.) and save them in a pre-set folder. The text acquisition module will regularly scan the folder where the core dump file is saved. If a newly saved core dump file is found, the core dump file, the image version label corresponding to the user container, and the corresponding core dump related parameters are obtained. After obtaining the above data, the data transfer module passes the core dump file as standard input to the pipeline command script called by the operating system kernel of the production work node S1, and passes the obtained image version label and core dump related parameters as command line parameters to the pipeline command script. Next, the pipeline command module uploads the passed core dump file, image tag, and core dump related parameters to the object storage service (i.e., OSS) through the pipeline command script. Then, after the above data is uploaded to the object storage service, a new core dump event is reported through the pipeline provided by the server.

[0103] The container orchestration platform S2 is, for example, Kubernetes, and includes an image pulling workflow and a container building workflow. The image pulling workflow is coordinated by the control plane components of Kubernetes (API Server and Controller-Manager, i.e., control manager), and is executed by the Kubelet and container runtime (such as Docker or containerd) on the analysis worker node S3. According to the image version label provided by the object storage service, a version-cured image with the same image version label is pulled from the version-cured image repository. The container building workflow is based on the version-cured image pulled by the image pulling workflow and is executed by the Kubelet and container runtime on the analysis worker node S3, and thereby builds an analysis container on the analysis worker node S3. In addition, the core dump file stored in the object storage service and the corresponding core dump-related parameters are mounted to the above-mentioned analysis container.

[0104] The analysis work node S3 includes an analysis container and an analysis module constructed by the container orchestration platform S2. The analysis module enables the analysis container to run an analysis script, and analyzes the mounted core dump file and the corresponding core dump related parameters to form an analysis result of the core dump.

[0105] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A core dump data processing method, characterized in that: include: Acquire a core dump file, wherein the core dump file includes a memory snapshot formed when an exception occurs when the application is running in a user container with an image version tag, wherein the user container is created based on a release image for deployment to a production environment; Passing the core dump file as standard input to a pipeline command script called by the operating system kernel of the host machine on which the user container is built; Passing the image tag and core dump related parameters as command line parameters to the pipeline command script, wherein the core dump related parameters are parameters generated when the core dump file is generated and used to provide context information; The pipeline command script uploads the core dump file, the image version label, and core dump related parameters; Pulling a version-cured image with the same image version tag according to the image version tag, and building an analysis container based on the version-cured image, wherein the version-cured image is used for version control; as well as The analysis container performs analysis based on the analysis script and according to the core dump file and the core dump related parameters to form an analysis result.

2. The core dump data processing method according to claim 1, characterized in that: The release image only includes the binary executable files and runtime dependencies of the application, and The version-fixed image includes the binary executable file, dependencies for rebuilding the same version of the application, debugging tools, source code of the application, a configuration file of the application, and the image version tag.

3. The core dump data processing method according to claim 2, characterized in that: The version-cured image also includes information of a version control system that manages the code repository, which is added in a read-only form, so as to obtain responsibility information that causes the core dump to occur.

4. The core dump data processing method according to claim 3, characterized in that: The responsibility information includes submission hash, submitter, submission text, submission time and submission ID.

5. The core dump data processing method according to claim 4, characterized in that: The cause of the core dump includes the problematic line of code that caused the core dump, The data processing method further includes: Acquire information of a submitter who submitted the problematic code line according to the problematic code line; and In the case where the information of the submitter is obtained, the analysis result is delivered, and If the information of the submitter is not obtained, the analysis result will not be delivered.

6. The core dump data processing method according to claim 1, characterized in that: The method also includes transferring the log information of the application program until a core dump occurs to the pipeline command script, and the pipeline command script also uploads the log information.

7. The core dump data processing method according to claim 1, characterized in that: The construction of the version solidified image and the release image includes: The CI / CD tool detects whether the source code of the application is submitted to the code repository as new source code. When it is detected that the source code of the application is submitted to the code repository as a new source code, the image building pipeline is triggered. The image building pipeline includes the following pipeline stages: The CI / CD tool pulls the source code of the application from the code repository; The CI / CD tool builds the release image by calling the release Dockerfile file and the version fixation Dockerfile file and executing the Docker build command; and The CI / CD tool builds the version-fixed image by calling the version-fixed Dockerfile file and executing the Docker build command, or The CI / CD tool builds a Debug image by calling the Dockerfile file for Debug and executing the Docker build command, and then builds the version solidified image based on the Debug image.

8. The core dump data processing method according to claim 7, characterized in that: The building of the version-fixed image and the release image further includes transferring the image version tag of the version-fixed image to the release image.

9. The core dump data processing method according to claim 8, characterized in that: After the construction of the version-cured image and the release image is completed, the version-cured image and the release image are pushed to a version-cured image warehouse and a release image warehouse respectively.

10. The core dump data processing method according to claim 1, characterized in that: Also includes: Passing the analysis results to the web backend; After receiving the analysis result, the web backend converts the analysis result into a format adapted to the web frontend, and transmits the analysis result in the format to the web frontend; as well as The web front end displays the analysis results.

11. The core dump data processing method according to claim 10, characterized in that: When the cause of the core dump cannot be analyzed according to the analysis result, the web backend is caused to perform the following operations: Downloading the core dump file to the host machine; Building and starting a debugging container based on the version solidified image, and mounting the core dump file to the debugging container by configuring volume mapping; as well as Starting a remote terminal or a remote command line interface in the debugging container by remote access; Starting a debugger in the debugging container by operating the remote terminal or the remote command line interface; as well as The web backend generates a URL pointing to the web frontend after starting the debugger.

12. A core dump analysis system, characterized in that: include: A file acquisition module, the file acquisition module acquires a core dump file, the core dump file including a memory snapshot formed when an exception occurs when an application is running in a user container with an image version tag, the user container is created based on a release image for deployment to a production environment; a data transfer module, wherein the data transfer module transfers the core dump file as a standard input to a pipeline command script called by an operating system kernel of a host machine on which the user container is constructed, and transfers the image tag and core dump related parameters as command line parameters to the pipeline command script, wherein the core dump related parameters are parameters generated when the core dump file is generated and used to provide context information; A pipeline command module, wherein the pipeline command module uploads the core dump file, the image version tag, and core dump related parameters through the pipeline command script; An image pulling workflow, wherein the image pulling workflow pulls a version-cured image having the same image version tag according to the image version tag; A container building workflow, wherein the container building workflow builds an analysis container based on the version-cured image, and the version-cured image is used for version control; as well as An analysis module is configured to cause the analysis container to run an analysis script and to perform analysis according to the core dump file and the core dump related parameters to form an analysis result.

Images