Method and apparatus for monitoring status of distributed services

Abstract

The application relates to the technical field of service monitoring, and provides a state monitoring method and device for a distributed service. The method comprises the following steps: acquiring current running data when each node calls a distributed service; generating a state curve of the distributed service according to the current running data of each node and a calling relationship between each node when the distributed service is called; and comparing the state curve with a window upper limit curve and a window lower limit curve to determine a state monitoring result of the distributed service. The state monitoring method for the distributed service provided by the embodiment of the application can provide correlation checking for the distributed service spanning multiple nodes, and the accuracy of state monitoring of the distributed service is improved.

Description

Technical Field

[0001] The present application relates to the technical field of service monitoring, and in particular to a method and device for status monitoring of distributed services. Background Art

[0002] A distributed system is a loosely coupled system consisting of multiple processors interconnected by communication lines. Currently, software architectures are gradually shifting to distributed architectures, breaking down monolithic structures into multiple services that interact with each other over the network to complete user tasks. This is known as distributed services. To ensure proper software operation, it's often necessary to monitor the distributed services invoked by each node in the distributed system to assess their health.

[0003] Related technologies monitor the services called by each node in a distributed system to determine whether the service status of that node is normal. However, this service monitoring method monitors isolated nodes. If the service is distributed across multiple nodes, it cannot provide distributed service relevance checks, affecting the accuracy of distributed service status monitoring. Summary of the Invention

[0004] This application aims to solve at least one of the technical problems in the related art. To this end, this application proposes a state monitoring method for distributed services, which can provide correlation checks for distributed services across multiple nodes and improve the accuracy of state monitoring of distributed services.

[0005] This application also proposes a status monitoring device for distributed services.

[0006] The present application also provides an electronic device.

[0007] The present application also provides a computer-readable storage medium.

[0008] A method for monitoring the status of a distributed service according to an embodiment of the first aspect of the present application includes:

[0009] Get the current running data of each node when calling distributed services;

[0010] generating a status curve of the distributed service according to the current operating data of each node and the calling relationship between the nodes when calling the distributed service;

[0011] The state curve is compared with the window upper limit curve and the window upper limit curve to determine the state monitoring result of the distributed service.

[0012] The state monitoring method of a distributed service provided in an embodiment of the present application obtains the current operating data of each node when calling the distributed service, and generates a state curve of the distributed service based on the current operating data of each node and the calling relationship between the nodes when calling the distributed service. The state curve is then compared with the window upper limit curve and the window upper limit curve to determine the state monitoring result of the distributed service. Therefore, when monitoring the state of the distributed service, the state curve formed by each node that calls the distributed service is monitored, rather than monitoring the state data of a single node, that is, a correlation check is provided for distributed services spanning multiple nodes, thereby improving the accuracy of state monitoring of the distributed service.

[0013] According to one embodiment of the present application, it further includes:

[0014] Obtain test sample data when each node calls distributed services;

[0015] generating a test sample curve for the distributed service according to the test sample data of each node and a calling relationship between the nodes when calling the distributed service;

[0016] Determining the window upper limit curve and the window lower limit curve according to each of the test sample curves;

[0017] The test sample data is operating data marked as normal.

[0018] According to an embodiment of the present application, determining the window upper limit curve and the window upper limit curve according to each of the test sample curves includes:

[0019] From the test sample curves, obtaining the test sample curve located at the top and determining it as the window upper limit curve; and

[0020] From the test sample curves, the test sample curve located at the bottom is obtained and determined as the window upper limit curve.

[0021] According to an embodiment of the present application, determining the window upper limit curve and the window upper limit curve according to each of the test sample curves includes:

[0022] Averaging the test sample curves to determine a preset curve;

[0023] The window upper limit curve and the window upper limit curve are determined according to the preset upper and lower limit intervals of each node and the preset curve.

[0024] According to an embodiment of the present application, the preset upper and lower limit intervals are determined according to the distributed service.

[0025] According to an embodiment of the present application, determining the window upper limit curve and the window upper limit curve according to each of the test sample curves includes:

[0026] Inputting each of the test sample curves into a trained neural network to determine the window upper limit curve and the window upper limit curve;

[0027] The neural network is trained by curve samples marked as being in normal operation, and the curve samples are generated when the target nodes call the distributed service.

[0028] According to one embodiment of the present application, it further includes:

[0029] Determining that the status monitoring result is that the running status of the distributed service is abnormal, and obtaining, from the status curve, each local curve located outside the window upper limit curve and the window upper limit curve;

[0030] It is determined that the total duration of each of the local curves reaches a preset duration, and an alarm message is generated.

[0031] A state monitoring device for a distributed service according to an embodiment of the second aspect of the present application includes:

[0032] The running data acquisition module is used to obtain the current running data of each node when calling the distributed service;

[0033] a state curve generating module, configured to generate a state curve of the distributed service based on the current running data of each node and the calling relationship between the nodes when calling the distributed service;

[0034] The service status monitoring module is used to compare the status curve with the window upper limit curve and the window upper limit curve to determine the status monitoring result of the distributed service.

[0035] According to an electronic device of an embodiment of the third aspect of the present application, the electronic device includes a processor and a memory storing a computer program, and when the processor executes the computer program, the state monitoring method of the distributed service described in any of the above embodiments is implemented.

[0036] According to the computer-readable storage medium of the fourth embodiment of the present application, a computer program is stored thereon, and when the computer program is executed by a processor, the status monitoring method of the distributed service described in any of the above embodiments is implemented.

[0037] According to the computer program product of the fifth embodiment of the present application, the computer program product includes: when the computer program is executed by a processor, the state monitoring method of the distributed service as described in any of the above embodiments is implemented.

[0038] The above one or more technical solutions in the embodiments of the present application have at least one of the following technical effects:

[0039] By obtaining the current running data of each node when calling the distributed service, and generating the status curve of the distributed service based on the current running data of each node and the calling relationship between the nodes when calling the distributed service, the status curve is compared with the window upper limit curve and the window upper limit curve to determine the status monitoring result of the distributed service. Therefore, when monitoring the status of the distributed service, the status curve formed by each node that calls the distributed service is monitored, rather than monitoring the status data of a single node, that is, providing correlation checks for distributed services across multiple nodes, thereby improving the accuracy of status monitoring of distributed services. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the present application or the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0041] Figure 1 Schematic diagram of the process of monitoring the status of distributed services provided by the embodiment of the present application;

[0042] Figure 2 It is a schematic diagram of the curve structure of the state curve;

[0043] Figure 3 Yes Figure 1 A flowchart further refining the window upper limit curve and the generation of the window upper limit curve in the state monitoring method of the distributed service;

[0044] Figure 4 Yes Figure 3 A flowchart further refining the window upper limit curve and the generation of the window upper limit curve in the state monitoring method of the distributed service;

[0045] Figure 5 Yes Figure 3 A flowchart further refining the window upper limit curve and the generation of the window upper limit curve in the state monitoring method of the distributed service;

[0046] Figure 6 It is a schematic diagram comparing the state curve with the window upper limit curve and the window upper limit curve;

[0047] Figure 7 This is a schematic diagram of the structure of a state monitoring device for distributed services provided in an embodiment of the present application;

[0048] Figure 8 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] To make the objectives, technical solutions, and advantages of this application more clear, the technical solutions in this application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this application.

[0050] Below, the state monitoring method and device for distributed services provided by the embodiments of the present application will be introduced and explained in detail through several specific embodiments.

[0051] In one embodiment, a method for monitoring the status of a distributed service is provided. The method is applied to a server and is used to monitor the operating status of the distributed service at each node when the distributed service is called. The server can be a standalone server or a server cluster composed of multiple servers. The server can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence sampling point devices.

[0052] like Figure 1 As shown, a state monitoring method for a distributed service provided in this embodiment includes:

[0053] Step 101: Obtain the current running data of each node when calling the distributed service;

[0054] Step 102: generating a status curve of the distributed service based on the current operating data of each node and the calling relationship between the nodes when calling the distributed service;

[0055] Step 103 : Compare the state curve with the window upper limit curve and the window upper limit curve to determine the state monitoring result of the distributed service.

[0056] By obtaining the current running data of each node when calling the distributed service, and generating the status curve of the distributed service based on the current running data of each node and the calling relationship between the nodes when calling the distributed service, the status curve is compared with the window upper limit curve and the window upper limit curve to determine the status monitoring result of the distributed service. Therefore, when monitoring the status of the distributed service, the status curve formed by each node that calls the distributed service is monitored, rather than monitoring the status data of a single node, that is, providing correlation checks for distributed services across multiple nodes, thereby improving the accuracy of status monitoring of distributed services.

[0057] In addition, since business pressure may be different under the same software and hardware conditions, the service status may have interval jitter. Therefore, by setting upper and lower limit curves for comparison with the status curve, the status curve is allowed to be trapped in a certain jitter range, thereby reducing the situation where the status curve is misjudged as abnormal due to normal jitter, and further improving the accuracy of status monitoring of distributed services.

[0058] In one embodiment, a distributed service spans multiple distributed nodes, with each node used to invoke a specific service function within the distributed service, i.e., a sub-service. For example, the distributed service may be a mobile service call. In this case, when invoking the distributed service, each node used to invoke the distributed service will sequentially invoke functions such as preloading, data decryption, interface rendering, security authentication, and remote invocation to complete the distributed service call. A node may be a network device such as a server or terminal device.

[0059] When a node calls a distributed service, it will call a business function in the distributed service. At this time, the running data of the business function can be used as the current running data when the node calls the distributed service.

[0060] After obtaining the current running data of each node when calling the distributed service, since there is a calling relationship between each node when calling the distributed service, for example, the called distributed service is A, and the business functions called by each node are A1, A2, A3, A4 and A5 respectively, that is, the five nodes call A1, A2, A3, A4 and A5 in sequence, then the state curve of the distributed service can be generated based on the calling sequence relationship between the business functions. Among them, the calling relationship between the business functions of the distributed service can be pre-recorded in the distributed service statistics table of the server, such as:

[0061]

[0062] In this way, when it is determined that a distributed service needs to be monitored, the calling relationship between the nodes that call the distributed service can be determined from the distributed service statistics table, so that the operating data obtained by each node, that is, the status value, can be fitted according to the calling relationship between the nodes to obtain a status curve.

[0063] For example, the calling relationship of A1-A5 is A1->A2->A3>-A4->A5, that is, the node that calls A1 first calls A1, and then the node that calls A2 first calls A2. At this time, the status curve of the distributed service can be generated by the current running data of A1-A5 and the order in which A1-A5 are called.

[0064] For example, assuming that the distributed service being called is A, the business functions called by each node are A1-A5, and the calling relationship is A1->A2->A3>-A4->A5. The current running data of A1-A5 are 10, 20, 15, 25 and 10 respectively, and the time points of calling the distributed service are 5, 15, 25, 35 and 50 respectively. The state curve of the distributed service A can be generated as follows: Figure 2 shown.

[0065] After obtaining the state curve of the distributed service, the state curve can be compared with the window upper limit curve and the window upper limit curve. Among them, the preset upper limit curve and the window upper limit curve can be determined according to the actual situation. In order to make the setting of the preset upper limit curve and the window upper limit curve more accurate and improve the accuracy of the state monitoring of the distributed service, in one embodiment, the preset upper limit curve and the window upper limit curve can be determined as follows: Figure 3 Shown, including:

[0066] Step 201: Acquire test sample data when each node calls a distributed service;

[0067] Step 202: generating a test sample curve for the distributed service based on the test sample data of each node and the calling relationship between the nodes when calling the distributed service;

[0068] Step 203, determining the window upper limit curve and the window upper limit curve according to each of the test sample curves;

[0069] The test sample data is operating data marked as normal.

[0070] In one embodiment, a distributed service call test is first performed multiple times on each node. After each call test, operational data determined to be normal is collected as test sample data. Then, using the time points at which each node calls the test sample data, each test sample data is fitted in chronological order to generate a test sample curve for the distributed service under normal conditions. In this way, through multiple call tests, multiple test sample curves for the distributed service under normal conditions can be obtained.

[0071] After obtaining multiple test sample curves, the multiple test sample curves can be used to determine the window upper limit curve and the window upper limit curve. In this way, it can be determined that the window upper limit curve and the window upper limit curve are both curves of the distributed service under normal call status.

[0072] For example, Figure 4 As shown, after obtaining multiple test sample curves, using the multiple test sample curves to determine the window upper limit curve and the window upper limit curve may include:

[0073] Step 301: From the test sample curves, obtain the test sample curve located at the top and determine it as the window upper limit curve; and

[0074] Step 302: From the test sample curves, obtain the test sample curve at the bottom and determine it as the window upper limit curve.

[0075] In one embodiment, after obtaining multiple test sample curves, since each test sample curve can indicate that the operating status of the distributed service is normal, the test sample curve at the top of each test sample curve, that is, the test sample curve in which the test sample data of any node is the peak value of the node, can be used as the window upper limit curve.

[0076] For example, each test sample curve includes test sample curve 1, test sample curve 2 and test sample curve 3. Test sample curve 1 is A1(10)->A2(20)->A3(15)>-A4(25)->A5(10); test sample curve 2 is A1(5)->A2(15)->A3(10)>-A4(20)->A5(5); test sample curve 3 is A1(3)->A2(10)->A3(8)>-A4(15)->A5(3), that is, in test sample curve 1, the test sample data corresponding to the node calling A1 is 10; the test sample data corresponding to the node calling A2 is 20; the test sample data corresponding to the node calling A3 is 15; the test sample data corresponding to the node calling A4 is 25; and the test sample data corresponding to the node calling A5 is 10. By comparison, it can be determined that in the test sample curve 1, the test sample data of each node are the peak values ​​of the node. In this case, the test sample curve 1 can be determined as the window upper limit curve.

[0077] Similarly, the test sample curve whose test sample data of any node are all valley values ​​of the node, that is, the test sample curve at the bottom, can be determined as the window upper limit curve.

[0078] However, considering that there may be intersections between the test sample curves, such as test sample curve 1 is A1(10)->A2(15)->A3(10)>-A4(25)->A5(10); test sample curve 2 is A1(5)->A2(20)->A3(15)>-A4(20)->A5(5), it is impossible to obtain the test sample curve at the top or bottom, resulting in the inability to determine the window upper limit curve and the window upper limit curve, affecting the subsequent status monitoring of the distributed service. For this reason, in one embodiment, if Figure 5 As shown, determining the window upper limit curve and the window upper limit curve according to each of the test sample curves includes:

[0079] Step 401, averaging the test sample curves to determine a preset curve;

[0080] Step 402 : determining the window upper limit curve and the window upper limit curve according to the preset upper and lower limit intervals of each node and the preset curve.

[0081] In one embodiment, after obtaining each test sample curve, the test sample data at the same time point in each test sample curve can be averaged to obtain multiple average sample data. The average sample data are then fitted in chronological order to form a preset curve.

[0082] Each node is pre-set with preset upper and lower limits for invoking distributed services. These limits can be determined based on actual circumstances. To ensure more accurate preset limits, the server can pre-store a mapping data table that stores the upper and lower limits corresponding to each distributed service invoked by any node, with each limit corresponding to a distributed service. When any node invokes a distributed service, it can retrieve the upper and lower limits corresponding to that node's invocation of the distributed service from the mapping data table as the preset limits.

[0083] For example, the following table shows:

[0084]

[0085]

[0086] The distributed service being called is distributed service C, and the nodes calling distributed service C are the mobile terminal, the target server, and the security device. The mobile terminal calls C1 and C4, the target server calls C2, and the security device calls C3. When the mobile terminal calls C1, an average calculation can be used to determine that the average sample data is 0.3 seconds. The preset upper and lower limits obtained from the mapping data table are [-5%, 5%]. Similarly, the average sample data and the preset upper and lower limits can be determined when the mobile terminal calls C4, when the target server calls C2, and when the security device calls C3.

[0087] Then, a preset curve can be determined based on the average sample data of each node when calling the distributed service, the call relationship between each node when calling the distributed service, such as C1->C2->C3->C4, and the time when each node calls the distributed service. After determining the preset curve, the average sample data of a node when calling the distributed service in the preset curve is expanded by the upper limit of the preset upper and lower limits corresponding to that node to expand the average sample data. For example, if the average sample data of node 1 when calling distributed service A is 15, and the preset upper and lower limits are [-5%, 5%], the average sample data of 15 is increased by 5% to expand the average sample data to 15.75. Similarly, the average sample data of each node when calling the distributed service can be expanded. After expanding each average sample data, the preset curve can be adjusted according to the expanded average sample data to obtain the window upper limit curve.

[0088] Similarly, the average sample data in the preset curve corresponding to each node's distributed service calls can be reduced by the lower limit of the preset upper and lower limit interval corresponding to each node, thereby reducing the average sample data when each node calls the distributed service. The preset curve is then adjusted based on the reduced average sample data to obtain the window upper limit curve. In this way, the window upper limit curve and the window upper limit curve can form a state fluctuation window interval bounded by the window upper limit curve and the window upper limit curve.

[0089] By averaging the curves of each test sample and determining the preset curve, the window upper limit curve and the window upper limit curve are determined based on the preset upper and lower limit intervals and the preset curve of each node, so that the obtained window upper limit curve and the window upper limit curve are more in line with the actual situation of the distributed service operation, and the accuracy of the subsequent use of the window upper limit curve and the window upper limit curve for distributed service status monitoring is improved.

[0090] In order to make the state fluctuation window interval formed by the obtained preset upper line curve and the window upper limit curve converge to a smaller interval, in one embodiment, each of the test sample curves can also be input into a trained neural network to determine the window upper limit curve and the window upper limit curve;

[0091] The neural network is trained by curve samples marked as being in normal operation, and the curve samples are generated when the target nodes call the distributed service.

[0092] Specifically, all the acquired test sample curves can be divided in proportion in advance, such as 6:4, so that 60% of the test sample curves are used as curve samples for training the neural network. Then, these curve samples are input into the neural network for training to obtain the output upper limit curve and lower limit curve. Then, according to the upper limit curve and lower limit curve output by the neural network, the loss function of the neural network is adjusted, and then the curve samples are re-input into the neural network to obtain new upper limit curve and lower limit curve. Until the number of training times reaches the preset number, and each test sample curve is within the state fluctuation window interval formed by the output upper limit curve and lower limit curve, the output upper limit curve and lower limit curve can be used as the upper and lower limit curves of the window.

[0093] When comparing the state curve generated by the current running data and call relationship when each node calls the distributed service with the window upper limit curve and the window upper limit curve, it can be determined whether the state curve is within the state fluctuation window interval formed by the window upper limit curve and the window upper limit curve. Figure 6 As shown in FIG, if the state curve is within the state fluctuation window, it means that the running state of the distributed service is normal.

[0094] If the operating data of the status curve in a certain time period exceeds the status fluctuation window range, it is considered to be abnormal jitter of the service. At this time, the status monitoring result can be determined as an abnormal operating status of the distributed service, and the status of the time period is recorded as a basis for subsequent review.

[0095] If the status monitoring result indicates that the distributed service's operating status is abnormal, the system can obtain the local curves located outside the window upper limit curve and the window upper limit curve from the status curve. The total duration of each local interval is then calculated, that is, the duration of the operating data in the status curve that exceeds the status fluctuation window interval. If this total duration is greater than the preset duration, it indicates that the status curve has experienced severe jitter and frequently exceeds the status fluctuation interval range. At this time, an alarm message is generated and sent to the management terminal used by the administrator to notify the administrator to promptly handle the fault.

[0096] If the administrator determines that the jitter is normal, the state curve can be used as a curve sample and input into the neural network for training to update the upper and lower limit curves of the window.

[0097] The following describes a state monitoring device for a distributed service provided in the present application. The state monitoring device for a distributed service described below and the state monitoring method for a distributed service described above can refer to each other.

[0098] In one embodiment, if Figure 7 As shown, a state monitoring device for a distributed service is provided, comprising:

[0099] The operation data acquisition module 210 is used to obtain the current operation data of each node when calling the distributed service;

[0100] A state curve generating module 220 is configured to generate a state curve of the distributed service based on the current running data of each node and the calling relationship between the nodes when calling the distributed service;

[0101] The service status monitoring module 230 is configured to compare the status curve with the window upper limit curve and the window upper limit curve to determine a status monitoring result of the distributed service.

[0102] The current running data of each node when calling the distributed service is acquired, and the state curve of the distributed service is generated according to the current running data of each node and the calling relationship between each node when calling the distributed service. Then, the state curve is compared with the upper limit curve and the lower limit curve to determine the state monitoring result of the distributed service. Therefore, when monitoring the state of the distributed service, the state curve formed by each node calling the distributed service is monitored, rather than the state data of a single node. In this way, the correlation check of the distributed service spanning multiple nodes is provided, and the accuracy of the state monitoring of the distributed service is improved.

[0103] In an embodiment, the service state monitoring module 230 is further configured to:

[0104] acquire test sample data of each node when calling the distributed service;

[0105] generate test sample curves of the distributed service according to the test sample data of each node and the calling relationship between each node when calling the distributed service;

[0106] determine the upper limit curve and the lower limit curve according to each test sample curve;

[0107] The test sample data is running data marked as a normal state.

[0108] In an embodiment, the service state monitoring module 230 is specifically configured to:

[0109] determine the test sample curve located at the uppermost position in each test sample curve as the upper limit curve; and

[0110] determine the test sample curve located at the lowermost position in each test sample curve as the lower limit curve.

[0111] In an embodiment, the service state monitoring module 230 is specifically configured to:

[0112] determine a preset curve by averaging each test sample curve;

[0113] determine the upper limit curve and the lower limit curve according to the preset upper and lower limit intervals of each node and the preset curve.

[0114] In an embodiment, the preset upper and lower limit intervals are determined according to the distributed service.

[0115] In an embodiment, the service state monitoring module 230 is specifically configured to:

[0116] Inputting each of the test sample curves into a trained neural network to determine the window upper limit curve and the window upper limit curve;

[0117] The neural network is trained by curve samples marked as being in normal operation, and the curve samples are generated when the target nodes call the distributed service.

[0118] In one embodiment, the service status monitoring module 230 is further configured to:

[0119] Determining that the status monitoring result is that the running status of the distributed service is abnormal, and obtaining, from the status curve, each local curve located outside the window upper limit curve and the window upper limit curve;

[0120] It is determined that the total duration of each of the local curves reaches a preset duration, and an alarm message is generated.

[0121] Figure 8 An example of a physical structure diagram of an electronic device is shown below. Figure 8 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call a computer program in the memory 830 to execute a method for status monitoring of a distributed service, for example, including:

[0122] Get the current running data of each node when calling distributed services;

[0123] generating a status curve of the distributed service according to the current operating data of each node and the calling relationship between the nodes when calling the distributed service;

[0124] The state curve is compared with the window upper limit curve and the window upper limit curve to determine the state monitoring result of the distributed service.

[0125] In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0126] On the other hand, an embodiment of the present application further provides a storage medium, the storage medium including a computer program, which may be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the state monitoring method of the distributed service provided in each of the above embodiments, for example, including:

[0127] Get the current running data of each node when calling distributed services;

[0128] generating a status curve of the distributed service according to the current operating data of each node and the calling relationship between the nodes when calling the distributed service;

[0129] The state curve is compared with the window upper limit curve and the window upper limit curve to determine the state monitoring result of the distributed service.

[0130] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, or of course, by hardware. Based on this understanding, the essence of the above technical solution or the part that contributes to the existing technology can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiments.

[0131] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for status monitoring of a distributed service, characterized in that: include: Get the current running data of each node when calling distributed services; generating a status curve of the distributed service according to the current operating data of each node and the calling relationship between the nodes when calling the distributed service; Comparing the state curve with the window upper limit curve and the window lower limit curve to determine the state monitoring result of the distributed service; The method further comprises: Obtain test sample data when each node calls distributed services; generating a test sample curve for the distributed service according to the test sample data of each node and a calling relationship between the nodes when calling the distributed service; Averaging the test sample curves to determine a preset curve; According to the upper limit of the preset upper and lower limit interval of any of the nodes, the average sample data corresponding to the node in the preset curve is expanded to determine the upper limit curve of the window; and according to the lower limit of the preset upper and lower limit interval of any of the nodes, the average sample data corresponding to the node in the preset curve is reduced to determine the lower limit curve of the window; The test sample data is operating data marked as normal.

2. The state monitoring method of distributed services according to claim 1, characterized in that: Determining the window upper limit curve and the window lower limit curve according to each of the test sample curves includes: From the test sample curves, obtaining the test sample curve located at the top and determining it as the window upper limit curve; and From the test sample curves, the test sample curve located at the bottom is obtained and determined as the window lower limit curve.

3. The state monitoring method of distributed services according to claim 1, characterized in that: The preset upper and lower limits are determined according to the distributed service.

4. The state monitoring method of distributed services according to claim 2, characterized in that: Determining the window upper limit curve and the window lower limit curve according to each of the test sample curves includes: Inputting each of the test sample curves into a trained neural network to determine the window upper limit curve and the window lower limit curve; The neural network is trained by curve samples marked as being in normal operation, and the curve samples are generated when each node calls the distributed service.

5. The method for status monitoring of distributed services according to claim 1, wherein: Also includes: Determining that the status monitoring result is that the running status of the distributed service is abnormal, and obtaining, from the status curve, each local curve located outside the window upper limit curve and the window lower limit curve; It is determined that the total duration of each of the local curves reaches a preset duration, and an alarm message is generated.

6. A state monitoring device for distributed services, characterized in that: include: The running data acquisition module is used to obtain the current running data of each node when calling the distributed service; a state curve generating module, configured to generate a state curve of the distributed service based on the current running data of each node and the calling relationship between the nodes when calling the distributed service; A service status monitoring module, configured to compare the status curve with a window upper limit curve and a window lower limit curve to determine a status monitoring result of the distributed service; The service status monitoring module is also used to: Obtain test sample data when each node calls distributed services; generating a test sample curve for the distributed service according to the test sample data of each node and a calling relationship between the nodes when calling the distributed service; Averaging the test sample curves to determine a preset curve; According to the upper limit of the preset upper and lower limit interval of any of the nodes, the average sample data corresponding to the node in the preset curve is expanded to determine the upper limit curve of the window; and according to the lower limit of the preset upper and lower limit interval of any of the nodes, the average sample data corresponding to the node in the preset curve is reduced to determine the lower limit curve of the window; The test sample data is operating data marked as normal.

7. An electronic device comprising a processor and a memory storing a computer program, characterized in that: When the processor executes the computer program, the state monitoring method for distributed services according to any one of claims 1 to 5 is implemented.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the state monitoring method for distributed services according to any one of claims 1 to 5 is implemented.

Images