A scene-based cloud component configuration recommendation method and system

Abstract

The application discloses a cloud-based scene component configuration recommendation method and system, equipment and medium, the generation method comprises the following steps: obtaining the running index data of an HBase instance; according to the running index data, determine the business type information corresponding to the HBase instance; according to the business type information, obtain the application scene parameter template corresponding to the HBase instance; based on the business type information and the application scene parameter template, generate the configuration information. The application can automatically generate and push the optimized configuration according to the real-time application scene, solve the related pain points in the prior art, meet the jvm parameter, database read-write scene parameter, system-level cluster configuration, HBase dependent component performance and other multi-application scene optimization and recommended configuration sharing, reduce the requirement of users on component knowledge, and reduce the operation and maintenance cost of large-scale distributed components.

Description

Technical Field

[0001] This invention relates to the field of network information technology, and in particular to a scenario-based cloud component configuration recommendation method, system, device, and medium. Background Technology

[0002] For HBase (Distributed Open Database) components that are already online, performance tuning will continue throughout the system's lifecycle. To achieve optimal read and write performance, optimization of four parameters is necessary: ​​component machine resource utilization efficiency, operating system parameters, HBase dependent services, and JVM (Java Virtual Machine) memory usage for each service. However, in current technologies, HBase components often fail to obtain appropriate configurations promptly after deployment. Reasons include: First, HBase relies on multiple services such as ZooKeeper and HDFS, and their parameter configurations are interdependent and affect performance. Adjustments to these configurations impact both table and region levels, requiring a high level of knowledge from users for component maintenance. Second, management cannot arbitrarily change instance parameter configurations without user consent, and continuous parameter tuning significantly increases maintenance manpower and time costs. More importantly, distributed big data components heavily rely on configuration changes brought about by real-time monitoring. Failure to promptly modify monitoring metrics can drastically reduce read and write performance, potentially causing production issues. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to overcome the above-mentioned defects in the prior art and provide a scenario-based cloud component configuration recommendation method, system, device and medium.

[0004] The present invention solves the above-mentioned technical problems through the following technical solution:

[0005] This invention provides a scenario-based cloud component configuration recommendation method, comprising the following steps:

[0006] Obtain runtime metrics data for the HBase instance;

[0007] Based on the operational metric data, determine the business type information corresponding to the HBase instance;

[0008] Based on the business type information, obtain the application scenario parameter template corresponding to the HBase instance;

[0009] The configuration information is generated based on the business type information and the application scenario parameter template.

[0010] Preferably, the operational metrics data includes at least one type of operational metrics from the hardware level, JDK level, and table level.

[0011] Preferably, the step of obtaining the operational metric data of the HBase instance includes:

[0012] Determine the target acquisition indicators based on the performance indicators of external input;

[0013] Based on the target collection indicators, the corresponding operational indicator data are obtained from the storage service.

[0014] Preferably, after the step of generating the configuration information, the method further includes:

[0015] Obtain the external modification parameters corresponding to the configuration information;

[0016] Generate an application scenario parameter template corresponding to the externally modified parameters;

[0017] The application scenario parameter template is broadcast.

[0018] This invention also provides a scenario-based cloud component configuration recommendation system, including:

[0019] The metrics data acquisition module is used to acquire the runtime metrics data of the HBase instance;

[0020] The business type determination module is used to determine the business type information corresponding to the HBase instance based on the operation indicator data;

[0021] The parameter template acquisition module is used to acquire the application scenario parameter template corresponding to the HBase instance based on the business type information.

[0022] The configuration information generation module is used to generate the configuration information based on the business type information and the application scenario parameter template.

[0023] Preferably, the operational metrics data includes at least one type of operational metrics from the hardware level, JDK level, and table level.

[0024] Preferably, the indicator data acquisition module includes:

[0025] The indicator determination unit is used to determine the target acquisition indicators based on the performance indicators input from external sources.

[0026] The data acquisition unit is used to acquire corresponding operational indicator data from the storage service based on the target acquisition indicators.

[0027] Preferably, the generation system further includes:

[0028] The parameter acquisition module is used to acquire external modification parameters corresponding to the configuration information;

[0029] The scene template generation module is used to generate an application scene parameter template corresponding to the externally modified parameters;

[0030] The scenario template sending module is used to broadcast the application scenario parameter template.

[0031] The present invention 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 computer program to implement the above-described scenario-based cloud component configuration recommendation method.

[0032] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described scenario-based cloud component configuration recommendation method.

[0033] The positive and progressive effects of this invention are as follows: By providing a scenario-based cloud component configuration recommendation method, system, device, and medium, this invention achieves automatic generation and push of optimized configurations based on real-time application scenarios, solving the aforementioned pain points in the prior art. While meeting the requirements for multi-application scenario optimization and recommended configuration sharing, such as JVM parameters, database read / write scenario parameters, system-level cluster configuration, and HBase dependent component performance, this invention also reduces the user's knowledge requirements for components and alleviates the operation and maintenance costs of large-scale distributed components. Attached Figure Description

[0034] Figure 1 This is a flowchart of the scenario-based cloud component configuration recommendation method according to Embodiment 1 of the present invention;

[0035] Figure 2 Configure a recommended system topology diagram for read / write scenarios of cloud HBase components;

[0036] Figure 3 Recommended system architecture diagram for cloud HBase component read / write scenarios;

[0037] Figure 4 Recommended flowchart for configuring read / write scenarios of cloud HBase components;

[0038] Figure 5 A module diagram of the scenario-based cloud component configuration recommendation system of Embodiment 2 of the present invention;

[0039] Figure 6 This is a structural block diagram of the electronic product according to Embodiment 3 of the present invention. Detailed Implementation

[0040] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0041] The scenario-based cloud component configuration recommendation method provided in this embodiment can be executed in smart terminals, computer terminals, network devices, chips, chip modules, or similar computing devices. The reference to "embodiment" in this application means that a specific feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. Those skilled in the art will explicitly and implicitly understand that the embodiments described in this application can be combined with other embodiments.

[0042] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0043] As indicated in this specification, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of expressly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0044] Example 1

[0045] See Figure 1 As shown, this embodiment specifically provides a scenario-based cloud component configuration recommendation method, including the following steps:

[0046] S1. Obtain the runtime metrics data of the HBase instance;

[0047] S2. Based on the operational metrics data, determine the business type information corresponding to the HBase instance;

[0048] S3. Based on the business type information, obtain the application scenario parameter template corresponding to the HBase instance;

[0049] S4. Generate configuration information based on business type information and application scenario parameter templates.

[0050] Specifically, the configuration information generation method in this embodiment is implemented from the console to the instance side based on four parts: a rule input and configuration display module (display), a rule engine (rule-engine), a metric collection engine (collector), and an analysis engine (analysis-engine). The rule input and configuration display module sends display metrics and parameter templates to the rule engine via a socket interface. The rule engine, as the central hub, is connected to the analysis engine along with the collection engine. The collection engine periodically collects metrics from the HBase region service via the JMX interface. The specific implementation methods of each module are as follows:

[0051] 1. Rule Input and Configuration Display Module

[0052] The core of this section lies in the console where rules are input and configurations are displayed. The rule input module is available on both the management and tenant consoles. This module allows tenants or administrators to select the performance metrics to be displayed and parameter templates for different scenarios, sending them to the rule engine in the instance-side agent. The display module, located on the tenant console, receives the analysis engine's judgment results, reads the recommended configuration for the corresponding scenario from the database, and displays it. Furthermore, recommended parameters can be shared among tenants. The tenant console can upload instance throughput and adjusted configuration parameters for its application scenario. The management console receives and filters the uploaded parameters. Recommended parameters are sent to each tenant console page via message notifications for tenants to browse and reference; additionally, administrators can add excellent shared parameters as new templates, enriching the application scenario configuration set.

[0053] 2. A rule engine with customizable scene configurations

[0054] The rules engine is the central hub connecting the data collection engine and the analysis engine, responsible for forwarding functions. It resides in the client (agent) service on the HBase instance side. After administrators input data into the console, performance metrics and scenario-based judgment rules are sent to the rules engine. The rules engine analyzes the performance metric formulas to calculate the necessary monitoring data and forwards it to the monitoring device, i.e., the data collection engine. For example, to calculate the read / write request ratio of a Region service in HBase, it needs to obtain the cumulative read / write request count over a certain period from the data collection engine; similarly, since MemStore and BlockCache objects in HBase have a long lifespan in JVM memory, analyzing CMS GC performance requires obtaining GC time. The rules engine then sends the metric values ​​returned by the monitoring device to the analysis engine. Recommended parameter templates for different application scenarios are also stored and managed by the rules engine.

[0055] 3. Monitoring device for automatically collecting performance indicators

[0056] The performance metric collection device will be deployed on the HBase component instance machine, using TSDB, ambari-LogSearch, and ambari-metrics as storage services. By default, the monitoring device will periodically collect and push relevant performance metrics such as JVM-related metrics, HBase table throughput, RegionServer request count, and WAL file size of the HBase instance to the storage service. After inputting the desired performance metrics through the console, the rule input module will push the names of the metrics required for performance metric calculation to the monitoring device. The monitoring device will then retrieve the values ​​from the storage service and push them to the rule engine.

[0057] 4. Multi-level classification analysis engine

[0058] The most crucial module within the analytics engine is the read / write request ratio calculation module. This module periodically retrieves instance runtime metrics from the rules engine. By analyzing recent read / write rates and memory usage, it determines the instance's business scenario type (e.g., disk capacity sensitive, bandwidth sensitive, etc.), then extracts the corresponding scenario parameter template from the rules engine and sends it along with the business type determination results to the display module. Additionally, the analytics engine performs monitoring metric analysis at the system hardware, HBase table, and region levels. At the system hardware level, it collects metrics on system I / O, CPU, network bandwidth, and memory using Linux tools. At the JDK level, it tracks the usage and proportion of the three generations of objects in the JVM. At the table level, it calculates the periodic read / write ratio by counting table read / write requests. At the region level, it focuses on the number of CRUD operations on the RegionServer, WAL growth rate, memory usage, etc. This layer-by-layer analysis improves the accuracy of scenario judgment from multiple dimensions, making recommended parameters more targeted.

[0059] Figure 2 and Figure 3 The diagrams show the topology and architecture of the cloud HBase component read / write scenario configuration recommendation system. The flowchart for the cloud HBase component read / write scenario configuration recommendation process is as follows. Figure 4 As shown. Specifically, it may include the following steps:

[0060] Step 1: Input various application scenario parameter templates into the operations and maintenance console, and input the metrics to be displayed into the tenant console, and send them to the rule engine.

[0061] Step 2: The rule engine receives the parameter template and display metrics, saves the template in the database, converts the display metrics into monitoring metric fields according to the pre-entered formulas, and sends them to the monitoring device.

[0062] Step 3: The monitoring device is responsible for periodically accessing the JMX interfaces of dependent services such as HBase. After receiving the metric fields, it sends the metric values ​​within the period back to the rule engine, which then forwards them to the analysis engine.

[0063] Step 4: The analysis engine receives the monitoring metrics and performs analysis at the operating system level, JDK level, table level, and region level, respectively, and pushes the scenario judgment results to the console.

[0064] Step 5: Users receive a notification about the scenario assessment in the console. After clicking, they can open the configuration and see the recommended values. After visually modifying the parameters, the current metric values ​​and configurations can be pushed to the operations and maintenance side. After administrators verify the feasibility of sharing these parameters, they can include them as new parameter templates and share them with all users via broadcast.

[0065] This technical solution can be used in PaaS cloud components, including but not limited to HBase, such as HDFS, Hive, Spark, etc. It can not only analyze the overall system caused by the machine resources of the components, but also be extended to the analysis of instance alarm monitoring indicators on the management side.

[0066] In a preferred embodiment, step S1 includes:

[0067] The target acquisition metrics are determined based on externally input performance metrics; based on the target acquisition metrics, the corresponding operational metric data is obtained from the storage service. Preferably, the operational metric data includes at least one type of operational metric from the hardware level, JDK level, and table level.

[0068] In a preferred implementation, step S4 is followed by: obtaining external modification parameters corresponding to the configuration information; generating an application scenario parameter template corresponding to the external modification parameters; and broadcasting the application scenario parameter template.

[0069] Preferably, the above Figure 4The illustrated process can be used to illustrate the feasibility of implementing a multi-level indicator analysis and configuration recommendation engine system in multiple application scenarios: After a tenant places an order to activate an HBase instance on the client-side console, the client agent is deployed on the instance side. The agent contains a rule engine, a monitoring engine, and an analysis engine. The monitoring engine periodically collects all preset monitoring indicators from the instance machine. The indicators can be divided into operating system level, JDK level, table level, and cluster level according to the business scope. Operating system level indicators include IO, CPU, network bandwidth, and system memory usage. JDK level indicators include the usage and percentage of three generations of objects in the JVM. Table level indicators include WAL read / write count statistics, table read / write count, and changes in the number of table regions within a period. Cluster level indicators include changes in the size of the RegionServer's storefile, changes in the total memstore, and read cache hit rate. All of these are recorded in storage services such as TSDB, PostgreSQL, and Solr.

[0070] While HBase-agent pushes storage metrics to the monitoring metric collection module, its rule engine analyzes the performance metric formulas to extract the necessary monitoring data. For example, to calculate the read / write request ratio of a RegionServer within a unit of time, the rule engine analyzes the metric formula and sends a request to the monitoring module: using JMX to retrieve the readRequestCount and writeRequestCount of the RegionServer within a specific time interval from the HBase interface.

[0071] The Agent's analytics engine calculates and judges metrics at various levels: At the operating system level, it focuses on IO, CPU, and memory usage. For example, when memory usage is high, the analytics engine will determine whether the machine has enabled disk caching and appropriately reduce the minimum amount of memory reserved by the system. At the JDK level, it focuses on analyzing the time spent in the GC process. If the number of GC cycles is too low, it indicates that the time for a single garbage collection is long, which will affect the read and write latency of HBase. The analytics engine will then suggest adjusting the threshold for GC memory usage. At the table level, for a request ratio of 10:1 for 15 consecutive days, it generates table read and write scenarios: read-heavy, write-light, and read-write balanced. At the cluster level, the number of CRUD requests for RegionServers is categorized as read and write requests, and then the read and write request ratio is calculated.

[0072] Finally, HBase-agent sends the multi-level scenario judgment results to the console interface. After receiving the scenario judgment results, the console pushes the corresponding scenario-recommended configuration experience values ​​from the MySQL database to the front end for display. After viewing the relevant information in the message list, users can click to enter the recommended (table or region) configuration parameter visualization interface, modify them, and restart to make the configuration take effect. After users have carefully modified the parameters, they can upload local instance read / write metrics and configurations to the operations and maintenance community with one click. After the administrator collects the uploaded configurations and verifies them by simulating scenarios, the reliable configuration is shared with each user through message notification, and the application scenarios in the parameter template library are updated in a timely manner.

[0073] This embodiment provides a configuration information generation method based on HBase application scenarios. It achieves automatic generation and push of optimized configurations according to real-time application scenarios, solving the aforementioned pain points in existing technologies. While meeting the optimization and recommended configuration sharing requirements for multiple application scenarios, including JVM parameters, database read / write scenario parameters, system-level cluster configuration, and HBase dependent component performance, it reduces the user's knowledge requirements for components and alleviates the operational costs of large-scale distributed components. Its advantages include the following:

[0074] 1. The management side only needs to input parameter templates for various application scenarios, and the scenario analysis is handled by the instance client, which reduces operation and maintenance costs and the skill requirements of support personnel;

[0075] 2. The operational metrics of services such as HDFS and ZooKeeper are managed uniformly by the data collection engine. The recommended configuration involves the operating system, JVM and multiple dependent services from bottom to top, and multi-level classification analysis is performed for HBase.

[0076] 3. Scene judgments and recommended values ​​are pushed to the console in real time via message notifications, allowing users to receive timely reminders of scene changes and reference configurations.

[0077] Example 2

[0078] Corresponding to the scenario-based cloud component configuration recommendation method described above, this embodiment also provides a scenario-based cloud component configuration recommendation system. These will be described in detail below. It should be noted that the scenario-based cloud component configuration recommendation system in this embodiment can be, for example, a standalone chip, chip module, or electronic device, or a chip or chip module integrated within an electronic device. Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, each module / unit can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, each module / unit can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0079] Specifically, such as Figure 5 As shown, the scenario-based cloud component configuration recommendation system of this embodiment includes:

[0080] Metric data acquisition module 1 is used to acquire the runtime metric data of the HBase instance;

[0081] Module 2, which determines the business type information corresponding to the HBase instance, is used to determine the business type information based on the operation indicator data.

[0082] Parameter template acquisition module 3 is used to obtain the application scenario parameter template corresponding to the HBase instance based on the business type information;

[0083] Configuration information generation module 4 is used to generate configuration information based on business type information and application scenario parameter templates.

[0084] In a preferred implementation, the indicator data acquisition module 1 includes:

[0085] The indicator determination unit is used to determine the target acquisition indicators based on the performance indicators input from external sources.

[0086] The data acquisition unit is used to acquire corresponding operational indicator data from the storage service based on the target collection indicators.

[0087] Preferably, the operational metrics data include at least one type of operational metrics from the hardware level, JDK level, and table level.

[0088] As a preferred implementation, the generation system further includes:

[0089] The parameter acquisition module is used to acquire external modification parameters corresponding to the configuration information;

[0090] The scene template generation module is used to generate application scene parameter templates that correspond to externally modified parameters;

[0091] The scenario template sending module is used to broadcast application scenario parameter templates.

[0092] This technical solution can be used in PaaS cloud components, including but not limited to HBase, such as HDFS, Hive, Spark, etc. It can not only analyze the overall system caused by the machine resources of the components, but also be extended to the analysis of instance alarm monitoring indicators on the management side.

[0093] After a tenant places an order to activate an HBase instance through the tenant-side console, the client agent will be deployed on the instance side. The agent includes a rules engine, a monitoring engine, and an analytics engine. The monitoring engine will periodically collect all preset monitoring metrics from the instance machine. Metrics can be divided into operating system level, JDK level, table level, and cluster level according to the business scope. Operating system level metrics include IO, CPU, network bandwidth, and system memory usage. JDK level metrics include the usage and percentage of three generations of objects in the JVM. Table level metrics include WAL read / write counts, table read / write counts, and changes in the number of table regions within a period. Cluster level metrics include changes in the size of the RegionServer's storefile, changes in the total memstore, and read cache hit rate. All of these are recorded in storage services such as TSDB, PostgreSQL, and Solr.

[0094] While HBase-agent pushes storage metrics to the monitoring metric collection module, its rule engine analyzes the performance metric formulas to extract the necessary monitoring data. For example, to calculate the read / write request ratio of a RegionServer within a unit of time, the rule engine analyzes the metric formula and sends a request to the monitoring module: using JMX to retrieve the readRequestCount and writeRequestCount of the RegionServer within a specific time interval from the HBase interface.

[0095] The Agent's analytics engine calculates and judges metrics at various levels: At the operating system level, it focuses on IO, CPU, and memory usage. For example, when memory usage is high, the analytics engine will determine whether the machine has enabled disk caching and appropriately reduce the minimum amount of memory reserved by the system. At the JDK level, it focuses on analyzing the time spent in the GC process. If the number of GC cycles is too low, it indicates that the time for a single garbage collection is long, which will affect the read and write latency of HBase. The analytics engine will then suggest adjusting the threshold for GC memory usage. At the table level, for a request ratio of 10:1 for 15 consecutive days, it generates table read and write scenarios: read-heavy, write-light, and read-write balanced. At the cluster level, the number of CRUD requests for RegionServers is categorized as read and write requests, and then the read and write request ratio is calculated.

[0096] Finally, HBase-agent sends the multi-level scenario judgment results to the console interface. After receiving the scenario judgment results, the console pushes the corresponding scenario-recommended configuration experience values ​​from the MySQL database to the front end for display. After viewing the relevant information in the message list, users can click to enter the recommended (table or region) configuration parameter visualization interface, modify them, and restart to make the configuration take effect. After users have carefully modified the parameters, they can upload local instance read / write metrics and configurations to the operations and maintenance community with one click. After the administrator collects the uploaded configurations and verifies them by simulating scenarios, the reliable configuration is shared with each user through message notification, and the application scenarios in the parameter template library are updated in a timely manner.

[0097] This embodiment provides a configuration information generation system based on HBase application scenarios. It automatically generates and pushes optimized configurations according to real-time application scenarios, addressing the aforementioned pain points in existing technologies. While meeting the needs for multi-application scenario optimization and recommended configuration sharing, including JVM parameters, database read / write scenario parameters, system-level cluster configuration, and HBase dependent component performance, it reduces the user's knowledge requirements for components and alleviates the operational costs of large-scale distributed components. Specifically, it includes the following:

[0098] 1. Four-Tier Engine Architecture of the Scene Configuration Recommendation System. The recommendation system consists of three parts on the instance side: rule input and display engine, collection engine, rule engine, and analysis engine. The rule input and display engine is responsible for inputting and displaying metrics and can share recommendation configurations. The collection engine collects monitoring metrics periodically according to metric rules and stores them in storage services such as Solr, HBase, and TSDB on the instance side. The rule engine receives metric collection rules and scene judgment rules from the console and pushes them to the analysis engine and collection engine respectively, serving as the central hub of the recommendation system. The analysis engine, based on the judgment rules, performs conversion calculations on the collected metrics, such as read / write ratio, memory usage, and file storage space variation, and periodically sends the scene judgment results to the tenant console, making it an important component of the recommendation system.

[0099] 2. Supports tenants uploading custom optimal parameters, and allows tenants to share configurations for multiple scenarios. Tenants can upload the metric values ​​and corresponding configurations of their own scenario instances through the console. The management console receives these, and operations personnel collect and filter them, then send excellent parameter tuning solutions to all tenant consoles via message notifications for reference. This configuration sharing scheme not only enriches the parameter set for real-world application scenarios but also enhances the activity level of the component's operations community, ensuring continuous positive user feedback on component usage.

[0100] 3. A multi-level metric analysis engine targeting machine systems, JDKs, Regions, and tables. At the system hardware level, it collects metrics on system I / O, CPU, network bandwidth, and memory using Linux tools. At the JDK level, it tracks the usage and proportion of objects across three generations in the JVM. At the table level, the analysis engine focuses on the number of table read / write requests, changes in the number of table regions, and changes in table index size. At the cluster level, the analysis engine focuses on the number of CRUD operations in RegionServers, WAL growth rate, memory usage, and many other metrics. This multi-level segmentation and analysis of monitoring data allows for more comprehensive and diverse recommended configuration parameters.

[0101] 4. Diversity of metrics rules for the data collection engine across multiple application scenarios. Currently, the configuration recommendation system applied to cloud HBase components only has an implementation plan for read / write scenarios. In the future, it can collect and optimize parameters such as JVM performance, database read / write scenario parameters, system-level cluster configuration, and HBase dependent component performance for multiple application scenarios to improve the overall performance of instance machine resources.

[0102] Example 3

[0103] Figure 6This is a schematic diagram of the structure of an electronic device provided in this embodiment. The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the scenario-based cloud component configuration recommendation method in the above embodiment. Figure 6 The electronic device 30 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0104] like Figure 6 As shown, the electronic device 30 can be manifested as a general-purpose computing device, such as a server device. The components of the electronic device 30 may include, but are not limited to: at least one processor 31, at least one memory 32, and a bus 33 connecting different system components (including memory 32 and processor 31).

[0105] Bus 33 includes a data bus, an address bus, and a control bus.

[0106] The memory 32 may include volatile memory, such as random access memory (RAM) 321 and / or cache memory 322, and may further include read-only memory (ROM) 323.

[0107] The memory 32 may also include a program / utility 325 having a set (at least one) of program modules 324, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0108] The processor 31 executes various functional applications and data processing by running computer programs stored in the memory 32, such as the scenario-based cloud component configuration recommendation method described above.

[0109] Electronic device 30 can also communicate with one or more external devices 34 (e.g., keyboard, pointing device, etc.). This communication can be performed via input / output (I / O) interface 35. Furthermore, the model-generating device 30 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 36. Figure 6 As shown, network adapter 36 communicates with other modules of the model-generated device 30 via bus 33. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the model-generated device 30, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (disk array) systems, tape drives, and data backup storage systems.

[0110] It should be noted that although several units / modules or sub-units / modules of the electronic device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0111] Example 4

[0112] This embodiment also provides a computer-readable storage medium storing a computer program thereon. When the program is executed by a processor, it implements the steps in the scenario-based cloud component configuration recommendation method of the above embodiments. The readable storage medium may specifically include, but is not limited to, portable disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0113] In a possible implementation, the present invention can also be implemented as a program product comprising program code. When the program product is run on a terminal device, the program code causes the terminal device to perform the steps in the scenario-based cloud component configuration recommendation method described above. The program code for executing the present invention can be written in any combination of one or more programming languages. The program code can be executed entirely on the user device, partially on the user device, as a standalone software package, partially on the user device and partially on a remote device, or entirely on a remote device.

[0114] While specific embodiments of the present invention have been described above, those skilled in the art should understand that these are merely illustrative examples, and the scope of protection of the present invention is defined by the appended claims. Those skilled in the art can make various changes or modifications to these embodiments without departing from the principles and essence of the present invention, but all such changes and modifications fall within the scope of protection of the present invention.

Claims

1. A scenario-based cloud component configuration recommendation method, characterized in that, Includes the following steps: Obtain runtime metrics data for the HBase instance; Based on the operational metric data, determine the business type information corresponding to the HBase instance; Based on the business type information, obtain the application scenario parameter template corresponding to the HBase instance; Based on the business type information and the application scenario parameter template, configuration information is generated; The generated configuration information specifically includes: Step 1: Input various application scenario parameter templates into the operations and maintenance console, and input the metrics to be displayed into the tenant console, and send them to the rule engine; Step 2: The rule engine receives the parameter template and display metrics, saves the template in the database, converts the display metrics into monitoring metric fields according to the pre-entered formulas, and sends them to the monitoring device. Step 3: The monitoring device periodically collects the metric values ​​of the HBase instance and pushes them to the storage service. After receiving the metric fields, the monitoring device retrieves the metric values ​​for the period from the storage service and sends them back to the rule engine, which then forwards them to the analysis engine. Step 4: The analysis engine receives the metric values ​​and performs analysis at the operating system level, JDK level, table level, and region level, respectively, and pushes the scenario judgment results to the console. Step 5: After receiving the scenario judgment result, the console pushes the corresponding scenario recommended configuration experience value from the database to the front end for display.

2. The scenario-based cloud component configuration recommendation method as described in claim 1, characterized in that, The operational metrics data include at least one type of operational metrics from the hardware level, JDK level, and table level.

3. The scenario-based cloud component configuration recommendation method as described in claim 1, characterized in that, The steps for obtaining the runtime metric data of the HBase instance include: Determine the target acquisition indicators based on the performance indicators of external input; Based on the target collection indicators, the corresponding operational indicator data are obtained from the storage service.

4. The scenario-based cloud component configuration recommendation method as described in claim 1, characterized in that, The step of generating the configuration information also includes: Obtain the external modification parameters corresponding to the configuration information; Generate an application scenario parameter template corresponding to the externally modified parameters; The application scenario parameter template is broadcast.

5. A scenario-based cloud component configuration recommendation system, characterized in that, include: The metrics data acquisition module is used to acquire the runtime metrics data of the HBase instance; The business type determination module is used to determine the business type information corresponding to the HBase instance based on the operation indicator data; The parameter template acquisition module is used to acquire the application scenario parameter template corresponding to the HBase instance based on the business type information. The configuration information generation module is used to generate configuration information based on the business type information and the application scenario parameter template; The generated configuration information specifically includes: Step 1: Input various application scenario parameter templates into the operations and maintenance console, and input the metrics to be displayed into the tenant console, and send them to the rule engine; Step 2: The rule engine receives the parameter template and display metrics, saves the template in the database, converts the display metrics into monitoring metric fields according to the pre-entered formulas, and sends them to the monitoring device. Step 3: The monitoring device periodically collects the metric values ​​of the HBase instance and pushes them to the storage service. After receiving the metric fields, the monitoring device retrieves the metric values ​​for the period from the storage service and sends them back to the rule engine, which then forwards them to the analysis engine. Step 4: The analysis engine receives the metric values ​​and performs analysis at the operating system level, JDK level, table level, and region level, respectively, and pushes the scenario judgment results to the console. Step 5: After receiving the scenario judgment result, the console pushes the corresponding scenario recommended configuration experience value from the database to the front end for display.

6. The scenario-based cloud component configuration recommendation system as described in claim 5, characterized in that, The operational metrics data include at least one type of operational metrics from the hardware level, JDK level, and table level.

7. The scenario-based cloud component configuration recommendation system as described in claim 5, characterized in that, The indicator data acquisition module includes: The indicator determination unit is used to determine the target acquisition indicators based on the performance indicators input from external sources. The data acquisition unit is used to acquire corresponding operational indicator data from the storage service based on the target acquisition indicators.

8. The scenario-based cloud component configuration recommendation system as described in claim 5, characterized in that, Also includes: The parameter acquisition module is used to acquire external modification parameters corresponding to the configuration information; The scene template generation module is used to generate an application scene parameter template corresponding to the externally modified parameters; The scenario template sending module is used to broadcast the application scenario parameter template.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes a computer program, it implements the scenario-based cloud component configuration recommendation method as described in any one of claims 1-4.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the scenario-based cloud component configuration recommendation method as described in any one of claims 1-4.

Images