CN109672741A - Micro services monitoring method, device, computer equipment and storage medium - Google Patents

Abstract

The present application relates to a microservice monitoring method, apparatus, computer equipment and storage medium. The method includes: displaying a link invocation monitoring page; the link invocation monitoring page includes an identification input entry; receiving a query identification for the identification input entry; displaying link invocation information; The query identifies the information queried and generated when the microservice is invoked; when the link invocation information is abnormal, receive an abnormal query request for the link invocation information; in response to the abnormal query request, display all The abnormal query result of the link calling information; the abnormal query result is the result of querying the link calling information. Using this method can help operation and maintenance personnel to use the link call monitoring page to quickly search and track various link call information, and when the microservice call is abnormal, quickly locate and solve the abnormal problem, so that the functions provided by the microservice monitoring method are more efficient. Diversification.

Description

Microservice monitoring method, apparatus, computer equipment and storage medium

technical field

The present application relates to the technical field of microservices, and in particular, to a microservice monitoring method, apparatus, computer equipment and storage medium.

Background technique

Microservice is an emerging software architecture, which mainly divides a large independent system into dozens of small services, and calls between each microservice through the Hyper Text Transfer Protocol (Hyper Text Transfer Protocol).

The existing microservice monitoring method mainly adopts the distributed service link monitoring solution provided by Spring Cloud, and integrates the distributed tracking system to collect the tracking data of the request link on each server. State Transfer) API (Application Programming Interface) interface to assist in querying and tracking data to realize program monitoring of distributed systems, so as to detect abnormal problems in the system in time.

However, the integration of the existing microservice monitoring methods in the Spring Cloud project is very simple, which makes it difficult to expand the subsequent functional business. Moreover, with the development of business and more and more scenarios of microservice monitoring, the existing microservice monitoring methods cannot meet the needs of different levels.

Therefore, the existing microservice monitoring methods have the problem of single function.

SUMMARY OF THE INVENTION

Based on this, it is necessary to provide a microservice monitoring method, device, computer equipment and storage medium that can increase the microservice information monitoring function in view of the technical problem of single function in the above microservice monitoring method.

A microservice monitoring method, the method comprising:

Displaying a link call monitoring page; the link call monitoring page includes an identification input entry;

receiving a query identifier for the identifier input entry;

Displaying link invocation information; the link invocation information is the information queried according to the query identifier and generated when the microservice is invoked;

When the link invocation information is abnormal, receive an abnormal query request for the link invocation information;

In response to the abnormal query request, an abnormal query result of the link invocation information is displayed; the abnormal query result is a result of querying the link invocation information.

In one embodiment, before the display link invokes the monitoring page, the method further includes:

Receive microservice call requests;

generating a call record item according to the microservice call request;

When the call record item does not include the first identifier, the first identifier is generated; the first identifier is used to mark the link invocation information of the microservice call request; the first identifier is used to communicate with all The query identifier is matched, and the link invocation monitoring page is instructed to display the link invocation information according to the query identifier.

In one embodiment, the method further includes:

obtaining the second identifier in the call record item;

When the call record item does not include the second identifier, the second identifier is generated according to the first identifier; the second identifier is used to record the number of microservice calls; the second identifier Used to mark exceptions when the microservice calls exceptions.

In one of the embodiments, when the call record item does not include the second identifier, generating the second identifier according to the first identifier includes:

When the call record item includes the first identifier, a second identifier of the exception is generated; the second identifier of the exception is used to mark the exception of the upper-level call of the microservice.

In one embodiment, before the display link invokes the monitoring page, the method further includes:

Get microservice call data;

Store the microservice invocation data in multiple microservice databases through message queues, so that the server can obtain the link invocation information in the multiple microservice databases according to the query identifier; the microservice invocation data They are respectively stored in the plurality of microservice databases according to data types.

In one embodiment, the multiple microservice databases include an in-memory database, a search engine database, a distributed database and a relational database; the in-memory database is used to store real-time statistics of the micro-service invocation data; the search engine The engine database is used to store the short-term microservice invocation data; the distributed database is used to store the long-term microservice invocation data; the relational database is used to store the offline statistics of the microservice invocation data.

In one embodiment, after the receiving the query identifier for the identifier input entry, the method further includes:

Obtain multiple candidate identifiers; the multiple candidate identifiers respectively have corresponding candidate call information;

matching the query identifier with the multiple candidate identifiers;

In the plurality of candidate identifiers, determine a target identifier;

The candidate invocation information corresponding to the target identifier is extracted as the link invocation information.

A microservice monitoring device, the device comprising:

a page display module for displaying a link call monitoring page; the link call monitoring page includes an identification input entry;

an identification receiving module for receiving a query identification for the identification input entry;

an information display module, configured to display link invocation information; the link invocation information is the information queried according to the query identifier and generated when the microservice is invoked;

a request receiving module, configured to receive an abnormal query request for the link invocation information when the link invocation information is abnormal;

A result display module, configured to display an abnormal query result of the link invocation information in response to the abnormal query request; the abnormal query result is a result of querying the link invocation information.

A computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program:

Displaying a link call monitoring page; the link call monitoring page includes an identification input entry;

receiving a query identifier for the identifier input entry;

Displaying link invocation information; the link invocation information is the information queried according to the query identifier and generated when the microservice is invoked;

When the link invocation information is abnormal, receive an abnormal query request for the link invocation information;

In response to the abnormal query request, an abnormal query result of the link invocation information is displayed; the abnormal query result is a result of querying the link invocation information.

A computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

Displaying a link call monitoring page; the link call monitoring page includes an identification input entry;

receiving a query identifier for the identifier input entry;

Displaying link invocation information; the link invocation information is the information queried according to the query identifier and generated when the microservice is invoked;

When the link invocation information is abnormal, receive an abnormal query request for the link invocation information;

In response to the abnormal query request, an abnormal query result of the link invocation information is displayed; the abnormal query result is a result of querying the link invocation information.

The above microservice monitoring method, device, computer equipment and storage medium, the link call monitoring page displayed by the user terminal is used to provide the operation and maintenance personnel after inputting the query ID, query the link call information related to the ID, and call the link when the link is called. In the case of abnormal information, the abnormal query request initiated by the operation and maintenance personnel is received, and the abnormal query result is displayed after responding to the request. Specifically, it includes the record processing of the identification, and the transmission and classification storage of the link invocation information. The invention provides a link invocation monitoring page, which is convenient for operation and maintenance personnel to quickly search and track link invocation information, and when the micro-service invocation is abnormal, it helps the operation and maintenance personnel to quickly locate and solve the abnormal problem, so that the micro-service monitoring method provides the The functions are more diversified.

Description of drawings

Fig. 1 is the application environment diagram of the microservice monitoring method in one embodiment;

2 is a schematic flowchart of a microservice monitoring method in one embodiment;

Fig. 3 is the information monitoring interface diagram of the microservice monitoring method in one embodiment;

Fig. 4 is the abnormal query interface diagram of the microservice monitoring method in one embodiment;

5 is a schematic diagram of data transmission of a microservice monitoring method in one embodiment;

6 is a structural block diagram of a microservice monitoring device in one embodiment;

Fig. 7 is the internal structure diagram of the computer device in one embodiment;

FIG. 8 is an internal structure diagram of a computer device in another embodiment.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present application more clearly understood, the present application will be described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, but not to limit the present application.

First of all, it should be noted that the term "first\second" involved in the embodiments of the present invention is only to distinguish similar objects, and does not represent a specific ordering of objects. It is understandable that "first\second" allows The specific order or sequence may be interchanged. It should be understood that the "first\second" distinctions may be interchanged under appropriate circumstances to enable the embodiments of the invention described herein to be practiced in sequences other than those illustrated or described herein.

Micro service Architecture is a software architecture, specifically a specific way of designing software applications as a suite of services that can be deployed independently, that is, a method of developing a single application as a set of small services, each Applications all run in their own process and communicate with a lightweight mechanism, usually the HTTP (Hyper Text Transfer Protocol) resource API (Application Programming Interface). These services are built around business functionality and can be deployed independently through a fully automated deployment mechanism. Also, these services are minimally centrally managed, can be written in different programming languages, and use different data storage technologies.

The microservice monitoring method provided by the present invention can be applied to the application environment shown in FIG. 1 . Wherein, in a microservice monitoring system, the monitoring terminal 102 and the monitoring server 104 communicate with the user terminal 106 through the network. The monitoring terminal 102 and the user terminal 106 can be, but are not limited to, various personal computers, notebook computers, smart phones, tablet computers and portable wearable devices, and the monitoring server 104 can be an independent server or a server cluster composed of multiple servers. to fulfill.

In one embodiment, as shown in FIG. 2, a microservice monitoring method is provided, and the method is applied to the monitoring terminal 102 in FIG. 1 as an example for description, including the following steps:

Step S210, displaying a link invocation monitoring page; the link invocation monitoring page includes an identification input entry.

Among them, the link call monitoring page is displayed on the monitoring terminal 102, and provides a page for operation and maintenance personnel to query and monitor the micro-service call information. Through the query entry provided on this page, the information about the micro-services that the user has called can be queried. It can be used as an interactive interface between the user and the device, please refer to the page shown in Figure 3.

The identifier input entry may be an input box for receiving an identifier input by a user on the link call monitoring page, or a trigger button for receiving an identifier input instruction, for example, a button-type component such as a virtual button, for example, the front-end device obtains The user ID of the user ID, or the call chain ID that records a microservice call for a user ID.

It should be noted that the user ID is the user ID of the user terminal obtained by the monitoring server 104 when the user terminal 106 initiates the microservice access operation, and the call chain ID is the end of a microservice call for each user who initiates microservice access. Afterwards, a globally unique string is allocated by the monitoring server 104 for this call, and the string remains unchanged during each microservice call, so that the operation and maintenance personnel can obtain relevant information of the globally unique string.

In the specific implementation, a link call monitoring page is provided, and the operation and maintenance personnel can obtain the call information of each user terminal 106 to the micro-service through the logo input entry designed in the page, such as what parameters are passed and what kind of execution is performed. operation and so on. That is, on the monitoring terminal 102, a road call monitoring page can be displayed. When the user inputs a certain identifier, the monitoring server 104 receives the identifier accordingly, and uses the identifier to query the call information corresponding to the identifier in the database. Monitoring terminal 102, so that operation and maintenance personnel can call the monitoring page according to the link, and use the identifier as a query signal to obtain all the micro-service invocation information involved in the same identifier, so as to monitor the micro-service invocation information of the account corresponding to each identifier. .

For example, as shown in Figure 3, a link call monitoring page is displayed, and the page is provided with an identification input entry. The identification input entry can be "user ID" or "call chain ID". When the operation and maintenance personnel After entering the ID number in the input box of "User ID", the information about the related microservice call for querying the user ID is submitted accordingly.

Step S220, receiving a query identifier for the identifier input entry.

The query identifier refers to the identifier input by the user through the interactive interface and used to query the microservice invocation information stored in the monitoring server 104. The query identifier has the identity recognition function, that is, the query identifier is unique, and the monitoring server 104 can The query ID obtains relevant information only for the query ID. The query identifier can be the user ID collected by the monitoring server 104 when the user terminal 106 initiates the microservice call, or it can be a character string allocated by the monitoring server 104 in response to each user terminal 106 calling the service, for example, the mobile phone number 13711112222, the character String 0504321C2F10.

In the specific implementation, the monitoring terminal 102 displays the link call monitoring page, and the operation and maintenance personnel use the identifier input entry on the link call monitoring page. After inputting the query identifier, the monitoring server 104 will receive the query identifier, and the query The identifier may be a string of any hexadecimal system generated by the monitoring server 104 in the early stage, or may be an identification code that reflects the identity of a user account, such as a mobile phone number, an IP address, and the like.

For example, the operation and maintenance personnel input the query ID as "0504321C2F10" in the "call chain ID" input box on the link call monitoring page, and then send the query ID to the monitoring server 104, and the monitoring server 104 will follow up on the query Identify the related microservice invocation information stored in each database.

Step S230, displaying link invocation information; the link invocation information is information queried according to the query identifier and generated when the microservice is invoked.

The link invocation information refers to information that contains the same query identifier and is used to correlate the link invocation information. Including quantity etc.

In the specific implementation, after the operation and maintenance personnel input the query identification at the identification input entry of the monitoring terminal 102, the monitoring server 104 will receive the query identification through the monitoring terminal 102, and use the received query identification to enter an information query, Analysis and processing step, after completing the information acquisition for the query identifier, the monitoring server 104 sends the queried information to the monitoring terminal 102, and the monitoring terminal 102 displays the information on the link call monitoring page according to predetermined rules, that is, displays the information about the query. Query the identified link invocation information. Here, the predetermined rule may refer to page layout, that is, after the monitoring terminal 102 obtains various information of the query identifier, it will display various link calling information according to preset page layout requirements.

For example, refer to FIG. 3, which includes a plurality of link invocation information, each link invocation information is associated with a different query identifier, and the query identifier is the "call chain ID" or "user ID". After the personnel input different query identifiers at each identifier input entry, the monitoring terminal 102 will only display the relevant link invocation information of the query identifier. As shown in FIG. 4 , the link invocation monitoring page of the monitoring terminal 102 only displays The "call chain ID" is "0504321C2F10", and the "user ID" is "hzf/1371373****" link call information, the link call information includes "time", that is, the call time "300ms"; "Service", that is, the number of microservices involved in the call "4"; "depth", that is, the microservice call level "3"; "SPAN", that is, the number of span identifiers "4" and so on.

Step S240, when the link invocation information is abnormal, receive an abnormal query request for the link invocation information.

The abnormal query request refers to a query operation for abnormal link invocation information. The query operation may be clicking on the abnormal place of the link invocation information, or popping up an abnormal pop-up window when the link invocation information is abnormal. Click The abnormal pop-up window can initiate an abnormal query request for link invocation information.

In the specific implementation, the operation and maintenance personnel can monitor various link invocation information through the link invocation monitoring page of the monitoring terminal 102. If there is an abnormality in a certain link invocation information, the abnormality prompt can be displayed in a highlighted color. An exception can also be an exception pop-up window to prompt the exception. The operation and maintenance personnel operate on the monitoring terminal 102 for different abnormal prompts, click the link call information of the abnormal prompt, or drag the link call information of the abnormal prompt, and the monitoring terminal 102 correspondingly initiates the abnormal query request of the operation, The monitoring server 104 thus responds to the request and executes the next step.

For example, please refer to Figure 3 and Figure 4. First, in Figure 3, the link call information whose "call chain ID" is "0504321C2F10" is displayed abnormally in a highlighted color on the link call monitoring page. When the operation and maintenance personnel are monitoring the terminal After clicking on the link call information on 102 , an abnormal query request is submitted to the monitoring server 104 through the monitoring terminal 102 .

Step S250, in response to the abnormal query request, displaying the abnormal query result of the link invocation information; the abnormal query result is a result of querying the link invocation information.

Among them, the abnormal query result refers to the abnormal statistics of link invocation information, which may include abnormal statistical results such as abnormal invocation duration, abnormal invocation of a microservice, etc.

In the specific implementation, after the operation and maintenance personnel submit the abnormal query request on the monitoring terminal 102, the monitoring server 104 responds to the request and sends the abnormal query result of the abnormal link call information to the monitoring terminal 102, and the monitoring terminal 102 receives the abnormality After querying the results, the abnormal query results are displayed on the link call monitoring page according to the preset page layout requirements.

For example, after the monitoring terminal 102 receives the abnormal query result sent by the monitoring server 104 and obtained by querying and analyzing the abnormal link invocation information, it displays the page shown in FIG. 4 on the link invocation monitoring page. The content in the abnormal query interface displayed on the page is the abnormal query result of the abnormal link call information.

In the above microservice monitoring method, the link call monitoring page displayed by the user terminal is used to provide the operation and maintenance personnel with inputting the query ID, and then query the link call information related to the ID, and receive the link call information when the link call information is abnormal. The abnormal query request initiated by the operation and maintenance personnel, and the abnormal query result is displayed after responding to the request. The invention provides a link invocation monitoring page, which is convenient for operation and maintenance personnel to quickly search and track link invocation information, and when the micro-service invocation is abnormal, it helps the operation and maintenance personnel to quickly locate and solve the abnormal problem, so that the micro-service monitoring method provides the The functions are more diversified.

In one embodiment, before the step S210, the method further includes:

Receive a microservice call request; generate a call record item according to the microservice call request; generate the first identifier when the call record item does not include a first identifier; the first identifier is used to mark the Link invocation information of a microservice invocation request; the first identifier is used for matching with the query identifier, and instructs the link invocation monitoring page to display the link invocation information according to the query identifier.

The microservice call request refers to a request initiated by the user terminal 106 to the monitoring server 104. The back-end system of the request in the monitoring server 104 will be called by a number of different microservices, and the final result will be generated by the cooperation of the multiple microservices. request result.

The call record item is the information collection and monitoring result set that the user terminal 106 requests the monitoring server 104 to call each microservice, and the call record item includes the request time of the user terminal, the request protocol, the duration of the microservice call and other information.

The first identifier refers to a global unique identifier generated by the monitoring server 104 for one external access to multiple microservices initiated by the user terminal 106 . In practical applications, the first identifier may also be referred to as a transaction identifier.

In a specific implementation, the monitoring server 104 must collect multiple pieces of link invocation information and store them in the database, so that the operation and maintenance personnel can perform information monitoring on the monitoring terminal 102 . The monitoring server 104 first receives the microservice call request sent by the user terminal 106, and after responding to the request, generates a call record item. At this time, the user identity information and request information of the user terminal 106 will be used by the first microservice monitoring system. A globally unique first identifier is collected by the first microservice/microapplication, and the first identifier is used to associate the information of the user terminal 106 accessing various microservices. Therefore, after the monitoring server 104 receives the microservice invocation request from the user terminal 106 and generates the invocation record item, it must first determine whether there is a first identifier in the invocation record item, and if not, generate a globally unique first identifier , and between invocations of each microservice, the first identifier remains unchanged.

For example, after receiving the microservice call request sent by the user terminal 106, the monitoring server 104 first generates a call record item (transaction record object), and then judges whether there is a first identifier in the hypertext transfer protocol request header of the call record item, If it does not exist, a globally unique first identifier is generated. In addition, the monitoring server 104 uses the microservice monitoring component (Filter) to collect information, all user call information of the mobile phone, and microservice running status information, such as user name, user number, and the like.

In one embodiment, the method further includes:

Obtain the second identifier in the call record item; when the call record item does not include the second identifier, generate the second identifier according to the first identifier; the second identifier is used to record The number of microservice calls; the second identifier is used to mark exceptions when the microservice calls are abnormal.

The second identifier refers to an identifier generated at the same time as the first identifier after the monitoring server 104 receives the microservice invocation request sent by the user terminal 106. The second identifier is different from the first identifier and is not globally unique. On the contrary, it is based on Different microservice calls generate different identifier values, that is, on the basis of the second identifier generated by the current calling microservice, if other microservices are called, a new second identifier will be generated for the other called microservices to record once The number of microservices involved in the invocation request, the function of which is to enable the monitoring server 104 to analyze the microservices invoked by its superiors or the microservices invoked by subordinates through the current second identifier, so as to establish a hierarchy between the invoked microservices relation.

In a specific implementation, after the monitoring server 104 generates a call record item for the user terminal 106 that initiates the microservice call request, it will not only acquire the first identifier, but also acquire the second identifier. When the call record item does not include the second identifier, the second identifier is mainly generated according to the existence of the first identifier.

For example, when the first identifier exists, the value of the second identifier generated is 9, indicating that an exception occurs in the upper-level microservice call; if the first identifier does not exist, when the first identifier is generated, the value of the first identifier is 0, Indicates that the call starts, and the number of microservice calls starts to count. It should be noted that taking the value of the second identifier as a natural integer is convenient for the monitoring server 104 to perform microservice invocation positioning and exception investigation when the information is subsequently invoked. In a microservice call, there will not be a situation where the first identifier does not exist but the second identifier exists, otherwise the call is meaningless.

In one embodiment, when the invocation record item does not include the second identifier, generating the second identifier according to the first identifier includes:

When the call record item includes the first identifier, a second identifier of the exception is generated; the second identifier of the exception is used to mark the exception of the upper-level call of the microservice.

In a specific implementation, if the call record item generated by the monitoring server 104 does not include the second identifier, the first identifier will be acquired, and a preset second identifier will be generated according to the existence of the first identifier.

For example, if the second identifier is not included in the call record item, but the first identifier exists, a second identifier is generated and takes the value 9; if the first identifier exists, a second identifier is also generated, but the second identifier is generated. The value is 0.

In one embodiment, before the step S210, the method further includes:

Acquiring microservice invocation data; storing the microservice invocation data in a plurality of microservice databases through a message queue, so that the server can acquire the link invocation information in the plurality of microservice databases according to the query identifier; The microservice invocation data is stored in the multiple microservice databases according to data types.

Among them, the microservice invocation data refers to real-time information such as the number of visits of each microservice, the concurrent access volume of the system, etc., and also includes short-term or long-term system alarm information.

In the specific implementation, the monitoring server 104 provides the monitoring terminal 102 to monitor the invocation information of the micro-services. First, the invocation information of various micro-services should be collected, and then the transmission and processing of various information data should be performed. First, the monitoring server 104 obtains the calling data of various microservices, then stores the calling data of various microservices locally, and transmits it to each database in the form of a file through a message queue. The types of data stored in each database are different. Different modules fetch databases of different data types.

It should be noted that there are two modes of transmission of microservice invocation data, and reference may be made to FIG. 5 , which is a schematic diagram of data transmission of the microservice monitoring method in one embodiment. Among them, the microservice monitoring component (Filter) may transmit the microservice call data to the message queue through the information input module, or may directly transmit it to the message queue.

For example, referring to Figure 5, there are 4 databases in the microservice monitoring system, and each database stores different types of data, which are processed by different modules.

In one embodiment, the multiple microservice databases include an in-memory database, a search engine database, a distributed database, and a relational database; the in-memory database is used to store real-time statistics of the micro-service invocation data; the search engine The database is used to store the short-term microservice invocation data; the distributed database is used to store the long-term microservice invocation data; the relational database is used to store the offline statistics of the microservice invocation data.

Among them, the in-memory database refers to Redis, which can greatly improve query performance, monitor information and analyze it in real time, and output the statistics results of frequently updated monitoring information, such as the number of visits of each microservice, the number of concurrent system visits, and other real-time information to Redis. In-memory database with good read and write performance. The calculation data of the real-time analysis of the in-memory database can be released in real time. The information stored in Redis is mainly some real-time monitoring data and alarm information, and the amount of stored data is small.

Among them, the search engine database refers to Elastic Search, which can quickly search for relevant information and quickly locate problems. Store short-term data in recent days or a month, and can quickly retrieve multiple conditions quickly in Elastic Search.

Among them, the distributed database refers to Hbase, which stores monitoring information for a long period and is the data source for offline analysis.

Among them, the relational database refers to MySQL, which mainly stores structured data of statistical results of offline analysis.

In a specific implementation, the microservice invocation data collected and acquired by the monitoring server 104 will be analyzed and stored in different databases, and the storage basis depends on the data type.

For example, as shown in Figure 5, the real-time computing service module obtains implementation summary data from the message queue and stores it in the in-memory database; the search engine loading module obtains short-term microservice call data from the message queue and stores it in the search engine database; persistent The service module obtains long-term microservice call data from the message queue and stores it in the distributed database; the offline computing service module obtains the institutionalized data of the statistical results of offline analysis from the message queue and stores it in the relational database.

In one embodiment, after the step S220, it further includes:

Obtaining multiple candidate identifiers; the multiple candidate identifiers respectively have corresponding candidate call information; matching the query identifier with the multiple candidate identifiers; determining the target identifier from the multiple candidate identifiers; extracting all the candidate identifiers The candidate invocation information corresponding to the target identifier is used as the link invocation information.

Wherein, the candidate identifier refers to an identifier that the monitoring server 104 collects and obtains the calling information in the early stage to store in the database, for example, the user's mobile phone number, user ID, user IP address, a custom generated string 0674321C2F10, etc.

The target identifier refers to an identifier that matches the query identifier among the candidate identifiers.

In the specific implementation, the monitoring server 104 takes the query identifier input by the user as the target, performs the identifier matching work among multiple candidate identifiers, uses the matched candidate identifier as the target identifier, and extracts the call information corresponding to the target identifier as the link call information for the monitoring terminal 102 to display.

For example, if the query identifier entered by the operation and maintenance personnel on the link call monitoring page of the monitoring terminal 102 is "0674321C2F10", the monitoring server 104 first searches the database to match the identifier, and then extracts the corresponding link call information after finding the target identifier. , and sent to the monitoring terminal 102, and the monitoring terminal 102 receives and displays the link calling information.

According to the solution provided by the embodiment of the present invention, before the monitoring terminal displays the link call monitoring page, the monitoring server first needs to collect link call information, that is, the information collection work is performed through the microservice call request initiated by the user terminal. During the information collection period, the monitoring server records the invocation information of the user terminal invoking the microservice mainly by preprocessing the first identifier and the second identifier, so that the calling process is associated or marked as abnormal. Through the solution proposed by the present invention, the operation and maintenance personnel can use the link call monitoring page displayed on the monitoring terminal to quickly search and track various link call information, and help the operation and maintenance personnel to quickly locate and solve the abnormal problem when the micro-service call is abnormal. , to make the functions provided by the microservice monitoring method more diversified.

It should be understood that although the various steps in the flowchart of FIG. 2 are shown in sequence according to the arrows, these steps are not necessarily executed in the sequence shown by the arrows. Unless explicitly stated herein, the execution of these steps is not strictly limited to the order, and these steps may be performed in other orders. Moreover, at least a part of the steps in FIG. 2 may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but may be executed at different times. The execution sequence of these sub-steps or stages It also does not have to be performed sequentially, but may be performed alternately or alternately with other steps or sub-steps of other steps or at least a portion of a phase.

In one embodiment, as shown in FIG. 6, a microservice monitoring device is provided, including a page display module 610, an identification receiving module 620, an information display module 630, a request receiving module 640, and a result display module 650, wherein:

a page display module 610, configured to display a link call monitoring page; the link call monitoring page includes an identification input entry;

an identification receiving module 620, configured to receive a query identification for the identification input entry;

an information display module 630, configured to display link invocation information; the link invocation information is the information queried according to the query identifier and generated when the microservice is invoked;

a request receiving module 640, configured to receive an abnormal query request for the link invocation information when the link invocation information is abnormal;

The result display module 650 is configured to display an abnormal query result of the link invocation information in response to the abnormal query request; the abnormal query result is a result of querying the link invocation information.

According to the solution provided by the embodiment of the present invention, the link invocation monitoring page displayed by the monitoring terminal is used to provide the operation and maintenance personnel with the link invocation information related to the identification after inputting the query identification, and when the link invocation information is abnormal , receives the abnormal query request initiated by the operation and maintenance personnel, and displays the abnormal query result after responding to the request. The invention provides a link call monitoring page, which is convenient for operation and maintenance personnel to quickly search and track link call information, and when the micro-service call is abnormal, it helps the operation and maintenance personnel to quickly locate and solve the abnormal problem, so that the micro-service monitoring solution provides The functions are more diversified.

In one embodiment, the apparatus further includes:

The call request receiving module is used to receive the microservice call request; the record item generation module is used to generate the call record item according to the microservice call request; the first identification generation module is used for when the call record item does not include When the first identifier is used, the first identifier is generated; the first identifier is used to mark the link invocation information of the microservice invocation request; the first identifier is used to match the query identifier, and according to the The query identifier instructs the link invocation monitoring page to display the link invocation information.

In one embodiment, the apparatus further includes:

A second identifier acquisition module, configured to acquire the second identifier in the call record item; a second identifier generation module, configured to obtain the second identifier according to the first identifier when the call record item does not include the second identifier , and generate the second identifier; the second identifier is used to record the number of the microservice calls; the second identifier is used to mark the exception when the microservice call is abnormal.

In one embodiment, the second identification generation module includes:

An exception identifier generating sub-module is configured to generate a second identifier of the exception when the call record item includes the first identifier; the second identifier of the exception is used to mark the exception of the upper-level invocation of the microservice.

In one embodiment, the apparatus further comprises:

The calling data acquisition module is used to obtain the micro-service calling data; the calling data storage module is used to store the micro-service calling data in the multiple micro-service databases through the message queue, so that the server can store the data in the multiple micro-service databases according to the query identifier. The link invocation information is obtained from each of the microservice databases; the microservice invocation data are respectively stored in the multiple microservice databases according to data types.

In one embodiment, the multiple microservice databases include an in-memory database, a search engine database, a distributed database, and a relational database; the in-memory database is used to store real-time statistics of the micro-service invocation data; the search engine The database is used to store the short-term microservice invocation data; the distributed database is used to store the long-term microservice invocation data; the relational database is used to store the offline statistics of the microservice invocation data.

In one embodiment, the apparatus further comprises:

A candidate identifier acquisition module is used to acquire multiple candidate identifiers; the multiple candidate identifiers respectively have corresponding candidate call information; an identifier matching module is used to match the query identifier with the multiple candidate identifiers; target identifiers A determination module is used for determining a target identifier among the plurality of candidate identifiers; an invocation information extraction module is used for extracting candidate invocation information corresponding to the target identifier as the link invocation information.

According to the solution provided by the embodiment of the present invention, before the monitoring terminal displays the link call monitoring page, the monitoring server first needs to collect link call information, that is, the information collection work is performed through the microservice call request initiated by the user terminal. During the information collection period, the monitoring server records the invocation information of the user terminal invoking the microservice mainly by preprocessing the first identification and the second identification, so that the calling process is associated or marked as abnormal. Through the solution proposed by the present invention, the operation and maintenance personnel can use the link call monitoring page displayed on the monitoring terminal to quickly search and track various link call information, and help the operation and maintenance personnel to quickly locate and solve the abnormal problem when the micro-service call is abnormal. , to make the functions provided by the microservice monitoring method more diversified.

In one embodiment, a computer device is provided, and the computer device can be a server, and its internal structure diagram can be as shown in FIG. 7 . The computer device includes a processor, memory, a network interface, and a database connected by a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium, an internal memory. The nonvolatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the execution of the operating system and computer programs in the non-volatile storage medium. The computer device's database is used to store identification information and device information. The network interface of the computer device is used to communicate with an external terminal through a network connection. The computer program implements a microservice monitoring method when executed by the processor.

In one embodiment, a computer device is provided, and the computer device may be a terminal, and its internal structure diagram may be as shown in FIG. 8 . The computer equipment includes a processor, memory, a network interface, a display screen, and an input device connected by a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium, an internal memory. The nonvolatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the execution of the operating system and computer programs in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal through a network connection. The computer program, when executed by the processor, implements a microservice monitoring method. The display screen of the computer equipment may be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment may be a touch layer covered on the display screen, or a button, a trackball or a touchpad set on the shell of the computer equipment , or an external keyboard, trackpad, or mouse.

Those skilled in the art can understand that the structures shown in FIG. 7 and FIG. 8 are only block diagrams of partial structures related to the solution of the present application, and do not constitute a limitation on the computer equipment to which the solution of the present application is applied. A computer device may include more or fewer components than those shown in the figures, or combine certain components, or have a different arrangement of components.

In one embodiment, a computer device is provided, including a memory and a processor, a computer program is stored in the memory, and the processor implements the following steps when executing the computer program:

Displaying a link invocation monitoring page; the link invocation monitoring page includes an identification input entry; receiving a query identification for the identification input entry; displaying link invocation information; the link invocation information is queried according to the query identification. information generated when the microservice is called; when the link call information is abnormal, receive an abnormal query request for the link call information; in response to the abnormal query request, display the link call information The abnormal query result is the result of querying the link invocation information.

In one embodiment, the processor further implements the following steps when executing the computer program:

Receive a microservice call request; generate a call record item according to the microservice call request; generate the first identifier when the call record item does not include a first identifier; the first identifier is used to mark the Link invocation information of a microservice invocation request; the first identifier is used for matching with the query identifier, and instructs the link invocation monitoring page to display the link invocation information according to the query identifier.

In one embodiment, the processor further implements the following steps when executing the computer program:

Obtain the second identifier in the call record item; when the call record item does not include the second identifier, generate the second identifier according to the first identifier; the second identifier is used to record The number of microservice calls; the second identifier is used to mark exceptions when the microservice calls are abnormal.

In one embodiment, the processor further implements the following steps when executing the computer program:

When the call record item includes the first identifier, a second identifier of the exception is generated; the second identifier of the exception is used to mark the exception of the upper-level call of the microservice.

In one embodiment, the processor further implements the following steps when executing the computer program:

Acquiring microservice invocation data; storing the microservice invocation data in a plurality of microservice databases through a message queue, so that the server can acquire the link invocation information in the plurality of microservice databases according to the query identifier; The microservice invocation data is stored in the multiple microservice databases according to data types.

In one embodiment, the processor further implements the following steps when executing the computer program:

The multiple microservice databases include an in-memory database, a search engine database, a distributed database and a relational database; the in-memory database is used to store the real-time statistics of the micro-service invocation data; the search engine database is used to store short-term data. the microservice invocation data; the distributed database is used to store the long-term microservice invocation data; the relational database is used to store the offline statistics of the microservice invocation data.

In one embodiment, the processor further implements the following steps when executing the computer program:

Obtaining multiple candidate identifiers; the multiple candidate identifiers respectively have corresponding candidate call information; matching the query identifier with the multiple candidate identifiers; determining the target identifier from the multiple candidate identifiers; extracting all the candidate identifiers The candidate invocation information corresponding to the target identifier is used as the link invocation information.

In one embodiment, a computer-readable storage medium is provided on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

Displaying a link invocation monitoring page; the link invocation monitoring page includes an identification input entry; receiving a query identification for the identification input entry; displaying link invocation information; the link invocation information is queried according to the query identification. information generated when the microservice is called; when the link call information is abnormal, receive an abnormal query request for the link call information; in response to the abnormal query request, display the link call information The abnormal query result is the result of querying the link invocation information.

In one embodiment, the computer program further implements the following steps when executed by the processor:

Receive a microservice call request; generate a call record item according to the microservice call request; generate the first identifier when the call record item does not include a first identifier; the first identifier is used to mark the Link invocation information of a microservice invocation request; the first identifier is used for matching with the query identifier, and instructs the link invocation monitoring page to display the link invocation information according to the query identifier.

In one embodiment, the computer program further implements the following steps when executed by the processor:

Obtain the second identifier in the call record item; when the call record item does not include the second identifier, generate the second identifier according to the first identifier; the second identifier is used to record The number of microservice calls; the second identifier is used to mark exceptions when the microservice calls are abnormal.

In one embodiment, the computer program further implements the following steps when executed by the processor:

When the call record item includes the first identifier, a second identifier of the exception is generated; the second identifier of the exception is used to mark the exception of the upper-level call of the microservice.

In one embodiment, the computer program further implements the following steps when executed by the processor:

Acquiring microservice invocation data; storing the microservice invocation data in a plurality of microservice databases through a message queue, so that the server can acquire the link invocation information in the plurality of microservice databases according to the query identifier; The microservice invocation data is stored in the multiple microservice databases according to data types.

In one embodiment, the computer program further implements the following steps when executed by the processor:

The multiple microservice databases include an in-memory database, a search engine database, a distributed database and a relational database; the in-memory database is used to store the real-time statistics of the micro-service invocation data; the search engine database is used to store short-term data. the microservice invocation data; the distributed database is used to store the long-term microservice invocation data; the relational database is used to store the offline statistics of the microservice invocation data.

In one embodiment, the computer program further implements the following steps when executed by the processor:

Obtaining multiple candidate identifiers; the multiple candidate identifiers respectively have corresponding candidate call information; matching the query identifier with the multiple candidate identifiers; determining the target identifier from the multiple candidate identifiers; extracting all the candidate identifiers The candidate invocation information corresponding to the target identifier is used as the link invocation information.

Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage In the medium, when the computer program is executed, it may include the processes of the above-mentioned method embodiments. Wherein, any reference to memory, storage, database or other medium used in the various embodiments provided in this application may include non-volatile and/or volatile memory. Nonvolatile memory may include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous chain Road (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

The technical features of the above embodiments can be combined arbitrarily. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction in the combination of these technical features It is considered to be the range described in this specification.

The above-mentioned embodiments only represent several embodiments of the present application, and the descriptions thereof are specific and detailed, but should not be construed as a limitation on the scope of the invention patent. It should be pointed out that for those skilled in the art, without departing from the concept of the present application, several modifications and improvements can be made, which all belong to the protection scope of the present application. Therefore, the scope of protection of the patent of the present application shall be subject to the appended claims.

Claims (10)

1. a kind of micro services monitoring method, which comprises the steps of:

Show that link calls the monitoring page；It includes mark input entrance that the link, which calls the monitoring page,；

Receive the inquiry mark for the mark input entrance；

Show link recalls information；The link recalls information is to be identified described in inquire, calling in incognito according to the inquiry The information generated when business；

When the link recalls information exception, the abnormal inquiry received for the link recalls information is requested；

It is requested in response to the abnormal inquiry, shows the abnormal inquiry result of the link recalls information；The abnormal inquiry knot Fruit is the result inquired the link recalls information.

2. the method according to claim 1, wherein also being wrapped before the display link calls the monitoring page It includes:

Receive micro services call request；

According to the micro services call request, generates and call entry；

When not including first identifier in the calling entry, the first identifier is generated；The first identifier is for marking The link recalls information of the micro services call request；The first identifier is used to be matched with inquiry mark, and root Indicate that the link calls the monitoring page to show the link recalls information according to inquiry mark.

3. according to the method described in claim 2, it is characterized by further comprising:

Obtain the second identifier in the calling entry；

When not including the second identifier in the calling entry according to the first identifier, the second identifier is generated； The second identifier calls quantity for recording the micro services；The second identifier is used to call in the micro services abnormal When, mark is abnormal.

4. according to the method described in claim 3, it is characterized in that, described work as in the calling entry not including described second When mark, according to the first identifier, the second identifier is generated, comprising:

When in the calling entry including the first identifier, abnormal second identifier is generated；The second abnormal mark Know the higher level for marking the micro services and calls exception.

5. the method according to claim 1, wherein also being wrapped before the display link calls the monitoring page It includes:

It obtains micro services and calls data；

Data are called to store by message queue into multiple micro services databases the micro services, for server according to Inquiry mark, in the multiple micro services database, obtains the link recalls information；The micro services call data by number It is stored respectively in the multiple micro services database according to type.

6. according to the method described in claim 5, it is characterized in that, the multiple micro services database includes internal storage data Library, search engine database, distributed data base and relational database；The memory database is for storing real-time statistics The micro services call data；Described search engine database is used to store the short-term micro services and calls data；Described point Cloth database is used to store the long-term micro services and calls data；The relational database is for storing the institute counted offline It states micro services and calls data.

7. the method according to claim 1, wherein in the inquiry received for the mark input entrance After mark, further includes:

Obtain multiple candidate identifications；The multiple candidate identification is respectively provided with corresponding candidate recalls information；

The inquiry is identified and is matched with the multiple candidate identification；

In the multiple candidate identification, target identification is determined；

The corresponding candidate recalls information of the target identification is extracted, as the link recalls information.

8. a kind of micro services monitoring device, which is characterized in that described device includes:

Page display module, for showing that link calls the monitoring page；The link call the monitoring page include mark input into Mouthful；

Receiving module is identified, for receiving the inquiry mark for being directed to the mark input entrance；

Information display module, for showing link recalls information；The link recalls information is to be identified to inquire according to the inquiry To, call the micro services when information that generates；

Request receiving module, for receiving the exception for being directed to the link recalls information when the link recalls information exception Inquiry request；

Result display module shows the abnormal inquiry knot of the link recalls information for requesting in response to the abnormal inquiry Fruit；The abnormal inquiry result is the result inquired the link recalls information.

9. a kind of computer equipment, including memory and processor, the memory are stored with computer program, feature exists In the step of processor realizes any one of claims 1 to 7 the method when executing the computer program.

10. a kind of computer readable storage medium, is stored thereon with computer program, which is characterized in that the computer program The step of method described in any one of claims 1 to 7 is realized when being executed by processor.