Program startup diagnostic method, device, equipment and readable storage medium

Abstract

The embodiment of the present invention relates to the field of computer technology, and discloses a program-initiated diagnostic method, device, equipment, and readable storage medium, the method comprising: obtaining an application program inserted with a diagnostic agent program, the diagnostic agent program including a connection package and an expansion plug-in package; starting the application program inserted with the diagnostic agent program, and at the same time using the diagnostic agent program and the class loader of the application program to isolate the operating environment of the diagnostic agent program and the application program, and using the connection package to establish a call chain between the diagnostic agent program and the application program to perform function calls between the application program and the diagnostic agent program; based on the connection package, the expansion plug-in package and the class loader, the application program is monitored to obtain the diagnostic result data of the application program. The application of the technical solution of the present invention can improve the accuracy and flexibility of the program-initiated diagnosis.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a program startup diagnosis method, device, equipment and readable storage medium. Background Art

[0002] The Spring framework is an open source Java development framework with the features of IOC (dependency injection) and AOP (aspect-oriented programming). During the startup of the program functions of an application based on the Spring framework, a series of bean objects, namely application components, need to be generated, and specific functions are implemented by operating these application components. Among them, during the startup of the application, data indicators such as the operating parameters of each application component of the application can reflect the performance of the application.

[0003] In the prior art, a target application program implanted with a probe program is deployed into a container. When the target application program is started, the probe program is loaded, and at least one performance indicator data during the operation of the target application is obtained through the probe program. The at least one performance indicator data is further analyzed through the probe program to obtain a performance analysis result of the target application.

[0004] However, implanting diagnostic programs in the form of probe programs will interfere with the target application, reducing the accuracy of the diagnosis. In addition, the probe program cannot flexibly set the listener for monitoring performance indicator data, further resulting in the inflexibility of the diagnostic method. Summary of the invention

[0005] In view of the above problems, embodiments of the present invention provide a method, apparatus, device and readable storage medium for diagnosing program startup, which are used to solve the problems of inaccurate diagnosis and low flexibility of program startup in the prior art.

[0006] According to one aspect of an embodiment of the present invention, a method for diagnosing program startup is provided, the method comprising:

[0007] Acquire an application program inserted with a diagnostic agent program, wherein the diagnostic agent program includes a connection package and an expansion plug-in package;

[0008] Starting the application program in which the diagnostic agent program is inserted, isolating the operating environment of the diagnostic agent program from that of the application program by using the class loader of the diagnostic agent program and the application program, and establishing a call chain between the diagnostic agent program and the application program by using the connection package to perform a function call between the application program and the diagnostic agent program;

[0009] Based on the connection package, the expansion plug-in package and the class loader, the application is monitored to obtain diagnostic result data of the application.

[0010] In an optional manner, the diagnostic agent program also includes: a main driver package, which starts the application program in which the diagnostic agent program is inserted, including: obtaining the startup class of the application program from the startup parameters of the application program, and calling the startup function of the startup class of the application program; parsing and obtaining the startup class of the diagnostic agent program from the main driver package, and calling the startup function of the startup class of the diagnostic agent program.

[0011] In an optional manner, the class loader of the application is an application system class loader, the class loader of the diagnostic agent is a custom class loader, and the connection package includes: a bridge package and a dependency package, and the connection package is used to establish a call chain between the diagnostic agent and the application to perform function calls between the application and the diagnostic agent, including: adding the bridge package to the root class loader of the application so that the application system class loader loads the abstract bridge class in the bridge package through the root class loader; adding the dependency package to the custom class loader so that the custom class loader loads the implementation class of the abstract bridge class in the dependency package; establishing a call chain between the diagnostic agent and the application through the abstract bridge class in the bridge package and the implementation class to perform function calls between the application and the diagnostic agent.

[0012] In an optional manner, the dependency package includes: a custom bytecode converter, which monitors the application based on the connection package, the extension plug-in package and the class loader to obtain the diagnostic result data of the application, including: loading and instantiating the custom bytecode converter in the dependency package according to the custom class loader, the custom bytecode converter including: initializing a bridge function, starting a listening function, and a bytecode conversion function; implanting the instantiated custom bytecode converter into the application system class loader, and calling the target functions of each target component of the application through the bytecode manipulation framework to call the listener in the extension plug-in package, monitor the target component of the application, and obtain the diagnostic result data of the application; the listener includes: components of the diagnostic process listener and the diagnostic status listener.

[0013] In an optional manner, the custom bytecode converter in the dependent package is loaded and instantiated according to the custom class loader, including: calling the class loading function of the custom class loader to obtain the bytecode base class object; calling the constructor object acquisition function of the bytecode base class object to load the custom bytecode converter; calling the initialization bridge function to instantiate the implementation class of the abstract bridge class, the functions of the implementation class of the abstract bridge class include: a function for adding an interception point before execution, a function for adding an interception point without exception after execution, and a function for adding an interception point with exception after execution; calling the startup listening function to instantiate a listening management container and a ready listening management container to obtain the instantiated custom bytecode conversion; the listening management container is used to manage the diagnostic process listener, and the ready listening management container is used to manage the diagnostic status listener.

[0014] In an optional manner, the target function of each target component of the application is called through the bytecode manipulation framework to call the listener in the extended plug-in package to listen to the target component of the application and obtain the diagnostic result data of the application, including: calling the bytecode conversion function to generate a first target component proxy class through the bytecode manipulation framework for the target component that meets the proxy class generation condition; calling the function of the implementation class of the abstract bridge class through the bytecode manipulation framework to add an interception point in the target function of the first target component proxy class according to the interception point addition condition to generate a second target component proxy class, wherein the second target component proxy class includes the target function with the interception point added; calling the target function with the interception point added to calculate the dependency chain of each second target component proxy class, and calling the listener in the extended plug-in package to obtain the diagnostic result data of the application.

[0015] In an optional manner, the target function with the added interception point is called to calculate the dependency chain of each second target component proxy class, and the listener in the extended plug-in package is called to obtain the diagnostic result data of the application, including: constructing a stack structure of each second target component proxy class, and calculating multiple dependency chains of second target component proxy classes through the stack structure; calling all the diagnostic process listeners through the instantiated listening management container to listen to the information at the interception point; calling the diagnostic status listener through the instantiated ready listening management container to listen to the startup status of the target component corresponding to the second target component proxy class, and the startup status includes: successful startup and failed startup; if the startup status is the successful startup, the diagnostic status listener and the diagnostic process listener corresponding to the target component corresponding to the second target component proxy class are closed and the information at the interception point is obtained, otherwise a prompt of the target component startup failure is sent to the user; the information at the interception point is summarized and processed according to the dependency chain of the second target component proxy class to generate the diagnostic result data of the application.

[0016] In an optional manner, during the process of starting the application program inserted with the diagnostic agent program, a bytecode insertion interface is also provided, and the instantiated custom bytecode converter is implanted into the application system class loader, including: calling the function of adding a bytecode converter of the bytecode insertion interface to implant the instantiated custom bytecode converter into the application system class loader.

[0017] In a second aspect, the present invention provides a program-initiated diagnostic device, comprising:

[0018] An acquisition module, used for acquiring an application program inserted with a diagnostic agent program, wherein the diagnostic agent program includes a connection package and an expansion plug-in package;

[0019] A startup module, used to start the application program inserted with the diagnostic agent program, and at the same time, to isolate the running environment of the diagnostic agent program and the application program by using the class loader of the diagnostic agent program and the application program, and to establish a call chain of the diagnostic agent program and the application program by using a connection package, so as to perform a function call between the application program and the diagnostic agent program;

[0020] The monitoring module is used to monitor the application based on the connection package, the expansion plug-in package, and the class loader to obtain the diagnosis result data of the application.

[0021] In a third aspect, the present invention provides a program-activated diagnostic device, comprising:

[0022] Processor, memory, communication interface;

[0023] The memory is used to store executable instructions of the processor;

[0024] Wherein, the processor is configured to execute the program-initiated diagnostic method as described in the first aspect above by executing the executable instructions.

[0025] In a fourth aspect, the present invention provides a readable storage medium, comprising: a computer program stored thereon, wherein when the computer program is executed by a processor, the program-initiated diagnostic method as described in the first aspect above is implemented.

[0026] The embodiment of the present invention obtains an application program inserted with a diagnostic agent program, wherein the diagnostic agent program includes a connection package and an extension plug-in package, starts the application program inserted with the diagnostic agent program, and simultaneously utilizes the diagnostic agent program and the class loader of the application program to isolate the running environment of the diagnostic agent program and the application program, utilizes the connection package to establish a call chain between the diagnostic agent program and the application program to perform function calls between the application program and the diagnostic agent program, monitors the application program based on the connection package, the extension plug-in package and the class loader, and obtains diagnostic result data of the application program, wherein the diagnostic agent program and the class loader of the application program are utilized to isolate the running environment of the diagnostic agent program and the application program, which can reduce interference between the diagnostic agent program and the application program, and simultaneously utilizes the connection package to establish a call chain between the diagnostic agent program and the application program to perform function calls between the application program and the diagnostic agent program, which can improve the accuracy of the diagnostic method for program startup, wherein the extension plug-in package of the diagnostic program can realize flexible configuration of the listener, thereby improving the flexibility of program startup diagnosis.

[0027] The above description is only an overview of the technical solution of the embodiment of the present invention. In order to more clearly understand the technical means of the embodiment of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the embodiment of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The accompanying drawings are only used to illustrate the embodiments and are not to be considered as limiting the present invention. In addition, the same reference symbols are used to represent the same components throughout the accompanying drawings. In the accompanying drawings:

[0029] Figure 1 A schematic flow chart of a first embodiment of a program-initiated diagnostic method provided by the present invention is shown;

[0030] Figure 2 An example diagram of a call chain provided by the present invention is shown;

[0031] Figure 3 A schematic flow chart of a second embodiment of the program-initiated diagnostic method provided by the present invention is shown;

[0032] Figure 4 An example diagram showing the diagnosis result data of an application program obtained according to the instantiated monitoring management container and the ready monitoring management container provided by the present invention;

[0033] Figure 5 An example diagram of loading and instantiating a custom bytecode converter in a dependent package provided by the present invention is shown;

[0034] Figure 6 An example diagram of the generation process of the second target component proxy class provided by the present invention is shown;

[0035] Figure 7 An example diagram showing the method of calling a target function with an interception point added thereto to calculate the dependency chain of each second target component proxy class and calling a listener in an extended plug-in package to obtain diagnostic result data of an application program provided by the present invention;

[0036] Figure 8 A schematic flow chart of a third embodiment of the program-initiated diagnostic method provided by the present invention is shown;

[0037] Fig. 9 A schematic structural diagram of a first embodiment of a program-initiated diagnostic device provided by the present invention is shown;

[0038] Fig.10 A schematic diagram of the structure of a program-initiated diagnostic device provided by the present invention is shown. DETAILED DESCRIPTION

[0039] Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0040] Figure 1 A flow chart of a first embodiment of the program-initiated diagnostic method provided by the present invention is shown. The execution subject is a program-initiated diagnostic device, which can generally be implemented by software, hardware, or a combination of software and hardware.

[0041] like Figure 1 As shown, the program-started diagnostic method of this embodiment may include the following steps:

[0042] Step S101: Acquire an application program into which a diagnostic agent program is inserted, wherein the diagnostic agent program includes a connection package and an extended plug-in package.

[0043] Specifically, an application program inserted with a diagnostic agent program can be obtained, wherein the diagnostic agent program includes a connection package and an extension plug-in package. Among them, the agent program, that is, the Java agent program Java Agent is an application program written in the Java programming language, which can be inserted into other Java applications at runtime, and perform operations such as monitoring, modifying or collecting runtime information on the inserted Java application program. The diagnostic agent program refers to an agent program that diagnoses the application program. Specifically, the diagnostic agent program includes a connection package for isolating the diagnostic agent program and the application program. Among them, the connection package refers to a JAR package loaded when the application is started, which is used to isolate and bridge the application and the diagnostic agent program, and the extension plug-in package refers to a JAR package loaded when the application is monitored, which is used to provide a listener.

[0044] The present invention does not limit the process of obtaining an application program with a diagnostic agent program inserted therein. Optionally, the file path of the diagnostic agent program can be added to the startup parameters of the application program to obtain the application program with the diagnostic agent program inserted therein. Specifically, before using the diagnostic agent program, the file path of the diagnostic agent program can be added to the startup parameters of the application program, for example: the diagnostic agent program is packaged into a JAR file, and the save path of the JAR file is added to the startup parameters of the application program, that is, the JAR package is passed to the application Java Virtual Machine (Java VirtualMachine, JVM for short) to update the startup parameters of the application program, wherein, if the application program is started, that is, the JVM of the application program is started and the diagnostic agent program is loaded, the diagnostic agent program can interact with the running application program to achieve operational purposes such as monitoring, modifying or collecting runtime information.

[0045] Step S102, start the application with the diagnostic agent program inserted, and use the diagnostic agent program and the application's class loader to isolate the diagnostic agent program from the application's running environment, and use the connection package to establish a call chain between the diagnostic agent program and the application to perform function calls between the application and the diagnostic agent program.

[0046] Specifically, an application with a diagnostic agent inserted can be started, and the diagnostic agent and the application's class loader can be used to isolate the diagnostic agent and the application's running environment, and a connection package can be used to establish a call chain between the diagnostic agent and the application to perform function calls between the application and the diagnostic agent.

[0047] The present invention does not limit the process of starting the application program with the diagnostic agent program inserted therein. Optionally, the application program with the diagnostic agent program inserted therein may be started by calling a start function of a start class.

[0048] Among them, the role of the class loader ClassLoader, that is, the Java class loader, is to dynamically load the class file into the JVM memory so that other classes can use the loaded class. There are many different types of class loaders, including but not limited to: root class loaders, extension class loaders, and application class loaders. Specifically, the present invention does not limit the process of isolating the operating environment of the diagnostic agent and the application program using the class loader of the diagnostic agent and the application program. Optionally, before isolating the operating environment of the diagnostic agent and the application program using the class loader of the diagnostic agent and the application program, an application system class loader for loading the connection package can be generated according to the application program, and a custom class loader for loading the connection package can be generated according to the diagnostic agent. Among them, the application system class loader ApplicationClassloader and the custom class loader ProfilerAgentClassLoader are isolated from each other. The two are at the same level and are inherited from the application class loader AppClassLoader. The classes loaded by the two are invisible to each other. Therefore, the operating environment of the diagnostic agent and the application can be isolated.

[0049] However, during the diagnostic process of program startup, while ensuring that the application system class loader ApplicationClassloader and the custom class loader ProfilerAgentClassLoader are isolated from each other, it is also necessary to ensure that the classes between the two can be called by each other, that is, the function call between the diagnostic agent and the application can be performed. Therefore, it is necessary to load the connection package in the diagnostic agent, that is, call some enhanced classes and tool classes in the diagnostic agent to connect the application system class loader ApplicationClassloader and the custom class loader ProfilerAgentClassLoader in a bridging manner. Among them, the present invention does not limit the process of using the connection package to establish a call chain between the diagnostic agent and the application to perform a function call between the application and the diagnostic agent. Optionally, the connection package can be loaded into the class loaders of the diagnostic agent and the application respectively, and then the call chain between the diagnostic agent and the application is established according to the diagnostic agent loaded with the connection package and the class loader of the application to perform a function call between the application and the diagnostic agent.

[0050] Step S103: Based on the connection package, the expansion plug-in package and the class loader, the application is monitored to obtain the diagnostic result data of the application.

[0051] Specifically, when starting the application program with the diagnostic agent program inserted, the application program can be monitored based on the connection package, the expansion plug-in package described in step S101 and the class loader described in step S102 to obtain the diagnostic result data of the application program.

[0052] The present invention does not limit the process of monitoring the application based on the connection package, the extension plug-in package and the class loader to obtain the diagnostic result data of the application. Optionally, the custom bytecode converter in the dependency package can be loaded and instantiated according to the custom class loader; the instantiated custom bytecode converter is then implanted into the application system class loader, and the target function of each target component of the application is called through the bytecode manipulation framework to call the listener in the extension plug-in package, monitor the target component of the application, and obtain the diagnostic result data of the application, wherein the connection package includes: a bridge package and a dependency package. The extension plug-in package is loaded into the class loader of the diagnostic agent when monitoring the application.

[0053] The program-initiated diagnostic method provided in this embodiment obtains an application program inserted with a diagnostic agent program, wherein the diagnostic agent program includes a connection package and an extension plug-in package, and starts the application program inserted with the diagnostic agent program. At the same time, the diagnostic agent program and the class loader of the application program are used to isolate the running environment of the diagnostic agent program and the application program, and a call chain between the diagnostic agent program and the application program is established by using the connection package to perform function calls between the application program and the diagnostic agent program. Based on the connection package, the extension plug-in package and the class loader, the application program is monitored to obtain diagnostic result data of the application program. The use of the diagnostic agent program and the class loader of the application program to isolate the running environment of the diagnostic agent program and the application program can reduce interference between the diagnostic agent program and the application program. At the same time, the use of the connection package to establish a call chain between the diagnostic agent program and the application program to perform function calls between the application program and the diagnostic agent program can improve the accuracy of the program-initiated diagnostic method. The extension plug-in package of the diagnostic program can realize flexible configuration of the listener, thereby improving the flexibility of program-initiated diagnosis.

[0054] exist Figure 1On the basis of the illustrated embodiment, the embodiment of the present invention further proposes that the diagnostic agent program also includes: a main driver package, optionally, starting the application program with the diagnostic agent program inserted therein may include: obtaining the startup class of the application program from the startup parameters of the application program, calling the startup function of the startup class of the application program, and parsing and obtaining the startup class of the diagnostic agent program from the main driver package, calling the startup function of the startup class of the diagnostic agent program to start the application program with the diagnostic agent program inserted therein. The present invention does not limit the process of obtaining the startup class of the application program from the startup parameters of the application program, wherein the description of the startup parameters of the application program can refer to the description in step S101, which will not be repeated here. The main driver package is a JAR package that stores the startup class of the diagnostic agent program. Specifically, the present invention does not limit the process of obtaining the main driver package. Optionally, the file path of the diagnostic agent program can be obtained through the startup parameters of the application program, and the JAR package of the diagnostic agent program can be further obtained through the path of the diagnostic agent program, wherein the JAR package of the diagnostic agent program includes the main driver package described above. Optionally, the present invention does not limit the process of parsing and obtaining the startup class of the diagnostic agent program from the main driver package. Optionally, the configuration item Premain-Class can be parsed in the configuration file of the main driver package, and the value of the configuration item is the startup class of the diagnostic agent program, wherein the startup function is also called the startup method.

[0055] Optionally, during the process of starting an application program in which a diagnostic agent program is inserted, a bytecode instrumentation interface is also provided. Specifically, while parsing and obtaining the startup class of the diagnostic agent program from the main driver package and calling the startup method premain of the startup class of the diagnostic agent program, a bytecode instrumentation interface Instrumentation API is also provided. Optionally, the startup method premain method provides an Instrumentation object, wherein the Instrumentation object can provide an Instrumentation interface, and the Instrumentation interface includes but is not limited to: a bytecode instrumentation interface, a bytecode modification interface, and a class information acquisition interface.

[0056] exist Figure 1 On the basis of the embodiment shown, the embodiment of the present invention further proposes that the class loader of the application is the application system class loader, the class loader of the diagnostic agent is a custom class loader, the connection package includes: a bridge package and a dependency package, and the connection package is used to establish a call chain between the diagnostic agent and the application to perform a function call between the application and the diagnostic agent, which may include:

[0057] First, add the bridge package to the root class loader of the application so that the application system class loader loads the abstract bridge class in the bridge package through the root class loader, and the root class loader is connected to the application system class loader. Among them, the bridge package is a JAR package that stores the abstract bridge class, and the dependency package is a JAR package that stores the custom bytecode converter. Specifically, the root class loader BootstrapClassLoader is connected to the application system class loader ApplicationClassloader through the extension class loader ExtClassLoader and the application class loader AppClassLoader. Among them, the root class loader BootstrapClassLoader, which is also called the original class loader, is the top level of the Java class loader hierarchy. Its parent class loader is null, and its main responsibility is to load Java's core class libraries, including Java SE API, classes and interfaces defined in the Java language specification, and classes required for the JVM itself to run. These core class libraries are usually located in JAVA_HOME / jre / lib / rt.jar, JAVA_HOME / jre / lib / resources.jar, etc. Among them, the parent class loader of the extension class loader ExtClassLoader is the root class loader BootstrapClassLoader. The extension class loader ExtClassLoader is usually used to load some core, system-level class libraries, such as some JNI (Java NativeInterface) related class libraries, which are usually provided by Java manufacturers and packaged as .jar files and placed in the lib / ext directory. Among them, the parent class loader of the application class loader AppClassLoader is the extension class loader ExtClassLoader. The extension class loader ExtClassLoader is usually used to load the class libraries of the application. These class libraries are usually written by users and packaged as .jar files or .class files and placed in the class path of the application. When the application is running, AppClassLoader will load these class libraries from the class path for the application to use. Among them, a class is a structure that defines an object, including data, namely attributes, and functions, namely methods. Class is the basis of object-oriented programming (OOP). It is a way to combine data and functions that operate on data. By using classes, data and data-related operations can be encapsulated together to form an independent unit, which is physically manifested as a bytecode file, namely a .class file.An abstract class is a class whose method is an abstract method that is only declared but not implemented. The declaration of an abstract method ends with a semicolon and has no method body. The main purpose of an abstract method is to provide an interface that can be implemented by other classes. In this way, different classes can implement the same method but in different ways, which makes the code more flexible and extensible.

[0058] Secondly, the dependent package is added to the custom class loader, so that the custom class loader loads the implementation class of the abstract bridge class in the dependent package, wherein the implementation class EventDriveBridgePoint of the abstract bridge class inherits from the abstract bridge class AbstractBridgePoint.

[0059] Then, a call chain between the diagnostic agent and the application is established through the abstract bridge class and the implementation class in the bridge package to perform function calls between the application and the diagnostic agent. Specifically, according to the above description, if the application system class loader loads the abstract bridge class in the bridge package through the root class loader, and the custom class loader loads the implementation class of the abstract bridge class, the application system class loader can access the custom class loader through the call chain between the diagnostic agent and the application, that is, the call chain composed of the abstract bridge class and the implementation class of the abstract bridge class. Among them, the call chain composed of the abstract bridge class and the implementation class of the abstract bridge class is the path of the abstract bridge class referencing the implementation class of the abstract bridge class. Optionally, in Java, when a class appears in multiple different versions of jar packages, if the entire operating environment has only one application system class loader ApplicationClassloader, then only one version of the class can be loaded. At this time, you can use the custom class loader ProfilerAgentClassLoader to load multiple versions of classes. Specifically, the custom class loader ProfilerAgentClassLoader can first scan the main driver package, extension plug-in package, and dependent package to find the paths of all classes, and then pass all paths to the application system class loader ApplicationClassloader when instantiating the custom class loader ProfilerAgentClassLoader. This ensures that all classes are bound to the application system class loader ApplicationClassloader.

[0060] Figure 2An example diagram of the call chain provided by the present invention is shown, wherein the root class loader BootstrapClassLoader is connected to the application system class loader ApplicationClassloader through the extension class loader ExtClassLoader and the application class loader AppClassLoader, the application system class loader loads the main driver package, the custom class loader loads the abstract dependency package, the root class loader loads the bridge package, the main driver package includes the startup class, the dependency package includes the implementation class of the abstract bridge class, the bridge package includes the bridge class and the abstract bridge class, the call chain is that the startup class in the main driver package calls the bridge class in the bridge package, the bridge class in the bridge package references the abstract bridge class in the bridge package, and the abstract bridge class in the bridge package calls the implementation class of the abstract bridge class.

[0061] Figure 3 A schematic flow chart of a second embodiment of a program-initiated diagnostic method provided by the present invention is shown. Figure 1 On the basis of the illustrated embodiment, this embodiment describes in detail the process of monitoring the application based on the connection package, the expansion plug-in package and the class loader to obtain the diagnostic result data of the application.

[0062] like Figure 3 As shown, in this embodiment, based on the connection package, the expansion plug-in package and the class loader, monitoring the application program and obtaining the diagnostic result data of the application program may include the following steps:

[0063] Step S301, load and instantiate the custom bytecode converter in the dependent package according to the custom class loader, the custom bytecode converter includes: initializing the bridge function, starting the monitoring function, and the bytecode conversion function.

[0064] The dependency package includes: a custom bytecode converter. The bytecode converter ClassFileTransformer is an interface used to convert and modify class files during class loading, that is, to modify the bytecode when the class is loaded. The custom bytecode converter is a class in the dependency package.

[0065] Specifically, the custom bytecode converter in the dependent package can be loaded according to the custom class loader, wherein loading is the first step of the class loading process, which is responsible for finding and loading the bytecode file of the class, wherein the class loader can find the class file according to the fully qualified name of the class, and read the content of the bytecode file into the memory, wherein the fully qualified name of the class includes the class name and the package name of the class. Optionally, the class loading function of the custom class loader can be called first to obtain the bytecode base class object. Then call the constructor object acquisition function of the bytecode base class object to load the custom bytecode converter. Among them, calling the constructor object acquisition function of the bytecode base class object can obtain the constructor object of the custom bytecode converter, which represents the constructor (Constructor object) of a Class class, which is used to create and initialize an object. When an instance of a class is created, the constructor will be called. Each class has at least one constructor. If the constructor is not explicitly defined, the compiler will automatically create a default no-parameter constructor.

[0066] Optionally, after the process of loading the custom bytecode converter in the dependent package according to the custom class loader is completed, the instantiation operation of the custom class loader can be started according to the obtained constructor object of the custom bytecode converter and the reflection technology. Among them, the reflection technology is the ability to dynamically obtain and operate class information at runtime. Through reflection, objects can be created, methods can be called, and fields can be accessed without knowing the class name.

[0067] Specifically, the custom bytecode converter in the dependent package can be instantiated according to the custom class loader. Optionally, the initialization bridge function can be called first to instantiate the implementation class of the abstract bridge class. The functions of the implementation class of the abstract bridge class include: the function of adding the interception point before execution, the function of adding the interception point without exception after execution, and the function of adding the interception point with exception after execution. Among them, the implementation class EventDriveBridgePoint of the abstract bridge class inherits from the abstract bridge class AbstractBridgePoint. Among them, the functions of the implementation class of the abstract bridge class, that is, the methods of the implementation class of the abstract bridge class include: the method of adding the interception point before execution atEnter, the method of adding the interception point without exception after execution atExit, and the method of adding the interception point with exception after execution atErrorExit. Optionally, the start listening function can be called again to instantiate the listening management container and the ready listening management container to obtain the custom bytecode conversion after instantiation. The listening management container is used to manage the diagnostic process listener, and the ready listening management container is used to manage the diagnostic status listener. Among them, the listening management container ListenContainer is a component that manages the diagnostic process listener with a plug-in mechanism, and manages the diagnostic process listener EventListener when the target function of the target component of the application is executed, that is, the diagnostic process listener component interface, wherein each diagnostic process listener EventListener can be implemented with the help of the plug-in mechanism. The diagnostic process listener EventListener provides two methods and two member attributes. For example: The member attributes of the diagnostic process listener EventListener include: the start status attribute started and the start time attribute startTimeMillis, wherein the start status attribute started is a member attribute, true represents started, false represents not started or closed, and the default is false, and the start time attribute startTimeMillis is a member attribute, which is the current time at startup, in milliseconds.For example, the methods of the diagnostic process listener EventListener include: the start method and the destruction method. The start method, when judging that the start state attribute started is false, will find all diagnostic process listeners through a custom SPI mechanism, complete the instantiation and save them in the listening management container ListenContainer, and then call the start method of each diagnostic process listener in turn, and set the start state attribute started to true, and the start time attribute startTimeMillis to the current time. The destruction method, when judging that the start state attribute started is true, traverses all diagnostic process listeners in the listening management container and calls the destruction method stop method to release resources, and then calculates various statistical indicators and outputs them to the network page html. Through the management of the listening management container, the following monitoring can be achieved, for example, calculating the startup time, the number of component beans, the number of used jar packages and the total number of jar packages, the number of classLoaders and other information, wherein the startup time can be obtained by subtracting startTimeMillis from the current latest time, and the monitored information can be saved in the statistical summary class (StartupReport). For example, to calculate the time consumption of each bean, specifically, you can traverse the startup information of each bean from StartupReport to obtain information such as the time consumption of the current bean and the time consumption of child nodes.

[0068] Among them, the ready listening management container ReadyListenContainer is a component that manages the diagnostic status listener StartupListener with a plug-in mechanism, and manages the diagnostic status listener interface StartupListener during the startup process of the target component of the application. Among them, each diagnostic status listener StartupListener can be implemented with the help of the plug-in mechanism. The diagnostic status listener StartupListener listener provides 2 methods, such as: the initialization method init and the status check method checkStatus. Among them, the initialization method init provides an operation to initialize the application component of the application. This method will be called immediately after the ready listening management container ReadyListenContainer is instantiated. Among them, the status check method check Status performs a readiness check on the application component of the application. If the judgment passes, that is, the status of the application component is started, the output of the result indicator is completed. The status check method checkStatus continuously polls the implementation objects of all listeners in the current container, that is, it continuously performs readiness checks on all application components in the application. If it is judged that each diagnostic status listener object, that is, the startup status of the application component is successful, the destruction method stop method of the listening management container ListenContainer is called to complete the output of the result indicator. If one of the diagnostic status listener objects, that is, the startup status of the application component is a startup failure, an exception is thrown to achieve the effect of the agent program diagnosis failure. Among them, after the ready listening management container ReadyListenContainer is instantiated, the asynchronous thread is started to execute the status check method checkStatus.

[0069] Figure 4 An example diagram of obtaining the diagnostic result data of an application based on the instantiated listening management container and the ready listening management container provided by the present invention is shown, wherein the instantiated ready listening management container executes the ready check method checkStatus to monitor the startup status of the target components corresponding to each second target component proxy class; if the startup status of the target components corresponding to all second target component proxy classes is successful startup, the resource release method of each diagnostic status listener is called; if the calling of the resource release method of each diagnostic status listener is completed, the resource release method of the listening management container is called; the resource release method of each diagnostic status listener is called; and the diagnostic result data of the application is output to the web page html.

[0070] As described above, the listener management container is a component that manages the diagnostic process listener with a plug-in mechanism, and the ready listener management container is a component that manages the diagnostic status listener with a plug-in mechanism. Therefore, the management mechanism of the listener is a plug-in mechanism to improve the flexibility of listener management. Specifically, the plug-in mechanism is an implementation method of the service provider discovery mechanism (ServiceProvider Interface, referred to as SPI), wherein the plug-in mechanism can find the instance class of the listener from the extended plug-in package, specifically, the plug-in interface and event can be defined, and the defined and named plug-in interface and event definition are added to the extended plug-in package, wherein the plug-in interface includes: a diagnostic process listener interface and a diagnostic status listener interface, wherein the plug-in interface can be orchestrated through the orchestration interface Sortable, and the plug-in interface can be named through the annotation interface SpiServices, wherein the orchestration capability provided by the orchestration interface Sortable is mainly manifested as: the plug-in implementation class can inherit the interface, it can number it, and finally in the listening management container ListenCont In ainer, the numbers of all listeners can be sorted, and finally they will be called one by one in this order in the call chain. Among them, the annotation interface SpiServices mainly marks the name of the plug-in implementation class and the corresponding plug-in interface. The events include: the base class InvokeEvent of the method execution class event, the event before method execution AtEnterEvent, inherited from the base class InvokeEvent of the method execution class event, the abnormal termination event AtErrorExitEvent during method execution, inherited from the base class InvokeEvent of the method execution class event, and the method execution end event AtExitEvent, inherited from the base class InvokeEvent of the method execution class event.

[0071] Figure 5An example diagram of loading and instantiating a custom bytecode converter in a dependent package provided by the present invention is shown, wherein, according to a startup class and a custom class loader, the custom bytecode converter is first loaded, and then the custom bytecode converter is instantiated, wherein instantiating the custom bytecode converter specifically includes: calling an initialization bridge function, calling a startup listening function, wherein calling the startup listening function specifically includes: instantiating a listening management container and instantiating a ready listening management container, if the instantiation of the ready listening management container is completed, the object of the custom bytecode converter is obtained, and based on the startup class, the object of the custom bytecode converter is added to the bytecode plug-in interface, so that when the function of adding the bytecode converter of the bytecode plug-in interface is called, the object of the custom bytecode converter is passed into the application system class loader, wherein the process of instantiating the listening management container includes instantiating a diagnostic process listener, and calling the startup function start of the diagnostic process listener, wherein the process of instantiating the ready listening management container includes instantiating a diagnostic status listener, and calling the initialization function init of the diagnostic status listener.

[0072] Step S302: implant the instantiated custom bytecode converter into the application system class loader, and call the target function of each target component of the application through the bytecode manipulation framework to call the listener in the extended plug-in package to monitor the target component of the application and obtain the diagnostic result data of the application. The listener includes: the components of the diagnostic process listener and the diagnostic status listener.

[0073] Specifically, the instantiated custom bytecode converter can be implanted into the application system class loader, wherein, as described above, in the process of starting an application program with a diagnostic agent inserted, a bytecode instrumentation interface is also provided. Therefore, the instantiated custom bytecode converter can be implanted into the application system class loader, which can include: calling the function of adding a bytecode converter of the bytecode instrumentation interface to implant the instantiated custom bytecode converter into the application system class loader. Specifically, the function of adding a bytecode converter of the bytecode instrumentation interface Instrumentation API can be called, that is, when the method addTransformer of adding a bytecode converter is called, the object ProfilerClassFileTransformer obtained after the instantiation process can be passed into the virtual machine JVM, so that the bytecode conversion method transform can be called before class loading, so that all classes in the application can be monitored.

[0074] Specifically, while the instantiated custom bytecode converter is implanted into the application system class loader, the target functions of each target component of the application can be called through the bytecode manipulation framework to call the listener in the extension plug-in package to monitor the target component of the application and obtain the diagnostic result data of the application.

[0075] Optionally, while the instantiated custom bytecode converter is implanted into the application system class loader, the bytecode conversion function can be called to generate the first target component proxy class through the bytecode manipulation framework for the target component that meets the proxy class generation condition. Among them, the proxy generation condition is the condition that the application component can generate the proxy class of the application component. Optionally, the proxy generation condition can be: calling the filter method filter of all diagnostic process listeners EventListener through the listening management container ListenContainer. If the application component of the application meets the listening requirements of at least one diagnostic process listener EventListener, then the application component meets the proxy generation condition. At this time, the application component, that is, the target component, can be used to generate the first target component proxy class. If the application component of the application does not meet the listening requirements of any diagnostic process listener EventListener, then the application component does not meet the proxy generation condition. At this time, the application component, that is, the target component cannot generate the first target component proxy class.

[0076] Figure 6 An example diagram of the generation process of the second target component proxy class provided by the present invention is shown, wherein the application system calls the constructor object acquisition function of the bytecode base class object, loads the custom bytecode converter, the custom bytecode converter calls the bytecode conversion function, generates the first target component proxy class through the bytecode manipulation framework for the target component that meets the proxy class generation conditions, and calls the function of the implementation class of the abstract bridge class through the bytecode manipulation framework to add interception points in the target function of the first target component proxy class according to the interception point addition conditions to generate the second target component proxy class.

[0077] Optionally, when calling the bytecode conversion function, the target component that meets the proxy class generation conditions is used to generate the first target component proxy class through the bytecode manipulation framework, and at the same time, the function of the implementation class of the abstract bridge class can be called through the bytecode manipulation framework to add an interception point in the target function of the first target component proxy class according to the interception point addition condition to generate the second target component proxy class. Among them, the interception point addition condition is the condition that the function of the application component can add an interception point. Optionally, the interception point implantation condition can be: calling the filter method filter of all diagnostic process listeners EventListener through the listening management container ListenContainer. If the function of the application component of the application meets the interception point addition requirement of at least one diagnostic process listener EventListener, then the function of the application component meets the interception point addition condition. At this time, the function of the application component, that is, the target function of the target component, can be added with an interception point through the bytecode manipulation framework javaASM. If the function of the application component of the application does not meet the interception point addition requirement of any diagnostic process listener EventListener, then the function of the application component does not meet the interception point addition condition. At this time, the function of the application component, that is, the target function of the target component, cannot add an interception point.

[0078] Optionally, the method for adding interception points includes: calling the function of the implementation class according to the calling order of the call chain, adding interception points for the target function of the target component that meets the conditions for adding interception points, specifically, calling the functions of the implementation class according to the calling order of the call chain: the adding function atEnter of the interception point before execution, the adding function atExit of the interception point without exception after execution, and the adding function atErrorExit of the interception point after execution, that is, reading the function and parameter annotations of the interception class Interceptor defined by the diagnostic agent program to obtain the array interception function processor InterceptorProcessor, and for the target function that meets the requirements for adding interception points, with the help of the bytecode manipulation framework Java ASM, implanting the array interception function processor InterceptorProcessor and saving it into the first target component proxy class generated above.

[0079] Optionally, after calling the function of the implementation class of the abstract bridge class through the bytecode manipulation framework to add an interception point in the target function of the first target component proxy class according to the interception point addition condition, and generating the second target component proxy class, the target function with the interception point added can be called to calculate the dependency chain of each second target component proxy class, and call the listener in the extension plug-in package to obtain the diagnostic result data of the application. Optionally, a stack structure of each second target component proxy class can be constructed, and multiple dependency chains of the second target component proxy class can be calculated through the stack structure; all diagnostic process listeners are called through the instantiated listening management container to monitor the information at the interception point; the diagnostic status listener is called through the instantiated ready listening management container to monitor the startup status of the target component corresponding to the second target component proxy class, and the startup status includes: startup success and startup failure; if the startup status is startup success, the diagnostic status listener and diagnostic process listener corresponding to the target component corresponding to the second target component proxy class are closed and the information at the interception point is obtained, otherwise a prompt of the target component startup failure is sent to the user; the information at the interception point is aggregated according to the dependency chain of the second target component proxy class to generate the diagnostic result data of the application. The description of the diagnosis process listener and the diagnosis status listener may refer to the description in step S201 , which will not be repeated in this embodiment.

[0080] Figure 7 An example diagram of the present invention is shown for calling a target function with an interception point added thereto to calculate the dependency chain of each second target component proxy class, and calling the listener in the extended plug-in package to obtain the diagnostic result data of the application program, wherein the application system proxy class calls the added function atEnter of the interception point before execution through the abstract bridge class and the implementation class of the abstract bridge class before the target function is executed, so that the listener calculates the dependency chain of each second target component proxy class, and calls the listener in the extended plug-in package to obtain the diagnostic result data of the application program, and saves the diagnostic result data in the statistical summary class (StartupReport); if the application system proxy class determines that the target function is executed normally, then after the target function is executed, the application system proxy class calls the added function atExit of the interception point without abnormality after execution through the abstract bridge class and the implementation class of the abstract bridge class, so that the listener calculates the dependency chain of each second target component proxy class, and calls the listener in the extended plug-in package to obtain the diagnostic result data of the application program, and saves the diagnostic result data in the statistical summary class (StartupReport).

[0081] Optionally, after the diagnostic result data of the application is generated, the diagnostic result data can be presented to the user through a diagnostic result browsing page. Specifically, a server-side httpserver can be started and created according to a preset server configuration file, and a result browsing page http web can be provided, wherein the result browsing page can provide a search based on diagnostic features, such as component startup time and other features, and can also provide a search based on the component name of the application, wherein, while searching based on the component name of the application, detailed diagnostic information of the component and the dependency chain in which the component is located can also be provided.

[0082] The present embodiment provides a process for monitoring the target components of an application to be diagnosed, by loading and instantiating a custom bytecode converter in a dependency package according to a custom class loader, implanting the instantiated custom bytecode converter into an application system class loader, and calling the target function of each target component of the application through a bytecode manipulation framework to call a listener in an extended plug-in package to monitor the target component of the application and obtain diagnostic result data of the application, wherein, by loading and instantiating the custom bytecode converter in a dependency package, implanting the instantiated custom bytecode converter into the application system class loader of the application and calling the target function of each target component to monitor the target component of the application, a comprehensive diagnosis of each application component of the application is achieved, and the comprehensiveness of the diagnosis of program startup is improved, wherein, by implementing the plug-in management mechanism of the listener through the extended plug-in package, the flexibility of the diagnosis of program startup can be improved.

[0083] Figure 8 A schematic flow chart of a third embodiment of the program-initiated diagnostic method provided by the present invention is shown. Figure 2 Based on the illustrated embodiment, the embodiment of the present invention describes in detail the process of calling the target function with an interception point added to calculate the dependency chain of each second target component proxy class, and calling all listeners in the extended plug-in package to obtain the diagnostic result data of the application.

[0084] like Figure 8 As shown, calling the target function with the interception point added in this embodiment to calculate the dependency chain of each second target component proxy class and calling all listeners in the extended plug-in package to obtain the diagnostic result data of the application may include the following steps:

[0085] Step S801: construct a stack structure of each second target component proxy class, and calculate a plurality of dependency chains of the second target component proxy classes through the stack structure.

[0086] Specifically, a stack structure of each second target component proxy class can be constructed, wherein the stack structure BeanInitMetric is used to store information of the current second target component proxy class, including but not limited to: the ID of the current second target component proxy class, the ID of the parent component proxy class, and the ID of the child component proxy class, as well as a label storing the name of the thread where the stack structure is located, the class loader, and the class name, wherein the stack structure is stored in a thread snapshot, wherein when the target function is executed, the stack structure of the current second target component proxy class is obtained and analyzed, and if the stack structure is not empty, the instance of the top of the stack, i.e., the head of the stack structure, is taken out, the current stack structure is set as a child component, and the ID of the parent component of the set child component is set as the ID of the current component, and if the stack structure is empty, the current second target component proxy class is pushed into the stack structure, and the information of the current second target component proxy class is saved in the statistical summary class StartupReport. When the target function is executed and there are no exceptions, the top of the stack is popped, that is, the instance at the top of the stack is taken out and deleted, and various information on the current event Event is added to the label of the current instance. Finally, the current time consumption and child node time consumption can be calculated based on the isolation timestamp. In this process, the stack structure plays a last-in-first-out role, which can ensure that the dependencies between components are calculated correctly. At the same time, by continuously popping components and obtaining their dependent components, multiple dependency chains of the second target component proxy class can be gradually constructed.

[0087] Optionally, after obtaining multiple dependency chains of the second target component proxy classes, all diagnostic process listeners can be notified. First, all listeners (EventListener) are found through the listening management container (ListenContainer). Specifically, it is first determined whether the trigger conditions are met (filter method), and then the event triggering (onFire method) is executed.

[0088] Step S802: The instantiated monitoring management container calls all the diagnostic process listeners to monitor the information at the interception point.

[0089] Specifically, all diagnostic process listeners can be called through the instantiated listening management container to listen to the information at the interception point. Optionally, the diagnostic process listener can inherit the diagnostic process listener interface and the orchestration interface Sortable, define the plug-in, that is, the diagnostic process listener initialization, and the processing mechanism after interception, inherit the spring environment, and internally include: filtering method filter, listening method listen, data collection method onFire, and resource release method close. Among them, the filtering method filter represents whether to intercept a certain class or intercept a certain method of a certain class, and the information of the interception point can be obtained by reading the content in the diagnostic agent configuration file. Among them, the listening method listen represents the behavior that supports interception, and the behaviors include: interception before execution, interception without exception after execution, and interception after execution with exceptions. Among them, the data collection method onFire represents The operation performed when the table is intercepted is mainly to collect the indicator data of the executed method and analyze and process these indicator data. Among them, the method input parameters of the data collection method onFire are various events, including the method execution pre-event AtEnterEvent, the method execution abnormal termination event AtErrorExitEvent and the method execution end event AtExitEvent. The interception behavior of the method can be judged through the above events. Among them, the indicator data including the thread name, the class loader, the class, the method name, and the time before and after execution can be obtained from various events and saved in the application's statistical summary class StartupReport. Among them, the dependency chain, that is, the dependency of the components in the call chain, can be recorded and saved in the application's statistical summary class StartupReport. Among them, the resource release method close is used to release the currently referenced resources. Optionally, the diagnostic process listener can inherit the diagnostic process listener interface and the orchestration interface Sortable, define the processing mechanism after the plug-in, i.e. the diagnostic process listener is initialized and intercepted, and internally includes: a closing method close, the closing method close obtains all loaded classes through, for example: the relevant methods of instrumentation Instrumentation and then deduplicates according to the code source CodeSource to obtain the loaded jar and class loader classloader, compares all the jars found by all the class loaders classloaders obtained with the loaded jar, obtains the unused jars and saves these data in the statistical summary class StartupReport.

[0090] Step S803: The instantiated ready listening management container calls the diagnostic status listener to monitor the startup status of the target component.

[0091] The startup status includes: startup success and startup failure.

[0092] Specifically, the diagnostic status listener can be called through the instantiated ready listening management container to listen to the startup status of the target component. Optionally, the diagnostic status listener can inherit the diagnostic status listener interface and the orchestration interface Sortable, and internally include: status check method check, the implementation of the check method is: read the monitoring detection uniform resource locator url, that is, the access address, according to the configuration of the diagnostic agent program, request the address, if the response status is normal, it returns "started", if the response status is abnormal, it is starting, the above-mentioned diagnostic status listener can perform application system readiness detection listening, optionally, the diagnostic status listener can inherit the diagnostic status listener interface and the orchestration interface Sortable, and internally include: status check method check, the implementation of the check method is: read the timeout time according to the configuration of the diagnostic agent program, if the startup time has reached the timeout time, return startup failure, otherwise return started, the above-mentioned diagnostic status listener can perform diagnostic agent program failure timeout detection listening.

[0093] Step S804: If the startup status is successful, close the diagnostic status listener and the diagnostic process listener corresponding to the target component and obtain the information at the interception point, otherwise send a prompt to the user that the startup of the target component failed.

[0094] Specifically, if the startup status is successful, the corresponding diagnostic status listener and the diagnostic process listener can be closed and the information at the interception point can be obtained, and the information at the interception point can be saved in the statistical summary class StartupReport. Otherwise, a prompt that the target component failed to start is sent to the user, where the prompt that the component failed to start can be presented to the diagnostic result browsing interface described in step S202.

[0095] Step S805: Summarize the information at the interception point according to the dependency chain of the second target component proxy class to generate diagnostic result data of the application.

[0096] Specifically, the information at the interception point can be aggregated according to the dependency chain calculated in step S801 to generate diagnostic result data of the application, wherein the diagnostic result data includes but is not limited to diagnostic result data of a single application component and diagnostic result data of a set of application components in the dependency chain.

[0097] The present embodiment provides a target function for calling an interception point to calculate the dependency chain of each second target component proxy class, and calls all listeners in the extended plug-in package to obtain the diagnostic result data of the application, by constructing a stack structure of each second target component proxy class, and calculating multiple dependency chains of second target component proxy classes through the stack structure, calling all diagnostic process listeners through the instantiated listening management container to monitor the information at the interception point, calling the diagnostic status listener through the instantiated ready listening management container to monitor the startup status of the target component, if the startup status is successful, close the diagnostic status listener and the diagnostic process listener corresponding to the target component and obtain the information at the interception point, otherwise send a prompt to the user that the target component has failed to start, summarize the information at the interception point according to the dependency chain of the second target component proxy class, and generate the diagnostic result data of the application, wherein the comprehensive monitoring of the application is achieved by combining the calculation of the dependency chain to call the diagnostic process listener and the call of the diagnostic status listener, thereby improving the comprehensiveness of the diagnosis of program startup.

[0098] Fig. 9 A schematic structural diagram of a first embodiment of a program-initiated diagnostic device provided by the present invention is shown.

[0099] like Fig. 9 As shown, the program-initiated diagnostic device 90 of this embodiment includes an acquisition module 91 , a startup module 92 and a monitoring module 93 .

[0100] An acquisition module 91 is used to acquire an application program inserted with a diagnostic agent program, wherein the diagnostic agent program includes a connection package and an expansion plug-in package;

[0101] A startup module 92 is used to start the application program inserted with the diagnostic agent program, and at the same time, to isolate the running environment of the diagnostic agent program and the application program by using the class loader of the diagnostic agent program and the application program, and to establish a call chain of the diagnostic agent program and the application program by using the connection package to perform function calls between the application program and the diagnostic agent program;

[0102] The monitoring module 93 is used to monitor the application based on the connection package, the expansion plug-in package, and the class loader to obtain the diagnostic result data of the application.

[0103] The device provided in this embodiment can be used to execute the above method embodiment Figures 1 to 8 The technical solution has similar implementation principles and technical effects, which will not be described in detail in this embodiment.

[0104] In an optional manner, the diagnostic agent program also includes: a main driver package, a startup module 92, and also includes: obtaining the startup class of the application from the startup parameters of the application, and calling the startup function of the startup class of the application; parsing and obtaining the startup class of the diagnostic agent program from the main driver package, and calling the startup function of the startup class of the diagnostic agent program.

[0105] In an optional manner, the class loader of the application is the application system class loader, the class loader of the diagnostic agent is a custom class loader, the connection package includes: a bridge package and a dependency package, and the startup module 92 also includes: adding the bridge package to the root class loader of the application so that the application system class loader loads the abstract bridge class in the bridge package through the root class loader; adding the dependency package to the custom class loader so that the custom class loader loads the implementation class of the abstract bridge class in the dependency package; establishing a call chain between the diagnostic agent and the application through the abstract bridge class and the implementation class in the bridge package to perform function calls between the application and the diagnostic agent.

[0106] In an optional manner, the dependency package includes: a custom bytecode converter, based on a connection package, an extension plug-in package and a class loader, a monitoring module 93, and also includes: loading and instantiating the custom bytecode converter in the dependency package according to the custom class loader, the custom bytecode converter including: initializing a bridge function, starting a monitoring function, and a bytecode conversion function; implanting the instantiated custom bytecode converter into the application system class loader, and calling the target functions of each target component of the application through the bytecode manipulation framework to call the listener in the extension plug-in package, monitor the target components of the application, and obtain the diagnostic result data of the application; the listener includes: components of the diagnostic process listener and the diagnostic status listener.

[0107] In an optional manner, the monitoring module 93 also includes: calling the class loading function of the custom class loader to obtain the bytecode base class object; calling the constructor object acquisition function of the bytecode base class object to load the custom bytecode converter; calling the initialization bridge function to instantiate the implementation class of the abstract bridge class, and the functions of the implementation class of the abstract bridge class include: a function for adding interception points before execution, a function for adding interception points without exceptions after execution, and a function for adding interception points with exceptions after execution; calling the start monitoring function to instantiate the monitoring management container and the ready monitoring management container to obtain the instantiated custom bytecode conversion; the monitoring management container is used to manage the diagnostic process listeners, and the ready monitoring management container is used to manage the diagnostic status listeners.

[0108] In an optional manner, the monitoring module 93 also includes: calling the bytecode conversion function to generate a first target component proxy class for the target component that meets the proxy class generation conditions through the bytecode manipulation framework; calling the function of the implementation class of the abstract bridge class through the bytecode manipulation framework to add an interception point in the target function of the first target component proxy class according to the interception point adding conditions to generate a second target component proxy class, and the second target component proxy class includes the target function with the interception point added; calling the target function with the interception point added to calculate the dependency chain of each second target component proxy class, and calling the listener in the extension plug-in package to obtain the diagnostic result data of the application.

[0109] In an optional manner, the monitoring module 93 also includes: constructing a stack structure of each second target component proxy class, and calculating multiple dependency chains of the second target component proxy classes through the stack structure; calling all diagnostic process listeners through the instantiated monitoring management container to monitor the information at the interception point; calling the diagnostic status listener through the instantiated ready monitoring management container to monitor the startup status of the target component corresponding to the second target component proxy class, and the startup status includes: successful startup and failed startup; if the startup status is successful startup, closing the diagnostic status listener and the diagnostic process listener corresponding to the target component corresponding to the second target component proxy class and obtaining the information at the interception point, otherwise sending a prompt to the user that the target component startup failed; summarizing the information at the interception point according to the dependency chain of the second target component proxy class to generate diagnostic result data of the application.

[0110] In an optional manner, during the process of starting an application program into which a diagnostic agent program is inserted, a bytecode insertion interface is also provided, and the monitoring module 93 also includes: calling the function of adding a bytecode converter of the bytecode insertion interface to implant the instantiated custom bytecode converter into the application system class loader.

[0111] Fig.10 The schematic diagram of the structure of the program-initiated diagnostic device provided by the present invention is shown. The specific embodiment of the present invention does not limit the specific implementation of the program-initiated diagnostic device.

[0112] like Fig.10 As shown, the diagnostic device started by the program may include: a processor (processor) 1002 , a communication interface (Communications Interface) 10010 , a memory (memory) 1006 , and a communication bus 1008 .

[0113] The processor 1002, the communication interface 10010, and the memory 1006 communicate with each other via the communication bus 1008. The communication interface 10010 is used to communicate with other devices such as a client or other server network elements. The processor 1002 is used to execute the program 1010, and specifically, can execute the relevant steps in the above-mentioned embodiment of the diagnostic method for program startup.

[0114] Specifically, the program 1010 may include program code, which includes computer-executable instructions.

[0115] The processor 1002 may be a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiment of the present invention. The one or more processors included in the program-started diagnostic device may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0116] The memory 1006 is used to store the program 1010. The memory 1006 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0117] The program 1010 may be specifically called by the processor 1002 to enable the diagnostic device started by the program to perform the following operations:

[0118] Obtain an application program inserted with a diagnostic agent program, wherein the diagnostic agent program includes a connection package and an extended plug-in package;

[0119] Starting the application program with the diagnostic agent program inserted, isolating the running environment of the diagnostic agent program and the application program by using the class loader of the diagnostic agent program and the application program, and establishing a call chain between the diagnostic agent program and the application program by using the connection package to perform function calls between the application program and the diagnostic agent program;

[0120] Based on the connection package, the expansion plug-in package and the class loader, the application is monitored to obtain the diagnostic result data of the application.

[0121] In an optional manner, the diagnostic agent program also includes: a main driver package, which starts an application program in which the diagnostic agent program is inserted, including: obtaining the startup class of the application program from the startup parameters of the application program, and calling the startup function of the startup class of the application program; parsing and obtaining the startup class of the diagnostic agent program from the main driver package, and calling the startup function of the startup class of the diagnostic agent program.

[0122] In an optional manner, the class loader of the application is the application system class loader, the class loader of the diagnostic agent is a custom class loader, and the connection package includes: a bridge package and a dependency package. The connection package is used to establish a call chain between the diagnostic agent and the application to perform functional calls between the application and the diagnostic agent, including: adding the bridge package to the root class loader of the application so that the application system class loader loads the abstract bridge class in the bridge package through the root class loader; adding the dependency package to the custom class loader so that the custom class loader loads the implementation class of the abstract bridge class in the dependency package; establishing a call chain between the diagnostic agent and the application through the abstract bridge class and implementation class in the bridge package to perform functional calls between the application and the diagnostic agent.

[0123] In an optional manner, the dependency package includes: a custom bytecode converter, which monitors the application based on the connection package, the extension plug-in package and the class loader to obtain the diagnostic result data of the application, including: loading and instantiating the custom bytecode converter in the dependency package according to the custom class loader, the custom bytecode converter including: initializing the bridge function, starting the listening function, and the bytecode conversion function; implanting the instantiated custom bytecode converter into the application system class loader, and calling the target function of each target component of the application through the bytecode manipulation framework to call the listener in the extension plug-in package, monitor the target component of the application, and obtain the diagnostic result data of the application; the listener includes: components of the diagnostic process listener and the diagnostic status listener.

[0124] In an optional manner, a custom bytecode converter in a dependent package is loaded and instantiated according to a custom class loader, including: calling a class loading function of the custom class loader to obtain a bytecode base class object; calling a constructor object acquisition function of the bytecode base class object to load the custom bytecode converter; calling an initialization bridge function to instantiate an implementation class of an abstract bridge class, the functions of the implementation class of the abstract bridge class including: a function for adding an interception point before execution, a function for adding an interception point without exception after execution, and a function for adding an interception point with exception after execution; calling a start listening function to instantiate a listening management container and a ready listening management container to obtain the instantiated custom bytecode conversion; the listening management container is used to manage diagnostic process listeners, and the ready listening management container is used to manage diagnostic status listeners.

[0125] In an optional manner, the target function of each target component of the application is called through the bytecode manipulation framework to call the listener in the extended plug-in package to listen to the target component of the application and obtain the diagnostic result data of the application, including: calling the bytecode conversion function to generate a first target component proxy class through the bytecode manipulation framework for the target component that meets the proxy class generation condition; calling the function of the implementation class of the abstract bridge class through the bytecode manipulation framework to add an interception point in the target function of the first target component proxy class according to the interception point addition condition to generate a second target component proxy class, and the second target component proxy class includes the target function with the interception point added; calling the target function with the interception point added to calculate the dependency chain of each second target component proxy class, and calling the listener in the extended plug-in package to obtain the diagnostic result data of the application.

[0126] In an optional manner, a target function with an interception point added is called to calculate the dependency chain of each second target component proxy class, and the listener in the extended plug-in package is called to obtain the diagnostic result data of the application, including: constructing a stack structure of each second target component proxy class, and calculating multiple dependency chains of second target component proxy classes through the stack structure; calling all diagnostic process listeners through the instantiated listening management container to listen to the information at the interception point; calling the diagnostic status listener through the instantiated ready listening management container to listen to the startup status of the target component corresponding to the second target component proxy class, and the startup status includes: successful startup and failed startup; if the startup status is successful startup, the diagnostic status listener and the diagnostic process listener corresponding to the target component corresponding to the second target component proxy class are closed and the information at the interception point is obtained, otherwise a prompt indicating that the target component startup failed is sent to the user; the information at the interception point is aggregated according to the dependency chain of the second target component proxy class to generate the diagnostic result data of the application.

[0127] In an optional manner, during the process of starting an application program inserted with a diagnostic agent program, a bytecode insertion interface is also provided to implant the instantiated custom bytecode converter into the application system class loader, including: calling the function of adding a bytecode converter of the bytecode insertion interface to implant the instantiated custom bytecode converter into the application system class loader.

[0128] An embodiment of the present invention provides a computer-readable storage medium, which stores at least one executable instruction. When the executable instruction runs on a program-initiated diagnostic device / apparatus, the program-initiated diagnostic device / apparatus executes the program-initiated diagnostic method in any of the above method embodiments.

[0129] The executable instructions may be specifically used to enable the diagnostic device / apparatus started by the program to perform the following operations:

[0130] Starting the application program with the diagnostic agent program inserted, isolating the running environment of the diagnostic agent program and the application program by using the class loader of the diagnostic agent program and the application program, and establishing a call chain between the diagnostic agent program and the application program by using the connection package to perform function calls between the application program and the diagnostic agent program;

[0131] Based on the connection package, the expansion plug-in package and the class loader, the application is monitored to obtain the diagnostic result data of the application.

[0132] In an optional manner, the diagnostic agent program also includes: a main driver package, which starts an application program in which the diagnostic agent program is inserted, including: obtaining the startup class of the application program from the startup parameters of the application program, and calling the startup function of the startup class of the application program; parsing and obtaining the startup class of the diagnostic agent program from the main driver package, and calling the startup function of the startup class of the diagnostic agent program.

[0133] In an optional manner, the class loader of the application is the application system class loader, the class loader of the diagnostic agent is a custom class loader, and the connection package includes: a bridge package and a dependency package. The connection package is used to establish a call chain between the diagnostic agent and the application to perform functional calls between the application and the diagnostic agent, including: adding the bridge package to the root class loader of the application so that the application system class loader loads the abstract bridge class in the bridge package through the root class loader; adding the dependency package to the custom class loader so that the custom class loader loads the implementation class of the abstract bridge class in the dependency package; establishing a call chain between the diagnostic agent and the application through the abstract bridge class and implementation class in the bridge package to perform functional calls between the application and the diagnostic agent.

[0134] In an optional manner, the dependency package includes: a custom bytecode converter, which monitors the application based on the connection package, the extension plug-in package and the class loader to obtain the diagnostic result data of the application, including: loading and instantiating the custom bytecode converter in the dependency package according to the custom class loader, the custom bytecode converter including: initializing the bridge function, starting the listening function, and the bytecode conversion function; implanting the instantiated custom bytecode converter into the application system class loader, and calling the target function of each target component of the application through the bytecode manipulation framework to call the listener in the extension plug-in package, monitor the target component of the application, and obtain the diagnostic result data of the application; the listener includes: components of the diagnostic process listener and the diagnostic status listener.

[0135] In an optional manner, a custom bytecode converter in a dependent package is loaded and instantiated according to a custom class loader, including: calling a class loading function of the custom class loader to obtain a bytecode base class object; calling a constructor object acquisition function of the bytecode base class object to load the custom bytecode converter; calling an initialization bridge function to instantiate an implementation class of an abstract bridge class, the functions of the implementation class of the abstract bridge class including: a function for adding an interception point before execution, a function for adding an interception point without exception after execution, and a function for adding an interception point with exception after execution; calling a start listening function to instantiate a listening management container and a ready listening management container to obtain the instantiated custom bytecode conversion; the listening management container is used to manage diagnostic process listeners, and the ready listening management container is used to manage diagnostic status listeners.

[0136] In an optional manner, the target function of each target component of the application is called through the bytecode manipulation framework to call the listener in the extended plug-in package to listen to the target component of the application and obtain the diagnostic result data of the application, including: calling the bytecode conversion function to generate a first target component proxy class through the bytecode manipulation framework for the target component that meets the proxy class generation condition; calling the function of the implementation class of the abstract bridge class through the bytecode manipulation framework to add an interception point in the target function of the first target component proxy class according to the interception point addition condition to generate a second target component proxy class, and the second target component proxy class includes the target function with the interception point added; calling the target function with the interception point added to calculate the dependency chain of each second target component proxy class, and calling the listener in the extended plug-in package to obtain the diagnostic result data of the application.

[0137] In an optional manner, a target function with an interception point added is called to calculate the dependency chain of each second target component proxy class, and the listener in the extended plug-in package is called to obtain the diagnostic result data of the application, including: constructing a stack structure of each second target component proxy class, and calculating multiple dependency chains of second target component proxy classes through the stack structure; calling all diagnostic process listeners through the instantiated listening management container to listen to the information at the interception point; calling the diagnostic status listener through the instantiated ready listening management container to listen to the startup status of the target component corresponding to the second target component proxy class, and the startup status includes: successful startup and failed startup; if the startup status is successful startup, the diagnostic status listener and the diagnostic process listener corresponding to the target component corresponding to the second target component proxy class are closed and the information at the interception point is obtained, otherwise a prompt indicating that the target component startup failed is sent to the user; the information at the interception point is aggregated according to the dependency chain of the second target component proxy class to generate the diagnostic result data of the application.

[0138] In an optional manner, during the process of starting an application program inserted with a diagnostic agent program, a bytecode insertion interface is also provided to implant the instantiated custom bytecode converter into the application system class loader, including: calling the function of adding a bytecode converter of the bytecode insertion interface to implant the instantiated custom bytecode converter into the application system class loader.

[0139] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system or other device. In addition, the embodiments of the present invention are not directed to any particular programming language.

[0140] In the description provided herein, a large number of specific details are described. However, it is understood that embodiments of the present invention can be practiced without these specific details. Similarly, in order to simplify the present invention and help understand one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, the various features of the embodiments of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. Wherein, the claims that follow the specific embodiment are hereby expressly incorporated into the specific embodiment, wherein each claim itself is a separate embodiment of the present invention.

[0141] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and further may be divided into a plurality of submodules or subunits or subcomponents. Except that at least some of such features and / or processes or units are mutually exclusive.

[0142] It should be noted that the above embodiments illustrate the present invention rather than limit it, and that those skilled in the art may devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference symbol between brackets shall not be construed as a limitation on the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "one" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention may be implemented by means of hardware comprising a number of different elements and by means of a suitably programmed computer. In a unit claim enumerating a number of devices, several of these devices may be embodied by the same hardware item. The use of the words first, second, and third, etc. does not indicate any order. These words may be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be understood as limitations on the order of execution.

Claims

1. A method for diagnosing program startup, characterized in that: include: Acquire an application program inserted with a diagnostic agent program, wherein the diagnostic agent program includes a connection package and an expansion plug-in package; Starting the application program in which the diagnostic agent program is inserted, isolating the operating environment of the diagnostic agent program from that of the application program by using the class loader of the diagnostic agent program and the application program, and establishing a call chain between the diagnostic agent program and the application program by using the connection package to perform a function call between the application program and the diagnostic agent program; Based on the connection package, the expansion plug-in package and the class loader, the application is monitored to obtain the diagnostic result data of the application; The diagnostic agent program also includes: a main driver package, which starts the application program inserted with the diagnostic agent program, including: Obtaining the startup class of the application from the startup parameters of the application, and calling the startup function of the startup class of the application; Parse and obtain the startup class of the diagnostic agent program from the main driver package, and call the startup function of the startup class of the diagnostic agent program; The class loader of the application is the application system class loader, the class loader of the diagnostic agent is a custom class loader, the connection package includes: a bridge package and a dependency package, and the connection package is used to establish a call chain between the diagnostic agent and the application to perform a function call between the application and the diagnostic agent, including: Adding the bridge package to the root class loader of the application program so that the application system class loader loads the abstract bridge class in the bridge package through the root class loader; Add the dependent package to the custom class loader, so that the custom class loader loads the implementation class of the abstract bridge class in the dependent package; Establishing a call chain between the diagnostic agent program and the application program through the abstract bridge class in the bridge package and the implementation class to perform a function call between the application program and the diagnostic agent program; The dependency package includes: a custom bytecode converter, which monitors the application based on the connection package, the expansion plug-in package and the class loader to obtain the diagnostic result data of the application, including: Load and instantiate the custom bytecode converter in the dependency package according to the custom class loader, wherein the custom bytecode converter includes: initializing a bridge function, starting a monitoring function, and a bytecode conversion function; The instantiated custom bytecode converter is implanted into the application system class loader, and the target functions of each target component of the application are called through the bytecode manipulation framework to call the listener in the extended plug-in package to monitor the target components of the application and obtain the diagnostic result data of the application; the listener includes: components of the diagnostic process listener and the diagnostic status listener.

2. The method according to claim 1, characterized in that Loading and instantiating the custom bytecode converter in the dependent package according to the custom class loader includes: Calling the class loading function of the custom class loader to obtain a bytecode base class object; Calling the constructor object acquisition function of the bytecode base class object to load the custom bytecode converter; Calling the initialization bridge function to instantiate the implementation class of the abstract bridge class, the functions of the implementation class of the abstract bridge class include: adding functions of interception points before execution, adding functions of interception points without exception after execution, and adding functions of interception points with exception after execution; The start listening function is called to instantiate a listening management container and a ready listening management container to obtain a custom bytecode conversion after instantiation; the listening management container is used to manage the diagnostic process listener, and the ready listening management container is used to manage the diagnostic status listener.

3. The method according to claim 2, characterized in that The target function of each target component of the application is called through the bytecode manipulation framework to call the listener in the extension plug-in package, monitor the target component of the application, and obtain the diagnostic result data of the application, including: Calling the bytecode conversion function to generate a first target component proxy class from a target component that meets the proxy class generation condition through a bytecode manipulation framework; Calling the function of the implementation class of the abstract bridge class through the bytecode manipulation framework to add an interception point in the target function of the first target component proxy class according to the interception point adding condition, and generating a second target component proxy class, wherein the second target component proxy class includes the target function with the interception point added; The target function with the added interception point is called to calculate the dependency chain of each second target component proxy class, and the listener in the extended plug-in package is called to obtain the diagnostic result data of the application.

4. The method according to claim 3, characterized in that Calling the target function with the added interception point to calculate the dependency chain of each second target component proxy class, and calling the listener in the extended plug-in package to obtain the diagnostic result data of the application, including: Constructing a stack structure of each second target component proxy class, and calculating a plurality of dependency chains of the second target component proxy classes through the stack structure; Calling all the diagnostic process listeners through the instantiated monitoring management container to monitor the information at the interception point; The instantiated ready listening management container calls the diagnostic status listener to monitor the startup status of the target component corresponding to the second target component proxy class, where the startup status includes: startup success and startup failure; If the startup status is the startup success, close the diagnostic status listener and the diagnostic process listener corresponding to the target component corresponding to the second target component proxy class and obtain the information at the interception point, otherwise send a prompt to the user that the startup of the target component failed; The information at the interception point is aggregated and processed according to the dependency chain of the second target component proxy class to generate diagnostic result data of the application.

5. The method according to any one of claims 2 to 4, characterized in that: In the process of starting the application program inserted with the diagnostic agent program, a bytecode insertion interface is also provided, and the instantiated custom bytecode converter is implanted into the application system class loader, including: The function of adding a bytecode converter of the bytecode insertion interface is called to implant the instantiated custom bytecode converter into the application system class loader.

6. A program-activated diagnostic device, characterized in that: include: An acquisition module, used to acquire an application program inserted with a diagnostic agent program, wherein the diagnostic agent program includes a connection package and an expansion plug-in package; A startup module, used to start the application program inserted with the diagnostic agent program, and at the same time, to isolate the running environment of the diagnostic agent program and the application program by using the class loader of the diagnostic agent program and the application program, and to establish a call chain of the diagnostic agent program and the application program by using a connection package, so as to perform a function call between the application program and the diagnostic agent program; A monitoring module, used to monitor the application based on the connection package, the expansion plug-in package, and the class loader to obtain the diagnostic result data of the application; The diagnostic agent program also includes: a main driver package, a startup module, which is specifically used to obtain the startup class of the application from the startup parameters of the application and call the startup function of the startup class of the application; parse and obtain the startup class of the diagnostic agent program from the main driver package and call the startup function of the startup class of the diagnostic agent program; The class loader of the application is the application system class loader, the class loader of the diagnostic agent is a custom class loader, the connection package includes: a bridge package and a dependency package, and the startup module is further specifically used to add the bridge package to the root class loader of the application so that the application system class loader loads the abstract bridge class in the bridge package through the root class loader; add the dependency package to the custom class loader so that the custom class loader loads the implementation class of the abstract bridge class in the dependency package; establish a call chain between the diagnostic agent and the application through the abstract bridge class in the bridge package and the implementation class to perform function calls between the application and the diagnostic agent; The dependency package includes: a custom bytecode converter, and the monitoring module is specifically used to load and instantiate the custom bytecode converter in the dependency package according to the custom class loader, and the custom bytecode converter includes: an initialization bridge function, a startup monitoring function, and a bytecode conversion function; the instantiated custom bytecode converter is implanted into the application system class loader, and the target function of each target component of the application is called through the bytecode manipulation framework to call the listener in the extended plug-in package, monitor the target component of the application, and obtain the diagnostic result data of the application; the listener includes: a component of a diagnostic process listener and a diagnostic status listener.

7. A program-activated diagnostic device, characterized in that: include: Processor, memory, communication interface; The memory is used to store executable instructions of the processor; The processor is configured to execute the program-initiated diagnostic method of any one of claims 1 to 5 by executing the executable instructions.

Images