Automatic micro-service health monitoring method and device and electronic equipment

Abstract

The invention provides an automatic micro-service health monitoring method and device and electronic equipment. According to the scheme, firstly, operation environment parameters and operation efficiency parameters of all micro-services in different internet data centers are obtained; then, processing all the operating environment parameters collected from different internet data centers, and performing weighted scoring processing on the operating environment parameters of the same micro-service in different internet data centers to obtain a comprehensive score of each micro-service; determining the operation efficiency of the same micro-service in different internet data centers according to the operation efficiency parameters, and obtaining operation efficiency evaluation results of the multiple micro-services; and finally, when the comprehensive score reaches a first preset alarm threshold value, and / or the operation efficiency evaluation result reaches a second preset alarm threshold value, triggering an alarm. According to the scheme, the problem of low efficiency of manually comparing the operating environments of the same micro-service in different internet data centers in the prior art is solved.

Description

Technical Field

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

[0002] When deploying distributed applications, it is very important to ensure the consistency of the operating environment of different servers. Especially for microservice clusters, the consistency of system parameters, system configuration, and startup commands is crucial to the performance and stability of the application.

[0003] For multiple service deployment tasks, when multiple deployment centers belong to different Internet Data Center (IDC) rooms, the server's operating environment and system environment may be different. It is necessary to compare the environments of multiple parties to ensure the consistency of the service operating environment. The environment to be compared includes the system parameters, environment variables, startup commands, system versions, hardware configurations, etc. of the service operation. The traditional comparison method generally uses manual methods to compare the operating environment one by one, which is time-consuming. Once the environment changes, it is impossible to quickly and accurately display the changed system parameters, and it is impossible to handle exceptions in time, resulting in low comparison efficiency. There are problems such as poor real-time performance and low reliability of microservice status checks, which affect the deployment efficiency of sub-centers. Summary of the invention

[0004] The main purpose of the present application is to provide a method, device, computer-readable storage medium and electronic device for automated microservice health monitoring, so as to at least solve the problem of low efficiency in manually comparing the operating environments of the same microservice in different Internet data centers in the prior art.

[0005] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a method for automated microservice health monitoring is provided, including: obtaining operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers; processing all the operating environment parameters collected from different Internet data centers, performing weighted scoring processing on the operating environment parameters of the same microservice in different Internet data centers, and obtaining a comprehensive score for each microservice; determining the operating efficiency of the same microservice in different Internet data centers according to the operating efficiency parameters, and obtaining operating efficiency evaluation results of multiple microservices; triggering an alarm when the comprehensive score reaches a first preset alarm threshold and / or the operating efficiency evaluation result reaches a second preset alarm threshold.

[0006] Optionally, the operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers are obtained, including: traversing all the Internet data centers, and using automated tools to collect the operating environment parameters of the microservices in each of the Internet data centers, wherein the operating environment parameters include system parameters, environment variables, startup commands, system version and hardware configuration.

[0007] Optionally, the operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers are obtained, including: collecting the operating efficiency parameters of each microservice in each Internet data center through a monitoring tool, wherein the operating efficiency parameters include peak TPS, disk usage and CPU usage.

[0008] Optionally, weighted scoring is performed on the operating environment parameters of the same microservice in different Internet data centers to obtain a comprehensive score for each microservice, including: determining the weight of each operating environment parameter of the same microservice in different Internet data centers according to a preset importance, wherein the weight reflects the importance of each operating environment parameter; calculating the difference between an actual value and a historical average value of each operating environment parameter to obtain a difference score for each operating environment parameter; multiplying the difference score of each operating environment parameter by the weight of each operating environment parameter to obtain a weighted score for each operating environment parameter; and adding all the weighted scores to obtain the comprehensive score for each microservice.

[0009] Optionally, the operating efficiency of the same microservice in different Internet data centers is determined according to the operating efficiency parameters to obtain operating efficiency evaluation results of multiple microservices, including: inputting the operating efficiency parameters into a preset efficiency evaluation model for analysis to obtain the operating efficiency evaluation results of each microservice in different Internet data centers, wherein the preset efficiency evaluation model analyzes the operating efficiency parameters based on historical data and preset rules.

[0010] Optionally, the method also includes: training a fault prediction model based on historical fault data and fault handling records; inputting the operating environment parameters and the operating efficiency parameters of the microservice collected from different Internet data centers into the fault prediction model for analysis, and automatically identifying the fault conditions of the microservice; if a fault is detected, executing corresponding repair measures according to the fault handling strategy learned by the fault prediction model.

[0011] Optionally, the method further comprises: generating a visual report, wherein the visual report comprises monitoring indicators, abnormal conditions, diagnosis results and repair status.

[0012] According to another aspect of the present application, a device for automated microservice health monitoring is provided, comprising: an acquisition unit, configured to acquire operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers; a scoring processing unit, configured to process all the operating environment parameters collected from different Internet data centers, and perform weighted scoring processing on the operating environment parameters of the same microservice in different Internet data centers to obtain a comprehensive score for each microservice; an evaluation unit, configured to determine the operating efficiency of the same microservice in different Internet data centers based on the operating efficiency parameters to obtain operating efficiency evaluation results of multiple microservices; and an alarm unit, configured to trigger an alarm when the comprehensive score reaches a first preset alarm threshold and / or the operating efficiency evaluation result reaches a second preset alarm threshold.

[0013] According to another aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute any one of the methods for automated microservice health monitoring.

[0014] According to another aspect of the present application, an electronic device is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include a method for executing any one of the automated microservice health monitoring methods described.

[0015] By applying the technical solution of the present application, first, the operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers are obtained; then, all the operating environment parameters collected from different Internet data centers are processed, and the operating environment parameters of the same microservice in different Internet data centers are weighted and scored to obtain a comprehensive score for each microservice; the operating efficiency of the same microservice in different Internet data centers is determined according to the operating efficiency parameters, and operating efficiency evaluation results of multiple microservices are obtained; finally, when the comprehensive score reaches a first preset alarm threshold, and / or the operating efficiency evaluation result reaches a second preset alarm threshold, an alarm is triggered, thereby solving the problem of low efficiency of manually comparing the operating environments of the same microservice in different Internet data centers in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings constituting part of the present application are used to provide a further understanding of the present application. The exemplary embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0017] Figure 1A hardware structure block diagram of a mobile terminal for performing a method for automated microservice health monitoring provided in an embodiment of the present application is shown;

[0018] Figure 2 A flow chart of a method for automated microservice health monitoring provided according to an embodiment of the present application is shown;

[0019] Figure 3 A flowchart of a specific method for automated microservice health monitoring provided according to an embodiment of the present application is shown;

[0020] Figure 4 A structural block diagram of an apparatus for automated microservice health monitoring provided according to an embodiment of the present application is shown.

[0021] The above drawings include the following reference numerals:

[0022] 102, processor; 104, memory; 106, transmission device; 108, input and output devices. DETAILED DESCRIPTION

[0023] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0024] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0026] As introduced in the background technology, the traditional comparison method in the prior art generally uses a manual method to compare the operating environment one by one, which is time-consuming. Once the environment changes, it is impossible to quickly and accurately display the changed system parameters, and it is impossible to handle the exception in time, resulting in low comparison efficiency. In order to solve the problem of low efficiency of manually comparing the operating environments of the same microservice in different Internet data centers, the embodiments of the present application provide a method, device, computer-readable storage medium and electronic device for automated microservice health monitoring.

[0027] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0028] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 1 is a hardware structure block diagram of a mobile terminal of a method for automated microservice health monitoring according to an embodiment of the present invention. Figure 1 As shown, the mobile terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the mobile terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the mobile terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0029] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the display method of device information in the embodiment of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, the above method is implemented. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof. The transmission device 106 is used to receive or send data via a network. The above-mentioned specific examples of the network may include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0030] In this embodiment, a method for automated microservice health monitoring running on a mobile terminal, a computer terminal or a similar computing device is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0031] Figure 2 FIG. 1 is a flow chart of a method for automated microservice health monitoring according to an embodiment of the present application. Figure 2 As shown, the method comprises the following steps:

[0032] Step S201, obtaining operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers;

[0033] Specifically, an Internet Data Center (IDC) is a place where computing, storage, and network equipment are stored in a centralized manner. It provides professional server hosting, leasing, and network access services for Internet content providers, corporate users, and third-party organizations, as well as a series of value-added services such as data backup, security protection, and content distribution. Internet data centers usually have the following characteristics and functions: High availability: IDCs are designed with redundant power systems, network facilities, and cooling systems to ensure that servers and other equipment can continue to operate stably and provide services even when some components fail. High security: IDCs have strict security measures, including physical security precautions (such as access control systems and surveillance cameras), network security protection (such as firewalls and intrusion detection systems), and data security policies (such as data encryption and backup). High-bandwidth network: IDCs are usually connected to high-speed Internet bandwidth, which can provide fast data transmission and processing capabilities to meet the needs of large-scale data exchange and high-traffic access. Professional operation and maintenance team: IDCs are equipped with professional operation and maintenance personnel and tools, which can monitor and manage the operation status of the data center 24 / 7, respond to and handle various operation and maintenance issues in a timely manner, and ensure high efficiency and high quality of services. Hosting and leasing services: IDC provides server hosting and leasing services. Enterprises can choose to place servers in IDC according to their own needs and let IDC manage them, or directly lease IDC server resources for use. Multi-regional deployment: Large IDC operators usually establish multiple data centers around the world to achieve distributed storage and processing of data, improve service coverage and access speed, and also provide disaster recovery and business continuity support.

[0034] Microservices is a software architecture design style that advocates splitting complex monolithic applications into a set of small, independent, independently deployable services, each of which performs a specific business function. Microservice architecture has the following key features: Independence: Each microservice is independent of other services, has its own code base, database, and operating environment, and can be independently developed, tested, deployed, and expanded. This independence allows individual services to be developed in parallel and will not affect each other when deployed, reducing system complexity and coupling. Fine-grained: Each microservice focuses only on a specific business function or domain, which makes the responsibilities of the service clearer, reduces code bloat, and is easier to understand and maintain. Fine-grained microservices also make the system easier to modularize and refactor. Lightweight communication: Microservices interact with each other through lightweight communication mechanisms such as HTTP / REST, gRPC, message queues, etc., rather than direct database access or complex internal calls. This helps decouple services and improve the flexibility and scalability of the system. Independently scalable: Since each microservice is independent, it can be independently expanded horizontally (adding service instances) or vertically (adding resources such as CPU, memory) according to their respective load conditions. This ability to scale on demand makes the microservice architecture very adaptable to high-concurrency, high-availability scenarios. Fault isolation and fault tolerance: The microservice architecture ensures that failures between services do not affect each other by design. When one service fails, other services can still work normally. In addition, microservices usually implement some fault-tolerant mechanisms, such as timeout processing, retry logic, circuit breaker mode, etc., to improve the overall stability and robustness of the system. Diversity of technology stacks: In the microservice architecture, different services can use different programming languages, development tools, and databases, which provides development teams with greater freedom to choose the most suitable technology stack based on the specific needs of the service. Continuous Integration and Continuous Deployment (CI / CD): The microservice architecture encourages the use of the CI / CD development model, that is, frequent integration testing and automated deployment. This can speed up development iterations and improve software quality, while also making it easier to track and roll back changes.

[0035] In the engine of automated fault diagnosis and microservice health monitoring, the concept of microservices means that the system needs to be able to monitor and compare the operating status and configuration differences of multiple independent microservices to ensure that they can maintain consistency and health in different data centers. This monitoring and diagnosis mechanism usually combines the lightweight communication, independent deployment and fault isolation characteristics of microservices to design corresponding algorithms and strategies to adapt to the complexity and dynamics of microservice architecture.

[0036] In the solution of automated microservice health monitoring, the concept of IDC is particularly important, because microservices may be deployed in multiple IDCs in different geographical locations. The purpose of the solution is to ensure the consistency of the microservice operating environment and efficiency in these different IDCs, monitor and compare the status of microservices in different IDCs through automated tools and algorithms, discover and handle possible differences or faults, and thus ensure the stability and reliability of the microservice architecture.

[0037] The operating environment parameters of the microservice obtained include system parameters, environment variables, startup commands, system version, and hardware configuration. These parameters are directly related to the stability and performance of the microservice. You can use the corresponding application programming interface (API) or library to obtain system parameters and environment variables. You can use command-line tools such as uname (a command-line tool used to display the name and version number of the operating system) to obtain the system version. You can use system-related APIs or command-line tools to obtain hardware configuration information, and use command-line tools such as lshw (a command-line tool, the full name is list hardware, which can list detailed information of various hardware components in the computer) or dmidecode (a command-line tool used to display the hardware information of the computer) to obtain hardware configuration information. Use third-party libraries or tools to obtain other required information.

[0038] Operation efficiency parameters mainly refer to the performance indicators of microservices during operation, including peak TPS (system throughput), disk usage, and CPU usage. These parameters can be collected in real time or regularly through monitoring systems deployed on microservices, such as Prometheus, Grafana, New Relic, etc. These monitoring systems can collect key performance data such as service response time, request processing capabilities, and resource usage through plug-ins, agents, or direct interaction with microservices. By collecting operation efficiency parameters, the health status and performance level of microservices can be evaluated, providing a basis for fault detection.

[0039] Through the above steps, the automated microservice health monitoring method can comprehensively and accurately obtain the operating environment and efficiency data of microservices in different IDCs, providing a solid data foundation for subsequent scoring, evaluation, diagnosis, and repair, thereby realizing automated monitoring and management of the health status of microservices.

[0040] Step S202: Process all the operating environment parameters collected from different Internet data centers, perform weighted scoring on the operating environment parameters of the same microservice in different Internet data centers, and obtain a comprehensive score for each microservice;

[0041] Specifically, the acquired operating environment parameters and operating efficiency parameters are integrated and preprocessed for subsequent analysis and scoring. Preprocessing includes data cleaning, format conversion, standardization or normalization to ensure that data from different IDCs can be effectively compared and analyzed.

[0042] Next, the operating environment parameters of the same microservice in different IDCs are compared. For example, if microservice A is deployed in both IDC1 and IDC2, the system parameters, environment variables, startup commands, system versions, and hardware configurations of microservice A in the two IDCs are compared to see if they are consistent. If there are differences, it is necessary to further analyze whether these differences will affect the operation and performance of the microservice. When analyzing the differences, it is necessary to consider the importance and sensitivity of the parameters. For example, inconsistent system versions may cause compatibility issues, while differences in hardware configurations may affect the response speed and processing capabilities of the microservice. Based on the comparison and analysis, a weighted scoring process is performed to obtain a comprehensive score for the microservice in a specific IDC environment. The calculated comprehensive score can be used to evaluate the operating status of the microservice in different IDC environments. A low score may indicate configuration errors, system incompatibility, or hardware bottlenecks, which require further diagnosis and repair.

[0043] Through this series of processing, the uniformity and stability of the microservice operating environment in different IDCs can be ensured, the failures and operation and maintenance workload caused by environmental differences can be reduced, and the operation efficiency and user experience of microservices can be improved. This technical step is the core link in the automated microservice health monitoring method, and uses a data-driven approach to provide a scientific basis and reliable means for the operation and maintenance and fault diagnosis of microservices.

[0044] Step S203, determining the operating efficiency of the same microservice in different Internet data centers according to the operating efficiency parameters, and obtaining operating efficiency evaluation results of the plurality of microservices;

[0045] Specifically, first, a series of operating efficiency parameters need to be collected from each IDC in real time or regularly. These parameters can reflect the performance status of microservices. Specific operating efficiency parameters include:

[0046] Peak TPS (Transactions Per Second): This is a key indicator to measure the transaction processing capability of a microservice, reflecting the maximum transaction or transaction volume that the service can handle per unit time.

[0047] Disk usage: High disk usage may mean there is a bottleneck in data storage or read and write operations.

[0048] CPU usage: CPU usage is an important indicator to measure the computing power utilization of microservices. Too high a usage rate may mean insufficient processing power.

[0049] The acquired operating efficiency parameter data is processed and analyzed, including data cleaning, data aggregation, and data comparison. Data cleaning is to remove invalid or erroneous data to ensure the accuracy of analysis. Data aggregation is to aggregate data at different time points in the same IDC to obtain the average or statistical value over a period of time. Data comparison is to compare the data of the same microservice in different IDCs to find differences.

[0050] Through in-depth analysis of the operating efficiency parameters, the operating efficiency of the same microservice in different IDC environments can be determined, and the operating efficiency evaluation results of multiple microservices can be obtained.

[0051] Through the above steps, the automated microservice health monitoring method can effectively monitor and evaluate the operating efficiency of microservices in different IDC environments, ensure the performance and stability of services, and provide data-driven decision support for operation and development teams.

[0052] Step S204: trigger an alarm when the above-mentioned comprehensive score reaches a first preset alarm threshold and / or the above-mentioned operation efficiency evaluation result reaches a second preset alarm threshold.

[0053] Specifically, each microservice is scored based on the operating environment parameters collected from different Internet data centers. The scoring is calculated in a weighted manner, where the weight of the parameter reflects the degree of its impact on the stability and efficiency of the microservice operation. The first preset alarm threshold is a pre-set value used to identify the health of the microservice operating environment. If the comprehensive score of the microservice reaches this threshold, it means that there are inconsistencies or potential problems in its operating environment, which may affect the normal operation or performance of the service. When the comprehensive score of the microservice reaches the first preset alarm threshold, an alarm is automatically triggered. The alarm can be notified to the operation and maintenance personnel by email, SMS, phone or internal communication system, so as to conduct problem troubleshooting and fault repair in a timely manner.

[0054] Specifically, the operating efficiency of each microservice is evaluated based on the operating efficiency parameters collected from different Internet data centers. Similarly, a set of operating efficiency thresholds are set to determine whether the operating efficiency of a microservice is lower than the expected level or industry standard. These thresholds can be determined based on historical data, service level agreements (SLAs), or performance test results. When the operating efficiency evaluation result of a microservice reaches a second preset alarm threshold, an alarm will also be triggered. The alarm will highlight inefficient microservices and IDCs, prompting the operation and maintenance team to take measures, such as optimizing resource allocation, adjusting microservice configurations, or performing code optimization, to improve the operating efficiency of the service.

[0055] Alerts can be triggered in the following ways:

[0056] Comprehensive score alarm: When the comprehensive score reaches the first preset alarm threshold, an alarm may be triggered even if the operating efficiency evaluation result is normal, because it indicates that there are inconsistencies or potential problems in the operating environment of the microservice.

[0057] Operation efficiency alarm: When the operation efficiency evaluation result reaches the second preset alarm threshold, an alarm may be triggered even if the comprehensive score is normal, because this indicates that the performance of the microservice is lower than expected and there may be an efficiency bottleneck.

[0058] Combined alarm: If the alarm conditions of the comprehensive score and the operation efficiency evaluation result are met at the same time, that is, the comprehensive score reaches the first preset alarm threshold, and the operation efficiency evaluation result reaches the second preset alarm threshold, then a more urgent alarm will be triggered to remind the operation and maintenance team to take immediate action.

[0059] By setting two preset alarm thresholds, the first preset alarm threshold and the second preset alarm threshold, and triggering the alarm when the conditions are met, the operation and maintenance team can be notified in time when inconsistencies or low operating efficiency occur in the microservice operating environment, so as to facilitate rapid response and problem handling, thereby ensuring the stable operation and efficient performance of the microservice.

[0060] In one embodiment of the present application, the operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers are obtained, including: traversing all the above-mentioned Internet data centers, and using automated tools to collect the above-mentioned operating environment parameters of the above-mentioned microservices of each of the above-mentioned Internet data centers, wherein the above-mentioned operating environment parameters include system parameters, environment variables, startup commands, system version and hardware configuration.

[0061] Specifically, we traverse all Internet data centers (IDCs), automatically scan and access all IDCs where microservices are deployed to ensure that comprehensive data can be collected. This step is achieved through the programming of automation tools, which specifically involves:

[0062] Network connection and access: It is necessary to be able to establish network connections with IDCs in different geographical locations and access their internal servers and microservices.

[0063] Authentication and permission control: For each IDC, corresponding access rights are required, which involves the use of keys, certificates or preset authentication mechanisms to ensure secure access.

[0064] For each microservice in the IDC, use a pre-set automated tool to collect operating environment parameters. The specific collection process is as follows:

[0065] System parameters: This includes the operating system and its version, kernel parameters, system load, etc. Collecting these parameters helps to understand the basic system environment in which the microservices run.

[0066] Environment variables: Environment variables are necessary configurations for microservice runtime, such as JAVA_OPTS, system path variables, etc. These variables are crucial to the startup and operation of microservices.

[0067] Startup command: Collect the startup command of the microservice to determine the operation initialization settings of the microservice, including the operation mode, resource restrictions, etc.

[0068] System version: This involves the software version that the service depends on, including middleware, database, etc. Differences in system versions may cause compatibility issues.

[0069] Hardware configuration: Hardware information, such as CPU model, memory size, disk type, etc., has a direct impact on the performance of microservices.

[0070] In another embodiment of the present application, the operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers are obtained, including: collecting the above-mentioned operating efficiency parameters of each of the above-mentioned microservices in each of the above-mentioned Internet data centers through a monitoring tool, wherein the above-mentioned operating efficiency parameters include peak TPS, disk utilization and CPU utilization.

[0071] Specifically, monitoring tools are software or systems used to collect server and microservice operating status data in real time or periodically. Common monitoring tools include Prometheus, Grafana, Zabbix, Nagios, etc. These tools can provide highly customized data collection and real-time monitoring functions. Choose the appropriate monitoring tool and configure the corresponding collection rules and monitoring indicators to ensure that the required operating efficiency parameters can be accurately obtained.

[0072] Peak TPS (Transactions Per Second) monitoring: Peak TPS is an important indicator to measure the processing capacity of microservices, indicating the maximum number of transactions or requests that a microservice can handle during the busiest period of time. Monitoring tools collect peak TPS data in the following ways: Transaction tracking: embed tracking code in the code of microservices or use AOP (Aspect-Oriented Programming) technology to record the processing of each transaction or request. Data aggregation: The monitoring tool regularly collects these transaction records and counts the number of transactions processed within a specific time window (such as one minute, one hour, etc.) to determine the peak TPS.

[0073] Disk usage monitoring: Disk usage is a key indicator for measuring the efficiency of microservice data storage and read and write. High disk usage may mean insufficient data storage space or a bottleneck in disk I / O operations. Monitoring disk usage can be achieved in the following ways: Disk space statistics: The monitoring tool regularly checks the usage of disk partitions, including used space, free space, and total space. Disk activity monitoring: Track the read and write operation rate and latency of the disk to evaluate the efficiency of disk I / O.

[0074] CPU usage monitoring: CPU usage is an important parameter to measure the utilization of microservice computing power. Too high or too low CPU usage may mean improper resource allocation or hardware bottlenecks. The steps to monitor CPU usage are as follows: CPU occupancy statistics: The monitoring tool continuously tracks CPU occupancy, including user-state and system-state CPU usage. Multi-core CPU support: In a multi-core CPU environment, the monitoring tool can collect the usage of each core separately to comprehensively evaluate the utilization of computing resources.

[0075] The automated collection and processing of this process greatly improves the efficiency and accuracy of monitoring, and can quickly discover performance issues and potential risks of microservices. Through the automated parameter collection steps, the operating environment and efficiency of microservices can be comprehensively evaluated, and the subsequent alarm mechanism and fault diagnosis process can be triggered to ensure the healthy operation and high performance of microservices. This method effectively overcomes the limitations of manual inspection and improves the accuracy, efficiency and coverage of monitoring, especially in large-scale microservice deployment scenarios, its advantages are more obvious.

[0076] In another embodiment of the present application, a weighted scoring process is performed on the operating environment parameters of the same microservice in different Internet data centers to obtain a comprehensive score for each of the microservices, including: determining the weight of each of the operating environment parameters of the same microservice in different Internet data centers according to a preset importance, wherein the weight reflects the importance of each of the operating environment parameters; calculating the difference between an actual value and a historical average value of each of the operating environment parameters to obtain a difference score for each of the operating environment parameters; multiplying the difference score of each of the operating environment parameters by the weight of each of the operating environment parameters to obtain a weighted score for each of the operating environment parameters; and adding all of the weighted scores to obtain the comprehensive score for each of the microservices.

[0077] Specifically, the weights are set based on the preset importance, taking into account the different degrees of influence of different parameters on the running status of microservices. For example, inconsistency in system versions may have a significant impact on the compatibility and stability of microservices, while differences in certain environmental variables may have a smaller impact. Therefore, it is necessary to evaluate the importance of each operating environment parameter and set the corresponding weight based on experience, service level agreement (SLA) and specific requirements of microservices.

[0078] After obtaining the actual values ​​of the operating environment parameters of the same microservice in each IDC, the difference between these parameters and the historical average is calculated to obtain the difference score of each operating environment parameter. The calculation of the historical average is based on the operating data of the microservice over a period of time, including the parameter values ​​under normal operating conditions. The steps for calculating the difference score are as follows:

[0079] Obtain historical data: Obtain the operating environment parameter values ​​of microservices within a certain time range from the database or monitoring system to form a historical data set.

[0080] Calculate historical averages: Perform statistical analysis on the parameter values ​​of historical data sets and calculate historical averages.

[0081] Calculate the difference: Compare the actual value of the parameter currently collected with the historical average value and calculate the difference. The greater the difference between the actual value and the average value, the higher the difference score.

[0082] Calculate weighted scores: Multiply the difference scores of each operating environment parameter by the preset weights to obtain the weighted scores of each operating environment parameter. This calculation step ensures that parameters with high weights have a greater impact on the comprehensive score.

[0083] Get the comprehensive score: Add up all weighted scores to get the comprehensive score of each microservice. This score reflects the consistency and stability of the microservice's operating environment in different IDCs. If the comprehensive score reaches the preset threshold, it means that there are major differences or problems in the microservice's operating environment, which requires further diagnosis and repair.

[0084] Through the above weighted scoring process, we can quantitatively evaluate the operating environment status of microservices in different IDCs, discover potential problems in a timely manner, and judge the health of microservices by the comprehensive score. This method provides a data-driven decision-making basis, which helps the operation and maintenance team to quickly locate and solve problems, thereby ensuring the high-quality operation of microservices. At the same time, the use of weighted scoring also makes it more flexible to adapt to the specific needs of different microservices, ensuring the accuracy and effectiveness of the scoring results.

[0085] In another embodiment of the present application, the operating efficiency of the same microservice in different Internet data centers is determined according to the operating efficiency parameters to obtain operating efficiency evaluation results of multiple microservices, including: inputting the operating efficiency parameters into a preset efficiency evaluation model for analysis to obtain the operating efficiency evaluation results of each of the microservices in different Internet data centers, wherein the preset efficiency evaluation model analyzes the operating efficiency parameters based on historical data and preset rules.

[0086] Specifically, the preset efficiency evaluation model is built based on historical data and preset rules, and its purpose is to quantify and evaluate the operating efficiency of microservices. The steps for building the model are as follows:

[0087] Historical data collection: Collect the operating efficiency parameters of microservices when running on different IDCs, as well as the corresponding service performance and user feedback data.

[0088] Data preprocessing: clean historical data, process missing values ​​and outliers, and ensure data quality.

[0089] Feature engineering: Extract features from historical data, including time series features, statistical features, etc., for training models.

[0090] Model training: Use machine learning algorithms (such as regression, neural networks, etc.) to train the model so that the model can predict the operating efficiency of microservices based on operating efficiency parameters.

[0091] Model validation: Verify the accuracy and generalization ability of the model through cross-validation or hold-out datasets.

[0092] After obtaining the operating efficiency parameters of a microservice in different IDCs, these parameters will be input into the preset efficiency evaluation model for analysis. The model will evaluate the operating efficiency based on the following steps:

[0093] Parameter standardization: Standardize or normalize the input operating efficiency parameters to make them meet the input requirements of the model.

[0094] Model prediction: The model predicts the operating efficiency of microservices in different IDCs based on standardized parameters.

[0095] Efficiency score: The prediction result of the model can be an efficiency score. The score range (such as 0 to 100) reflects the operating efficiency of the microservice, where a higher score indicates better operating efficiency.

[0096] The efficiency score obtained after model analysis is the operational efficiency evaluation result, which will reflect the difference in operational efficiency of the same microservice in different IDCs. The operational efficiency evaluation result is generated based on the following logic:

[0097] Threshold comparison: Compare the efficiency score with the preset efficiency threshold to determine whether the operating efficiency of the microservice meets the requirements.

[0098] Efficiency report: Generates an operational efficiency evaluation report, which lists in detail the efficiency scores and comparative analysis of microservices in different IDCs.

[0099] Abnormal marking: If the operating efficiency evaluation result of a microservice in a certain IDC is lower than expected, the system will mark it as abnormal to notify the operation and maintenance personnel to conduct troubleshooting or performance tuning.

[0100] By inputting the operating efficiency parameters into the preset efficiency evaluation model for analysis, the operating efficiency of the same microservice in different IDCs can be quantitatively evaluated to obtain the operating efficiency evaluation results. This result provides an important basis for the healthy operation and performance optimization of microservices, helps to timely discover and solve efficiency problems, and ensures that microservices can run with high quality and efficiency in all IDCs.

[0101] In order to reduce the manual troubleshooting and handling work of operation and maintenance personnel and improve the timeliness and efficiency of fault response, in one embodiment of the present application, the above method also includes: training a fault prediction model based on historical fault data and fault handling records; inputting the above operating environment parameters and the above operating efficiency parameters of the above microservices collected from different above Internet data centers into the above fault prediction model for analysis, and automatically identifying the fault conditions of the above microservices; if a fault is detected, executing corresponding repair measures according to the fault handling strategy learned by the above fault prediction model.

[0102] Specifically, the training of the fault prediction model is based on historical fault data and fault handling records, and its goal is to build a model that can automatically identify fault modes from operating environment parameters and operating efficiency parameters. The model training process is as follows:

[0103] Historical data preparation: Collect historical data of all failure situations encountered by microservices during operation, including operating environment parameters before and after the failure, operating efficiency parameters, and failure types and processing results.

[0104] Data preprocessing: clean historical data, handle missing values, outliers, and inconsistencies, and ensure data quality and consistency.

[0105] Feature extraction: Extract fault-related features from historical data, including abnormal values ​​of parameters, relationships between parameters, time series characteristics, etc.

[0106] Model selection: Select an appropriate machine learning algorithm, such as decision tree, random forest, support vector machine, or neural network, based on the problem type and data characteristics of the fault prediction.

[0107] Model training: The preprocessed data and features are input into the model, and the model is trained through supervised learning so that it can identify and predict faults.

[0108] Model evaluation: Use cross-validation or a holdout dataset to evaluate the model’s predictive accuracy and reliability to ensure the model’s ability to generalize to new data.

[0109] After the fault prediction model is trained, the operating environment parameters and operating efficiency parameters of the microservices collected from different IDCs can be input into the fault prediction model for real-time or periodic analysis. The fault identification process of the fault prediction model is as follows:

[0110] Real-time monitoring: Continuously monitor the operation data of microservices in each IDC. Once data collection is completed, it is immediately input into the model for analysis.

[0111] Data standardization: Standardize the input running data to ensure that the data format and range are consistent with those during model training.

[0112] Fault prediction: The model predicts whether the microservice has potential faults based on the input operation data.

[0113] Fault type identification: If the model predicts a fault, it further identifies the specific fault type, such as hardware failure, software error, improper configuration, etc.

[0114] If the fault prediction model detects a fault in a microservice, it will automatically execute the corresponding repair measures based on the fault handling strategy learned by the model. The execution of the fault handling strategy follows the following steps:

[0115] Strategy matching: After the model predicts the fault type, it searches for processing strategies that match the fault type. These strategies are included in the fault processing records or are preset fault response rules.

[0116] Execution of repair measures: Automatically execute matched repair measures, including restarting services, updating configurations, optimizing codes, allocating more resources, etc.

[0117] Result feedback: After the repair measures are executed, the operation data of the microservice is collected again and input into the model for analysis to verify whether the fault has been resolved.

[0118] Iterative learning: The results of fault handling are recorded and used to iteratively train the fault prediction model so that the fault prediction model can learn new fault modes and handling strategies, thereby improving the accuracy and efficiency of fault prediction and handling.

[0119] By introducing the fault prediction model, it is possible to automatically identify and handle microservice failures in different IDCs, greatly reducing the manual troubleshooting and handling work of operation and maintenance personnel, and improving the timeliness and efficiency of fault response. In addition, the iterative learning mechanism of the model enables the system to continuously optimize fault prediction and handling strategies, adapt to changes in the microservice operating environment, and thus ensure the stable operation and efficient performance of microservices.

[0120] In order to provide a real-time overview of the running status of microservices, in one embodiment of the present application, the method further includes: generating a visualization report, wherein the visualization report includes monitoring indicators, abnormal conditions, diagnostic results, and repair status.

[0121] Specifically, monitoring indicators are the results of real-time or periodic monitoring of the health status and service performance of microservices. In the visual report, these indicators are organized and displayed in the form of charts or numerical values ​​for quick understanding. Monitoring indicators include:

[0122] Comparison of operating environment parameters: such as comparison of differences in system parameters, environment variables, startup commands, system versions, and hardware configurations.

[0123] Operation efficiency parameters: such as real-time values ​​and historical trends of peak TPS, disk usage, and CPU usage.

[0124] Weighted score and operation efficiency evaluation results: Displays the comprehensive score and operation efficiency score of microservices in different IDCs, intuitively reflecting the consistency and efficiency of services.

[0125] Abnormal situations refer to situations that are found during monitoring and do not conform to expected behavior. These situations indicate potential failures or performance issues. In the visual report, abnormal situations are highlighted to help operation and maintenance personnel quickly locate the problem. Abnormal situations include:

[0126] Significant differences in operating environment parameters, such as inconsistent system versions, insufficient hardware configuration, etc.

[0127] Operation efficiency parameters deviate from the normal range, such as a significant drop in peak TPS and an abnormal surge in CPU usage.

[0128] The comprehensive score or operation efficiency evaluation result reaches the preset alarm threshold.

[0129] The diagnostic results are the nature and possible causes of the fault obtained after analyzing the monitoring data. In the visual report, the diagnostic results are recorded in detail to provide guidance for troubleshooting. The diagnostic results include:

[0130] Fault type: such as hardware failure, software error, improper configuration, etc.

[0131] Fault cause analysis: Based on the analysis of the fault prediction model, it provides possible causes of the fault and helps understand the nature of the problem.

[0132] Repair suggestions: Combined with historical fault handling records, possible repair measures and operation suggestions are provided to operation and maintenance personnel.

[0133] Repair status tracking shows the repair measures taken for detected faults and their execution results. In the visual report, the transparency of the repair status helps track the progress of fault handling and ensure the timeliness and effectiveness of service restoration. The repair status includes:

[0134] Detailed record of repair measures: records every repair operation performed, including operation type, time, target, etc.

[0135] Repair result: Displays the service status after each repair operation, such as whether the service has returned to normal, whether the performance has improved, etc.

[0136] Continuous tracking of repair status: Continuously display the service performance trend after the repair measures are executed until the service status is stable.

[0137] To ensure the readability and usefulness of the visual report, it is necessary to design easy-to-understand charts and data presentation methods. The report includes:

[0138] Graphical display of monitoring indicators: Use line charts, bar charts, scatter plots and other graphics to intuitively display the real-time values ​​and historical trends of parameters.

[0139] Highlight anomalies: Mark anomalies with bold colors or symbols to make them stand out in reports.

[0140] Tabular presentation of diagnostic results and repair status: Diagnostic results and repair status are recorded in detail in tabular form for easy reference and tracking.

[0141] By generating visual reports containing monitoring indicators, abnormal conditions, diagnostic results and repair status, it can not only provide operation and maintenance personnel with a real-time overview of the microservice operation status, but also help quickly locate problems, understand the causes of failures, and track the progress of fault handling, thereby improving the management efficiency and response speed of microservices and ensuring stable and efficient operation of services.

[0142] In order to enable those skilled in the art to more clearly understand the technical solution of the present application, the implementation process of the method for automated microservice health monitoring of the present application will be described in detail below in conjunction with specific embodiments.

[0143] This embodiment relates to a specific method for automated microservice health monitoring, such as Figure 3 As shown, the following steps are included:

[0144] Configure scheduled tasks and automatically triggered tasks. In this step, set the execution frequency (scheduled) and trigger conditions (automatic) of the monitoring tasks. This usually requires operation and maintenance personnel or system administrators to configure according to service requirements and resource conditions. Scheduled tasks ensure that the monitoring process can be automatically run within the set time interval, and automatically triggered tasks start monitoring according to specific conditions (such as microservice status changes, performance indicator abnormalities, etc.), achieving more flexible and timely monitoring.

[0145] The overall process is divided into two parts. The first part is to obtain the operating efficiency parameters of each microservice in different IDCs, and use the preset efficiency evaluation model to analyze the operating efficiency parameters to obtain the operating efficiency evaluation results of each microservice in different IDCs. The operating efficiency evaluation results are compared with the second preset alarm threshold to determine whether the operating efficiency evaluation results reach the second preset alarm threshold, that is, to determine whether the operating efficiency evaluation results meet the requirements. If so, the process ends; if not, an alarm is triggered.

[0146] The second part is to obtain the operating environment parameters of each microservice in different IDCs, determine the weight of each operating environment parameter according to the preset importance, and calculate the difference between the actual value of each operating environment parameter and the historical average value to obtain the difference score of each operating environment parameter, multiply the difference score of each operating environment parameter by the weight of each operating environment parameter to obtain the weighted score of each operating environment parameter, and then add all the weighted scores to obtain the above-mentioned comprehensive score of each microservice, compare the comprehensive score of each microservice with the first preset alarm threshold, and judge whether the comprehensive score of each microservice reaches the first preset alarm threshold, that is, judge whether the comprehensive score of each microservice meets the requirements. If the requirements are met, the process is terminated; if the requirements are not met, an alarm is triggered.

[0147] After the alarm process is triggered, based on the results of anomaly detection, machine learning algorithms are used to perform fault diagnosis, identify specific fault conditions, and learn effective strategies from historical fault handling records. According to the diagnosis results, corresponding repair measures are executed, such as: Automatically adjust resources: such as increasing CPU or memory allocation. Optimize microservice code: Optimize performance bottlenecks in the code. Hardware failure replacement: If a hardware failure is identified, the hardware replacement or repair process can be triggered. Configuration adjustment: Change environment variables or system parameters to adapt to the operation requirements of microservices.

[0148] Finally, a visual report containing monitoring indicators, abnormal conditions, diagnostic results, and repair status can be generated. The report helps operation and maintenance personnel to intuitively understand the health status and processing effects of microservices through charts and data display. At the same time, the generation of reports also facilitates subsequent analysis and decision-making.

[0149] Through the above process, the automatic monitoring, comparative analysis, fault diagnosis and repair of the operating efficiency and environmental parameters of microservices, as well as the generation of result reports can be achieved, forming a closed-loop fault handling mechanism, which effectively improves the operating quality and operation and maintenance efficiency of microservices.

[0150] The following is a specific embodiment of the application of this application in the context of banking business:

[0151] Background of the implementation example: In order to improve the stability and disaster recovery capabilities of the business system, a large bank adopts a dual-center service deployment architecture, that is, deploying the same service in two different IDCs (Internet data centers) to ensure that when any center fails, the other center can take over the service and maintain business continuity. In order to ensure that the server operating environment and the health status of the microservices in the two centers are consistent, the bank adopts the method of automated microservice health monitoring of the present application.

[0152] Implementation steps:

[0153] (1) Data collection:

[0154] The automated tool traverses the microservices deployed in the two IDCs and collects their operating environment parameters, including system parameters (such as operating system version, kernel parameters), environment variables (such as JVM heap memory settings), startup commands, system version, and hardware configuration (such as CPU model, memory size, and hard disk type). At the same time, the integrated monitoring tool collects the operating efficiency parameters of the microservices, focusing on peak TPS (transactions per second), disk usage, and CPU usage.

[0155] (2) Weighted scoring of operating environment parameters:

[0156] Assign weights to the operating environment parameters based on the preset importance. For example, the system version and hardware configuration may have higher weights than environment variables and startup commands. Then, calculate the difference between the actual value of each parameter and the historical average value to obtain the difference score, and multiply the difference score by the weight to obtain the weighted score. Finally, summarize all weighted scores to provide a comprehensive score for each microservice's environmental consistency in different IDCs.

[0157] (3) Operation efficiency evaluation:

[0158] The collected operating efficiency parameters are input into the preset efficiency evaluation model. Based on historical data and the performance indicators of microservices, the model can analyze whether the operating efficiency of services in different IDCs is consistent and whether there are performance bottlenecks, and obtain the operating efficiency evaluation results of each microservice.

[0159] (4) Alarm mechanism:

[0160] Set the first preset alarm threshold and the second preset alarm threshold. When the comprehensive score of the microservice reaches the first preset alarm threshold, and / or the operation efficiency score reaches the second preset alarm threshold, an alarm will be automatically triggered, and the operation and maintenance team will be notified via email, SMS or internal notification system, describing the specific circumstances and possible causes of the failure.

[0161] (5) Fault prediction and automatic repair:

[0162] Based on the bank's historical fault data and fault handling records, a fault prediction model is trained. When the operating environment parameters or operating efficiency parameters of the microservice are detected to deviate from the normal range, the model analyzes the data and automatically identifies the fault situation. If a fault is determined to exist, repair measures are automatically executed according to the fault handling strategy learned by the model, such as restarting the service, adjusting resource configuration, optimizing code, etc.

[0163] (6) Visual report generation:

[0164] Automatically generate a visual report containing microservice operating environment parameters, operating efficiency parameters, fault conditions, and repair status. The report displays the trends and differences of each parameter in the form of charts and text, as well as detailed records of fault detection and repair, to facilitate in-depth analysis and subsequent optimization by the operation and maintenance team.

[0165] Implementation effect:

[0166] By adopting the automated microservice health monitoring method of this application, the bank has achieved real-time monitoring of the running status of microservices, and can detect environmental configuration inconsistencies and performance bottlenecks early, prevent potential failures, and ensure that business continuity is not affected. At the same time, the automated fault prediction and repair functions reduce the manual intervention of the operation and maintenance team, improve the fault response speed, reduce the operation and maintenance costs, and enhance the overall stability and security of the bank's IT system.

[0167] The embodiment of the present application also provides a device for automated microservice health monitoring. It should be noted that the device for automated microservice health monitoring in the embodiment of the present application can be used to execute the method for automated microservice health monitoring provided in the embodiment of the present application. The device is used to implement the above-mentioned embodiments and preferred implementation modes, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceived.

[0168] The following is an introduction to the device for automated microservice health monitoring provided in an embodiment of the present application.

[0169] Figure 4 is a structural block diagram of an apparatus for automated microservice health monitoring according to an embodiment of the present application. Figure 4 As shown, the device includes: an acquisition unit 10, a scoring processing unit 20, an evaluation unit 30 and an alarm unit 40.

[0170] An acquisition unit 10 is used to acquire operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers;

[0171] A scoring processing unit 20 is used to process all the operating environment parameters collected from different Internet data centers, perform weighted scoring on the operating environment parameters of the same microservice in different Internet data centers, and obtain a comprehensive score for each microservice;

[0172] An evaluation unit 30 is used to determine the operating efficiency of the same microservice in different Internet data centers according to the operating efficiency parameters, and obtain operating efficiency evaluation results of the plurality of microservices;

[0173] The alarm unit 40 is used to trigger an alarm when the above-mentioned comprehensive score reaches a first preset alarm threshold and / or the above-mentioned operation efficiency evaluation result reaches a second preset alarm threshold.

[0174] In one embodiment of the present application, the acquisition unit includes:

[0175] The first collection module is used to traverse all the above-mentioned Internet data centers and use automated tools to collect the above-mentioned operating environment parameters of the above-mentioned microservices of each of the above-mentioned Internet data centers, wherein the above-mentioned operating environment parameters include system parameters, environment variables, startup commands, system versions and hardware configurations.

[0176] In another embodiment of the present application, the acquisition unit includes:

[0177] The second collection module is used to collect the above-mentioned operating efficiency parameters of each of the above-mentioned microservices in each of the above-mentioned Internet data centers through a monitoring tool, wherein the above-mentioned operating efficiency parameters include peak TPS, disk utilization and CPU utilization.

[0178] In another embodiment of the present application, the scoring processing unit includes:

[0179] A determination module, used to determine the weight of each of the operating environment parameters of the same microservice in different Internet data centers according to a preset importance, wherein the weight reflects the importance of each of the operating environment parameters;

[0180] A calculation module, used to calculate the difference between the actual value and the historical average value of each of the above operating environment parameters, and obtain the difference score of each of the above operating environment parameters;

[0181] A multiplication module, used for multiplying the difference score of each of the operating environment parameters by the weight of each of the operating environment parameters to obtain a weighted score of each of the operating environment parameters;

[0182] The adding module is used to add all the above weighted scores to obtain the above comprehensive score of each of the above microservices.

[0183] In another embodiment of the present application, the evaluation unit includes:

[0184] The analysis module is used to input the above-mentioned operating efficiency parameters into a preset efficiency evaluation model for analysis, so as to obtain the above-mentioned operating efficiency evaluation results of each of the above-mentioned microservices in different above-mentioned Internet data centers, wherein the above-mentioned preset efficiency evaluation model analyzes the above-mentioned operating efficiency parameters based on historical data and preset rules.

[0185] In order to reduce the manual troubleshooting and processing work of operation and maintenance personnel and improve the timeliness and efficiency of fault response, in one embodiment of the present application, the above-mentioned device also includes:

[0186] A training unit, used for training a fault prediction model based on historical fault data and fault handling records;

[0187] An analysis unit, configured to input the operating environment parameters and the operating efficiency parameters of the microservices collected from different Internet data centers into the fault prediction model for analysis, and automatically identify the fault conditions of the microservices;

[0188] The execution unit is used to execute corresponding repair measures according to the fault handling strategy learned by the above fault prediction model if a fault is detected.

[0189] In order to provide a real-time overview of the running status of microservices, in one embodiment of the present application, the above-mentioned device further includes:

[0190] The generating unit is used to generate a visual report, wherein the visual report includes monitoring indicators, abnormal conditions, diagnosis results and repair status.

[0191] The above-mentioned device for automated microservice health monitoring includes a processor and a memory. The above-mentioned acquisition unit, scoring processing unit, evaluation unit, alarm unit, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to implement corresponding functions. The above-mentioned modules are all located in the same processor; or, the above-mentioned modules are located in different processors in any combination.

[0192] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0193] An embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute the method for automated microservice health monitoring.

[0194] An embodiment of the present invention provides an electronic device, including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, the steps of the above-mentioned method for automated microservice health monitoring are implemented.

[0195] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program that initializes the steps of the above-mentioned method for automated microservice health monitoring.

[0196] Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order than here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present invention is not limited to any specific combination of hardware and software.

[0197] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0198] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, 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 generate 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 flowchart and / or block diagram. 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.

[0199] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate 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 A function specified in one or more boxes.

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

[0201] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0202] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0203] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0204] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0205] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for automated microservice health monitoring, characterized in that: include: Obtain the operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers; Processing all the operating environment parameters collected from different Internet data centers, performing weighted scoring on the operating environment parameters of the same microservice in different Internet data centers, and obtaining a comprehensive score for each microservice; Determine the operating efficiency of the same microservice in different Internet data centers according to the operating efficiency parameter, and obtain operating efficiency evaluation results of multiple microservices; When the comprehensive score reaches a first preset alarm threshold, and / or the operation efficiency evaluation result reaches a second preset alarm threshold, an alarm is triggered.

2. The method according to claim 1, characterized in that Obtain the operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers, including: Traversing all the Internet data centers, and using automated tools to collect the operating environment parameters of the microservices of each Internet data center, The operating environment parameters include system parameters, environment variables, startup commands, system version and hardware configuration.

3. The method according to claim 1, characterized in that Obtain the operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers, including: Collect the operating efficiency parameters of each microservice in each Internet data center through a monitoring tool, The operating efficiency parameters include peak TPS, disk usage and CPU usage.

4. The method according to claim 1, characterized in that: The operating environment parameters of the same microservice in different Internet data centers are weighted and scored to obtain a comprehensive score for each microservice, including: Determine the weight of each of the operating environment parameters of the same microservice in different Internet data centers according to a preset importance, where the weight reflects the importance of each of the operating environment parameters; Calculate the difference between the actual value and the historical average value of each of the operating environment parameters to obtain a difference score for each of the operating environment parameters; Multiplying the difference score of each operating environment parameter by the weight of each operating environment parameter to obtain a weighted score of each operating environment parameter; All the weighted scores are added together to obtain the comprehensive score of each microservice.

5. The method according to claim 1, characterized in that Determining the operating efficiency of the same microservice in different Internet data centers according to the operating efficiency parameters, and obtaining operating efficiency evaluation results of multiple microservices, including: The operating efficiency parameters are input into a preset efficiency evaluation model for analysis to obtain the operating efficiency evaluation results of each microservice in different Internet data centers. The preset efficiency evaluation model analyzes the operating efficiency parameters based on historical data and preset rules.

6. The method according to claim 1, characterized in that The method further comprises: Train the fault prediction model based on historical fault data and fault handling records; Inputting the operating environment parameters and the operating efficiency parameters of the microservice collected from different Internet data centers into the fault prediction model for analysis, and automatically identifying the fault conditions of the microservice; If a fault is detected, corresponding repair measures are executed according to the fault handling strategy learned by the fault prediction model.

7. The method according to claim 1, characterized in that The method further comprises: Generate a visual report including monitoring indicators, abnormal conditions, diagnosis results and repair status.

8. An apparatus for automated microservice health monitoring, characterized in that: include: An acquisition unit, used to acquire operating environment parameters and operating efficiency parameters of each microservice in different Internet data centers; A scoring processing unit, used to process all the operating environment parameters collected from different Internet data centers, perform weighted scoring processing on the operating environment parameters of the same microservice in different Internet data centers, and obtain a comprehensive score for each microservice; An evaluation unit, configured to determine the operation efficiency of the same microservice in different Internet data centers according to the operation efficiency parameter, and obtain operation efficiency evaluation results of multiple microservices; The alarm unit is used to trigger an alarm when the comprehensive score reaches a first preset alarm threshold and / or the operation efficiency evaluation result reaches a second preset alarm threshold.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the method for automated microservice health monitoring according to any one of claims 1 to 7.

10. An electronic device, characterized in that: include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include a method for performing automated microservice health monitoring as described in any one of claims 1 to 7.

Images