Plug-in running state detection method and electronic device

Abstract

The application provides a plug-in running state detection method and an electronic device. The method comprises the following steps: firstly, determining a target plug-in to be detected in a plurality of function plug-ins for realizing a target service in a pipeline mode; then, determining a plug-in embedding position according to the target plug-in; embedding a monitoring plug-in in the plug-in embedding position; and finally, detecting the running state of the target plug-in through the monitoring plug-in. Through the method, the correctness of the running state of each plug-in can be accurately detected without high communication and debugging costs.

Description

Technical Field

[0001] The embodiments of this application relate to, but are not limited to, the field of computer technology, and in particular to a method for detecting the running status of a plug-in and an electronic device. Background Technology

[0002] Pipelining is a method for breaking down complex tasks into multiple subtasks and executing these subtasks sequentially or in parallel. These subtasks can be encapsulated using plug-in technology. Plug-in technology allows for the dynamic addition or replacement of functional modules in a software system without modifying the core code. These plug-ins typically have well-defined interfaces and can be developed, tested, and deployed independently. Due to the standardized, independent, and open nature of plug-ins, different vendors can participate in their research and development, enabling collaborative development and sharing of plug-ins and accelerating business innovation.

[0003] However, since components within a production line may come from different manufacturers, verifying the correctness of each component's operation requires communication and debugging between these manufacturers, resulting in excessively high communication and debugging costs. How to accurately verify the correctness of each component's operation without incurring excessive communication and debugging costs is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] This application provides a method and electronic device for detecting the running status of plugins, which can accurately detect the correctness of the running status of each plugin without requiring excessive communication and debugging costs.

[0005] On the one hand, embodiments of this application provide a method for detecting the running status of a plugin, including: determining a target plugin to be detected among multiple functional plugins that implement a target business in a pipeline manner; determining the plugin embedding position according to the target plugin, and embedding a monitoring plugin at the plugin embedding position; and detecting the running status of the target plugin through the monitoring plugin.

[0006] On the other hand, embodiments of this application also provide an electronic device, including: at least one processor; at least one memory for storing at least one program; at least one program is run by at least one processor to perform the plug-in running state detection method as described above.

[0007] On the other hand, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions for executing the plug-in running status detection method as described above.

[0008] On the other hand, embodiments of this application also provide a computer program product, including a computer program or computer instructions, wherein the computer program or computer instructions are stored in a computer-readable storage medium, and the processor of an electronic device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the electronic device to perform the plug-in running status detection method as described above.

[0009] In this embodiment, the target plugin to be monitored is first identified among multiple functional plugins that implement the target business in a pipeline manner. Then, the plugin embedding position is determined based on the target plugin, and a monitoring plugin is embedded at the embedding position. The monitoring plugin then monitors the operational status of the target plugin. By embedding an independent monitoring plugin into a pipeline business that includes multiple functional plugins, the operational status of the target plugin in the pipeline business can be monitored without changing the overall input / output logic of the pipeline business or making any modifications to the original functional plugins. This decoupling of plugin functionality and operational analysis functionality allows for accurate detection of the correctness of the operational status of each plugin without incurring excessive communication and debugging costs. Attached Figure Description

[0010] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application;

[0011] Figure 2 This is a schematic diagram of a plug-in monitoring and management system provided in an embodiment of this application;

[0012] Figure 3 This is a schematic diagram of the structure of a monitoring plug-in provided in an embodiment of this application;

[0013] Figure 4 This is a flowchart of a plug-in runtime status detection method provided in an embodiment of this application;

[0014] Figure 5A This is a configuration diagram of a monitoring plugin loading interface provided in an embodiment of this application;

[0015] Figure 5B This is a configuration diagram of a monitoring plugin uninstallation interface provided in an embodiment of this application;

[0016] Figure 6A This is a schematic diagram of various monitoring plugins supporting different operating modes provided in the embodiments of this application;

[0017] Figure 6B This is an application diagram illustrating the various monitoring plugins supporting different operating modes provided in the embodiments of this application;

[0018] Figure 7This is an application diagram illustrating the various operating modes supported by the monitoring plugin provided in this embodiment;

[0019] Figure 8 This is a schematic diagram of a process for embedding multiple monitoring plug-ins at multiple locations in a production line, provided in one embodiment of this application;

[0020] Figure 9 This is a schematic diagram of embedding multiple monitoring plug-ins at multiple locations in a production line, provided in another embodiment of this application;

[0021] Figure 10A This is a schematic diagram illustrating different operations performed on the monitoring plug-in in a pipeline, as provided in an embodiment of this application.

[0022] Figure 10B This is a schematic diagram of the interface configuration for performing different operations on the monitoring plug-in in the pipeline, provided in an embodiment of this application.

[0023] Figure 11A This is a schematic diagram of a monitoring plugin supporting single-path forwarding mode provided in an embodiment of this application;

[0024] Figure 11B This is a configuration diagram of the monitoring plugin supporting single-path forwarding mode provided in the embodiments of this application;

[0025] Figure 12A This is a schematic diagram of a monitoring plugin supporting multi-path forwarding mode provided in an embodiment of this application;

[0026] Figure 12B This is a configuration diagram of a monitoring plugin supporting multi-path forwarding mode provided in an embodiment of this application;

[0027] Figure 13A This is a schematic diagram of a monitoring plugin supporting replication mode provided in an embodiment of this application;

[0028] Figure 13B This is a configuration diagram of the monitoring plugin supporting replication mode provided in an embodiment of this application;

[0029] Figure 14 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] To make the objectives, technical methods, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0031] It should be noted that although the flowchart shows a logical order, in some cases, the steps shown or described may be performed in a different order than that shown in the flowchart. In the description of the specification, claims, and the foregoing drawings, "multiple" means two or more; "greater than," "less than," and "exceeding" are understood to exclude the stated number; "above," "below," and "within" are understood to include the stated number. The use of terms such as "first" and "second" is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly specifying the number of indicated technical features or their sequential relationship.

[0032] Currently, in fields such as multimedia processing, audio and video encoding, decoding, Quality of Experience (QoE) processing, and Artificial Intelligence (AI) processing can be encapsulated as plug-ins, and these plug-ins can be pipelined together to achieve a variety of media processing services. Plug-in architecture and pipeline management have been widely applied in the 5G core network media plane and internet multimedia processing fields.

[0033] Currently, the existing plugin monitoring technologies in the industry are mainly divided into two categories:

[0034] (1) Plugin log printing management. By modifying plugins to add logs and combining log level switch management, the plugin's running status can be analyzed.

[0035] (2) Data stream coloring. Coloring control data is added to the input and output data streams of the plugin, and combined with the log printing of the input and output interfaces, to realize the monitoring and analysis of the plugin's running status.

[0036] The above method (1) incurs performance overhead due to the increased logging, and also increases the complexity of plugin development, requiring different vendors to coordinate log formats and logging level controls. When new problems are discovered, vendors need to communicate to modify plugins and adjust logging logic. This intrusive solution requires close cooperation among multiple vendors, increasing the difficulty of plugin maintenance.

[0037] For the above method (2), the addition of color control data to the data stream requires modification of the data stream, increasing the data transmission pressure and reducing the processing performance of the plugin. When new problems are discovered or new data statistics items are added, it is necessary to coordinate with multiple vendors to adjust the plugin interface to support the new color control data transmission, which to some extent reduces the flexibility of the plugin.

[0038] Therefore, when the plugins in a pipeline come from different manufacturers, it is necessary for each manufacturer to cooperate and communicate to debug in order to check the correctness of the operation status of each plugin, which will result in excessively high communication and debugging costs.

[0039] To accurately detect the correctness of the operational status of each plugin without incurring excessive communication and debugging costs, this application provides a plugin operational status detection method, electronic device, computer-readable storage medium, and computer program product. The method first identifies the target plugin to be detected among multiple functional plugins implementing a target business in a pipeline manner. Then, it determines the plugin embedding position based on the target plugin and embeds a monitoring plugin at that position. Next, the monitoring plugin is used to detect the operational status of the target plugin. By embedding an independent monitoring plugin into a pipeline business comprising multiple functional plugins, the operational status of the target plugin in the pipeline business can be detected without changing the overall input / output logic of the pipeline business or modifying the original functional plugins. This decoupling of plugin functionality and operational analysis functionality allows for accurate detection of the correctness of the operational status of each plugin without incurring excessive communication and debugging costs.

[0040] The embodiments of this application can be applied to media processing such as audio and video on the core network media plane, as well as media processing of new call NCP AS, 5G messaging, etc. For example Figure 1 As shown, in the core network media plane elements, audio and video services are implemented in a plug-in pipeline. Encoding and decoding plug-ins are combined with AI plug-ins such as face recognition, subtitle synthesis, video synthesis, and portrait cutout to realize services such as fun calls and translation. In this application scenario, the plug-in running status detection method of this application embodiment can be applied to analyze the running status of each plug-in, analyze the performance indicators such as data stream processing latency and bandwidth fluctuation of each plug-in, and provide key maintenance guarantees for the core network media plane service experience.

[0041] The embodiments of this application will be further described below with reference to the accompanying drawings.

[0042] Reference Figure 2 As shown, Figure 2 This is a schematic diagram of a plug-in monitoring and management system provided in an embodiment of this application. This system dynamically embeds monitoring plug-ins into the business pipeline to monitor the operational status of each plug-in within the pipeline. The pipeline consists of multiple plug-ins, each working independently, and each plug-in's processing consumes a certain amount of time, ultimately affecting the overall system latency. By monitoring plug-ins on data packet size, data packet interval, retransmission behavior, etc., within the pipeline, the system's operational status can be effectively analyzed and identified, providing support for pipeline fault analysis and optimization.

[0043] exist Figure 2 The plug-in monitoring and management system may include a plug-in management unit 201, a pipeline management unit 202, a pipeline engine unit 203, a monitoring log unit 204, and a runtime monitoring and management unit 205.

[0044] The plugin management unit 201 is used to manage monitoring plugins, including the management of loading and unloading monitoring plugins.

[0045] Pipeline management unit 202 is used to implement business pipeline orchestration, that is, to connect and manage multiple plugins and combine them to realize various business functions. For example, video decoding plugins, portrait background replacement plugins, and video encoding plugins can be chained together to realize portrait background replacement business. In addition, pipeline management unit 203, besides supporting the above basic business orchestration, also supports the embedded orchestration management of monitoring plugins among various plugins in the business pipeline.

[0046] Pipeline engine unit 203 is used to load functional plugins and monitoring plugins embedded in the pipeline, enabling the flow of media data between plugins. Monitoring plugins are treated as "ordinary" functional plugins and are scheduled for execution. When scheduled, monitoring plugins perform processing such as input data stream forwarding, metric analysis, and log writing.

[0047] The monitoring log unit 204 is used to interface with the pipeline engine unit 203 for log communication, receive monitoring logs generated by the pipeline engine unit 203, and perform log parsing, storage, index management, etc.

[0048] The operation monitoring and management unit 205 is used to interface with the monitoring log unit 204 to retrieve monitoring log information and index each data stream according to pipeline ID, monitoring plug-in ID or data stream ID, etc., in order to analyze the operation status of the corresponding functional plug-in.

[0049] In some embodiments, the structure of the monitoring plugin can be referenced. Figure 3 As shown. In Figure 3The monitoring plugin 300 may include a forwarding unit 301, an analysis unit 302, and a logging unit 303. The forwarding unit 301 directly forwards the input stream to the output stream, achieving data passthrough. The forwarding unit 301 can immediately forward the received data stream, thereby minimizing processing latency within the monitoring plugin 300. The analysis unit 302 can collect data packet size, timestamps, message types, etc., of the input stream and perform internal input stream interval statistics. The analysis unit 302 does not perform input stream unpacking; it only collects data stream-level metrics, minimizing the impact of the monitoring plugin on system resource consumption and data transmission latency. The logging unit 303 uses a cached, delayed batch logging method, meaning that data stream forwarding is completed before logging.

[0050] exist Figure 2 In this system, the plug-in management unit 201 is connected to the pipeline engine unit 203 via the IF1 interface and to the pipeline management unit 202 via the IF2 interface; the pipeline management unit 202 is connected to the pipeline engine unit 203 via the IF3 interface; the pipeline engine unit 203 is connected to the monitoring and logging unit 204 via the IF4 interface; and the monitoring and logging unit 204 is connected to the operation monitoring and management unit 205 via the IF5 interface. The IF1 interface is the plug-in management interface, used by the plug-in management unit 201 to send load or unload plug-in commands to the pipeline engine unit 203 and to receive the operation results. The IF2 interface is the plug-in status query interface, used by the pipeline management unit 202 to query the plug-in management unit 201 for the plug-in status and to synchronize the usage status of plug-ins in the pipeline. It should be noted that only plug-ins in the loading state can be orchestrated, and plug-ins currently in use in the pipeline are prohibited from being unloaded. The IF3 interface is the pipeline deployment interface, used by the pipeline management unit 202 to deploy pipelines to the pipeline engine unit 203 and dynamically update pipelines. This enables the embedding of monitoring plugins into the pipeline and the monitoring and analysis of the operational status of functional plugins. The IF4 interface is the monitoring log push / collection interface, used by the pipeline engine unit 203 to output monitoring logs to the monitoring log unit 204. The IF5 interface is the monitoring log analysis interface, used by the monitoring management unit 205 to query the monitoring log unit 204 for the operational logs of plugins within the monitoring pipeline, enabling the analysis of the operational status of functional plugins.

[0051] It should be noted that although this embodiment takes the core network media plane system as an example, this embodiment is not limited to this. For example, in 5G networks, 6G networks, and 5GMC messaging networks, depending on the different network topologies and the different network elements being connected, the data streams supported by the plug-in are not limited to audio and video media streams, and other data streams can also be applied.

[0052] Reference Figure 4As shown, Figure 4 This is a flowchart of a plug-in runtime status detection method provided in an embodiment of this application. The method may include, but is not limited to, the following steps S410 to S430.

[0053] Step S410: Among the multiple functional plugins that implement the target business in a pipeline manner, determine the target plugin to be tested;

[0054] Step S420: Determine the plugin embedding location based on the target plugin, and embed the monitoring plugin at the plugin embedding location;

[0055] Step S430: Detect the running status of the target plugin by monitoring the plugin.

[0056] In some embodiments, the target plugin to be detected can be determined from multiple functional plugins that implement the target service in a pipelined manner, based on a set detection task. For example, suppose the target service is a portrait background replacement service during video processing, and the video decoding plugin, portrait background replacement plugin, and video encoding plugin are connected in series in a pipeline to implement this target service. If the detection task requires detecting the processing latency of the portrait background replacement plugin, then it can be determined that the portrait background replacement plugin is the target plugin to be detected.

[0057] In some embodiments, after determining the target plugin to be detected, the plugin embedding position can be determined based on the target plugin, and then a monitoring plugin can be embedded at that embedding position to enable the monitoring of the target plugin's operational status. The plugin embedding position can be the data output position of the target plugin; therefore, the monitoring plugin can be embedded at the target plugin's data output position. For example, suppose a video decoding plugin, a portrait background replacement plugin, and a video encoding plugin are connected in a pipeline to implement a portrait background replacement service, where the portrait background replacement plugin is the target plugin to be detected. Then, the data output position of the portrait background replacement plugin is the plugin embedding position, which is located in the connection line between the portrait background replacement plugin and the video encoding plugin. After embedding the monitoring plugin at the plugin embedding position, the monitoring plugin will be located between the portrait background replacement plugin and the video encoding plugin. At this point, the video decoding plugin, portrait background replacement plugin, monitoring plugin, and video encoding plugin are connected in a pipeline.

[0058] In some embodiments, after a monitoring plugin is embedded at the plugin embedding location, the monitoring plugin can be run to detect the running status of the target plugin. For example, when the monitoring plugin is embedded at the data output location of the portrait background replacement plugin, the output data of the portrait background replacement plugin can be collected through the monitoring plugin, and then the running status of the portrait background replacement plugin can be detected based on the output data of the portrait background replacement plugin to complete the set detection task.

[0059] The plug-in runtime status detection method described in steps S110 to S430 first identifies the target plug-in to be detected among multiple functional plug-ins implementing the target business in a pipeline manner. Then, the plug-in embedding position is determined based on the target plug-in, and a monitoring plug-in is embedded at that position. The runtime status of the target plug-in is then detected using the monitoring plug-in. By embedding an independent monitoring plug-in into a pipeline business comprising multiple functional plug-ins, the overall input / output logic of the pipeline business can be changed without altering the original functional plug-ins, and the runtime status of the target plug-in in the pipeline business can be detected without any modification to these original functional plug-ins. This decoupling of plug-in functionality from runtime analysis functionality allows for accurate detection of the correctness of the runtime status of each plug-in without incurring excessive communication and debugging costs.

[0060] In some embodiments, in response to the detection of the running status of the target plugin by the monitoring plugin, the monitoring plugin is immediately uninstalled, which can effectively reduce the processing latency of the entire business process and thus minimize the impact on the entire business process.

[0061] In some embodiments, when embedding a monitoring plugin at the plugin embedding location, the target detection metrics for the target plugin can be determined first, such as latency detection metrics, bandwidth fluctuation detection metrics, etc. Then, a monitoring plugin supporting the target detection metrics is loaded through the target path, and the loaded monitoring plugin is then embedded into the plugin embedding location. By loading the monitoring plugin into the system first, embedding the loaded monitoring plugin into the pipeline, and then unloading the monitoring plugin immediately after it has completed detecting the running status of the target plugin, dynamic loading and unloading of the monitoring plugin can be achieved, reducing communication and debugging costs. Furthermore, the impact of the monitoring plugin on the entire working system can be minimized, ensuring the normal operation of the entire working system.

[0062] In some embodiments, depending on the business scenario and business pipeline, multiple different monitoring plugins can be deployed to collect different monitoring metrics. These different monitoring plugins can be distinguished by their plugin names. For example, one or more monitoring plugins can be loaded from a specified path using the monitoring plugin loading interface, and different monitoring plugins can be deployed in different directories. Furthermore, one monitoring plugin or multiple monitoring plugins can be uninstalled using the monitoring plugin uninstall interface, based on their plugin names.

[0063] In some embodiments, the control instructions for monitoring the plugin loading interface and monitoring the plugin unloading interface can be implemented in different ways, and an appropriate choice can be made according to the actual application situation. No specific limitation is made here. For example Figure 5A and Figure 5B As shown, the control commands for both the monitoring plugin loading interface and the monitoring plugin uninstallation interface can be implemented using JSON. Figure 5A This is a code structure diagram of a plugin loading monitoring interface. Figure 5B This is a code structure diagram illustrating an interface for monitoring plugin uninstallation. For example, in... Figure 5A In this framework, the monitoring plugin loading interface includes behavior fields and module fields. Behavior fields describe the operations performed on the monitoring plugin, including loading and unloading. Module fields describe the plugin information. For example, when the behavior field describes a loading operation for a monitoring plugin, the module field describes the plugin information of the plugin to be loaded, including the plugin name and storage location. The module field can describe the plugin information of one or more monitoring plugins, indicating that one or more monitoring plugins are loaded at once. For example... Figure 5A In the code, the module field describes two monitoring plugins, monitoring plugin A and monitoring plugin B, indicating that monitoring plugin A and monitoring plugin B are loaded simultaneously. Additionally, when the behavior field describes an uninstallation operation for a monitoring plugin, the module field describes the plugin information of the monitoring plugin to be uninstalled, including the plugin name. The module field can describe the plugin information of one or more monitoring plugins, corresponding to the uninstallation of one or more monitoring plugins at a time. For example... Figure 5A In the text, the module field describes two monitoring plugins, monitoring plugin A and monitoring plugin B, indicating that monitoring plugin A and monitoring plugin B are uninstalled simultaneously at one time.

[0064] In some embodiments, when there are multiple target detection indicators, i.e., when multiple target detection indicators need to be detected, multiple monitoring plugins can be embedded, and each monitoring plugin corresponds to at least one of the multiple target detection indicators. In this case, when embedding the loaded monitoring plugins into the plugin embedding location, the multiple loaded monitoring plugins can be embedded into the plugin embedding location according to the indicator types of the multiple target detection indicators, either through a concatenation method or a combination of data stream replication and concatenation.

[0065] In some embodiments, the monitoring plugin can support multiple operating modes, such as single-path forwarding mode, multi-path forwarding mode, replication mode, and single-input mode. Replication mode refers to the monitoring plugin's ability to redirect the input streams of certain functional plugins to other analysis modules, thereby achieving the function of a stream splitter. Single-input mode refers to a mode with only an input stream and no output stream, which can be used for detailed data analysis of the input stream. By embedding monitoring plugins with multiple operating modes among different functional plugins in the pipeline, compatibility with plugins of various input stream quantities is achieved, supporting single-path forwarding, multi-path forwarding, and other functions.

[0066] refer to Figure 6A and Figure 6B As shown, Figure 6A Examples of various monitoring plugins supporting different operating modes are provided. Figure 6B Examples of applications supporting various monitoring plugins in different operating modes are provided. Figure 6B In the single-path forwarding mode example shown, the target plugin to be detected has only one output stream. Therefore, it is only necessary to embed a monitoring plugin (i.e., in series mode) at the data output position of the target plugin. Figure 6B In the single-path forwarding mode example two shown, the target plugin to be detected has two output streams. In this case, two monitoring plugins (i.e., cascaded) can be embedded at the data output position of the target plugin. The two monitoring plugins correspond one-to-one with the two output streams, monitoring each output stream of the target plugin respectively. Through the single-path forwarding mode, only the data streams that must be analyzed are monitored, thereby minimizing the impact of embedding into the pipeline. When the target plugin to be detected has N output streams, a monitoring plugin supporting multi-path forwarding mode can be embedded at the data output position of the target plugin. This multi-path forwarding mode monitoring plugin can support receiving M data streams, where N and M are both greater than or equal to 2, and M is less than or equal to N. For example, in... Figure 6BIn the multi-forwarding mode example shown, the target plugin to be detected has two output streams. In this case, a monitoring plugin supporting two-way forwarding mode (i.e., serial connection) can be embedded at the data output position of the target plugin. Through multi-forwarding mode, timestamp-level comparison analysis of the target plugin's multiple output streams can be achieved, thereby analyzing the time synchronization characteristics of the target plugin's multiple output streams. Figure 6B In the example of combining the replication mode with the single-input mode, when a full metric analysis of the output stream of the target plugin A needs to be performed, a monitoring plugin (S2a) supporting replication mode and a monitoring plugin (S2b) supporting single-input mode can be embedded together at the data output position of the target plugin A. For the monitoring plugin (S2a) supporting replication mode, the output stream of the target plugin A can be replicated into two or more output streams. One output stream is output to the downstream functional plugin B according to the original data stream forwarding relationship within the pipeline, while the other output streams are output to the monitoring plugin (S2b) supporting single-input mode. For the monitoring plugin (S2b) supporting single-input mode, it receives the output stream of the monitoring plugin (S2a) supporting replication mode, and this output stream terminates within the monitoring plugin (S2b) supporting single-input mode, ceasing further output. This monitoring plugin (S2b) supporting single-input mode can perform detailed data analysis on the received data stream, such as full metric analysis, encoding / decoding analysis, etc.

[0067] The following section provides a detailed introduction to the operating modes supported by the monitoring plugin, using specific examples.

[0068] refer to Figure 7 As shown, Figure 7 This is an application diagram illustrating the various operating modes supported by the monitoring plugin in this embodiment. Figure 7 The document provides exemplary diagrams illustrating single-plugin applications, multi-plugin serial applications, and serial applications combining stream replication for monitoring plugins. Figure 7 The single-plugin application example shown illustrates that monitoring plug-in S1 can collect data from the input stream of target plug-in A, and monitoring plug-in S2 can collect data from the output stream of target plug-in A. For Figure 7 The illustrated example of a plug-in chain application shows that monitoring plug-in S1 can collect data from the input stream of target plug-in A, while monitoring plug-ins S2a and S2b can collect data from the output stream of target plug-in A using different analytical metrics. For Figure 7The illustrated example of stream replication combined with serial application shows that monitoring plugin S1 can collect data from the input stream of target plugin A, and monitoring plugin S2c can replicate the output stream of target plugin A. One output stream is output to functional plugin B according to the original data flow relationship, while the other output stream is output to monitoring plugin S2d for full metric collection and analysis of the output stream of target plugin A. Monitoring plugin S2c can extend the replication of a specific data stream while minimizing the impact on the original pipeline data stream forwarding. Monitoring plugin S2d can independently analyze the output stream of target plugin A. Since the data stream replicated by monitoring plugin S2c does not affect the original pipeline data forwarding relationship, more detailed metric analysis can be performed on the replicated data stream through monitoring plugin S2d, such as time-consuming operations like multi-metric collection and data comparison. By combining stream replication with serial application, not only can low latency of the original pipeline data forwarding be achieved, but also detailed analysis capabilities for specific data can be supported, thereby enabling more accurate detection of the operational status of the target plugin.

[0069] In some embodiments, when monitoring the operational status of a target plugin, the monitoring plugin can first collect data stream-level metrics from the data stream output by the target plugin to obtain data stream-level metric parameters. Then, the operational status of the target plugin can be analyzed based on these parameters. Specifically, during the data stream-level metric collection process, the monitoring plugin directly forwards the data stream along its original transmission path. In obtaining data stream-level metric parameters, the monitoring plugin can collect at least one of the following parameters: packet size, timestamp, and message type. This effectively reduces the impact of the monitoring plugin on the entire operating system.

[0070] In some embodiments, after the monitoring plugin forwards the data stream, it can also record detection logs for the target plugin, so that the data stream collected by the monitoring plugin can be analyzed in full metrics, thereby achieving accurate detection of the target plugin's operating status.

[0071] In some embodiments, when embedding a monitoring plugin at a plugin embedding location, the first link at the plugin embedding location is first deleted, where the target plugin is connected to the subsequent plugin via the first link. Then, a second link connecting the target plugin and the monitoring plugin is added, followed by a third link connecting the monitoring plugin and the subsequent plugin. Alternatively, when uninstalling the monitoring plugin, the second and third links can be deleted first, and then a fourth link connecting the target plugin and the subsequent plugin can be added. This allows the monitoring plugin to be embedded in the plugin embedding location to monitor the operational status of the target plugin, or to be uninstalled from the pipeline, without affecting the existing pipeline data forwarding relationships.

[0072] In some embodiments, depending on the detection task, the monitoring plugin can be embedded in different positions within the pipeline. For example, the monitoring plugin can be embedded before the first functional plugin in the pipeline, after the last functional plugin, or between any two functional plugins in the pipeline, thereby enabling monitoring embedding at any position within the pipeline. For instance, when the detection task is to detect the input stream of the pipeline, the monitoring plugin can be embedded before the first functional plugin. Similarly, when the detection task is to detect the output stream of the pipeline, the monitoring plugin can be embedded after the last functional plugin. Furthermore, when the detection task is to detect the output stream of a specific functional plugin in the pipeline, the monitoring plugin can be embedded between that functional plugin and its successor plugin.

[0073] For example Figure 8 As shown, Figure 8 An example is given of the process of embedding multiple monitoring plugins at multiple locations within a pipeline. Figure 8 In the pipeline, functional plugins A through G form a pipeline. Based on multiple detection tasks, it is determined that different monitoring plugins need to be embedded at positions p1, p2, p3, and p4. Here, p1 is the input position of the entire pipeline, p2 is the position between functional plugins A and B, p3 is the position where functional plugins D and E converge and output to functional plugin F, and p4 is the output position of the entire pipeline. Therefore, it is determined that monitoring plugin S1 supporting single-path forwarding mode can be embedded at p1, monitoring plugin S2 supporting single-path forwarding mode can be embedded at p2, monitoring plugin S3 supporting multi-path forwarding mode can be embedded at p3, and monitoring plugin S4 supporting single-path forwarding mode can be embedded at p4. After embedding different monitoring plugins at positions p1, p2, p3, and p4, the following can be obtained: Figure 8 The diagram in the lower middle shows a pipeline with an embedded monitoring plugin.

[0074] In other embodiments, such as Figure 9 As shown, the monitoring plugin S3 embedded in the p3 location can also be changed to two monitoring plugins that support single-path forwarding mode (such as...). Figure 9 As shown in S3a and S3b), this also enables the detection of the running status of functional plug-in D and functional plug-in E, improving the flexibility of detecting the running status of different functional plug-ins in the pipeline.

[0075] In some embodiments, such as Figure 10A and Figure 10B As shown, exemplary examples are provided for performing deletion, embedding, and update operations on monitoring plugins within a pipeline. Figure 10A In this pipeline, monitoring plugin 1001, monitoring plugin 1003, and functional plugins A through F form a pipeline. For this pipeline, it is necessary to delete monitoring plugin 1001, add monitoring plugin 1002 between functional plugins A and B, and update monitoring plugin 1003. These processes can be performed as follows: Figure 10B This is achieved using the control commands shown. Figure 10B As can be seen, multiple monitoring plugins can be processed in batches. That is, multiple operations on monitoring plugins can be achieved through a single interface call, including deletion, addition, and update operations, and each operation can be executed multiple times.

[0076] like Figure 10BAs shown, each operation can be described by a single JSON object and serve as a member of the ModuleList array. Each member of the ModuleList array can include an operation type field, a plugin identifier field, a plugin name field, an input stream identifier field, an output stream identifier field, and a plugin configuration parameter field. The operation type field supports three operation types: add, delete, and update. The plugin identifier field describes the ID of the monitoring plugin, uniquely identifying the monitoring plugin within the pipeline. It should be noted that functional plugins and monitoring plugins can use the same identifier value range or different identifier value ranges, depending on the actual application needs; no specific limitation is made here. For example, the identifier value of a monitoring plugin can start from 1000, and the identifier value of a functional plugin can start from 1. The plugin name field describes the name of the monitoring plugin. The input stream identifier field describes the identifier of the input stream of the monitoring plugin; each input stream of the monitoring plugin uses a stream identifier (streamid), which can be numbered starting from 0. For example, assuming a monitoring plugin has two input streams, the description of the input stream identifier field could be {"streamid": 0} or {"streamid": 1}. The output stream identifier field describes the identifier of the monitoring plugin's output stream. Each output stream of the monitoring plugin uses a unique stream identifier (streamid), which can start from 0. For example, assuming a monitoring plugin has two output streams, the description of the output stream identifier field could be {"streamid": 0} or {"streamid": 1}. The plugin configuration parameter field describes the configuration parameters of the monitoring plugin. These can be customized according to the functionality of the monitoring plugin. For example, the plugin configuration parameter field can be used to set the flow forwarding relationships, analysis items, log placement rules, and other related information for the monitoring plugin.

[0077] In some embodiments, when the operation type field is described as a delete operation, it indicates the deletion of a monitoring plugin. In this case, only the plugin identifier field and the plugin name field need to be included. When the operation type field is described as an add operation, it indicates the addition of a monitoring plugin. In this case, the operation type field, plugin identifier field, plugin name field, input stream identifier field, and output stream identifier field need to be included. In addition, the plugin configuration parameter field can be included depending on the actual application requirements. When the operation type field is described as an update operation, it indicates that the configuration parameters of a monitoring plugin need to be updated. In this case, only the plugin identifier field, plugin name field, and plugin configuration parameter field need to be included.

[0078] It should be noted that, as Figure 10BIn the pipeline, the Link list is used to identify changes in the link relationships between input and output streams of plugins caused by adding or deleting plugins. Each link relationship is identified by a from-to stream relationship pair. `from` identifies the starting plugin ID and plugin output stream ID of the stream (e.g., `{"moduleId":xx,"streamId":yy}`), or the input stream ID of the pipeline (`pipeline_streamId`). `to` identifies the ending plugin ID and plugin input stream ID of the stream (e.g., `{"moduleId":xx,"streamId":yy}`), or the output stream ID of the pipeline (`pipeline_streamId`). Each from-to link relationship can support two operation types, such as simultaneously adding and deleting a link relationship.

[0079] In some embodiments, when the monitoring plugin includes plugin configuration parameters, in response to an update in the detection type of the target plugin's running state, the plugin configuration parameters of the monitoring plugin can be updated so that the updated plugin configuration parameters are compatible with the updated detection type.

[0080] In some embodiments, the monitoring plugin supports three configurations: Transmit, Probe, and Log. These configurations enable flexible monitoring and control of input streams within the pipeline. They allow selective monitoring of different input streams and flexible control over the monitoring statistics for each input stream. This means different monitoring statistics can be used for different input streams within the pipeline, enabling fine-grained, on-demand analysis of the pipeline's operational status. The Transmit rule supports explicit control over the forwarding relationship between input and output streams and allows copying one output stream into multiple output streams. This means that while maintaining the original input-output flow relationships between functional plugins within the pipeline, specific data streams can be copied and forwarded, allowing for additional data analysis of those specific streams. The processing of copied streams does not affect the original pipeline's processing logic. Furthermore, the Probe rule can consist of three configuration items: Streamid, Items, and Output. Multiple sets of rules can be configured, each corresponding to one input stream. The Streamid configuration item within each group identifies the input stream corresponding to the current group; the Items configuration item is used to configure the indicators to be statistically analyzed, and can configure one or more indicator items. Different groups can use different indicator items. By configuring according to input stream groups, differentiated monitoring and analysis of different input streams can be achieved. Within each group, it is possible to set an independent Output configuration item (or Output path) to control the output location of the monitoring indicator data of a specific input stream. By configuring different Output configuration items for different groups, it is possible to achieve directory-based storage of the analysis indicator data of the input stream.

[0081] Reference Figure 11A and Figure 11B As shown, Figure 11A and Figure 11B An example configuration of the monitoring plugin in single-path forwarding mode is provided. Figure 11B In the `transmit` rule, the forwarding mapping between the input and output streams of the monitoring plugin is specified. Both the input and output channels of the monitoring plugin can be numbered starting from 0. The `from-to` link is used to identify the mapping between the input and output streams of the monitoring plugin, where `from` indicates the stream identifier of the input stream and `to` indicates the stream identifier of the output stream.

[0082] exist Figure 11BIn this framework, Probe rules are used to configure the analysis rules for data streams by the monitoring plugin. Multiple rules can be configured within a Probe rule, each rule being a JSON array object. Each array object includes three fields: Streamid, Iteams, and Output. These fields specify the input stream to which the rule applies, the statistical metric to be analyzed, and the output path of the statistical metric, respectively. When Streamid = 0, it means that the Probe rule applies to the input stream with Streamid = 0. When multiple input streams exist, the Streamid can be used to distinguish the Probe rules applied to different input streams, allowing different input streams to use different Probe rules. The Iteams field is an array that lists the input stream analysis metrics to be analyzed. In some embodiments, the metrics supported by the Iteams field may include at least one of the following: "PktType", "PktSize", "PktTimeStamp", "avgInterval", "maxInterval", "AddSeqNum", "PktCountsPerSecond", and "TotalCounts". Each rule can arbitrarily select one or more of these statistical items.

[0083] exist Figure 11B In the configuration, the Log field is used to set the log generation interval and log tag identifier. For analysis log data generated from the input stream, the corresponding tag identifier can be specified through the Log configuration to facilitate indexing by the log storage unit. Additionally, the Interval field is used to set the generation interval of the analysis logs, in seconds, where 0 indicates real-time log generation. By setting the Interval field to control the log output period of the monitoring plugin, different analysis requirements can be met.

[0084] Reference Figure 12A and Figure 12B As shown, Figure 12A and Figure 12B An exemplary configuration example of a monitoring plugin for multi-path forwarding mode is provided. This multi-path forwarding mode monitoring plugin can support multiple input and output streams, where the number of input and output streams is equal. Figure 12B In the configuration, the Transmit rule specifies the forwarding mapping between the input and output streams of the monitoring plugin. The input stream ID and output stream ID are the same for the from-to link. For an input stream with Streamid=0, the output is sent to the output stream with Streamid=0; for an input stream with Streamid=1, the output is sent to the output stream with Streamid=1. Separate Probe rules can be set for multiple input streams. For example... Figure 12BAs shown, probe rules were set for the input streams with Streamid=0 and Streamid=1 respectively. Probe rules for different input streams can be configured to be the same or different. For example... Figure 12B In the code, different analysis rules are configured for the input streams with Streamid=0 and Streamid=1 (e.g., ...). Figure 12B (See the Iteams field shown). It should be noted that in multi-path forwarding mode, the Log configuration for different input streams can use the same or different TAG identifiers and Interval field contents. For example... Figure 12B As shown, Log configurations were set for the input streams with Streamid=0 and Streamid=1 respectively, and different TAG identifiers and Interval field contents were used.

[0085] Reference Figure 13A and Figure 13B As shown, Figure 13A and Figure 13B An example configuration of the monitoring plugin for replication mode is provided. Figure 13B In the code, the Transmit rule specifies the forwarding mapping between the input and output streams of the monitoring plugin, achieving stream replication by configuring the same from stream identifier to different to stream identifiers. For example... Figure 13B As shown, this implements the copying of the input stream with Streamid=0 to the output streams with Streamid=0 and Streamid=1. It should be noted that one or more output streams can be copied for a single input stream. For example... Figure 13B As shown, a Probe rule is set for the input stream with Streamid=0, supporting Items and Output configuration items. The specific format can be found in the description of the single-path forwarding mode, and will not be repeated here. A Log configuration item is set for the input stream with Streamid=0, supporting TAG and Interval configurations.

[0086] The plug-in runtime status detection method provided in this application embodiment can effectively improve the detection and analysis capabilities of the plug-in pipeline orchestration system, and effectively decouple plug-in business functions from plug-in runtime indicator monitoring. Furthermore, in the plug-in orchestration system, the plug-in runtime status detection method provided in this application embodiment can also effectively monitor and analyze data flow indicators between any interconnected functional plug-ins within the pipeline, thereby enabling dynamic embedded monitoring of any functional plug-in location in the pipeline, and thus effectively improving the pipeline system's indicator analysis and fault location capabilities. Additionally, when functional plug-ins within the pipeline are provided by multiple parties, the plug-in runtime status detection method provided in this application embodiment allows plug-in developers to focus on the functional development of their plug-ins without needing to pay attention to the monitoring needs of the pipeline integrator, thereby effectively reducing plug-in maintenance costs.

[0087] Additionally, refer to Figure 14 As shown, one embodiment of this application also discloses an electronic device 1400, which includes at least one processor 1410; at least one memory 1420 for storing at least one program; when the at least one program is executed by the at least one processor 1410, it implements the plug-in running status detection method as in any of the preceding embodiments.

[0088] In addition, one embodiment of this application discloses a computer-readable storage medium storing computer-executable instructions for executing the plug-in running status detection method as described in any of the preceding embodiments.

[0089] Furthermore, one embodiment of this application also discloses a computer program product, including a computer program or computer instructions, which are stored in a computer-readable storage medium. The processor of an electronic device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the electronic device to perform the plug-in running status detection method as described in any of the preceding embodiments.

[0090] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0091] The above is a detailed description of the preferred embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for detecting the runtime status of a plugin, comprising: Among multiple functional plugins that implement the target business in a pipeline manner, identify the target plugin to be tested; Determine the plugin embedding location based on the target plugin, and embed the monitoring plugin at the plugin embedding location; The monitoring plugin is used to detect the running status of the target plugin.

2. The method according to claim 1, characterized in that, The method further includes: In response to the completion of the detection of the running status of the target plugin, the monitoring plugin is uninstalled.

3. The method according to claim 1, characterized in that, The embedding of the monitoring plugin at the plugin embedding location includes: Determine the target detection metrics for detecting the target plugin; The monitoring plugin that supports the target detection metrics is loaded via the target path; The loaded monitoring plugin is then embedded into the plugin embedding location.

4. The method according to claim 3, characterized in that, The number of target detection indicators is multiple, and the number of monitoring plugins is multiple, with each monitoring plugin corresponding to at least one of the multiple target detection indicators.

5. The method according to claim 4, characterized in that, The step of embedding the loaded monitoring plugin into the plugin embedding location includes: Based on the index types of the multiple target detection indicators, the loaded monitoring plugins are embedded into the plugin embedding location in one of the following ways: Series connection; The data stream replication method is combined with the serial method.

6. The method according to claim 1, characterized in that, The monitoring plugin supports one of the following operating modes: Single-path forwarding mode; Multi-path forwarding mode; Copy mode; Single input mode.

7. The method according to claim 1, characterized in that, The step of detecting the running status of the target plugin through the monitoring plugin includes: The monitoring plugin collects data stream-level metrics from the data stream output by the target plugin to obtain data stream-level metric parameters. Analyze the running status of the target plugin based on the data stream level indicator parameters; In the process of collecting data stream-level indicators from the data stream output by the target plugin, the monitoring plugin directly forwards the data stream according to its original transmission path.

8. The method according to claim 7, characterized in that, The step of collecting data stream-level metrics from the data stream output by the target plugin through the monitoring plugin to obtain data stream-level metric parameters includes: The monitoring plugin collects at least one of the following parameters from the data stream output by the target plugin to obtain the data stream-level indicator parameters: Data packet size, timestamp, message type.

9. The method according to claim 7, characterized in that, The method further includes: After the monitoring plugin forwards the data stream, the monitoring plugin records a detection log for the target plugin.

10. The method according to claim 2, characterized in that, The embedding of the monitoring plugin at the plugin embedding location includes: Delete the first link at the plugin embedding location, wherein the target plugin is connected to the subsequent plugin through the first link; Add a second link connecting the target plugin and the monitoring plugin; Add a third link to connect the monitoring plugin and the subsequent plugin.

11. The method according to claim 10, characterized in that, Uninstalling the monitoring plugin includes: Delete the second link and the third link; Add a fourth link connecting the target plugin and the successor plugin.

12. The method according to claim 1, characterized in that, The monitoring plugin includes plugin configuration parameters; the method further includes: In response to an update in the detection type of the target plugin's running status, the plugin configuration parameters of the monitoring plugin are updated to adapt the updated plugin configuration parameters to the updated detection type.

13. An electronic device, comprising: At least one processor; At least one memory for storing at least one program; At least one of the programs is run by at least one of the processors to perform the plug-in running status detection method according to any one of claims 1 to 12.

14. A computer program product, comprising a computer program or computer instructions, characterized in that, The computer program or the computer instructions are stored in a computer-readable storage medium. The processor of the electronic device reads the computer program or the computer instructions from the computer-readable storage medium and executes the computer program or the computer instructions, causing the electronic device to perform the plug-in running status detection method according to any one of claims 1 to 12.

Images