Cloud platform service monitoring method, device and electronic equipment

Abstract

The application discloses a cloud platform service monitoring method and device and electronic equipment, and relates to the technical field of link tracking. The method comprises the following steps: performing a preset position in each service link of OpenStack according to an OSProfiler monitoring framework; performing standardized processing on the preset position of the link; setting the link in the core dependent library; replacing the original implementation of the OSProfiler monitoring framework, and reconstructing the OSProfiler monitoring framework; and monitoring the reconstructed OpenStack service link. The main idea of the application is to use the existing OSProfiler monitoring framework to monitor the key modules of the OpenStack service link, and to move the preset position to the core dependent library. Compared with directly using other cloud platform service monitoring solutions, the compatibility of the OSProfiler and the OpenStack is better, the key preset position is similar, the invasiveness is small, the system stability is not easily affected, and the problem that the current OpenStack cloud platform service monitoring method uses other monitoring solutions to affect the system stability is solved.

Description

Technical Field

[0001] This application relates to the field of link tracing technology, specifically to a cloud platform service monitoring method, device, and electronic device. Background Technology

[0002] The cloud platform is responsible for providing users with computing, network, and storage resources and is the most important component of cloud computing. A cloud platform consists of numerous services, such as resource management services, billing management services, user management services, and business management services. Each of these services contains multiple microservices. Taking resource management services as an example, they are typically built on OpenStack and include several self-services such as KeyStone, Nova, Cinder, and Neutron. OpenStack is an open-source cloud operating system, and cloud platforms typically use OpenStack for resource management. While cloud platforms are powerful, without reasonable and effective monitoring methods, a failure in any module of the platform can be extremely difficult for troubleshooting personnel.

[0003] Current platform service monitoring or performance monitoring methods typically employ distributed tracing, such as the OSProfiler solution for OpenStack, which tracks link data by embedding tracking points in the code of various OpenStack sub-projects.

[0004] However, the OSProfiler solution suffers from incomplete performance data collection and data structures that do not conform to industry standards, making it unable to achieve real-time aggregation and visualization of the entire OpenStack service chain. Adopting other cloud platform service monitoring solutions requires adding new monitoring points to OpenStack, and this coupled intrusion could potentially introduce significant instability into a mature system. Summary of the Invention

[0005] In view of this, this application provides a cloud platform service monitoring method, device and electronic device, the main purpose of which is to solve the problem that the current OpenStack cloud platform service monitoring method will affect the system stability when other monitoring schemes are adopted.

[0006] Firstly, this application provides a cloud platform service monitoring method, including:

[0007] Implement monitoring points according to the preset locations of the OSProfiler monitoring framework in each service link of OpenStack;

[0008] The link tracking points at the preset locations are standardized so that they are set in the core dependency library.

[0009] Replace the native implementation of the OSProfiler monitoring framework and reconstruct the OSProfiler monitoring framework;

[0010] Monitor the reconstructed OpenStack service chain.

[0011] Optionally, the step of placing data points according to the preset locations of the OSProfiler monitoring framework in each service link of OpenStack includes: placing data points in the HTTP request entry process; placing data points in the database access tracing process; placing data points in the remote procedure call protocol access tracing process; placing data points in the external service call tracing process; and placing data points in the thread execution tracing process.

[0012] Optionally, the step of standardizing the link tracking points at the preset location so that the link tracking points are set in the core dependency library includes: determining the process function corresponding to the service link where the preset location is located; and based on the process function, moving the link tracking points at the preset location to the core dependency library corresponding to the process function.

[0013] Optionally, replacing the native implementation of the OSProfiler monitoring framework includes replacing the native implementation of the OSProfiler monitoring framework with a tracing information library and a tracing programming interface.

[0014] Optionally, the method further includes: processing link data from different service sources through a data standardization module.

[0015] Optionally, the step of processing link data from different service sources through the data standardization module includes: when new link data is detected, collecting the link data and uploading it to a message queue; polling the message queue to find heterogeneous link data generated by different service sources; standardizing the heterogeneous link data; and storing the standardized link data after the standardization process is completed.

[0016] Optionally, the standardization process for the heterogeneous link data includes: extracting key features from the heterogeneous link data and unifying the data structure type; and unifying the format of the tracking identifier and span identifier in the heterogeneous link data.

[0017] Secondly, this application provides a cloud platform service monitoring device, comprising:

[0018] The instrumentation unit is configured to perform instrumentation based on the preset locations of the OSProfiler monitoring framework in each service link of OpenStack.

[0019] The processing unit is configured to perform normalization processing on the link embedding points at the preset location, so that the link embedding points are set in the core dependency library;

[0020] The refactoring unit is configured to replace the native implementation of the OSProfiler monitoring framework and refactor the OSProfiler monitoring framework.

[0021] The monitoring unit is configured to monitor the reconstructed OpenStack service chain.

[0022] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the cloud platform service monitoring method described in the first aspect.

[0023] Fourthly, this application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the cloud platform service monitoring method described in the first aspect.

[0024] Using the above technical solution, this application provides a cloud platform service monitoring method, device, and electronic device. First, following the OSProfiler monitoring framework, pre-defined locations in each OpenStack service link are marked with monitoring points. Then, the monitoring points for each pre-defined location are standardized and moved to the core dependency library. Next, the native implementation of the OSProfiler monitoring framework is replaced, and the OSProfiler monitoring framework is reconstructed, enabling monitoring of the reconstructed OpenStack service links. Compared to related technologies, this application provides a low-intrusion, highly scalable performance observation method for the core cloud platform service OpenStack. It first standardizes and moves the link monitoring points to the core dependency library, and then uses the mainstream link observation framework OSProfiler to reconstruct the monitoring point implementation method, achieving real-time observation of OpenStack service links. The core idea of ​​this application is to leverage the existing OSProfiler monitoring framework's ability to monitor key modules of the OpenStack service chain by moving the data tracking points to the core dependency library. This expands the scope of data tracking without affecting the original framework. Furthermore, the OSProfiler monitoring framework is reconstructed by replacing the native implementation. The reconstructed data chain tracing is more standardized, ensuring that the chain data conforms to industry standards and improving the comprehensiveness and scalability of the chain data. Compared to directly adopting other cloud platform service monitoring solutions, OSProfiler has better compatibility with OpenStack, and the key data tracking points are located close to each other, thus having less invasiveness and less likelihood of affecting system stability.

[0025] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0027] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 A flowchart illustrating a cloud platform service monitoring method provided in an embodiment of this application is shown.

[0029] Figure 2 This illustration shows a schematic diagram of the instrumentation points for OSProfiler link tracing provided in an embodiment of this application;

[0030] Figure 3 This illustration shows a schematic diagram of moving OSProfiler instrumentation points to the core dependency library of OpenStack, as provided in an embodiment of this application.

[0031] Figure 4 A flowchart illustrating another cloud platform service monitoring method provided in an embodiment of this application is shown;

[0032] Figure 5 A schematic diagram of the structure of a cloud platform service monitoring device provided in an embodiment of this application is shown. Detailed Implementation

[0033] To better understand the above-mentioned objectives, features, and advantages of this application, the solution of this application will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0034] The cloud platform service monitoring method proposed in this embodiment is applied to a cloud platform service monitoring device or electronic device. The device or electronic device can be installed or integrated into some cloud platform management systems and can execute any of the cloud platform service monitoring methods mentioned below during operation.

[0035] To address the issue that current OpenStack cloud platform service monitoring methods can negatively impact system stability when using other monitoring solutions, this embodiment provides a cloud platform service monitoring method, such as... Figure 1 As shown, the method includes:

[0036] S101, install monitoring points according to the preset locations of the OSProfiler monitoring framework in each service link of OpenStack.

[0037] First, following the OSProfiler monitoring framework, pre-defined locations are used to embed monitoring points in each OpenStack service chain. It's important to note that OpenStack is an open-source cloud operating system, and cloud platforms typically use OpenStack for resource management. OSProfiler is an observation solution (hereinafter referred to as the monitoring framework or monitoring method) provided by the OpenStack community, primarily used for monitoring and observing OpenStack services. Specifically, this is achieved by pre-embedding monitoring points at key locations, such as... Figure 2 As shown, data tracking points are implemented at preset locations such as the HTTP request entry point and the message queue. Data tracking refers to the techniques and implementation processes involved in capturing, processing, and sending data related to specific user behaviors or events, commonly found in data collection and tracking. The cloud platform service monitoring method proposed in this embodiment is based on the OSProfiler monitoring framework.

[0038] S102, standardize the link tracking points at the preset locations so that the link tracking points are set in the core dependency library.

[0039] Specifically, such as Figure 2 As shown, the OSProfiler monitoring framework's default locations can include five categories: HTTP request entry points, database (DB) access tracing, remote procedure call protocol access tracing (RPC access tracing), external service call tracing, and thread execution status tracing. The tracking points in these five locations are standardized, moving them to the core OpenStack dependency packages to increase their impact in a low-intrusive manner.

[0040] S103 replaces the native implementation of the OSProfiler monitoring framework and refactors the OSProfiler monitoring framework.

[0041] Replacing the native implementation of the OSProfiler monitoring framework, for example by using Jaeger-Client or OpenTelemetry-API, allows for the reconstruction of the tracing and data acquisition methods in OSProfiler. This ensures that the data transmission links conform to industry standards and improves the comprehensiveness and scalability of the data. Jaeger-Client is a library used to send tracing information to the Jaeger server, while OpenTelemetry-API is a programming interface used to inspect code for collecting telemetry data, such as traces, metrics, and logs. Both are methods that can replace the native implementation of the OSProfiler monitoring framework.

[0042] S104 monitors the reconstructed OpenStack service chain.

[0043] In this embodiment, monitoring points are first implemented at preset locations in each OpenStack service link according to the OSProfiler monitoring framework. Then, the monitoring points at each preset location are standardized and moved to the core dependency library. Next, the native implementation of the OSProfiler monitoring framework is replaced, and the OSProfiler monitoring framework is reconstructed, enabling monitoring of the reconstructed OpenStack service links. Compared to related technologies, this embodiment provides a low-intrusion, highly scalable performance observation method for the core cloud platform service OpenStack. It first standardizes the link monitoring points and moves them to the core dependency library, then uses the mainstream link observation framework OSProfiler to reconstruct the monitoring point implementation method, achieving real-time observation of OpenStack service links.

[0044] Typically, cloud platforms use OpenStack for resource management. As the most popular open-source project in cloud computing, OpenStack's functionality is quite comprehensive. While the OSProfiler monitoring solution provided by the OpenStack community has good compatibility with OpenStack and covers most key monitoring points, the performance data collected during the monitoring process is not comprehensive, and the data structure does not conform to industry standards. The single OSProfiler module lacks a complete ecosystem and cannot achieve real-time aggregation and visualization of the entire OpenStack service chain. Furthermore, using mainstream industry tracing solutions for OpenStack services requires adding new tracking points to OpenStack, and this coupled intrusion could potentially introduce significant instability into a mature system.

[0045] The core idea of ​​this embodiment is to leverage the existing OSProfiler monitoring framework's ability to monitor key modules of the OpenStack service chain by moving the data tracking points to the core dependency library. This expands the scope of data tracking without affecting the original framework. Furthermore, the OSProfiler monitoring framework is reconstructed by replacing the native implementation. The reconstructed data chain tracing is more standardized, ensuring that the chain data conforms to industry standards and improving the comprehensiveness and scalability of the chain data. Compared to directly adopting other cloud platform service monitoring solutions, OSProfiler has better compatibility with OpenStack, with key data tracking points located close together, resulting in less invasiveness and less likelihood of impacting system stability. This solves the problem of current OpenStack cloud platform service monitoring methods impacting system stability when using other monitoring solutions.

[0046] Optionally, monitoring points can be installed according to the preset locations of the OSProfiler monitoring framework in each OpenStack service link, including: installing points for the HTTP request entry process; installing points for the database access tracing process; installing points for the remote procedure call protocol access tracing process; installing points for the external service call tracing process; and installing points for the thread execution tracing process.

[0047] In this embodiment, compared with other monitoring methods that directly embed data into the core library, OSProfiler has advantages such as good OpenStack compatibility and the implementation of key data embedding methods, making the data embedding method less invasive and less likely to affect the stability of the system.

[0048] Specifically, based on the instrumentation characteristics of OSProfiler in various OpenStack services, the following five key instrumentation locations can be summarized:

[0049] HTTP request entry point: Utilizing existing tracking points in the OpenStack service web application processing framework, OSProfiler is modified to implement HTTP request performance evaluation.

[0050] DB Database Access Tracing: Leveraging existing instrumentation points in the OpenStack service's database access code, OSProfiler is modified to perform performance evaluation on each database request.

[0051] RPC Access Tracing: Leveraging existing instrumentation points in the RPC access code of OpenStack services, OSProfiler is modified to perform performance evaluation on each database request.

[0052] External service call tracing: By adding tracking points to external service access to public component libraries, performance evaluation of external service access can be achieved.

[0053] Thread execution tracking: By adding tracking points to the common thread component library, performance evaluation of thread execution can be achieved.

[0054] The above five types of tracking points are the preset locations for tracking points in various service links of the current OSProfiler monitoring framework. However, the links generated by OSProfiler do not conform to the industry standard (OpenTracing) specification, and therefore cannot be presented in real time using industry standard link collection, storage, and display software. This is one of the problems that this embodiment aims to solve. Subsequently, the tracking points will be standardized and moved to the core dependency packages of the corresponding OpenStack services to improve the impact of the tracking points in a low-intrusive manner.

[0055] Optionally, the link tracking points at the preset locations are standardized so that the link tracking points are set in the core dependency library, including: determining the process function corresponding to the service link at the preset location; and moving the link tracking points at the preset locations to the core dependency library corresponding to the process function based on the process function.

[0056] In this embodiment, as Figure 3 As shown, taking external service calls as an example, whether it's nova-api accessing the Neutron service or glance-api accessing Keystone, they both call the external application access method in the keystoneauth1 core dependency package. Therefore, by simply adding an OSProfiler instrumentation point for this method, we can achieve tracing of all OpenStack components accessing external services. Using the same method, adding corresponding instrumentation points to the core libraries of OpenStack's osprofiler, oslo_db, oslo_message, and eventlet enables tracing of HTTP requests, database, message queue access, and threads. This involves moving the instrumentation points up to the core dependency library corresponding to each process function, thereby achieving monitoring of that function. This approach is less invasive and less likely to impact stability.

[0057] Optionally, the native implementation of the OSProfiler monitoring framework can be replaced, including by replacing the native implementation of the OSProfiler monitoring framework with a tracing information library and a tracing programming interface.

[0058] In this embodiment, the tracing information database and tracing programming interface can, for example, use Jaeger-Client and OpenTelemetry-Api. The OSProfiler module already has interfaces for five types of data collection: HTTP requests, message queue access, database access, thread execution, and external calls, and these are implemented based on OSProfiler. Therefore, simply replacing the native OSProfiler implementation with the Jaeger-Client / OpenTelemetry-Api implementation achieves standardized collection of link data. Then, the real-time storage and visualization tools provided by the link observation community enable real-time observation of OpenStack service links. Compared to the native OSProfiler solution, the community-provided collection scheme offers features such as automatic service anomaly capture and custom data collection methods, resulting in richer and more scalable link data.

[0059] Furthermore, the cloud platform service monitoring method proposed in this embodiment can also solve the problem of inconsistent observation of link data from different service sources. Each service on a cloud platform typically has its own R&D team, and each team uses different link tracing tools for service observation. If the link data of numerous services cannot be correlated, it will be impossible to quickly locate the actual fault through the service observation system once the cloud platform fails. Although relevant communities have provided unified observation solutions similar to OpenTelemetry, in actual production processes, due to cross-team collaboration and the inconvenience of modifying mature service code, it is often difficult to use community technologies to achieve unified link data for all services. This results in the inability to share link data, creating a data silo problem that restricts the global observation of services.

[0060] In response, this embodiment also proposes to improve the data standardization module, and to standardize the heterogeneous link data of different service sources in order to achieve the association and unification of various service links of the cloud platform.

[0061] Optionally, cloud platform service monitoring methods also include: processing link data from different service sources through a data standardization module.

[0062] In this embodiment, to address the data incompatibility issues caused by different link tracing tools used by different services on the cloud platform, and to enable direct link call relationships between services that do not provide services, this embodiment proposes a data standardization module for a heterogeneous service tracing system. It also specifies the standard data format and storage method of the system, achieving integrated analysis of heterogeneous service tracing systems.

[0063] Optionally, the data standardization module processes link data from different service sources, including: when new link data is detected, collecting the link data and uploading it to a message queue; polling the message queue to find heterogeneous link data generated by different service sources; standardizing the heterogeneous link data; and storing the standardized link data after the standardization process is completed.

[0064] In this embodiment, heterogeneous link data refers to link data from different service sources (whose data structures may differ). By using a heterogeneous link data standardization algorithm, the problems of association, storage, and display of link data from different services on the cloud platform are solved, enabling real-time association and display of all service links on the cloud platform, thereby addressing the difficulty of cloud platform fault analysis.

[0065] Specifically, the data standardization module includes a data acquisition plugin, a high-performance message queue, a data processing module, and a data storage module. It is primarily used for the acquisition and standardization of heterogeneous service link data. When new link data is generated, the data acquisition plugin uploads the data to the central high-performance message queue in real time. The data processing module polls the message queue, performs standardization processing on the heterogeneous service link data, and then re-stores the processed data to the storage module. This achieves the fusion of heterogeneous service link data.

[0066] For newly connected services, if they need to be included in the link analysis system, they only need to send the data to the data access module. The data access module uses a filter-style approach to determine whether the service to be connected is legitimate and whether the data is trace data. If both conditions are met, the data is sent to the central message queue. The purpose of this data filtering is to ensure system stability and prevent unauthorized services from frequently sending data to the system, thus avoiding performance and storage pressure on the system's message queue, standardization module, and storage module.

[0067] Optionally, the heterogeneous link data is standardized, including: extracting key features from the heterogeneous link data and unifying the data structure type; and unifying the format of the tracking identifier and span identifier in the heterogeneous link data.

[0068] In this embodiment, the inconsistent Trace data generated by different link tracing systems leads to a lack of uniformity in link data across different services. The most significant issue is the inconsistency in the algorithms used to generate the unique link identifier (TraceID) and the range identifier (SpanID). For example, Service A's TraceID might be a 32-bit string, while Service B's TraceID is only 16 bits. It's difficult to unify the traces of the same request from different services, and their data structures also differ. This embodiment addresses this by customizing a unified data structure and standardizing algorithms to achieve the fusion of heterogeneous data.

[0069] Specifically, the most important data fields are abstracted and encapsulated, while other details are removed. Then, through a standardized algorithm, the link data is unified, enabling a consistent front-end display and allowing links between different services to communicate with each other. The steps are as follows: Figure 4 As shown, it includes:

[0070] S401 parses trace data from different service source links.

[0071] S402 extracts key fields including original TraceID, original SpanID, ServiceName, dataTime, request duration, and lineage.

[0072] S403 uses the MD5 digital signature algorithm to generate a unified TraceID and SpanID while retaining the original TraceID and SpanID.

[0073] S404, fill in the lineage relationship. In the lineage relationship, the key is the unified TraceID and SpanID, and the value is the original TraceID and SpanID.

[0074] By uniformly converting the TraceId and SpanId of different services into 32-bit (or other uniform bit length) strings while retaining the original values, fault backtracking can be performed in the respective service tracing systems if needed. Additionally, the lineage relationships in the Span data, i.e., the dependencies between services / methods, need to be extracted.

[0075] In summary, the cloud platform service monitoring method proposed in this embodiment provides a low-intrusion, highly scalable performance observation method. First, the link tracking points are standardized and moved to the core dependency library. Then, the OSProfiler tracking point implementation method is reconstructed using a mainstream link observation framework to achieve real-time observation of OpenStack service links. Building upon the existing OSProfiler monitoring framework's ability to monitor key modules of the OpenStack service link, the tracking point location is moved to the core dependency library, thus increasing the scope of tracking point impact without affecting the original framework. Furthermore, the OSProfiler monitoring framework is reconstructed by replacing the native implementation. The reconstructed data link tracing is more standardized, ensuring that link data conforms to industry standards and improving the comprehensiveness and scalability of link data. Compared to directly adopting other cloud platform service monitoring solutions, OSProfiler has better compatibility with OpenStack, with key tracking point locations being close together, resulting in less invasiveness and less likelihood of impacting system stability. This solves the problem that current OpenStack cloud platform service monitoring methods can affect system stability when using other monitoring solutions.

[0076] Furthermore, it addresses the issue of inconsistent observation of link data from different service sources. By employing a heterogeneous link data standardization algorithm, it resolves the problems of associating, storing, and displaying link data from different services on the cloud platform, enabling real-time interconnected display of all service links on the cloud platform, thereby solving the difficulty of cloud platform fault analysis.

[0077] Furthermore, as Figures 1 to 4 The specific implementation of the method shown in this embodiment provides a cloud platform service monitoring device, such as... Figure 5 As shown, the device includes: a data embedding unit 51, a processing unit 52, a reconstruction unit 53, and a monitoring unit 54.

[0078] The instrumentation unit 51 is configured to perform instrumentation based on the preset locations of the OSProfiler monitoring framework in each service link of OpenStack.

[0079] Processing unit 52 is configured to perform normalization processing on the link embedding points at the preset location, so that the link embedding points are set in the core dependency library;

[0080] Reconstruction unit 53 is configured to replace the native implementation of the OSProfiler monitoring framework and reconstruct the OSProfiler monitoring framework;

[0081] Monitoring unit 54 is configured to monitor the reconstructed OpenStack service links.

[0082] In specific application scenarios, the event tracking unit 51 is specifically configured to track events in the following ways: HTTP request entry process; database access tracking process; remote procedure call protocol access tracking process; external service call tracking process; and thread execution tracking process.

[0083] In specific application scenarios, the processing unit 52 is further configured to determine the process function corresponding to the service link where the preset location is located; based on the process function, the link embedding point of the preset location is moved up to the core dependency library corresponding to the process function.

[0084] In specific application scenarios, the refactoring unit 53 is further configured to replace the native implementation of the OSProfiler monitoring framework with a tracing information library and a tracing programming interface.

[0085] In specific application scenarios, the processing unit 52 is further configured to process link data from different service sources through the data standardization module.

[0086] In a specific application scenario, the processing unit 52 is further configured to collect the link data and upload it to a message queue when new link data is detected; poll the message queue to find heterogeneous link data generated by different service sources; perform standardization processing on the heterogeneous link data; and store the standardized link data after completing the standardization processing.

[0087] In specific application scenarios, the processing unit 52 is further configured to extract key features from the heterogeneous link data, unify the data structure type, and unify the format of the tracking identifier and span identifier in the heterogeneous link data.

[0088] It should be noted that other corresponding descriptions of the various functional units involved in the cloud platform service monitoring device provided in this embodiment can be found in [reference]. Figures 1 to 4 The corresponding description in [the document] will not be repeated here.

[0089] Based on the above, Figures 1 to 4 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figures 1 to 4 The method shown.

[0090] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0091] Based on the above, Figures 1 to 4 The method shown, and Figure 5 To achieve the above objectives, this application also provides an electronic device, which can be configured on a computer side, etc. The device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-described objectives. Figures 1 to 4 The method shown.

[0092] Based on the above, Figures 1 to 4 The method shown, and Figure 5 To achieve the above objectives, the present application also provides a chip in the illustrated virtual device embodiment, including one or more interface circuits and one or more processors; the interface circuits are used to receive signals from the memory of an electronic device and send the signals to the processors, the signals including computer instructions stored in the memory; when the processor executes the computer instructions, it causes the electronic device to perform the above-described... Figures 1 to 4 The method shown.

[0093] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0094] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0095] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0096] Through the above description of the implementation methods, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented using hardware. By applying the scheme of this embodiment, firstly, according to the OSProfiler monitoring framework, preset locations in each OpenStack service link are marked with data points. Then, the data points for each preset location are standardized, moving the data points to the core dependency library. Next, the native implementation of the OSProfiler monitoring framework is replaced, and the OSProfiler monitoring framework is reconstructed, allowing monitoring of the reconstructed OpenStack service links. Compared to related technologies, this application provides a low-intrusion, highly scalable performance observation method for the core cloud platform service OpenStack. Firstly, the link data points are standardized and moved to the core dependency library. Then, the mainstream link observation framework OSProfiler is used to reconstruct the data point implementation method, enabling real-time observation of OpenStack service links. The core idea of ​​this application is to leverage the existing OSProfiler monitoring framework's ability to monitor key modules of the OpenStack service chain by moving the data tracking points to the core dependency library. This expands the scope of data tracking without affecting the original framework. Furthermore, the OSProfiler monitoring framework is reconstructed by replacing the native implementation. The reconstructed data chain tracing is more standardized, ensuring that the chain data conforms to industry standards and improving the comprehensiveness and scalability of the chain data. Compared to directly adopting other cloud platform service monitoring solutions, OSProfiler has better compatibility with OpenStack, and the key data tracking points are located close to each other, thus having less invasiveness and less likelihood of affecting system stability.

[0097] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0098] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A cloud platform service monitoring method, characterized in that, include: Implement monitoring points according to the preset locations of the OSProfiler monitoring framework in each service link of OpenStack; The link tracking points at the preset locations are standardized so that they are set in the core dependency library. Replace the native implementation of the OSProfiler monitoring framework and reconstruct the OSProfiler monitoring framework; The refactored OSProfiler monitoring framework is used to monitor the OpenStack service chain. The standardization process for the link tracking points at the preset locations, ensuring that the link tracking points are set in the core dependency library, includes: Determine the process function corresponding to the service link where the preset location is located; Based on the process function, the link embedding points at the preset positions are moved to the core dependency library corresponding to the process function; Replace the native implementation of the OSProfiler monitoring framework, including: The native implementation of the OSProfiler monitoring framework is replaced with a tracing information database and a tracing programming interface.

2. The method according to claim 1, characterized in that, The step of installing monitoring points according to the preset locations of the OSProfiler monitoring framework in each service link of OpenStack includes: Implement event tracking for the HTTP request entry point process; Implement data tracking points for the database access process; Implement event tracking for remote procedure call protocol access tracing; Implement event tracking for external service call processes; Implement event tracking for thread execution.

3. The method according to any one of claims 1 to 2, characterized in that, The method further includes: The data standardization module processes link data from different service sources.

4. The method according to claim 3, characterized in that, The data standardization module processes link data from different service sources, including: When new link data is detected, the link data is collected and uploaded to the message queue; The message queue is polled to find heterogeneous link data generated by different service sources; The heterogeneous link data is standardized. After the standardization process is completed, the standardized link data is stored.

5. The method according to claim 4, characterized in that, The standardization process for the heterogeneous link data includes: Key features are extracted from the heterogeneous link data, and the data structure type is unified; The formats of the tracking identifier and span identifier in the heterogeneous link data are standardized.

6. A cloud platform service monitoring device, characterized in that, include: The instrumentation unit is configured to perform instrumentation based on the preset locations of the OSProfiler monitoring framework in each service link of OpenStack. The processing unit is configured to perform normalization processing on the link embedding points at the preset location, so that the link embedding points are set in the core dependency library; The refactoring unit is configured to replace the native implementation of the OSProfiler monitoring framework and refactor the OSProfiler monitoring framework. The monitoring unit is configured to monitor the OpenStack service links using the refactored OSProfiler monitoring framework; The standardization process for the link tracking points at the preset locations, ensuring that the link tracking points are set in the core dependency library, includes: Determine the process function corresponding to the service link where the preset location is located; Based on the process function, the link embedding points at the preset positions are moved to the core dependency library corresponding to the process function; Replace the native implementation of the OSProfiler monitoring framework, including: The native implementation of the OSProfiler monitoring framework is replaced with a tracing information database and a tracing programming interface.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

8. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 5.

Images