Resource data query method and device, electronic equipment and storage medium

Abstract

The application provides a resource data query method and device, electronic equipment and storage medium. The method comprises the following steps: acquiring a plurality of binlog log data from a database of the OpenStack, and performing format processing on each binlog log data to obtain a plurality of to-be-screened log data; determining a resource identifier to be monitored based on a current deployment task; determining target log data to be monitored from the plurality of to-be-screened log data based on the resource identifier, and determining the target log data as resource data of the current deployment task, so as to determine the OpenStack resource state by acquiring the binlog log data in real time, and optimize the delay and state loss caused by periodically calling the API to query the resource state.

Description

Technical Field

[0001] This application relates to the field of resource query technology, and in particular to a resource data query method, apparatus, electronic device and storage medium. Background Technology

[0002] This section is intended to provide background or context for the embodiments of this application as set forth in the claims. The description herein is not intended to be a prior art simply because it is included in this section.

[0003] Kubernetes (k8s) and OpenStack are two commonly used systems for deploying applications on cloud platforms. Users can achieve specific business requirements through a common cloud platform scheduling system. For example, a software deployment task includes a container-based web service and a virtual machine-based MySQL database. The cloud platform scheduling system will deploy the container-based web service on k8s and the virtual machine-based MySQL database on OpenStack.

[0004] On Kubernetes, resource changes generate related resource events, allowing for accurate tracking of resource creation and runtime status. However, in OpenStack, resources such as virtual machine instance creation, floating IPs, and heat orchestration tasks lack corresponding event support. Querying the current status of OpenStack resources requires periodically calling OpenStack's API. However, this periodic API query method impacts the real-time performance of OpenStack resource status checks. Furthermore, while using a large number of threads to increase concurrency can improve real-time performance, it also increases system resource consumption, leading to resource waste. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a resource data query method, apparatus, electronic device and storage medium.

[0006] To achieve the above objectives, this application provides a resource data query method, which is applied to a container cloud platform system based on Kubernetes and OpenStack; the method includes:

[0007] Multiple binlog log data are obtained from the OpenStack database, and each binlog log data is formatted to obtain multiple log data to be filtered;

[0008] Determine the resource identifiers that need to be monitored based on the current deployment tasks;

[0009] Based on the resource identifier, the target log data to be monitored is determined from a plurality of log data to be filtered, and the target log data is determined as the resource data of the currently deployed task;

[0010] Based on the resource data of the currently deployed task, generate the OpenStack resource standard event;

[0011] The OpenStack resource standard events are pushed to the message middleware to control the event storage and query device of the container cloud platform system to retrieve the OpenStack resource standard events from the message middleware.

[0012] Based on the same inventive concept, an exemplary embodiment of this application also provides a resource data query device, which is applied to a container cloud platform system based on Kubernetes and OpenStack; the device includes:

[0013] The acquisition module retrieves multiple binlog log data from the OpenStack database and formats each binlog log data to obtain multiple log data to be filtered.

[0014] The module identifies the resource identifiers that need to be monitored based on the currently deployed tasks.

[0015] The filtering module determines the target log data to be monitored from multiple log data to be filtered based on the resource identifier, and identifies the target log data as the resource data of the currently deployed task.

[0016] The generation module generates the OpenStack resource standard events based on the resource data of the currently deployed task;

[0017] The query module pushes the OpenStack resource standard events to the message middleware to control the event storage and query device of the container cloud platform system to obtain the OpenStack resource standard events from the message middleware.

[0018] Based on the same inventive concept, an exemplary embodiment of this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the program to implement the resource data query method as described above.

[0019] Based on the same inventive concept, an exemplary embodiment of this application also provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the resource data query method described above.

[0020] As described above, the resource data query method, apparatus, electronic device, and storage medium provided in this application obtain multiple binlog log data from the OpenStack database, format each binlog log data to obtain multiple log data to be filtered; determine the resource identifier to be monitored based on the current deployment task; determine the target log data to be monitored from the multiple log data to be filtered based on the resource identifier, and determine the target log data as the resource data of the current deployment task. This allows for the determination of OpenStack resource status by obtaining binlog log data in real time, optimizing the latency and status loss caused by periodically calling the API to query resource status. Simultaneously, determining the resource identifier to be monitored through the current deployment task and filtering the multiple log data to be filtered based on the resource identifier makes the obtained log data more targeted, improving event generation efficiency and resource utilization. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of a container cloud platform system architecture based on Kubernetes and OpenStack, according to an embodiment of this application.

[0023] Figure 2 This is a flowchart illustrating a resource data query method according to an embodiment of this application;

[0024] Figure 3 This is a flowchart illustrating another resource data query method according to an embodiment of this application;

[0025] Figure 4 This is a schematic diagram of the structure of a resource data query device according to an embodiment of this application;

[0026] Figure 5 This is a schematic diagram of the structure of a specific electronic device according to an embodiment of this application. Detailed Implementation

[0027] The principles and spirit of this application will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are provided merely to enable those skilled in the art to better understand and implement this application, and are not intended to limit the scope of this application in any way. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0028] According to embodiments of this application, a resource data query method, system, electronic device, and storage medium are proposed.

[0029] In this article, it is important to understand that any number of elements in the accompanying figures is for illustrative purposes and not for limitation, and any naming is for distinction only and has no limiting meaning.

[0030] The principles and spirit of this application will be explained in detail below with reference to several representative embodiments. Invention Overview

[0032] Currently in OpenStack, there are no corresponding event supports for resources such as creating virtual machine instances, floating IPs, and heat orchestration tasks. To query the current status of OpenStack resources, it's necessary to periodically call the OpenStack API. However, this periodic API query method impacts the real-time performance of OpenStack resource status checks. Furthermore, while using a large number of threads to increase concurrency can improve real-time performance, it also increases system resource consumption, leading to resource waste. In addition, as deployment tasks increase, the differences in calling methods and real-time performance between Kubernetes and OpenStack resource status checks increase the complexity of resource status checks, affecting their accuracy and ultimately hindering resource management on the cloud platform.

[0033] To address the aforementioned problems, this application provides a resource data query method, specifically including:

[0034] Multiple binlog data points are retrieved from the OpenStack database, and each binlog data point is formatted to obtain multiple log data points to be filtered. Based on the current deployment task, resource identifiers that need to be monitored are determined. Based on these resource identifiers, target log data to be monitored is selected from the multiple log data points to be filtered, and this target log data is designated as the resource data of the current deployment task. This approach, by retrieving binlog data in real time and formatting it, determines the resource status of OpenStack, optimizing the latency and missing status caused by periodically calling APIs to query resource status. Simultaneously, by determining the resource identifiers to be monitored based on the current deployment task and filtering the multiple log data points based on these identifiers, the obtained log data becomes more targeted, improving event generation efficiency and resource utilization.

[0035] After introducing the basic principles of this application, the various non-limiting embodiments of this application will be described in detail below.

[0036] Application Scenarios Overview

[0037] In specific application scenarios, the resource data query method of this application can be applied to various container cloud platform systems based on Kubernetes and OpenStack. (Reference) Figure 1 This is a schematic diagram of a container cloud platform system architecture based on Kubernetes and OpenStack in an embodiment of this application. After receiving the target task, the business server will send the target task to the scheduling engine. The scheduling engine will determine the scheduling task of resources based on factors such as different users, different resource requirements, and different priorities. For example, a model training task will be distributed to Kubernetes, corresponding to deployment, pods, and service resources; for example, a game client packaging business will be distributed to OpenStack, corresponding to virtual hosts and floating IPs.

[0038] The resource data query method according to exemplary embodiments of this application will be described below with reference to specific application scenarios. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way. Rather, the embodiments of this application can be applied to any applicable scenario.

[0039] Exemplary methods

[0040] refer to Figure 2This application provides a resource data query method, which is applied to a container cloud platform system based on Kubernetes and OpenStack; the method includes the following steps:

[0041] S101: Obtain multiple binlog log data from the OpenStack database, and format each binlog log data to obtain multiple log data to be filtered.

[0042] In practical implementation, Kubernetes (k8s) is an open-source virtual container management system for managing multiple hosts on a cloud platform. OpenStack is an open-source virtual machine management platform that can easily provide virtual machine resources to tenants. In container cloud platform systems based on Kubernetes and OpenStack, it is often necessary to query the resource status of Kubernetes and OpenStack. However, current related technologies can only query OpenStack resource data through the API interface provided by OpenStack. The OpenStack resource data that can be queried through the API is limited, often missing some important resource status changes. At the same time, the method of periodically querying the API will affect the real-time performance of resource status checks. Considering these shortcomings, the inventors of this application propose a method to obtain OpenStack resource data without using the API. Research has shown that the binlog logs in the OpenStack database record the data change requests received by the database. The database generally uses it for database abnormal state recovery and data backup. For example, if the database restarts at time B and some data is lost, the database can be restored to state B based on a backup at time A plus the binlog logs from A to B. Based on this, the inventors of this application conceived of using the binlog log as the raw data of OpenStack resource data, that is, first obtaining binlog log data from the OpenStack database. Optionally, a binlog capture device can be set up in the OpenStack database to obtain the binlog log of database changes in real time.

[0043] It's important to note that since binlog logs are binary files that primarily record SQL statements that update or potentially update database data, directly obtained binlog log data cannot be used directly. Each binlog log entry needs to be formatted. Optionally, you can choose from existing methods for formatting binlog log data. For example, the `show binlogevents` command can display event information in the log as a list, or you can directly use MySQL's built-in binlog parsing tool, `mysqlbinlog`, to format the binlog log data. Alternatively, you can parse different binlog data based on different binlog types (query events, insert events, creation events, deletion events, etc.) and represent the formatted binlog log data (i.e., the log data to be filtered) using JSON format.

[0044] S102, determine the resource identifiers that need to be monitored based on the currently deployed tasks.

[0045] In practice, to improve the efficiency of determining OpenStack resource data and avoid acquiring too much useless resource data, after obtaining multiple log data to be filtered, the resource identifiers that need to be monitored are first determined based on the current deployment task. For example, if the current deployment task is to create an OpenStack instance resource with the instance name A, then the corresponding resource identifier means that the log data to be filtered (formatted binlog data) with the table name "instance", column name "instance_name", and value "A" and operation code "create" is the log data to be filtered.

[0046] S103, based on the resource identifier, determine the target log data to be monitored from the multiple log data to be filtered, and determine the target log data as the resource data of the currently deployed task.

[0047] In practice, after determining the resource identifier corresponding to the current deployment task, the target log data to be monitored can be determined from multiple log data to be filtered based on the resource identifier, and the target log data can be determined as the resource data of the current deployment task.

[0048] S104, Based on the resource data of the currently deployed task, generate the OpenStack resource standard event.

[0049] In practice, after identifying the target log data as the resource data of the currently deployed task, the resource data of the currently deployed task is converted into OpenStack resource standard events to facilitate user querying. Optionally, the specific format of the OpenStack resource standard event can be set as needed and is not limited thereto.

[0050] In some embodiments, generating the OpenStack resource standard event based on the resource data of the currently deployed task specifically includes:

[0051] Based on a preset format, the resource data of the currently deployed task is converted into OpenStack resource standard events;

[0052] The OpenStack resource standard events include: event type, event occurrence time, event associated resource identifier, and event description fields.

[0053] In practice, to enable users to quickly obtain the information they want when querying OpenStack resource data, the target log data can be converted according to a preset format to obtain the OpenStack resource standard events. The specific preset format can be set as needed and is not limited thereto. Generally, the OpenStack resource standard events may include: event type, event occurrence time, event associated resource identifier, and event description field.

[0054] S105, push the OpenStack resource standard events to the message middleware to control the event storage and query device of the container cloud platform system to obtain the OpenStack resource standard events from the message middleware.

[0055] In specific implementation, after converting the resource data of the current deployment task into the resource standard event of OpenStack, it is necessary to store the resource standard event of OpenStack for subsequent use and query. At this time, considering that after the container cloud platform system obtains the resource standard event of OpenStack, it can immediately send out the resource standard event in a timely manner to save the cache space of the system. The resource standard event of OpenStack can be pushed to the message middleware. The message middleware is a middleware for establishing channels and sending data or files in a system that requires network communication. Optionally, after pushing the resource standard event of OpenStack to the message middleware, the resource standard event of OpenStack saved in the system cache can be cleared. At this time, the resource standard event of OpenStack is saved in the message middleware, and the event storage and query device can actively pull the resource standard event of OpenStack from the message middleware and save it in the storage medium of the event storage and query device. Optionally, the timing for the event storage and query device to actively pull the resource standard event of OpenStack from the message middleware can be set as needed. For example, after pushing the resource standard event of OpenStack to the message middleware, the event storage and query device can be immediately controlled to obtain the resource standard event of OpenStack from the message middleware. It can also control the event storage and query device to obtain the resource standard event of OpenStack from the message middleware according to a preset frequency. It should be noted that the event storage and query device can be a part or a module of the container cloud platform system based on Kubernetes and OpenStack.

[0056] In some embodiments, determining the resource identifier to be monitored based on the current deployment task specifically includes:

[0057] Obtain the current deployment task;

[0058] Determine the resource identifier to be monitored corresponding to the current deployment task from the preset resource identifier list.

[0059] In specific implementation, to improve the efficiency of determining the resource identifier, a preset resource identifier list can be set in advance. The identifier list includes various deployment tasks and the resource identifiers to be monitored corresponding to each deployment task.

[0060] In practical implementation, after converting the resource data of the currently deployed task into OpenStack resource standard events, these events need to be stored for subsequent use and retrieval. Considering that the container cloud platform system can immediately send out the OpenStack resource standard events upon receiving them to save system cache space, the OpenStack resource standard events can be pushed to a message middleware. This message middleware is used by systems requiring network communication to establish channels and send data or files. Optionally, after pushing the OpenStack resource standard events to the message middleware, the OpenStack resource standard events stored in the system cache can be cleared. At this point, the OpenStack resource standard events are stored in the message middleware, and the event storage and retrieval device can actively retrieve the OpenStack resource standard events from the message middleware and store them in the storage medium of the event storage and retrieval device. Optionally, the timing at which the event storage and query device actively pulls the OpenStack resource standard event from the message middleware can be configured as needed. For example, after the OpenStack resource standard event is pushed to the message middleware, the event storage and query device can be immediately controlled to retrieve the OpenStack resource standard event from the message middleware. Alternatively, the event storage and query device can be controlled to retrieve the OpenStack resource standard event from the message middleware at a preset frequency. It should be noted that the event storage and query device can be part of or a module of a container cloud platform system based on Kubernetes and OpenStack.

[0061] In some embodiments, after converting the resource data of the currently deployed task into OpenStack resource standard events, the method further includes:

[0062] The unified event web interface provided by the event storage and query device of the container cloud platform system is invoked to send the OpenStack resource standard event to the event storage and query device, so that the event storage and query device can obtain the OpenStack resource standard event.

[0063] In practice, after the resource data of the currently deployed task is converted into the OpenStack resource standard event, in order to ensure that the event storage and query device of the container cloud platform system can receive the OpenStack resource standard event in real time, the OpenStack resource standard event can be sent to the event storage and query device by calling the unified event web interface provided by the event storage and query device of the container cloud platform system, so that the event storage and query device can obtain the OpenStack resource standard event.

[0064] In some embodiments, after the event storage query device obtains the OpenStack resource standard event, the method further includes:

[0065] The resource events of the Kubernetes can be obtained by accessing the Kubernetes API server;

[0066] The Kubernetes resource events are stored in the event storage query device.

[0067] In practical implementation, to facilitate the subsequent use of a unified event query logic to obtain detailed status of deployed resources and reduce the complexity of container cloud platform systems based on Kubernetes and OpenStack, after storing the standard OpenStack resource events in the event storage and query device, the Kubernetes resource events are further obtained by accessing the Kubernetes API server, and then stored in the event storage and query device. This API server provides HTTP REST interfaces for adding, deleting, modifying, querying, and monitoring various Kubernetes resource objects (pods, RCs, Events, etc.), and serves as the data bus and data center for the entire Kubernetes system. Accessing the Kubernetes API server allows access to the Kubernetes resource events.

[0068] In some embodiments, after storing the Kubernetes resource events in the event storage query device, the method further includes:

[0069] The event storage and query device unifies the storage format of Kubernetes resource events and OpenStack standard resource events.

[0070] In specific implementation, the storage format of Kubernetes resource events and OpenStack standard resource events is unified in the event storage and query device, so that users can query Kubernetes resource events and OpenStack standard resource events simultaneously using a single format.

[0071] In some embodiments, after storing the Kubernetes resource events in the event storage query device, the method further includes:

[0072] Configure a query interface for the event storage query device to query resource events of Kubernetes and standard resource events of OpenStack, and set query conditions in the query interface:

[0073] The query conditions include queries based on deployment environment, queries based on resource type, and queries based on resource identifier.

[0074] In practice, to further facilitate users in querying resource status, the query conditions for the event storage query device are set according to the deployment environment, resource type, resource identifier, etc., so that users can quickly find the corresponding resource status when they input the deployment environment and other conditions of the current deployment task.

[0075] refer to Figure 3 This is a flowchart illustrating another resource data query method according to an embodiment of this application. In this method, users of container cloud platform systems based on Kubernetes and OpenStack submit resource tasks to Kubernetes and OpenStack respectively. Upon receiving a resource task, Kubernetes sends the corresponding Kubernetes resource event to the event storage and query device via the API server. Upon receiving a resource task, OpenStack retrieves binlog data from its database, formats the retrieved binlog data, determines the resource identifier corresponding to the queried resource based on the user-submitted resource task, filters the formatted binlog data according to the resource identifier, encapsulates the filtered binlog data into a standard event, and finally sends the standard event to the event storage and query device. When a user sends a query for a resource event to the event storage and query device, the event storage and query device returns either a Kubernetes resource event or the corresponding OpenStack standard event to the user.

[0076] The resource data query method provided in this application retrieves multiple binlog log data from the OpenStack database and formats each binlog log data to obtain multiple log data to be filtered. Based on the current deployment task, a resource identifier to be monitored is determined. Based on the resource identifier, the target log data to be monitored is determined from the multiple log data to be filtered, and the target log data is identified as the resource data of the current deployment task. This method determines the OpenStack resource status by retrieving binlog log data in real time and formatting it, thus optimizing the latency and status loss caused by periodically calling the API to query resource status. Simultaneously, by determining the resource identifier to be monitored through the current deployment task and filtering the multiple log data to be filtered based on this resource identifier, the obtained log data becomes more targeted, improving event generation efficiency and resource utilization.

[0077] Exemplary device

[0078] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a resource data query device, which is applied to a container cloud platform system based on Kubernetes and OpenStack.

[0079] refer to Figure 4 The resource data query device includes:

[0080] The acquisition module 201 acquires multiple binlog log data from the OpenStack database and formats each binlog log data to obtain multiple log data to be filtered.

[0081] Module 202 determines the resource identifiers that need to be monitored based on the currently deployed tasks;

[0082] The filtering module 203 determines the target log data to be monitored from multiple log data to be filtered based on the resource identifier, and determines the target log data as the resource data of the currently deployed task;

[0083] The generation module 204 generates the OpenStack resource standard events based on the resource data of the currently deployed task;

[0084] The query module 205 pushes the OpenStack resource standard events to the message middleware to control the event storage and query device of the container cloud platform system to obtain the OpenStack resource standard events from the message middleware.

[0085] In some embodiments, the determining module is specifically configured as follows:

[0086] Get the currently deployed tasks;

[0087] The resource identifiers that need to be monitored for the currently deployed task are determined from the list of preset resource identifiers.

[0088] In some embodiments, the generation module is specifically configured as follows:

[0089] Based on a preset format, the resource data of the currently deployed task is converted into OpenStack resource standard events;

[0090] The OpenStack resource standard events include: event type, event occurrence time, event associated resource identifier, and event description fields.

[0091] In some embodiments, the apparatus further includes an interface module configured to:

[0092] The unified event web interface provided by the event storage and query device of the container cloud platform system is invoked to send the OpenStack resource standard event to the event storage and query device, so that the event storage and query device can obtain the OpenStack resource standard event.

[0093] In some embodiments, the apparatus further includes a storage module configured to:

[0094] The resource events of the Kubernetes can be obtained by accessing the Kubernetes API server;

[0095] The Kubernetes resource events are stored in the event storage query device.

[0096] In some embodiments, the apparatus further includes:

[0097] The event storage and query device unifies the storage format of Kubernetes resource events and OpenStack standard resource events.

[0098] In some embodiments, the apparatus further includes:

[0099] Configure a query interface for the event storage query device to query resource events of Kubernetes and standard resource events of OpenStack, and set query conditions in the query interface:

[0100] The query conditions include queries based on deployment environment, queries based on resource type, and queries based on resource identifier.

[0101] For ease of description, the above system is described by dividing it into various modules based on their functions. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0102] The system described above is used to implement the corresponding resource data query method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0103] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the resource data query method described in any of the above embodiments.

[0104] Figure 5 This embodiment illustrates a more specific hardware structure of an electronic device, which may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0105] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0106] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0107] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0108] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0109] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0110] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0111] The electronic devices described above are used to implement the corresponding resource data query methods in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0112] Exemplary program product

[0113] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the resource data query method as described in any of the above embodiments.

[0114] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0115] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute a resource data query method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0116] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in the details for the sake of brevity.

[0117] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0118] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0119] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A method for querying resource data, characterized in that, The method is applied to container cloud platform systems based on Kubernetes and OpenStack; the method includes: Multiple binlog log data are obtained from the OpenStack database, and each binlog log data is formatted to obtain multiple log data to be filtered; Determine the resource identifiers that need to be monitored based on the current deployment tasks; Based on the resource identifier, the target log data to be monitored is determined from a plurality of log data to be filtered, and the target log data is determined as the resource data of the currently deployed task; Based on the resource data of the currently deployed task, generate the OpenStack resource standard event; The OpenStack resource standard events are pushed to the message middleware to control the event storage and query device of the container cloud platform system to obtain the OpenStack resource standard events from the message middleware. This includes identifying the resource identifiers that need to be monitored based on the current deployment tasks, specifically including: Get the currently deployed tasks; Determine the resource identifier that needs to be monitored corresponding to the currently deployed task from the preset resource identifier list; Based on the resource data of the currently deployed task, generate the OpenStack resource standard event, specifically including: Based on a preset format, the resource data of the currently deployed task is converted into OpenStack resource standard events; The OpenStack resource standard events include: event type, event occurrence time, event associated resource identifier, and event description fields.

2. The method according to claim 1, characterized in that, After converting the resource data of the currently deployed task into OpenStack resource standard events, the method further includes: The unified event web interface provided by the event storage and query device of the container cloud platform system is invoked to send the OpenStack resource standard event to the event storage and query device, so that the event storage and query device can obtain the OpenStack resource standard event.

3. The method according to claim 1, characterized in that, After the event storage query device obtains the OpenStack resource standard event, the method further includes: The resource events of the Kubernetes can be obtained by accessing the Kubernetes API server; The Kubernetes resource events are stored in the event storage query device.

4. The method according to claim 3, characterized in that, After storing the Kubernetes resource events in the event storage query device, the method further includes: The event storage and query device unifies the storage format of Kubernetes resource events and OpenStack standard resource events.

5. The method according to claim 4, characterized in that, After storing the Kubernetes resource events in the event storage query device, the method further includes: Configure a query interface for the event storage query device to query resource events of Kubernetes and standard resource events of OpenStack, and set query conditions in the query interface: The query conditions include queries based on deployment environment, queries based on resource type, and queries based on resource identifier.

6. A resource data query device, characterized in that, The device is used in a container cloud platform system based on Kubernetes and OpenStack; the device includes: The acquisition module retrieves multiple binlog log data from the OpenStack database and formats each binlog log data to obtain multiple log data to be filtered. The module identifies the resource identifiers that need to be monitored based on the currently deployed tasks. The filtering module determines the target log data to be monitored from multiple log data to be filtered based on the resource identifier, and identifies the target log data as the resource data of the currently deployed task. The generation module generates the OpenStack resource standard events based on the resource data of the currently deployed task; The query module pushes the OpenStack resource standard events to the message middleware to control the event storage query device of the container cloud platform system to obtain the OpenStack resource standard events from the message middleware. Specifically, the determining module is configured to obtain the currently deployed task; and determine the resource identifier that needs to be monitored corresponding to the currently deployed task from a preset resource identifier list. The generation module is specifically configured to convert the resource data of the currently deployed task into OpenStack resource standard events based on a preset format; wherein, the OpenStack resource standard events include: event type, event occurrence time, event associated resource identifier, and event description field.

7. An electronic device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor, when executing the program, implements the method as described in any one of claims 1 to 5.

8. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing a computer to perform the method according to any one of claims 1 to 5.

Images