Microservice health monitoring method, device, electronic device and storage medium

Abstract

The present invention provides a method, device, electronic device and storage medium for monitoring the health of a microservice, and relates to the field of microservice technology. The method includes: after detecting a monitoring instruction triggered by a user, determining at least one dependent component to be monitored of a target microservice; for any dependent component to be monitored, monitoring multiple indicators characterizing the operation status of any dependent component to be monitored through a monitoring strategy corresponding to any dependent component to be monitored, and determining the health value of any dependent component to be monitored based on the sum of the health values corresponding to each indicator of any dependent component to be monitored; determining the health value of the target microservice based on the health value of each dependent component to be monitored and the weight corresponding to each dependent component to be monitored. The embodiment of the present invention can determine the health value of a microservice through the health value and corresponding weight of each component, thus providing a way to evaluate the health of a microservice.

Description

Technical Field

[0001] The present invention relates to the field of microservice technology, and in particular to a method, device, electronic device, and storage medium for monitoring the health of a microservice. Background Art

[0002] Currently, the operation of microservices depends on multiple SAAS (Software-as-a-Service) layer service components, such as the MySQL relational database management system and the Redis remote dictionary service. The stable operation of microservices is inseparable from the healthy operation of these components.

[0003] Most existing monitoring systems directly monitor the various components of the SAAS layer. Through the monitoring system, you can see the detailed indicator data of different components, and each detailed indicator data can be set with different display formats and alarm rules. However, these are all based on SAAS layer monitoring, which makes it impossible to obtain the overall situation of microservices. Summary of the Invention

[0004] The present invention provides a microservice health monitoring method, device, electronic device and storage medium, which can determine the health value of the microservice by determining the health value of at least one dependent component to be monitored of the target microservice and the health value of each component and the corresponding weight, thus providing a way to evaluate the health of the microservice.

[0005] In a first aspect, an embodiment of the present invention provides a method for monitoring the health of a microservice, including:

[0006] After detecting a user-triggered monitoring instruction, determining at least one dependent component to be monitored of the target microservice; wherein the dependent component to be monitored is a component of a SAAS layer service that affects the operation of the target microservice;

[0007] For any dependent component to be monitored, multiple indicators representing the operating status of any dependent component to be monitored are monitored through the monitoring strategy corresponding to the any dependent component to be monitored, and the health value of the any dependent component to be monitored is determined based on the sum of the health values corresponding to each indicator of the any dependent component to be monitored; wherein the health value corresponding to the indicator represents the degree of influence of the indicator on the normal operation of the dependent component to be monitored;

[0008] The health value of the target microservice is determined based on the health value of each dependent component to be monitored and the weight corresponding to each dependent component to be monitored.

[0009] The above method can provide a method for evaluating the health of microservices. Specifically, it determines at least one dependent component to be monitored of the target microservice, and determines the health value of each dependent component to be monitored based on the sum of the health values of the indicators corresponding to each dependent component to be monitored. Then, the health value of the target microservice is determined by the health value of each dependent component to be monitored and the corresponding weight. In this way, health evaluation can be performed from the perspective of microservices.

[0010] In one possible implementation, after detecting a user-triggered monitoring instruction, determining at least one dependent component of a target microservice to be monitored includes:

[0011] After detecting a user-triggered monitoring instruction, a selection interface is displayed; wherein the selection interface includes multiple components of the SAAS layer service that affect the operation of the target microservice;

[0012] In response to a selection instruction triggered by the user in the selection interface, the component selected by the selection instruction is used as the dependent component to be monitored.

[0013] The above method can provide a component selection method through user selection instructions, thereby improving the user experience.

[0014] In one possible implementation, the health value corresponding to each indicator of the dependent component to be monitored is determined in the following manner:

[0015] For each indicator of the dependent component to be monitored, if the indicator meets the preset condition corresponding to the indicator, determine the health value corresponding to the indicator as a first preset value; wherein the first preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored meets the preset condition corresponding to each indicator;

[0016] If the indicator does not meet the preset conditions corresponding to the indicator, the health value corresponding to the indicator is determined to be the target value; wherein the target value is the ratio of the second preset value to the total number of indicators of the dependent component to be monitored; the second preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored does not meet the preset conditions corresponding to each indicator.

[0017] The above method determines whether the indicator meets the preset conditions corresponding to the indicator and assigns different values as health values, thereby obtaining different degrees of impact, so that the degree of impact is quantified, making it clear at a glance and improving the user experience.

[0018] In one possible implementation, the weights corresponding to the dependent components to be monitored are determined in the following manner:

[0019] Method 1: Using a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein the first read and write counts is the total number of occurrences of the code representing the read function and the write function in the code that implements the dependent component to be monitored; or

[0020] Method 2: Using a second ratio between the second read and write times of the dependent component to be monitored and the sum of the second read and write times of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein, the second read and write times is the total number of times the read and write functions are executed during the operation of the dependent component to be monitored within a preset time period; or

[0021] Method three: Determine a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice, and a second ratio between the second read and write counts of the dependent component to be monitored and the sum of the second read and write counts of all dependent components to be monitored of the target microservice;

[0022] The weight corresponding to each dependent component to be monitored is determined based on the first ratio and the coefficient corresponding to the first ratio, and the second ratio and the coefficient corresponding to the second ratio; wherein the coefficient corresponding to method two is determined based on the running time of each dependent component to be monitored during operation, and the coefficient corresponding to method one is the difference between the coefficient corresponding to method two and the threshold.

[0023] The above method determines the weights statically or dynamically, or determines the weights statically and dynamically, and obtains the health value of the microservice by weighting the health value of each dependent component to be monitored, which makes it closer to the actual health level of the microservice and improves the accuracy.

[0024] In one possible implementation, wherein:

[0025] If the dependent component to be monitored is a MySQL relational database management system, the indicators corresponding to the dependent component to be monitored are part or all of the MySQL startup status, the size of the read buffer in MySQL, the usage of MySQL, and the number of open files in MySQL;

[0026] If the dependent component to be monitored is a component that implements the Redis remote dictionary service, the indicators corresponding to the dependent component to be monitored are part or all of the startup status of the component that implements the Redis remote dictionary service, the master node in the cluster of the component that implements the Redis remote dictionary service, the backup status of the component that implements the Redis remote dictionary service, and the memory size of the component that implements the Redis remote dictionary service;

[0027] If the dependent component to be monitored is a MongoDB database based on distributed file storage, the indicators corresponding to the dependent component to be monitored are part or all of the MongoDB startup status, the delay time of the MongoDB replication delay function, the number of connected systems in MongoDB, and the memory size of MongoDB.

[0028] The above method can determine the health value of microservices through the MySQL relational database management system, the component that implements the Redis remote dictionary service, and the MongoDB database based on distributed file storage. These components serve as the cornerstones of operations such as data storage, message transmission, and file operations, making the evaluated health value more accurate.

[0029] In one possible implementation, after determining the health value of the target microservice based on the health value of each dependent component to be monitored and the weight corresponding to each dependent component to be monitored, the method further includes:

[0030] Based on the correspondence between health ranges and display colors, determine the display color corresponding to the health range to which the health value of each dependent component to be monitored belongs, as well as the display color corresponding to the health range to which the health value of the target microservice belongs;

[0031] A display image is constructed according to the display color corresponding to the health range to which the health value of each dependent component to be monitored belongs, and the display color corresponding to the health range to which the health value of the target microservice belongs, and the display image is displayed.

[0032] The above method can express the different health levels of microservices to users through colors, thereby improving the user experience.

[0033] In a second aspect, an embodiment of the present invention provides a device for monitoring the health of a microserver, comprising:

[0034] A determination module is configured to determine, after detecting a user-triggered monitoring instruction, at least one dependent component of a target microservice to be monitored; wherein the dependent component to be monitored is a component of a SaaS layer service that affects the operation of the target microservice;

[0035] The monitoring module is used to monitor multiple indicators representing the operation status of any dependent component to be monitored through the monitoring strategy corresponding to the any dependent component to be monitored, and determine the health value of any dependent component to be monitored based on the sum of the health values corresponding to each indicator of the any dependent component to be monitored; wherein the health value corresponding to the indicator represents the degree of influence of the indicator on the normal operation of the dependent component to be monitored; and determine the health value of the target microservice based on the health value of each dependent component to be monitored and the weight corresponding to each dependent component to be monitored.

[0036] In one possible implementation, the monitoring module is specifically configured to:

[0037] Method 1: Using a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein the first read and write counts is the total number of occurrences of the code representing the read function and the write function in the code that implements the dependent component to be monitored; or

[0038] Method 2: Using a second ratio between the second read and write times of the dependent component to be monitored and the sum of the second read and write times of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein, the second read and write times is the total number of times the read and write functions are executed during the operation of the dependent component to be monitored within a preset time period; or

[0039] Method three: Determine a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice, and a second ratio between the second read and write counts of the dependent component to be monitored and the sum of the second read and write counts of all dependent components to be monitored of the target microservice;

[0040] The weight corresponding to each dependent component to be monitored is determined based on the first ratio and the coefficient corresponding to the first ratio, and the second ratio and the coefficient corresponding to the second ratio; wherein the coefficient corresponding to method two is determined based on the running time of each dependent component to be monitored during operation, and the coefficient corresponding to method one is the difference between the coefficient corresponding to method two and the threshold.

[0041] In a third aspect, an embodiment of the present invention provides an electronic device, including:

[0042] processor;

[0043] a memory for storing instructions executable by the processor;

[0044] The processor is configured to execute the instructions to implement the microservice health monitoring method as described in any one of the first aspects.

[0045] In a fourth aspect, an embodiment of the present invention provides a storage medium. When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute the microservice health monitoring method as described in any one of the first aspects.

[0046] In addition, the technical effects brought about by any implementation method in the second to fourth aspects can refer to the technical effects brought about by different implementation methods in the first aspect, and will not be repeated here.

[0047] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 A flowchart of a method for monitoring microservice health provided by an embodiment of the present invention;

[0049] Figure 2 A schematic diagram showing the health values corresponding to the indicators of dependent components to be monitored provided by an embodiment of the present invention;

[0050] Figure 3 A schematic diagram showing the relationship between two methods for obtaining weights corresponding to dependent components to be monitored provided in an embodiment of the present invention;

[0051] Figure 4 A schematic diagram of the relationship between the coefficient of the ratio of a dependent component to be monitored and the running time provided in an embodiment of the present invention;

[0052] Figure 5 A schematic diagram showing the health value of a microservice provided by an embodiment of the present invention;

[0053] Figure 6 A schematic diagram of the structure of a microservice health monitoring device provided by an embodiment of the present invention;

[0054] Figure 7 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0055] To make the objectives, technical solutions, and advantages of the present invention more apparent, the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the embodiments described herein are merely some, rather than all, of the present invention. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without inventive effort are intended to fall within the scope of protection of the present invention.

[0056] Currently, the operation of microservices depends on service components at multiple SAAS layers. The stable operation of microservices is inseparable from the healthy operation of these components. However, during general monitoring, each SAAS component is monitored separately, resulting in the inability to know the health status of the entire microservice.

[0057] Based on this, the present invention proposes a method for evaluating the health of the entire microservice.

[0058] The following is a detailed description with reference to the accompanying drawings:

[0059] Combine Figure 1 As shown, an embodiment of the present invention provides a method for monitoring the health of a microservice, including:

[0060] S100: After detecting a monitoring instruction triggered by a user, determining at least one dependent component to be monitored of a target microservice; wherein the dependent component to be monitored is a component of a SaaS layer service that affects the operation of the target microservice;

[0061] Among them, the microservice system may include a user interface, and a "monitoring button" may be provided in the user interface. When the user clicks the "monitoring button", the user triggers the monitoring instruction.

[0062] Alternatively, there is a "monitoring button" on the electronic device, which is a physical button. When the user presses the "monitoring button", the user triggers the monitoring instruction.

[0063] Of course, the above description is only exemplary and cannot be used as a specific limitation of the present invention.

[0064] At least one dependent component to be monitored of the target microservice is determined in the following manner:

[0065] Set all SaaS layer service components that affect the operation of the target microservice as dependent components to be monitored; or

[0066] After detecting a user-triggered monitoring instruction, a selection interface is displayed; wherein the selection interface includes multiple components of the SAAS layer service that affect the operation of the target microservice;

[0067] In response to a selection instruction triggered by the user in the selection interface, the component selected by the selection instruction is used as the dependent component to be monitored.

[0068] Exemplarily, multiple components of the SAAS layer service that affect the operation of the target microservice include MySQL relational database management system, components that implement Redis remote dictionary service, components that implement RabbitMQ message queue, Kafka open source stream processing platform, FTP (File Transfer Protocol) server, s3 (Simple Storage Service), MongoDB distributed file storage-based database and other components. These components play the role of operational cornerstones for data storage, message delivery, file operations, etc. during the operation of the microservice, and these components can be selected as dependent components. The selection interface includes the above-mentioned multiple components, and the user selects a component on the selection interface and uses the selected component as the dependent component to be monitored. Of course, the user can select one or more, and the present invention does not limit this.

[0069] S3 is an Internet storage solution, which can be understood as software that provides storage services. This service is designed to make web-scale computing easier for developers. S3 provides a simple web service interface for storing and retrieving any amount of data at any time, anywhere on the web. This service gives all developers access to the same highly scalable, reliable, secure, fast, and affordable data storage infrastructure that Amazon uses to run its global network of websites. This service is designed to maximize economies of scale for developers.

[0070] S101: For any dependent component to be monitored, monitor multiple indicators representing the operation status of any dependent component to be monitored using the monitoring strategy corresponding to any dependent component to be monitored, and determine the health value of any dependent component to be monitored based on the sum of the health values corresponding to each indicator of any dependent component to be monitored; wherein the health value corresponding to the indicator represents the degree of influence of the indicator on the normal operation of the dependent component to be monitored;

[0071] Among them, the indicators of the dependent components to be monitored can reflect the operation status of certain microservices, such as the MySQL service. The indicators used in this article are read_buffer_size (MySQL read buffer size), slave_max_allowed_packet (the maximum size of the event that the SQL thread can read), max_used_connections (the current number of connections), max_connections (the maximum number of connections), innodb_num_open_files (the number of files opened simultaneously by the Iinnodb layer), and open_files_limit (the maximum number of files opened by the Iinnodb layer).

[0072] For example, if the dependent component to be monitored is a MySQL relational database management system, the indicators corresponding to the dependent component to be monitored are part or all of the MySQL startup status, the size of the read buffer in MySQL, the usage of MySQL, and the number of open files in MySQL;

[0073] If the dependent component to be monitored is a component that implements the Redis remote dictionary service, the corresponding indicators of the dependent component to be monitored are part or all of the following: the startup status of the component that implements the Redis remote dictionary service, the master node in the cluster of the component that implements the Redis remote dictionary service, the backup status of the component that implements the Redis remote dictionary service, and the memory size of the component that implements the Redis remote dictionary service;

[0074] If the dependent component to be monitored is MongoDB, a database based on distributed file storage, the corresponding indicators of the dependent component to be monitored are part or all of the MongoDB startup status, the delay time of the MongoDB replication delay function, the number of connected systems in MongoDB, and the memory size of MongoDB.

[0075] For example, when the dependent component to be monitored is the MySQL relational database management system, the health value of the MySQL relational database management system is determined based on the sum of the health value corresponding to the MySQL startup status, the health value corresponding to the size of the read buffer in MySQL, the health value corresponding to the MySQL usage, and the health value corresponding to the number of open files in MySQL;

[0076] When the dependent component to be monitored is a component that implements the Redis remote dictionary service, the health value of the component that implements the Redis remote dictionary service is determined based on the sum of the health value corresponding to the startup status of the component that implements the Redis remote dictionary service, the health value corresponding to the master node in the cluster of the component that implements the Redis remote dictionary service, the health value corresponding to the backup status of the component that implements the Redis remote dictionary service, and the health value corresponding to the memory size of the component that implements the Redis remote dictionary service.

[0077] When the dependent component to be monitored is a MongoDB database based on distributed file storage, the health value of MongoDB is determined based on the sum of the health value corresponding to the MongoDB startup status, the health value corresponding to the delay time of the MongoDB replication delay function, the health value corresponding to the number of connected systems in MongoDB, and the health value corresponding to the memory size of MongoDB.

[0078] Monitoring multiple metrics representing the operational status of any dependent component is accomplished through a metric monitor. This tool regularly collects static metrics from various SaaS services, storing them in a specific format. Alarm thresholds can be set for each static metric, and during metric collection, alarms are generated based on the thresholds. This functionality can be implemented independently or using open source software.

[0079] S102: Determine the health value of the target microservice according to the health value of each dependent component to be monitored and the weight corresponding to each dependent component to be monitored.

[0080] For example, if at least one dependent component to be monitored of the target microservice is MySQL, a component that implements the Redis remote dictionary service, and MongoDB, then the health value of the target microservice is determined based on the weights corresponding to MySQL and MySQL, the weights corresponding to the component that implements the Redis remote dictionary service and the component that implements the Redis remote dictionary service, and the weights corresponding to MongoDB and MongoDB.

[0081] In summary, the embodiment of the present invention determines the health value corresponding to the indicator of at least one dependent component to be monitored of the target microservice, and determines the health value of the dependent component to be monitored based on the sum of the health values corresponding to the indicators of each dependent component to be monitored. The health value of the entire microservice is determined based on the health values of all dependent components to be monitored of the target microservice and the weights corresponding to all dependent components to be monitored. This provides a health evaluation method for microservices, allowing users to understand the overall health of the microservices.

[0082] The health value corresponding to each indicator of the dependent component to be monitored is determined in the following way:

[0083] For each indicator of the dependent component to be monitored, if the indicator meets the preset condition corresponding to the indicator, then determine the health value corresponding to the indicator as a first preset value; wherein the first preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored meets the preset condition corresponding to each indicator;

[0084] If the indicator does not meet the preset conditions corresponding to the indicator, the health value corresponding to the indicator is determined to be the target value; wherein the target value is the ratio of the second preset value to the total number of indicators of the dependent component to be monitored; the second preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored does not meet the preset conditions corresponding to each indicator.

[0085] If the dependent component to be monitored is MySQL, the selected detailed indicators and the corresponding preset conditions for each indicator are:

[0086] E1.mysql_up == 0;

[0087] Meaning: "whether MySQL is started";

[0088] E2.mysql_global_variables_read_buffer_size>mysql_global_variables_slave_max_allowed_packet;

[0089] Meaning: "read buffer size is larger than maximum";

[0090] E3.mysql_global_status_max_used_connections>mysql_global_variables_max_connections*0.8;

[0091] Meaning: "More than 80% of the maximum connection limit was used";

[0092] E4.mysql_global_status_innodb_num_open_files>(mysql_global_variables_open_files_limit)*0.75;

[0093] Meaning: The number of open files is too high. It has reached 75% of the maximum value.

[0094] The dependent component to be monitored is the component that implements the Redis remote dictionary service. The selected detailed indicators and the preset conditions corresponding to each indicator are:

[0095] E1.redis_up = 0;

[0096] Meaning: "Is redis enabled?"

[0097] E2.(count(redis_instance_info{role="master"})or vector(0))<1;

[0098] Meaning: "The Redis cluster has no master node";

[0099] E3.time()-redis_rdb_last_save_timestamp_seconds>60*60*24;

[0100] Meaning: "Redis has not been backed up for 24 hours";

[0101] E4.redis_memory_used_bytes / redis_total_system_memory_bytes*100>90;

[0102] Significance: The Redis system is out of memory;

[0103] If the dependent component to be monitored is MongoDB, the selected detailed indicators and the corresponding preset conditions for each indicator are:

[0104] E1.mongodb_up == 0;

[0105] Meaning: "Whether MongoDB is enabled;

[0106] E2.mongodb_mongod_replset_member_optime_date{state="PRIMARY"}-ON(set)mongodb_mongod_replset_member_optime_date{state="SECONDARY"}>10;

[0107] Meaning: "MongoDB replication delay exceeds 10s";

[0108] E3.avg by(instance)(rate(mongodb_connections{state="current"}[1m])) / avg by(instance)(sum(mongodb_connections)by(instance))*100>80;

[0109] Significance: "Excessive connections (>80%)"

[0110] E4.(sum(mongodb_memory{type="virtual"})BY(instance) / sum(mongodb_memory{type="mapped"})BY(instance))>3;

[0111] Meaning: "High memory usage".

[0112] For example, the second preset value is 100, the first preset value is 0, and MySQL establishes 4 indicators. When an indicator does not meet the corresponding preset conditions, the score is -100 divided by 4, which is -25 points; when the indicator meets the corresponding preset conditions, the score is 0; when Redis has n indicators, when each indicator does not meet the corresponding preset conditions, the score is When the indicator meets the corresponding preset conditions, the score is 0.

[0113] The health value of the dependent component to be monitored is

[0114] Furthermore, each monitoring result of each dependent component to be monitored is recorded, and the fields recorded include "health value, which detailed indicator is deducted, which detailed indicator is not deducted, and the time point of monitoring.

[0115] Combine Figure 2 As shown in the figure, the central area represents the health value of the dependent component to be monitored and records the current time node. The remaining four sector areas respectively represent whether the four indicators of the dependent component to be monitored meet the preset conditions corresponding to the indicators. If the indicators meet the preset conditions corresponding to the indicators, the sector area will be green and will display words such as "normal" and "-0 points". If the indicators do not meet the preset conditions corresponding to the indicators, the sector area will be red and will display words such as "abnormal". Points" and other words.

[0116] The weights of the dependent components to be monitored are determined in the following ways:

[0117] Method 1: The first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice is used as the weight corresponding to the dependent component to be monitored; wherein the first read and write counts is the total number of occurrences of the code representing the read function and the write function in the code that implements the dependent component to be monitored; or

[0118] Method 2: The second ratio between the second read and write times of the dependent component to be monitored and the sum of the second read and write times of all dependent components to be monitored of the target microservice is used as the weight corresponding to the dependent component to be monitored; wherein the second read and write times is the total number of times the read and write functions are executed during the operation of the dependent component to be monitored within a preset time period; or

[0119] Method 3: Determine a first ratio between a first read / write count of the dependent component to be monitored and the sum of the first read / write counts of all dependent components to be monitored of the target microservice, and a second ratio between a second read / write count of the dependent component to be monitored and the sum of the second read / write counts of all dependent components to be monitored of the target microservice;

[0120] The weight corresponding to each dependent component to be monitored is determined based on the first ratio and the coefficient corresponding to the first ratio, the second ratio and the coefficient corresponding to the second ratio; wherein the coefficient corresponding to method two is determined based on the running time of each dependent component to be monitored during operation, and the coefficient corresponding to method one is the difference between the coefficient corresponding to method two and the threshold.

[0121] Specifically, the first method is to obtain the weight using a static method: statically count the call points (read functions or write functions) of each dependent component to be monitored in the entire code, and record the number of read functions and write functions of each dependent component to be monitored n i ,The total number N can be obtained by adding up the number of times each dependent component to be monitored.

[0122] The weight of each dependent component to be monitored is

[0123] The second method is to obtain the weight in a dynamic way: implement the read function and write function on the base class of each dependent component to be monitored to count, and take the sum of the number of times each dependent component to be monitored calls the read function and write function within a period of time as M, and the number of times each dependent component to be monitored calls the read function and write function separately as m i , then the weight of each dependent component to be monitored is

[0124] Furthermore, the method for obtaining the number of calls is:

[0125] For example, in a Django project, access to MySQL can be achieved through ORM methods using Python objects to read and write databases. Components that implement the Redis remote dictionary service can also achieve the same effect through Python's Redis library. The number of read and write functions can then be counted in the ORM's models base class. Each time a read or write function is executed on any model, a count +1 is added to a Count table. All models in the entire project inherit this models base class, so any read or write to the MySQL database in the project will accumulate this count. This way, the number of calls can be obtained in days or weeks. Other components such as Redis and RabbitMQ can also use similar methods to obtain the number of calls over a period of time.

[0126] Regarding method three: Based on experience, for a given metric, over time, dynamically acquired weights have an increasing influence on the metric's actual weight, while statically acquired weights have a decreasing influence. Therefore, the relationship between statically and dynamically acquired weights for a monitored dependency over time is shown in Figure 3.

[0127] Among them, combined Figure 3 As shown, the x-axis represents time T and the y-axis represents weight; the curve C1 represents the weight W 静 , curve C2 represents the authority W 动 ;

[0128] Assume that there is a coefficient k such that the weight corresponding to a single dependent component to be monitored satisfies the above relationship:

[0129] W i =kW 动 +(1-k)W 静

[0130] in

[0131] The relationship between time t and coefficient K is as follows Figure 4 shown.

[0132] Among them, combined Figure 4 As shown, the x-axis is time, the y-axis is the value of the k coefficient, 0<=k<=1, and curve C3 is a curve obtained by the functional relationship between the running time of the dependent component to be monitored and the coefficient corresponding to the dependent component to be monitored.

[0133] As can be seen from curve C3, as time goes by, the k value gradually tends to be stable, and the ratio of the weight obtained by static method and the weight obtained by dynamic method also tends to be stable. In this way, a ratio P that gradually tends to the real weight can be calculated. i .

[0134] The health value of the target microservice is calculated by multiplying the health value of each dependent component to be monitored by its respective weight, and then summing up the weighted dependent components to be monitored as the health value of the target microservice.

[0135] The formula for calculating the health value of the target microservice is:

[0136]

[0137] Among them, W i is the i-th dependent component to be monitored, W 动 W i The weight obtained dynamically, W 静 W i The weight obtained by static means, k is W 动 The corresponding coefficient.

[0138] After determining the health value of the target microservice based on the health value of each dependent component to be monitored and the weight corresponding to each dependent component to be monitored, the method further includes:

[0139] Based on the correspondence between health ranges and display colors, determine the display color corresponding to the health range to which the health value of each dependent component to be monitored belongs, as well as the display color corresponding to the health range to which the health value of the target microservice belongs;

[0140] A display image is constructed according to the display color corresponding to the health range to which the health value of each dependent component to be monitored belongs, and the display color corresponding to the health range to which the health value of the target microservice belongs, and the display image is displayed.

[0141] For example, the health value of a microservice and the health value of each dependent component to be monitored of the microservice are displayed. The thickness of the line connecting the service to the dependent component to be monitored represents the weight corresponding to the dependent component to be monitored, and the area of each dependent component to be monitored represents the health value of the dependent component to be monitored. For example, green represents a healthy score of 80 to 100, yellow represents a normal score between 60 and 80, and red represents an abnormal score of less than 60.

[0142] Combine Figure 5 As shown in the figure, the health value of MySQL is 80 points, the health value of Redis is 60 points, and the health value of MongoDB is 90 points. The corresponding weight of MySQL is 0.1, the corresponding weight of Redis is 0.6, and the corresponding weight of MongoDB is 0.3. The health value of the target microservice is 71 points. Details: Green represents rules that do not exceed the threshold and no points are deducted. Red represents rules that exceed the threshold and points are deducted. Each dependent component to be monitored displays its own score. The thickness of the line between the dependent component to be monitored and the microservice is used to indicate the weight of the dependent component to be monitored. When the user clicks on a specific dependent component to be monitored, a Figure 2 Detailed display of dependent components to be monitored.

[0143] In summary, this approach evaluates the health of a microservice from the perspective of its monitored dependent components, providing a quantitative display of its health. This provides a clear overview and allows users to check specifically whether the indicators corresponding to the monitored dependent components are normal. Compared to previous technologies, this approach uses more evaluation dimensions and uses statically and dynamically derived weights to calculate the true weight of each monitored dependent component, providing a closer approximation of the microservice's true health.

[0144] It highlights the key points in the microservice dependency chain and quantifies the display elements (the health value of the microservice and the health value of the dependent components to be monitored). This allows for displaying information in more dimensions, such as the health status of the entire microservice, the health status of each dependent component to be monitored, and the corresponding weight of each dependent component to be monitored.

[0145] like Figure 6 As shown, the present invention also provides a device for monitoring the health of a micro server, comprising:

[0146] The determination module 600 is configured to determine at least one dependent component of the target microservice to be monitored after detecting a monitoring instruction triggered by a user; wherein the dependent component to be monitored is a component of a SaaS layer service that affects the operation of the target microservice;

[0147] The monitoring module 601 is used to monitor multiple indicators representing the operation status of any dependent component to be monitored through the monitoring strategy corresponding to the any dependent component to be monitored, and determine the health value of any dependent component to be monitored based on the sum of the health values corresponding to each indicator of the any dependent component to be monitored; wherein the health value corresponding to the indicator represents the degree of influence of the indicator on the normal operation of the dependent component to be monitored; and determine the health value of the target microservice based on the health value of each dependent component to be monitored and the weight corresponding to each dependent component to be monitored.

[0148] Optionally, the determination module 600 is specifically configured to:

[0149] After detecting a user-triggered monitoring instruction, a selection interface is displayed; wherein the selection interface includes multiple components of the SAAS layer service that affect the operation of the target microservice;

[0150] In response to a selection instruction triggered by the user in the selection interface, the component selected by the selection instruction is used as the dependent component to be monitored.

[0151] Optionally, the monitoring module 601 is specifically configured to:

[0152] For each indicator of the dependent component to be monitored, if the indicator meets the preset condition corresponding to the indicator, determine the health value corresponding to the indicator as a first preset value; wherein the first preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored does not meet the preset condition corresponding to each indicator;

[0153] If the indicator does not meet the preset conditions corresponding to the indicator, the health value corresponding to the indicator is determined to be the target value; wherein the target value is the ratio of the second preset value to the total number of indicators of the dependent component to be monitored; the second preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored does not meet the preset conditions corresponding to each indicator.

[0154] Optional monitoring module, specifically used for:

[0155] Method 1: Using a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein the first read and write counts is the total number of occurrences of the code representing the read function and the write function in the code that implements the dependent component to be monitored; or

[0156] Method 2: Using a second ratio between the second read and write times of the dependent component to be monitored and the sum of the second read and write times of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein, the second read and write times is the total number of times the read and write functions are executed during the operation of the dependent component to be monitored within a preset time period; or

[0157] Method three: Determine a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice, and a second ratio between the second read and write counts of the dependent component to be monitored and the sum of the second read and write counts of all dependent components to be monitored of the target microservice;

[0158] The weight corresponding to each dependent component to be monitored is determined based on the first ratio and the coefficient corresponding to the first ratio, and the second ratio and the coefficient of the second ratio; wherein the coefficient corresponding to method two is determined based on the running time of each dependent component to be monitored during operation, and the coefficient corresponding to method one is the difference between the coefficient corresponding to method two and the threshold.

[0159] Optional, where:

[0160] If the dependent component to be monitored is a MySQL relational database management system, the indicators corresponding to the dependent component to be monitored are part or all of the MySQL startup status, the size of the read buffer in MySQL, the usage of MySQL, and the number of open files in MySQL;

[0161] If the dependent component to be monitored is a component that implements the Redis remote dictionary service, the indicators corresponding to the dependent component to be monitored are part or all of the startup status of the component that implements the Redis remote dictionary service, the master node in the cluster of the component that implements the Redis remote dictionary service, the backup status of the component that implements the Redis remote dictionary service, and the memory size of the component that implements the Redis remote dictionary service;

[0162] If the dependent component to be monitored is a MongoDB database based on distributed file storage, the indicators corresponding to the dependent component to be monitored are part or all of the MongoDB startup status, the delay time of the MongoDB replication delay function, the number of connected systems in MongoDB, and the memory size of MongoDB.

[0163] Optionally, the device further comprises:

[0164] The display module is used to determine the display color corresponding to the health range of the health value of each dependent component to be monitored, and the display color corresponding to the health range of the health value of the target microservice, based on the correspondence between the health range and the display color;

[0165] A display image is constructed according to the display color corresponding to the health range to which the health value of each dependent component to be monitored belongs, and the display color corresponding to the health range to which the health value of the target microservice belongs, and the display image is displayed.

[0166] In addition, combined Figures 1-6 The micro-server health monitoring method and apparatus described in the embodiments of the present invention may be implemented by an electronic device.

[0167] The electronic device includes: a processor;

[0168] a memory for storing instructions executable by the processor;

[0169] The processor is configured to execute the instructions to implement the micro-server health monitoring method as described in any one of the above descriptions.

[0170] Based on the above introduction, for example, Figure 7 electronic equipment structure.

[0171] The electronic device may include a processor 710 and a memory 720 storing computer program instructions.

[0172] Specifically, the processor 710 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiment of the present invention.

[0173] The memory 720 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 720 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 720 may include a removable or non-removable (or fixed) medium. Where appropriate, the memory 720 may be inside or outside the data processing device. In a specific embodiment, the memory 720 is a non-volatile solid-state memory. In a specific embodiment, the memory 720 includes a read-only memory (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or a flash memory, or a combination of two or more of these.

[0174] The processor 710 implements any one of the task execution methods in the above embodiments by reading and executing computer program instructions stored in the memory 720 .

[0175] In one example, the electronic device may further include a communication interface 730 and a bus 740. Figure 7 As shown, the processor 710 , the memory 720 , and the communication interface 730 are connected via a bus 740 and communicate with each other.

[0176] The communication interface 730 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present invention.

[0177] Bus 740 comprises hardware, software or both, couples the parts of electronic equipment to each other.For example, and not limitation, bus can comprise accelerated graphics port (AGP) or other graphics bus, enhanced industry standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industry standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations.In suitable cases, bus 740 can comprise one or more buses.Although the embodiment of the present invention describes and shows specific bus, the present invention considers any suitable bus or interconnection.

[0178] The electronic device can execute the method for executing a task in the embodiment of the present invention based on the received task, thereby realizing the combination Figures 1-6 Described is a method and apparatus for monitoring the health of a microserver.

[0179] In addition, in combination with the electronic device in the above embodiments, an embodiment of the present invention may provide a storage medium, which, when the instructions in the storage medium are executed by the processor of the electronic device, enables the electronic device to execute the micro-server health monitoring method as described in any one of the above items.

[0180] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0181] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0182] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0183] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0184] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A method for monitoring microservice health, characterized in that: include: After detecting a user-triggered monitoring instruction, determining at least one dependent component to be monitored of the target microservice; wherein the dependent component to be monitored is a component of a SAAS layer service that affects the operation of the target microservice; For any dependent component to be monitored, multiple indicators representing the operating status of any dependent component to be monitored are monitored through the monitoring strategy corresponding to the any dependent component to be monitored, and the health value of the any dependent component to be monitored is determined based on the sum of the health values corresponding to each indicator of the any dependent component to be monitored; wherein the health value corresponding to the indicator represents the degree of influence of the indicator on the normal operation of the dependent component to be monitored; Multiply the health value of each dependent component to be monitored by the corresponding weight of each dependent component to be monitored, and then add up the weighted sum of the dependent components to be monitored as the health value of the target microservice; Determine the health value of each indicator of the dependent component to be monitored in the following way: For each indicator of the dependent component to be monitored, if the indicator meets the preset condition corresponding to the indicator, determine the health value corresponding to the indicator as a first preset value; wherein the first preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored meets the preset condition corresponding to each indicator; If the indicator does not meet the preset conditions corresponding to the indicator, the health value corresponding to the indicator is determined to be the target value; wherein the target value is the ratio of the second preset value to the total number of indicators of the dependent component to be monitored; the second preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored does not meet the preset conditions corresponding to each indicator.

2. The microservice health monitoring method according to claim 1, characterized in that: After detecting a user-triggered monitoring instruction, determining at least one dependent component of the target microservice to be monitored includes: After detecting a user-triggered monitoring instruction, a selection interface is displayed; wherein the selection interface includes multiple components of the SAAS layer service that affect the operation of the target microservice; In response to a selection instruction triggered by the user in the selection interface, the component selected by the selection instruction is used as the dependent component to be monitored.

3. The microservice health monitoring method according to claim 1 or 2, characterized in that: Determine the weights of the dependent components to be monitored in the following ways: Method 1: Using a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein the first read and write counts is the total number of occurrences of the code representing the read function and the write function in the code that implements the dependent component to be monitored; or Method 2: Using a second ratio between the second read and write times of the dependent component to be monitored and the sum of the second read and write times of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein, the second read and write times is the total number of times the read and write functions are executed during the operation of the dependent component to be monitored within a preset time period; or Method three: Determine a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice, and a second ratio between the second read and write counts of the dependent component to be monitored and the sum of the second read and write counts of all dependent components to be monitored of the target microservice; The weight corresponding to each dependent component to be monitored is determined based on the first ratio and the coefficient corresponding to the first ratio, and the second ratio and the coefficient corresponding to the second ratio; wherein the coefficient corresponding to method two is determined based on the running time of each dependent component to be monitored during operation, and the coefficient corresponding to method one is the difference between the coefficient corresponding to method two and the threshold.

4. The microservice health monitoring method according to claim 1, characterized in that: in: If the dependent component to be monitored is a MySQL relational database management system, the indicators corresponding to the dependent component to be monitored are part or all of the MySQL startup status, the size of the read buffer in MySQL, the usage of MySQL, and the number of open files in MySQL; If the dependent component to be monitored is a component that implements the Redis remote dictionary service, the indicators corresponding to the dependent component to be monitored are part or all of the startup status of the component that implements the Redis remote dictionary service, the master node in the cluster of the component that implements the Redis remote dictionary service, the backup status of the component that implements the Redis remote dictionary service, and the memory size of the component that implements the Redis remote dictionary service; If the dependent component to be monitored is a MongoDB database based on distributed file storage, the indicators corresponding to the dependent component to be monitored are part or all of the MongoDB startup status, the delay time of the MongoDB replication delay function, the number of connected systems in MongoDB, and the memory size of MongoDB.

5. The microservice health monitoring method according to claim 1, characterized in that: After determining the health value of the target microservice based on the health value of each dependent component to be monitored and the weight corresponding to each dependent component to be monitored, the method further includes: Based on the correspondence between health ranges and display colors, determine the display color corresponding to the health range to which the health value of each dependent component to be monitored belongs, as well as the display color corresponding to the health range to which the health value of the target microservice belongs; A display image is constructed according to the display color corresponding to the health range to which the health value of each dependent component to be monitored belongs, and the display color corresponding to the health range to which the health value of the target microservice belongs, and the display image is displayed.

6. A device for monitoring the health of microservices, characterized in that: include: A determination module is configured to determine, after detecting a user-triggered monitoring instruction, at least one dependent component of a target microservice to be monitored; wherein the dependent component to be monitored is a component of a SaaS layer service that affects the operation of the target microservice; A monitoring module is used to monitor, for any dependent component to be monitored, multiple indicators that characterize the operation status of any dependent component to be monitored through the monitoring strategy corresponding to the any dependent component to be monitored, and determine the health value of any dependent component to be monitored based on the sum of the health values corresponding to each indicator of the dependent component to be monitored; wherein the health value corresponding to the indicator represents the degree of influence of the indicator on the normal operation of the dependent component to be monitored; the health value of each dependent component to be monitored is multiplied by the weight corresponding to each dependent component to be monitored, and then the sum of the weighted dependent components to be monitored is accumulated as the health value of the target microservice; Determine the health value of each indicator of the dependent component to be monitored in the following way: For each indicator of the dependent component to be monitored, if the indicator meets the preset condition corresponding to the indicator, determine the health value corresponding to the indicator as a first preset value; wherein the first preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored meets the preset condition corresponding to each indicator; If the indicator does not meet the preset conditions corresponding to the indicator, the health value corresponding to the indicator is determined to be the target value; wherein the target value is the ratio of the second preset value to the total number of indicators of the dependent component to be monitored; the second preset value is the health value of the dependent component to be monitored when each indicator of the dependent component to be monitored does not meet the preset conditions corresponding to each indicator.

7. The microservice health monitoring device according to claim 6, characterized in that: Monitoring module, specifically used for: Method 1: Using a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein the first read and write counts is the total number of occurrences of the code representing the read function and the write function in the code that implements the dependent component to be monitored; or Method 2: Using a second ratio between the second read and write times of the dependent component to be monitored and the sum of the second read and write times of all dependent components to be monitored of the target microservice as the weight corresponding to the dependent component to be monitored; wherein, the second read and write times is the total number of times the read and write functions are executed during the operation of the dependent component to be monitored within a preset time period; or Method three: Determine a first ratio between the first read and write counts of the dependent component to be monitored and the sum of the first read and write counts of all dependent components to be monitored of the target microservice, and a second ratio between the second read and write counts of the dependent component to be monitored and the sum of the second read and write counts of all dependent components to be monitored of the target microservice; The weight corresponding to each dependent component to be monitored is determined based on the first ratio and the coefficient corresponding to the first ratio, and the second ratio and the coefficient corresponding to the second ratio; wherein the coefficient corresponding to method two is determined based on the running time of each dependent component to be monitored during operation, and the coefficient corresponding to method one is the difference between the coefficient corresponding to method two and the threshold.

8. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the microservice health monitoring method according to any one of claims 1 to 5.

9. A storage medium, characterized in that: include: When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the microservice health monitoring method according to any one of claims 1 to 5.

Images