Methods, devices, equipment, and storage media for determining microservice exceptions

Abstract

This disclosure provides a method, apparatus, device, and storage medium for determining microservice anomalies, which can be applied to the fields of computer technology or fintech. The method includes: obtaining an initial list of microservice devices from a microservice registry via a preset interface; obtaining a current list of microservice devices from the microservice registry via the preset interface, wherein the current list of microservice devices is returned by the microservice registry after performing heartbeat detection on multiple microservice devices, and the current list of microservice devices includes a second set of device identifiers; comparing a first set of device identifiers and a second set of device identifiers to determine a first abnormal device identifier from the first set of device identifiers; and determining an abnormal microservice device from among the multiple microservice devices based on the first abnormal device identifier.

Description

Technical Field

[0001] This disclosure relates to the fields of computer technology or financial technology, and more particularly to a method, apparatus, device, storage medium, and program product for determining microservice anomalies. Background Technology

[0002] Traditional monolithic service architectures suffer from problems such as excessive project complexity, difficulty in extending the technology stack, and difficulty in maintenance. In response, microservice distributed architectures have emerged. During the development of this invention, the inventors discovered the following problems in related technologies: with the distributed deployment of microservices, anomalies in some microservices often go undetected, eventually leading to a cascading failure effect and service crashes. The inability to promptly identify anomalies in microservices further reduces the efficiency and accuracy of anomaly handling. Summary of the Invention

[0003] In view of the above problems, this disclosure provides a method, apparatus, device, storage medium and program product for determining microservice exceptions, in order to at least partially solve the above problems.

[0004] One aspect of this disclosure provides a method for determining microservice anomalies, comprising: obtaining an initial microservice device list from a microservice registry via a preset interface, wherein the initial microservice device list is obtained based on the registration of multiple microservice devices in the microservice registry, and the microservice device list includes a first set of device identifiers; obtaining a current microservice device list from the microservice registry via the preset interface, wherein the current microservice device list is returned by the microservice registry after performing heartbeat detection on multiple microservice devices, and the current microservice device list includes a second set of device identifiers; comparing the first set of device identifiers and the second set of device identifiers to determine a first abnormal device identifier from the first set of device identifiers; and determining an abnormal microservice device from among the multiple microservice devices based on the first abnormal device identifier.

[0005] According to embodiments of this disclosure, the method further includes: collecting operational information of multiple microservice devices through a log collector to obtain operational logs; searching for abnormal operational information from the operational logs based on a preset expression; and determining a second abnormal device identifier based on the abnormal operational information.

[0006] According to embodiments of this disclosure, the method further includes: analyzing in real time the abnormal information associated with the first abnormal device identifier and the second abnormal device identifier respectively, and obtaining analysis results; and storing the analysis results in a time-series database.

[0007] According to embodiments of this disclosure, the time-series database is connected to a visualization component; the method further includes: obtaining the analysis results from the time-series database; generating an analysis report based on the analysis results; and displaying the analysis report through the visualization component.

[0008] According to an embodiment of this disclosure, the microservice device described above runs microservices, and the preset expression described above is determined in the following manner: setting abnormal thresholds for multiple metrics of the microservices; and setting the preset expression based on the abnormal thresholds described above.

[0009] According to embodiments of this disclosure, the method further includes: configuring an alarm policy for the microservice device based on the above-mentioned abnormal threshold; and generating and sending alarm information using a message notification component based on the above-mentioned alarm policy.

[0010] According to embodiments of this disclosure, the method further includes: in response to the microservice startup request, the microservice device actively registers with the microservice center to obtain configuration information associated with the startup request; and pulls the configuration information into the microservice device's local database to start the microservice.

[0011] This disclosure also provides a device for determining microservice anomalies, comprising: a first acquisition module, configured to acquire an initial microservice device list from a microservice registry via a preset interface, wherein the initial microservice device list is obtained based on the registration of multiple microservice devices in the microservice registry, and the microservice device list includes a first device identifier set; a second acquisition module, configured to acquire a current-time microservice device list from the microservice registry via the preset interface, wherein the current-time microservice device list is returned by the microservice registry after performing heartbeat detection on multiple microservice devices, and the current-time microservice device list includes a second device identifier set; a comparison module, configured to compare the first device identifier set and the second device identifier set to determine a first abnormal device identifier from the first device identifier set; and a first determination module, configured to determine an abnormal microservice device from the multiple microservice devices based on the first abnormal device identifier.

[0012] This disclosure also provides an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the aforementioned method for determining microservice exceptions.

[0013] This disclosure also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the aforementioned method for determining microservice exceptions.

[0014] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the method for determining microservice exceptions described above.

[0015] According to the microservice anomaly determination method, apparatus, device, storage medium, and program product provided in this disclosure, an initial microservice device list and a current microservice device list are obtained from a microservice registry center via a preset interface; a first abnormal device identifier is determined by comparing a first device identifier and a second device identifier in the two lists; and an abnormal device is identified based on the first abnormal device identifier. Because the initial microservice device list and the current microservice device list are compared, inconsistencies indicate that a microservice backup has gone offline, thereby enabling monitoring of terminated microservice devices and comprehensive monitoring of abnormal situations during microservice operation. Therefore, this at least partially solves the problem of some microservice anomalies going undetected, achieving the technical effect of improving the efficiency and accuracy of anomaly handling. Attached Figure Description

[0016] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0017] Figure 1 The illustrations illustrate application scenarios of a method, apparatus, device, storage medium, and program product for determining microservice anomalies according to embodiments of the present disclosure.

[0018] Figure 2 A flowchart illustrating a method for determining microservice anomalies according to an embodiment of this disclosure is shown schematically.

[0019] Figure 3 The diagram illustrates a system architecture of a method for determining microservice anomalies according to an embodiment of the present disclosure.

[0020] Figure 4 A schematic block diagram illustrating a microservice anomaly determination apparatus according to an embodiment of the present disclosure is shown; and

[0021] Figure 5 A block diagram of an electronic device suitable for implementing a method for determining microservice anomalies according to an embodiment of the present disclosure is shown schematically. Detailed Implementation

[0022] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0024] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0025] When using expressions such as "at least one of A, B, and C", they should generally be interpreted in accordance with the meaning that is commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc.).

[0026] Traditional monolithic service architectures suffer from problems such as excessive project complexity, difficulty in extending the technology stack, and difficulty in maintenance, leading to the emergence of microservice distributed architectures. However, with the distributed deployment of microservices, anomalies often cannot be detected immediately, eventually causing a cascading failure effect and service crashes.

[0027] Therefore, relevant technologies generally monitor microservice request responses based on Skywalking (an application performance monitoring tool for distributed systems) or Sentry (an error monitoring and collection system for anomaly reporting and monitoring), or monitor microservice traffic based on Sentinel-client (a traffic control component for distributed services). Sentry is a mainstream solution, but its deployment is complex, requiring numerous containers and making management cumbersome. The other two methods require integrating the corresponding framework into the microservice, rendering them ineffective for monitoring when the microservice is terminated. For example, when releasing a new microservice version, it's difficult to monitor if some microservices fail to start normally using existing methods.

[0028] Therefore, since the relevant solutions are essentially based on providing monitoring data after integration into microservices to achieve the effect of microservice anomaly monitoring, the monitoring of microservices can only be performed on running microservices. Because of this, not only is the code highly intrusive, but the monitoring data function is also ineffective when the microservice is in a terminated state, making terminated microservices unmonitored or unable to be monitored in a timely manner, thus reducing the efficiency and accuracy of anomaly handling.

[0029] In view of this, this disclosure provides a method, apparatus, device, storage medium, and program product for determining microservice anomalies, to improve the efficiency and accuracy of handling anomalies. Specifically, the method includes: obtaining an initial microservice device list from a microservice registry through a preset interface, wherein the initial microservice device list is obtained based on the registration of multiple microservice devices in the microservice registry, and the microservice device list includes a first set of device identifiers; obtaining a current microservice device list from the microservice registry through the preset interface, wherein the current microservice device list is returned by the microservice registry based on heartbeat detection of multiple microservice devices, and the current microservice device list includes a second set of device identifiers; comparing the first set of device identifiers and the second set of device identifiers to determine a first abnormal device identifier from the first set of device identifiers; and determining an abnormal microservice device from multiple microservice devices based on the first abnormal device identifier.

[0030] It should be noted that the method and apparatus for determining microservice anomalies as defined in this disclosure can be used in the fields of computer technology or financial technology, or in any field other than computer technology or financial technology. This disclosure does not limit the application field of the method and apparatus for determining microservice anomalies.

[0031] In the technical solutions disclosed herein, the collection, storage, use, processing, transmission, provision, disclosure, and application of data (including but not limited to user personal information) comply with the provisions of relevant laws and regulations, necessary confidentiality measures have been taken, and they do not violate public order and good morals.

[0032] Figure 1 The illustrations illustrate application scenarios of methods, apparatus, devices, storage media, and program products for determining microservice anomalies according to embodiments of the present disclosure.

[0033] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, a microservice device cluster 105, a microservice registry 106, and a server 107. The network 104 serves as a medium for providing communication links between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the microservice device cluster 105; between the microservice device cluster 105 and the microservice registry 106; and between the microservice registry 106 and the server 107. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0034] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays, including but not limited to smartphones, tablets, laptops, and desktop computers. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0035] Users can send business requests to the microservice device cluster 105 using at least one of the first terminal device 101, the second terminal device 102, and the third terminal device 103. For example, a user might need to browse a specified webpage or view text and images linked within it. The microservice device cluster 105 can contain multiple microservice devices. The microservices running on these devices can process the business requests, such as retrieving or generating webpages, information, images, or data based on the user's request and feeding them back to at least one of the first terminal device 101, the second terminal device 102, and the third terminal device 103. During the process of handling these business requests, anomalies may occur. Therefore, it is necessary to monitor the microservice devices and handle these anomalies to ensure the normal operation of the business.

[0036] The microservice registry 106 can include configuration files for microservices. For example, Nacos (a microservice platform). Microservices actively register with the microservice registry 106 upon startup, and the registry 106 can also perform heartbeat monitoring on microservice devices.

[0037] Server 107 can be a server that provides various services. For example, it can obtain an initial list of microservice devices and a list of microservice devices at the current time from the microservice registry 106 through a preset interface; compare the first set of device identifiers and the second set of device identifiers that exist in the two lists respectively, determine the first abnormal device identifier from the first set of device identifiers; and determine the abnormal microservice device from multiple microservice devices based on the first abnormal device identifier.

[0038] It should be noted that the microservice anomaly determination method provided in this embodiment can generally be executed by server 107. Correspondingly, the microservice anomaly determination device provided in this embodiment can generally be located in server 107. The microservice anomaly determination method provided in this embodiment can also be executed by a server or server cluster that is different from server 107 but can communicate with microservice registry 106 and / or server 107. Correspondingly, the microservice anomaly determination device provided in this embodiment can also be located in a server or server cluster that is different from server 107 but can communicate with microservice registry 106 and / or server 107. It should also be noted that server 107 can also directly interact with the microservice cluster to monitor running microservices.

[0039] It should be understood that Figure 1 The number of terminal devices, microservice devices, networks, microservice registries, and servers shown in the diagram is merely illustrative. Depending on implementation needs, any number of terminal devices, microservice devices, networks, microservice registries, and servers can be included.

[0040] The following will be based on Figure 1 The described scene, through Figures 2-3 The method for determining microservice anomalies according to the disclosed embodiments is described in detail.

[0041] Figure 2 A flowchart illustrating a method for determining microservice anomalies according to an embodiment of this disclosure is shown schematically.

[0042] like Figure 2 As shown, the method for determining microservice anomalies in this embodiment includes operations S201 to S204.

[0043] In operation S201, an initial microservice device list is obtained from the microservice registry through a preset interface. The initial microservice device list is obtained based on the registration of multiple microservice devices in the microservice registry, and the microservice device list includes a first set of device identifiers.

[0044] In operation S202, the current microservice device list is obtained from the microservice registry through a preset interface. The current microservice device list is returned by the microservice registry after performing heartbeat detection on multiple microservice devices. The current microservice device list includes a second set of device identifiers.

[0045] In operation S203, the first device identifier set and the second device identifier set are compared in order to determine the first abnormal device identifier from the first device identifier set.

[0046] In operation S204, the abnormal microservice device is identified from multiple microservice devices based on the first abnormal device identifier.

[0047] According to embodiments of this disclosure, the default interface is, for example, an API (Application Programming Interface). Communication between the server and the microservice registry can be achieved through the API interface. The default interface can also be adaptively adjusted according to actual needs.

[0048] According to embodiments of this disclosure, the microservice registry center may be, for example, Nacos (Dynamic Naming and Configuration Service, a registry / configuration service center). The microservice registry center is used to provide registration services and configuration information retrieval services to microservices.

[0049] According to embodiments of this disclosure, the initial microservice device list can be understood as the full list obtained when microservice devices first register with the microservice registry. The first device identifier refers to an identifier capable of identifying the microservice device, such as the IP address of the microservice device. The first device identifier set can be a set consisting of multiple IP addresses. Optionally, in addition to IP address information, the initial microservice device list may also include other information, such as CPU (central processing unit) information, GPU (graphics processing unit) information, disk information, network bandwidth, memory, etc.

[0050] According to embodiments of this disclosure, the current list of microservice devices can be understood as the list of currently online microservice devices obtained after the microservice devices have registered and started running. "Current moment" can be understood as the moment when the online microservice devices are obtained.

[0051] According to embodiments of this disclosure, the purpose of performing heartbeat detection on microservices can be to detect whether the microservice device is still online. Heartbeat detection can be understood as a periodic operation used to check whether communication and information exchange are maintained between the microservice device and the microservice registry. For example, after a microservice starts, it sends a "heartbeat packet" to the microservice registry at regular intervals. This heartbeat packet contains basic information about the service at the current moment. Upon receiving this heartbeat packet, the microservice registry first checks whether the current microservice is in the registered list. If it is not in the registered list, it registers the service as a new service; if it is in the registered list, it indicates that the microservice is in a healthy state, meaning the microservice device is online and running normally. If a microservice fails to interact with the microservice registry multiple times consecutively, the microservice device is considered offline.

[0052] According to embodiments of this disclosure, it should be understood that because microservice devices may experience disconnections during operation, the current list of microservice devices will differ from the initial list. In one embodiment, the server can periodically call an API interface to obtain the current list of microservice devices.

[0053] According to embodiments of this disclosure, the second device identifier refers to an identifier capable of identifying a microservice device, such as the IP address of the microservice device. The set of second device identifiers can be a set consisting of multiple IP addresses. Optionally, the list of microservice devices at the current moment may include other information in addition to IP address information, such as CPU (central processing unit) information, GPU (graphics processing unit) information, disk information, network bandwidth, memory, etc.

[0054] According to embodiments of this disclosure, the first abnormal device identifier can be an identifier that exists in a first device identifier set but does not exist in a second device identifier set, such as an IP address that exists in the first device identifier set but does not exist in the second device identifier set. This IP address can be used to represent a microservice device that has gone offline. An abnormal microservice device can refer to this offline microservice device.

[0055] According to the microservice anomaly determination method, apparatus, device, storage medium, and program product provided in this disclosure, an initial microservice device list and a current microservice device list are obtained from a microservice registry center via a preset interface; a first abnormal device identifier is determined by comparing a first device identifier and a second device identifier in the two lists; and an abnormal device is identified based on the first abnormal device identifier. Because the initial microservice device list and the current microservice device list are compared, inconsistencies indicate that a microservice backup has gone offline, thereby enabling monitoring of terminated microservice devices and comprehensive monitoring of abnormal situations during microservice operation. Therefore, this at least partially solves the problem of some microservice anomalies going undetected, achieving the technical effect of improving the efficiency and accuracy of anomaly handling.

[0056] Figure 3 A system architecture diagram illustrating a method for determining microservice anomalies according to an embodiment of this disclosure is shown schematically. The following is based on... Figure 3 The system architecture shown provides a detailed description of the methods provided in the embodiments of this disclosure.

[0057] like Figure 3 As shown, the system architecture 300 may include a business request module 301, a Nacos microservice registry (hereinafter referred to as Nacos) 302, multiple microservice devices 303, a log collector 304, a message queue module 305, a monitoring and analysis microservice module 306, a time-series database 307, a visualization component 308, and an information notification module 309. Each microservice device runs a microservice. Connections between modules can be made via wired, wireless communication links, or fiber optic cables.

[0058] like Figure 3 As shown, the above method may also include the following startup operations: in response to the microservice startup request, the microservice device actively registers with the microservice center in order to obtain the configuration information associated with the startup request; the configuration information is pulled into the microservice device's local database in order to start the microservice.

[0059] According to embodiments of this disclosure, the service request module can send service requests, such as browsing web pages, downloading images, and opening links. These service requests can be implemented through at least one terminal device. The microservice startup request can be triggered by these service requests. For example, if browsing a web page is required, a microservice needs to be processed, and the microservice needs to be started to enable web page browsing according to the service request.

[0060] According to embodiments of this disclosure, when a microservice on a microservice device starts, it actively registers with Nacos. The microservice's configuration file can be set in Nacos's configuration center. Simultaneously with or after registering, the microservice device can retrieve relevant configuration information such as configuration files, business parameters, historical data, and attribute parameters into its local database to enable microservice startup.

[0061] According to embodiments of this disclosure, in cases of high traffic, multiple microservice devices can be started and registered during proactive registration to improve business processing efficiency. For example, if the access volume exceeds a threshold, several microservice devices can be automatically added to register with Nacos through pre-set policies or written scripts to achieve dynamic scaling of microservices, ensuring normal business operation and improving processing efficiency. This process achieves dynamic scaling of microservices without manual intervention, reducing labor costs and improving the automation of microservice monitoring.

[0062] like Figure 3 As shown, the above method may further include the following operations: collecting runtime information from multiple microservice devices using a log collector to obtain runtime logs; searching for abnormal runtime information from the runtime logs based on a preset expression; and determining a second abnormal device identifier based on the abnormal runtime information. The preset expression is determined as follows: setting abnormal thresholds for multiple metrics of the microservice; and setting the preset expression based on the abnormal thresholds.

[0063] According to embodiments of this disclosure, monitoring of microservice anomalies can be divided into two categories: monitoring of running microservices and monitoring of terminated microservices. Monitoring of running microservices can be achieved through a log collector and a message queue module. For example, the log collector filters and analyzes the collected abnormal runtime information through scripts, and then feeds the abnormal runtime information back to the monitoring and analysis microservice module through the message queue module, thereby achieving monitoring of running microservices.

[0064] According to embodiments of this disclosure, a microservice can have multiple operational metrics, such as execution time, response time, number of operational exceptions, and queries per second (QPS). Each metric can be configured with a corresponding exception threshold; if a metric exceeds or falls below the exception threshold, the microservice is considered to be malfunctioning. The operational information of a microservice can refer to data and parameters generated by the microservice device during the processing of business requests, such as response time, processing time, number of exceptions, QPS, and whether memory overflow occurred. It should also be understood that, since each microservice handles different business processes, the operational information should include the device identifier of each microservice device, as well as the data and parameters collected based on that device identifier.

[0065] According to embodiments of this disclosure, the preset expression can be set based on an anomaly threshold. For example, if a response time greater than 5 seconds is considered a microservice anomaly, the preset expression could be "if the response time > 5 seconds". Based on this preset expression, a search can be performed in the runtime log to filter out content matching the preset expression. It should be understood that the filtered information can include not only the anomaly value but also the identifier of the microservice device associated with the anomaly value. The abnormal runtime information can refer to the anomaly value, and the second anomaly device identifier can refer to the identifier of the microservice device associated with the anomaly value. There can be multiple second anomaly device identifiers, thus indicating that multiple microservices have experienced anomalies.

[0066] According to embodiments of this disclosure, Go scripts can also be used to analyze important anomalies in the logs collected during operation. This analysis can determine whether the service process is running normally or whether the service function is malfunctioning, such as memory overflow.

[0067] According to embodiments of this disclosure, terminated microservices are detected as follows: The monitoring and analysis microservice module proactively and periodically calls the Nacos API to obtain a list of currently online microservice devices, including device IP addresses and other information. When a microservice device first connects to Nacos, the monitoring and analysis microservice module can obtain a full list of microservice devices through the API and cache it in memory. If the full list of microservice devices in memory is inconsistent with the list of online microservice devices returned by the latest heartbeat monitoring, it indicates that a microservice has gone offline and the service is abnormal. At this time, based on the inconsistency comparison result, the microservice name and IP address of the abnormal microservice device can be obtained. In one embodiment, the monitoring and analysis microservice module can be equivalent to... Figure 1 Server 107 in the middle.

[0068] According to embodiments of this disclosure, by comparing the full list of microservice devices with the latest list of online microservice devices returned by heartbeat monitoring, in the event of inconsistency, it can be indicated that a microservice backup has gone offline. This enables the monitoring of terminated microservice devices and achieves comprehensive monitoring of abnormal situations during microservice operation. Therefore, it at least partially solves the problem in related technologies where abnormalities in terminated microservice devices cannot be detected or cannot be detected in a timely manner, improving the efficiency and accuracy of abnormal situation handling.

[0069] According to embodiments of this disclosure, a first abnormal device identifier can correspond to a microservice device in a terminated state, and a second abnormal device identifier can correspond to a microservice device in a running state that is abnormal. There can be multiple first and second abnormal device identifiers. After obtaining the first and second abnormal device identifiers, the abnormal information associated with each identifier can be analyzed in real time to obtain analysis results; these results are then stored in a time-series database.

[0070] According to embodiments of this disclosure, the monitoring and analysis microservice module can analyze the abnormal information associated with the first abnormal device identifier and the second abnormal device identifier, and obtain the abnormal items, abnormal values, and abnormal device identifiers, etc. By summarizing the contents of these abnormalities, the analysis results can be obtained, which can be stored in a time-series database for easy subsequent display.

[0071] According to embodiments of this disclosure, the time series database is connected to a visualization component; after the analysis results can be stored in the time series database, the analysis results can be retrieved from the time series database; an analysis report is generated based on the analysis results; and the analysis report is displayed through the visualization component.

[0072] According to embodiments of this disclosure, the analysis report can be a clearer and more concise graph created based on the analysis results, such as an image, table, tree diagram, or guide map drawn based on the analysis results, so that business personnel can make decisions through the analysis report.

[0073] According to embodiments of this disclosure, the visualization component can access a time-series database and can also generate reports and graph display platforms in real time to display various metrics of microservices, such as QPS and time-consuming time-series graphs, thereby realizing the visualization of microservice status.

[0074] According to embodiments of this disclosure, by visually displaying and analyzing reports and various metrics of microservices, business personnel can be provided with decision-making support and timely handling of abnormal microservices.

[0075] According to embodiments of this disclosure, the method further includes configuring an alarm policy for the microservice device based on an anomaly threshold; and generating and sending alarm information using a message notification component based on the alarm policy.

[0076] According to embodiments of this disclosure, the purpose of setting alarm policies is to draw the attention of business personnel so that anomalies can be handled promptly. When setting alarm policies, different alarm policies can be set for each operational indicator when it exceeds an abnormal threshold. These alarm policies can be adaptively adjusted according to actual needs. For example, alarm policies with different levels / priorities can be set based on the impact of the anomaly. Anomalies can be handled sequentially according to their level / priority, improving the efficiency of handling anomalies. It is understood that anomalies that the system can handle automatically do not require notification to business personnel; only anomalies that the system can handle automatically can require notification to business personnel. This improves the efficiency of anomaly handling and reduces the labor costs for business personnel.

[0077] According to embodiments of this disclosure, when reminding business personnel, the message notification component can be used to find the corresponding information notification template according to the alarm policy. After concatenating the abnormal operation information and the information notification template, alarm information can be obtained, which can then be sent through the message notification component.

[0078] According to embodiments of this disclosure, a microservice monitoring method based on Nacos, visualization components, and log collection and analysis is provided. This method mainly comprises timed heartbeat monitoring, error log analysis and reporting, visualization, anomaly message filtering, and anomaly alarm notification. It enables anomaly monitoring of running and terminated microservices and allows for sending alarm information to business personnel. Furthermore, alarm policies are set for anomalies to achieve real-time monitoring and alarms for microservices. This ensures that business personnel can resolve issues promptly before or immediately after an impact, preventing widespread business failures.

[0079] According to embodiments of this disclosure, a method for proactively monitoring terminated microservice anomalies using Nacos's API is provided. An automatic, dynamic microservice monitoring method using Nacos's API can support seamless expansion of microservice monitoring. A microservice monitoring method integrating proactive heartbeat monitoring and task request monitoring ensures comprehensive monitoring of microservice operational status and improves the accuracy of handling microservice anomalies.

[0080] The microservice monitoring method based on Nacos, visualization components, and log collection analysis provided in this disclosure introduces timed proactive heartbeat detection. This enables timely detection of anomalies even when a microservice is in an abnormal termination state, avoiding the shortcomings of existing solutions that rely on the return status at microservice startup for monitoring. This distributed microservice monitoring method, capable of monitoring both running and terminated microservices and providing visualized decision-making and real-time anomaly alerts, offers robust operational assurance for systems with distributed cluster structures.

[0081] It should be noted that, unless it is explicitly stated that there is a sequential order of execution between different operations, or that there is a sequential order of execution between different operations in terms of technical implementation, the execution order between multiple operations may not be significant, and multiple operations may be executed simultaneously.

[0082] Based on the above-described method for determining microservice anomalies, this disclosure also provides a device for determining microservice anomalies. The following will be combined with... Figure 4 The device is described in detail.

[0083] Figure 4 A schematic block diagram of a microservice anomaly determination apparatus according to an embodiment of the present disclosure is shown.

[0084] like Figure 4 As shown, the microservice anomaly determination device 400 in this embodiment includes a first acquisition module 410, a second acquisition module 420, a comparison module 430, and a first determination module 440.

[0085] The first acquisition module 410 is used to obtain an initial microservice device list from the microservice registry center through a preset interface. The initial microservice device list is obtained based on the registration of multiple microservice devices in the microservice registry center, and the microservice device list includes a first device identifier set.

[0086] The second acquisition module 420 is used to obtain the current microservice device list from the microservice registry through a preset interface. The current microservice device list is returned by the microservice registry after performing heartbeat detection on multiple microservice devices. The current microservice device list includes a second set of device identifiers.

[0087] The comparison module 430 is used to compare the first device identifier set and the second device identifier set in order to determine the first abnormal device identifier from the first device identifier set.

[0088] The first determination module 440 is used to determine the abnormal microservice device from multiple microservice devices based on the first abnormal device identifier.

[0089] According to the microservice anomaly determination method, apparatus, device, storage medium, and program product provided in this disclosure, an initial microservice device list and a current microservice device list are obtained from a microservice registry center via a preset interface; a first abnormal device identifier is determined by comparing a first device identifier and a second device identifier in the two lists; and an abnormal device is identified based on the first abnormal device identifier. Because the initial microservice device list and the current microservice device list are compared, inconsistencies indicate that a microservice backup has gone offline, thereby enabling monitoring of terminated microservice devices and comprehensive monitoring of abnormal situations during microservice operation. Therefore, this at least partially solves the problem of some microservice anomalies going undetected, achieving the technical effect of improving the efficiency and accuracy of anomaly handling.

[0090] According to embodiments of this disclosure, the microservice anomaly determination device may further include a collection module, a search module, and a second determination module.

[0091] The data collection module is used to collect the operation information of multiple microservice devices through a log collector to obtain operation logs.

[0092] The search module is used to search for abnormal runtime information from the runtime log based on preset expressions.

[0093] The second determination module is used to determine the identifier of the second abnormal device based on the abnormal operation information.

[0094] According to embodiments of this disclosure, the microservice anomaly determination device may further include an analysis module and a storage module.

[0095] The analysis module is used to analyze the abnormal information associated with the first abnormal device identifier and the second abnormal device identifier in real time, and obtain the analysis results.

[0096] The storage module is used to store the analysis results into the time series database.

[0097] According to embodiments of this disclosure, the microservice anomaly determination device may further include a third acquisition module, a generation module, and a display module.

[0098] The third acquisition module is used to obtain analysis results from the time series database.

[0099] The generation module is used to generate analysis reports based on the analysis results.

[0100] The presentation module is used to display analytical reports through visualization components.

[0101] According to embodiments of this disclosure, the search module may further include a first setting unit and a second setting unit.

[0102] The first setting unit is used to set abnormal thresholds for multiple metrics of the microservice.

[0103] The second setting unit is used to set a preset expression based on the abnormal threshold.

[0104] According to embodiments of this disclosure, the microservice anomaly determination device may further include a configuration module and a sending module.

[0105] The configuration module is used to configure the alarm policies of microservice devices based on the anomaly threshold.

[0106] The sending module is used to generate and send alarm information using the message notification component according to the alarm policy.

[0107] According to embodiments of this disclosure, the microservice anomaly determination device may further include a response module and a pull module.

[0108] The response module is used to respond to the startup request of a microservice. The microservice device actively registers with the microservice center in order to obtain the configuration information associated with the startup request.

[0109] The pull module is used to pull configuration information into the local database of the microservice device in order to start the microservice.

[0110] According to embodiments of this disclosure, any plurality of modules among the first acquisition module 410, the second acquisition module 420, the comparison module 430, and the first determination module 440 may be combined into one module, or any one of these modules may be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the first acquisition module 410, the second acquisition module 420, the comparison module 430, and the first determination module 440 may be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of software, hardware, and firmware methods, or in a suitable combination of any of these methods. Alternatively, at least one of the first acquisition module 410, the second acquisition module 420, the comparison module 430, and the first determination module 440 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0111] It should be noted that the microservice exception determination device part in the embodiments of this disclosure corresponds to the microservice exception determination method part in the embodiments of this disclosure. For a detailed description of the microservice exception determination device part, please refer to the microservice exception determination method part, which will not be repeated here.

[0112] Figure 5 A block diagram of an electronic device suitable for implementing a method for determining microservice anomalies according to an embodiment of the present disclosure is shown schematically.

[0113] like Figure 5 As shown, an electronic device 500 according to an embodiment of the present disclosure includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The processor 501 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0114] RAM 503 stores various programs and data required for the operation of electronic device 500. Processor 501, ROM 502, and RAM 503 are interconnected via bus 504. Processor 501 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 502 and / or RAM 503. It should be noted that the programs may also be stored in one or more memories other than ROM 502 and RAM 503. Processor 501 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0115] According to embodiments of this disclosure, the electronic device 500 may further include an input / output (I / O) interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0116] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0117] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 502 and / or RAM 503 and / or one or more memories other than ROM 502 and RAM 503 described above.

[0118] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the microservice exception determination method provided in embodiments of this disclosure.

[0119] When the computer program is executed by the processor 501, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0120] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0121] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0122] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0125] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A method for determining microservice exception, comprising: obtaining an initial microservice device list from a microservice registry through a preset interface, wherein the initial microservice device list is obtained according to registration of a plurality of microservice devices in the microservice registry, and the microservice device list comprises a first device identifier set; obtaining a current microservice device list from the microservice registry through the preset interface, wherein the current microservice device list is returned according to heartbeat detection of the microservice registry on a plurality of microservice devices, and the current microservice device list comprises a second device identifier set; comparing the first device identifier set and the second device identifier set to determine a first exception device identifier from the first device identifier set; determining an exception microservice device from a plurality of microservice devices according to the first exception device identifier. 2.The method of claim 1, further comprising: collecting running information of a plurality of microservice devices through a log collector to obtain a running log; searching for exception running information from the running log based on a preset expression; determining a second exception device identifier according to the exception running information. 3.The method of claim 2, further comprising: analyzing exception information associated with the first exception device identifier and the second exception device identifier respectively in real time to obtain an analysis result; storing the analysis result into a time series database.

4. The method of claim 3, wherein, The time series database is connected with a visualization component; The method further comprises: obtaining the analysis result from the time series database; generating an analysis report based on the analysis result; displaying the analysis report through the visualization component.

5. The method of claim 2, wherein, The microservice device runs a microservice, and the preset expression is determined by: setting an exception threshold for a plurality of indexes of the microservice; setting the preset expression according to the exception threshold. 6.The method of claim 5, further comprising: configuring an alarm strategy of the microservice device according to the exception threshold; generating and sending alarm information using a message notification component according to the alarm strategy. 7.The method of claim 5, further comprising: in response to a start request of the microservice, the microservice device actively registers with the microservice registry to obtain configuration information associated with the start request; pulling the configuration information into a local database of the microservice device to start the microservice. 8.A device for determining microservice exception, comprising: a first obtaining module, configured to obtain an initial microservice device list from a microservice registry through a preset interface, wherein the initial microservice device list is obtained according to registration of a plurality of microservice devices in the microservice registry, and the microservice device list comprises a first device identifier set; A second obtaining module is configured to obtain a micro-service device list at a current time from the micro-service registry through the preset interface, wherein the micro-service device list at the current time is returned according to heartbeat detection of a plurality of micro-service devices by the micro-service registry, and the micro-service device list at the current time comprises a second device identifier set. A comparison module is configured to compare the first device identifier set and the second device identifier set, so as to determine a first abnormal device identifier from the first device identifier set. A first determination module is configured to determine an abnormal micro-service device from the plurality of micro-service devices according to the first abnormal device identifier. 9.An electronic device, comprising: one or more processors; a storage device for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, enable the one or more processors to perform the method according to any one of claims 1-7. 10.A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1-7. 11.A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images