WO2023083079A1 - 第三方系统监控系统、方法、装置、设备及存储介质 - Google Patents

第三方系统监控系统、方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2023083079A1
WO2023083079A1 PCT/CN2022/129323 CN2022129323W WO2023083079A1 WO 2023083079 A1 WO2023083079 A1 WO 2023083079A1 CN 2022129323 W CN2022129323 W CN 2022129323W WO 2023083079 A1 WO2023083079 A1 WO 2023083079A1
Authority
WO
WIPO (PCT)
Prior art keywords
party system
target
success rate
threshold
party
Prior art date
Application number
PCT/CN2022/129323
Other languages
English (en)
French (fr)
Inventor
张波清
侯俊丞
Original Assignee
百果园技术(新加坡)有限公司
张波清
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 百果园技术(新加坡)有限公司, 张波清 filed Critical 百果园技术(新加坡)有限公司
Publication of WO2023083079A1 publication Critical patent/WO2023083079A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system

Definitions

  • the present application relates to the field of computer technology, for example, to a third-party system monitoring system, method, device, equipment and storage medium.
  • each business system will more or less rely on the functions of third-party systems.
  • the payment system will rely on a variety of third-party payment channels for users to pay.
  • the stability of the third-party system directly affects the stability of the business system. Therefore, it is necessary to monitor the third-party systems, and when they fail to be available, the business system itself can issue corresponding alarms or automatically handle them.
  • the present application provides a new third-party system monitoring system, method, device, equipment and storage medium for identifying and diagnosing third-party system problems, and can accurately identify the occurrence of third-party system failures.
  • a third-party system monitoring system proposed in this disclosure includes: a business system, configured to provide business functions, and can call an interface of a third-party system; a third-party system, configured to provide at least one interface to provide a corresponding third-party system for the business system Functions; monitoring device, configured to monitor a third-party system; and, detection node, configured to actively invoke an interface of a third-party system for detection according to a notification from the monitoring device.
  • a third-party system monitoring method proposed by the present application includes the following steps: obtaining data reported by at least one business system, determining the first success rate of interface calls of at least one third-party system based on the data reported by the business system, and judging Whether the first success rate is lower than the first threshold, and the third-party system whose first success rate is lower than the first threshold is taken as the target third-party system; notify the detection node to actively detect the target third-party system, to Obtain the second success rate of the interface call of the target third-party system; determine whether the second success rate is lower than the second threshold, and determine the target based on the judgment result that the second success rate is lower than the second threshold There is a fault in the third-party system; based on the judgment result that the second success rate is higher than or equal to the second threshold, it is determined that the target third-party system has no fault or the fault has been recovered.
  • a third-party system monitoring device proposed in the present disclosure includes: an inspection module configured to obtain data reported by at least one business system, and determine the first success rate of interface calls of at least one third-party system based on the data reported by the business system , and judge whether the first success rate is lower than the first threshold, and use the third-party system whose first success rate is lower than the first threshold as the target third-party system; the detection module is configured to notify the detection node to detect the target The third-party system conducts active detection to obtain the second success rate of the interface call of the target third-party system; the fault judgment module is configured to judge whether the second success rate is lower than a second threshold, based on the second success rate being low Based on the judgment result of the second threshold, it is determined that there is a fault in the target third-party system, and based on the judgment result that the second success rate is higher than or equal to the second threshold, it is determined that the target third-party system is not faulty or The fault has been restored.
  • a third-party system monitoring device proposed in the present disclosure includes: a memory configured to store non-transitory computer-readable instructions; and a processor configured to run the computer-readable instructions so that the processor implements the aforementioned Any third-party system monitoring method.
  • a computer-readable storage medium proposed in the present disclosure is used for storing non-transitory computer-readable instructions, and when the non-transitory computer-readable instructions are executed by a computer, the computer executes any one of the aforementioned third-party systems monitoring method.
  • Fig. 1 is a schematic diagram of the overall architecture of a third-party system monitoring system according to an embodiment of the present application
  • FIG. 2 is a schematic diagram of the overall architecture of a third-party system monitoring system according to another embodiment of the present application.
  • FIG. 3 is a schematic flow diagram of a third-party system monitoring method according to an embodiment of the present application.
  • FIG. 4 is a schematic flow diagram of a third-party system monitoring method according to another embodiment of the present application.
  • FIG. 5 is a schematic diagram of global node detection provided by an embodiment of the present application.
  • Fig. 6 is a schematic diagram of a third-party system monitoring device according to an embodiment of the present application.
  • FIG. 1 is a schematic diagram of the overall architecture and system components of a third-party system monitoring system proposed by an embodiment of the present application.
  • the third-party system monitoring system mainly includes: a service system, a third-party system, a monitoring device, and a detection node.
  • the business system (Business System) is set to provide business functions and be able to call interfaces of one or more third-party systems. It should be noted that, in general, business systems provide users with complete and specific business functions, some of which may need to be implemented by calling interfaces provided by third-party systems.
  • the third party system (Third Party System) is set to provide one or more interfaces to provide the business system with the interface implementation of corresponding third party functions.
  • the monitoring device which may also be called a monitoring system (Monitor System), is configured to monitor a third-party system.
  • the monitoring device is set to help the business system to monitor and diagnose the third-party system, for example, to automatically handle the failure and recovery of the third-party system.
  • the specific processing performed by the monitoring device please refer to the part of the monitoring method.
  • the probe node (Probe Node) is set to actively call the third-party system interface for detection according to the notification of the monitoring device, and provides the ability to actively call the third-party system interface.
  • the hardware implemented by the probe node includes, but is not limited to, a server.
  • FIG. 2 is a schematic diagram of the overall architecture and system components of a third-party system monitoring system proposed by another embodiment of the present application.
  • the third-party system monitoring system may also include: one or more of a data reporting node (Data Collecter Node) and a data storage node (Storage).
  • Data Collecter Node data reporting node
  • Storage data storage node
  • the data reporting node is set to collect data information for use by the monitoring device.
  • This part of the data is mainly the statistical information of each call of the third-party system interface by the business system, including the interface call of the third-party system interface called by the business system. information.
  • the data reporting node may send the information of the interface call made by the service system to the third-party system to the data storage node for storage, so as to be used by the monitoring device.
  • the data reporting node can be integrated into the business system.
  • the data storage node also called a storage device, is configured to store specific data, including recording information reported from the business system and information reported from the detection node, for use by the monitoring device.
  • the above-mentioned multiple system components may include the following relationship:
  • the business system will rely on third-party systems to achieve.
  • the third-party system provides some interfaces, and the business system can complete specific functions by calling these interfaces, such as querying user information, saving user information, and so on.
  • the business system can integrate the function of the data reporting node and set it to record the statistical information of the business system calling the third-party system interface.
  • the data reporting node can record the statistical information of the interface call to the storage device for use by the monitoring device.
  • the statistical information of each interface call includes but is not limited to: business system name, business type, third-party system name, third-party system interface name, whether the call is successful, region information (such as the name of the region), computer room name, time, version etc.
  • region information such as the name of the region
  • computer room name such as the name of the region
  • time time, version etc.
  • the large area may refer to: the area where the server room is located, which is used to indicate the environment in which the service is deployed.
  • the monitoring device can notify the detection node to actively call the third-party system interface by sending a message to the detection node, and then can indirectly obtain real-time interface call data.
  • the detection node actively calls the third-party system interface.
  • the example detection strategy may be set to call the interface every 20 seconds, and call the interface 20 times in total, and then record the results of the 20 calls.
  • the detection node After the detection node finishes calling the third-party system interface, it can record the detection result to the storage device.
  • the recorded detection results include but are not limited to: business system name, business type, third-party system name, third-party system interface name, region information (such as the name of the region), computer room name, interface call times, success rate, detection ID, time, version, etc.
  • the monitoring device can obtain statistical information from the storage device, including the information invoked by the third-party system interface.
  • the information invoked by the third-party system interface may include two parts of information, one part is the information reported from the service system; the other part is the information reported from the detection node. Based on these two pieces of information, the monitoring device can determine whether the third-party system is faulty and whether it is restored, so that corresponding post-operation processing can be performed.
  • the monitoring device can notify the business system to perform relevant automatic operations, for example, notify the business system to go online and offline for the corresponding third-party system.
  • the present application does not limit the number of multiple system components included in the third-party system monitoring system.
  • the third-party system monitoring system may include one or more business systems, one or more third-party systems, one or more monitoring devices, and one or more detection nodes; for example, the third-party system monitoring system may also include one or more Multiple data reporting nodes, one or more data storage nodes.
  • FIG. 1 only schematically shows some aspects of the third-party system monitoring involved.
  • This application does not limit the interaction between multiple system module nodes to the above-mentioned methods and contents, but may also include other Signal transmission and data interaction.
  • the interaction between multiple systems may be bidirectional, and the data of the interaction is not limited to the aforementioned data.
  • FIG. 3 is a schematic flowchart of an embodiment of a third-party system monitoring method of the present application.
  • FIG. 4 is a schematic diagram of the core processing flow of the monitoring system in an embodiment of the third-party system monitoring method of the present application.
  • the third-party system monitoring method in the example of the present application mainly includes the following steps:
  • Step S11 obtain the data reported by one or more business systems, determine the first success rate of the interface call of one or more third-party systems based on the data reported by the business system, and judge whether the first success rate is lower than the first success rate A threshold, using a third-party system whose first success rate is lower than the first threshold as a target third-party system.
  • the data reported by a business system includes information about one or more interface calls made by the business system to one or more third-party systems, for example, information about whether each interface call is successful.
  • the reported data may also include information such as the identifier of the business system corresponding to each interface call, the identifier of the called third-party system, and the like.
  • the success rate of the business system calling the third-party system interface is higher than the first threshold, it indicates that the third-party system interface can be used by the business system. If the business system successfully calls the third-party system interface If the rate is lower than or equal to the first threshold, it indicates that the third-party system may have a fault.
  • the business system can periodically send data to the storage device for recording, and the monitoring system can obtain the data reported by the business system from the storage device.
  • the first success rate of interface calls of one or more third-party systems may be calculated based on the data reported by the business system within a period of time. For example, it may be determined whether the third-party system is suspected of failure according to multiple communication information between a service system and a third-party system within a period of time (for example, the last 10 minutes). For example, determine whether the service system’s interface call to the third-party system is successful based on whether the signal transmission and reception of multiple communications is successful, and use the success rate within this time period as the first success rate to avoid judging the fault based on a single communication. Circumstances lead to misjudgment.
  • the information of the third-party system that is, the target third-party system
  • the information of the called interface of the third-party system and/or call the Information such as the information of the business system of the third-party system is stored in the Detect Queue as tag information.
  • Use the detection queue to record the conditions of the third-party system, the third-party system interface, and the business system with a low first success rate, which is beneficial to use this information for subsequent detection and processing.
  • the detection queue is used to store tag information, and the existence of the tag information indicates that the third-party system interface may have a fault.
  • the probe queue is recorded in the data storage node (Storage).
  • the tag information includes but is not limited to: business system name (or identity ID), business system type, third-party system name (or identity ID), third-party system interface name (or identity ID), and/or The region to which the third-party system belongs, and so on.
  • step S12 the detection node is notified to actively detect the target third-party system, so as to obtain a second success rate of the interface call of the target third-party system.
  • the detection node is set to: detect the third-party system according to the set detection rules, and determine whether the interface call of the detection node to the third-party system is successful, so as to determine the aforementioned second success rate.
  • the detection node can be notified multiple times within a period of time to actively detect the target third-party system, and the detection node’s response to the target third-party system can be calculated according to whether the interface calls to the target third-party system are successful during multiple active detections.
  • the second success rate of the interface call of the target third-party system so as to avoid misjudgment caused by judging the failure situation only based on a single communication situation.
  • request an interface call of the monitored third-party system ie, the aforementioned target third-party system
  • intervals for example, 20 seconds
  • a preset number of times for example, 10 times
  • the detection result information of the detection node can be recorded in the storage device for persistent storage, so as to facilitate analysis and processing in subsequent steps, and also facilitate comprehensive utilization of multiple results for analysis.
  • the second success rate may be recorded in a unified storage location.
  • Recording the second success rate in a unified storage location refers to not storing the detection result information of the detection node in the memory of the server where the detection node is located, but recording the detection result information of multiple detection nodes in a preset
  • the storage device is, for example, stored in the aforementioned data storage node.
  • the monitoring system can obtain the tag information stored in the previous stage from the detection queue to determine the target third-party system, and then the monitoring system notifies the detection node to start active detection of the target third-party system corresponding to the tag information to obtain the interface call second success rate.
  • Step S13 judging whether the second success rate is lower than the second threshold, if it is lower than the second threshold, it is determined that the target third-party system is faulty, and if it is higher than or equal to the second threshold, it is determined that the target third-party system is not faulty or faulty recovered.
  • the monitoring system can obtain the data of the active detection from the storage device, because the success rate of the interface call is directly recorded in the data (that is, the aforementioned second success rate), so it can be directly judged whether the second success rate is lower than the second threshold.
  • the first threshold is not directly related to the second threshold, and the first threshold and the second threshold can be set separately according to specific business scenarios.
  • the second threshold may be greater than, less than, or equal to the first threshold.
  • the success or failure result data of the request to the third system can be stored, so that corresponding judgment and processing can be performed by reading the stored data.
  • the information of the third-party system that has been determined to be faulty can also be recorded in the detection queue.
  • information such as flag information and specific fault information of a faulty third-party system is recorded in the detection queue, so that corresponding processing can be performed according to these information in the subsequent processing stage.
  • the initiators of the interface calls are different, one is the business system and the other is the detection node; in addition, the data on which the first success rate and the second success rate are determined are different, and the first success rate It is the success rate based on the interface calls of a third-party system recorded in the data reported by the business system; and the second success rate is that the detection node actively calls a third-party system in real time, and according to the active The success rate of the call situation.
  • the third-party system monitoring method illustrated in the present application further includes: step S14, if it is determined that the target third-party system has a fault, then automatically perform fault processing; and periodically notify the detection node to monitor the target third-party system.
  • the system conducts active detection until it is determined that the fault has been recovered, or, after performing the aforementioned automatic fault processing, it notifies the detection node to conduct active detection on the target third-party system again to determine whether the target third-party system is currently faulty; if the target third-party system is judged again If there is a fault in the three-party system, it will automatically perform fault processing again; if it is determined that the fault has been recovered, it will automatically perform fault recovery processing.
  • automatic fault handling may include but not limited to: notify the business system, the target third-party system, and/or related systems by sending corresponding control signals or terminal to automatically handle the corresponding faults.
  • the failure recovery process will be automatically performed, which may include but not limited to: notify the business system, the target third-party system, and/or related systems or terminals to automatically perform corresponding failure recovery processing. For example, when a fault occurs, the phone will give an alarm, and the call to it will be automatically stopped or replaced by another available third-party system; when the fault is restored, the call to it can be automatically resumed, etc.
  • periodically notifying the detecting node to actively detect the faulty third-party system until it is determined that the fault has been recovered may include: periodically (for example, every 10 minutes) notifying the detecting node that the fault determined in step S11
  • the target third-party system performs the process of the aforementioned step S12 and step S13, or periodically performs the process of the aforementioned step S11 to step S13, to determine whether one or more third-party systems currently have faults, and if it is determined that there is a third-party system
  • the above-mentioned step S14 is performed again to automatically perform fault processing on the faulty third-party system until it is judged that the fault has been recovered according to the current data in step S13, then the fault judgment is stopped and the fault recovery process is performed.
  • the relevant information of the third-party system i.e. the target third-party system
  • the relevant information of the third-party system i.e. the target third-party system
  • the relevant information of the third-party system i.e. the target third-party system
  • the relevant information of the third-party system i.e. the target third-party system
  • the relevant information of the third-party system i.e. the target third-party system
  • the relevant information of the third-party system i.e. the target third-party system
  • the relevant information of the third-party system i.e. the target third-party system that just had a fault
  • the relevant information of the third-party system i.e. the target third-party system
  • the relevant information of the third-party system i.e. the target third-party system that just had a fault
  • the relevant information of the third-party system i.e. the target third-party system
  • the relevant information of the third-party system i.e. the target third-party system that just
  • the aforementioned automatic fault handling includes: automatic sending of notification reports, automatic off-shelf, automatic traffic transfer, and automatic version switching
  • the aforementioned automatic fault recovery processing includes: automatic sending of notification reports, automatic listing, One or more of automatic traffic transfer and version automatic switching.
  • Automatically send notification reports Notify the relevant person in charge of third-party system failure or recovery, send detection reports, etc.
  • Automatic removal from shelves Automatic removal of third-party system failures, including notifying the business system to remove the faulty third-party system from the shelves. For example, in the payment scenario, if a fault is detected in a third-party payment channel, the monitoring system will notify the business system to remove the payment channel to prevent users from continuing to use it and affect the product experience. In the same way, the third-party system will be automatically put on the shelf after the failure of the third-party system is restored, including notifying the business system that the restored third-party system will be put on the shelf.
  • Automatic traffic transfer When the business system fails to access the third-party system, and the third-party system is deployed in multiple computer rooms, and only some computer rooms fail, the monitoring system can notify the business system to migrate the traffic accessing the faulty computer room to the normal one. In the computer room, the fault traffic is eliminated by traffic diversion. In the same way, after the third-party system failure computer room is restored, the previous traffic will be transferred back.
  • the detection phase of the aforementioned step S12 may include notifying the detection node to access multiple software versions of the target third-party system, if the detection node fails to access the current software version of the third-party system but accesses the historical version of the third-party system successfully; Then, the monitoring system can notify the business system to switch from the third-party system accessing the new version to the third-party system accessing the previous version, and solve the fault through version switching. Similarly, after the bug of the new version of the third-party system is resolved, the historical version will be switched to the new version.
  • the first success rate of multiple time periods and/or the second success rate of multiple time periods may be used to determine whether there is a fault in the third-party system.
  • the aforementioned step S11 may include: based on the data reported by the business system in multiple time periods (for example, called the first time period), respectively determine the first success rate of the interface call of the third-party system in each first time period , determining the target third-party system according to the first success rates corresponding to the multiple first time periods.
  • the first time period quantity threshold does not exceed the total number of the first time period.
  • the first time period quantity threshold may be equal to or slightly smaller than the total number of the first time periods.
  • the "three-party system” refers to a third-party system whose first success rate corresponding to all time periods is lower than the first threshold.
  • the aforementioned step S12 may include: notifying the detection node to perform multiple active detections on the target third-party system, so as to obtain a second success rate corresponding to multiple time periods (for example, called the second time period); and, the aforementioned step S13
  • the method may include: judging whether there is a fault in the target third-party system according to the second success rate corresponding to the plurality of second time periods.
  • the second time period quantity threshold does not exceed the total number of the second time period.
  • the second time period quantity threshold may be equal to or slightly less than the total number of the second time period. In fact, when it is equal to, the aforementioned "if the second success rate lower than the second threshold exceeds the second time period quantity threshold", that is is: if each second success rate corresponding to the plurality of second time periods is lower than the second threshold.
  • the third-party system monitoring method of the present application further includes: separately determining whether each second success rate among the multiple second success rates corresponding to the multiple second time periods is higher than the third threshold, and if so, The number of the second success rate at the third threshold exceeds the third time period quantity threshold, and if the result of judging whether the first success rate corresponding to a plurality of first time periods is lower than the first threshold is lower than the first threshold If the quantity of the success rate exceeds the quantity threshold of the first time period, it is determined that the target third-party system is not faulty and the business system itself is faulty. It should be noted that the third time period quantity threshold does not exceed the total number of the second time period.
  • the threshold value of the number of the third time period may be equal to or slightly less than the total number of the second time period.
  • the aforementioned "if the number of the second success rate higher than the third threshold exceeds the threshold number of the third time period" is: if each second success rate corresponding to the plurality of second time periods is higher than the third threshold.
  • One of the above two processes with a plurality of second success rates corresponding to the plurality of second time periods. For example, instead of using multiple second success rates to judge whether there is a fault in the target third-party system, only multiple second success rates are used to judge whether there is a fault in the business system.
  • the detection of step S11 and/or the detection of steps S12 and S13 are carried out in multiple time periods, and the detection results and/or detection results of multiple time periods are integrated for fault judgment, which can improve fault judgment accuracy.
  • FIG. 5 is a schematic diagram of implementation logic of global arbitrary node detection in an embodiment of the third-party system monitoring method of the present application.
  • the example third-party system monitoring method of the present application further includes: deploying the detection areas of the detection nodes. This step is generally performed in advance, or may also be performed before the aforementioned step S11 or step S12.
  • deploying the detection areas of the detection nodes may include: deploying the detection nodes in multiple regions around the world, so as to perform global detection.
  • the aforementioned step S12 may include: notifying the detection node corresponding to the area to which the target third-party system belongs to perform active detection.
  • this application does not limit the specific area division method. For example, it may be an area divided according to the geographic location where the hardware of the detection node or the third-party system is located, or it may also be an area divided according to the network address. It should be noted that regions can also be divided in multiple ways, for example, regions can be divided according to geographical location and network address at the same time.
  • the detection nodes can be deployed globally.
  • the monitoring system implements active detection by detecting nodes, and the detection nodes themselves are stateless. Stateless means that the state information of the detection nodes will not be stored in the current server memory. Considering that the performance of the same function in different states is often different, by setting stateless detection nodes, the detection nodes in different regions of the world can The functions presented are also consistent, enabling global deployment. That is to say, we need to deploy detection nodes from which large area we need to initiate detection. When the monitoring system decides which large areas need to be detected, it will send detection notifications to the detection nodes in the corresponding large areas.
  • the detection node can actively detect service conditions in multiple regions around the world, so as to grasp the specific request situation of each region , and thus be able to locate and solve problems efficiently and pertinently.
  • the third-party system monitoring method of the present application may also include: pre-deploying the same type of third-party systems in multiple areas, and recording the deployment of the third-party systems, if it is determined that the third-party system in an area If there is a fault, the third-party system of the same type in another area is used to replace the faulty third-party system during fault handling, so that request traffic transfer can be realized.
  • targeted treatment can be done.
  • a third-party system that a business system relies on has deployed services in both Asia and Europe. If there is a problem with the service in Asia but not in Europe, the business system can send the request from the Asian region to the European region.
  • the aforementioned tag information recorded in the detection queue may include the area to which the third-party system belongs, so as to schedule the detection nodes according to the tag information.
  • informing the detection node in the aforementioned step S12 to actively detect the target third-party system to obtain the second success rate of the interface call may include: using multiple detection nodes deployed in multiple different areas to The target third-party system performs active detection to obtain multiple second success rates corresponding to multiple detection nodes in multiple areas.
  • whether the second success rate in the aforementioned step S13 is judged to be lower than the second threshold, if lower than the second Determining that there is a fault in the target third-party system may include: judging whether each second success rate in a plurality of second success rates is lower than the second threshold, and if any second success rate exceeding the first area quantity threshold is lower than the second threshold two thresholds, it is determined that the target third-party system is faulty.
  • the first region quantity threshold does not exceed the total number of detection nodes that detect the target third-party system.
  • the first area number threshold may be equal to or slightly less than the total number of detection nodes that detect the target third-party system.
  • the aforementioned "if the second success rate exceeding the first area number threshold is lower than The second threshold" means that if each second success rate corresponding to a plurality of different regions is lower than the second threshold.
  • the third-party system monitoring method of the present application may further include: judging each of the multiple second success rates Whether the second success rate is higher than the third threshold, if there is a second success rate exceeding the second area number threshold higher than the third threshold, it is determined that the target third-party system is not faulty and the business system itself is faulty. Because, if the request of the business system fails, but the requests of the detection nodes in multiple areas are unanimously successful, it is likely to be caused by the business system itself.
  • the second area quantity threshold does not exceed the total number of detection nodes that detect the target third-party system.
  • the threshold value of the second area number may be equal to or slightly less than the total number of detection nodes that detect the target third-party system.
  • the third threshold means that if each of the second success rates corresponding to a plurality of different regions is higher than the third threshold.
  • the accuracy of fault judgment can be improved by using detection nodes in multiple areas to perform detection and fault judgment.
  • deployment of detection nodes and detection of third-party systems can be performed according to different network operators.
  • the third-party system monitoring method of the present application may also include: deploying one or more detection nodes in the area of one or more network operators;
  • the active detection by the three-party system may include: notifying one or more detection nodes whose network operator is the same as the network operator of the target third-party system among the plurality of detection nodes to perform active detection. In this way, it can be judged whether the network problem causes the request for the third-party system interface to fail.
  • the third-party system accesses the network of the first operator, but the service system uses the request initiated by the network of the second operator, then in order to rule out the problem of not being a network operator, we can deploy the detection node on the network of the first operator.
  • the cloud server of the operator's network initiates the request. If the request still fails, it has nothing to do with the network, and it is likely to be a problem with the third-party system.
  • the embodiment of the present application also provides a third-party system monitoring device, which mainly includes: an inspection module, a detection module and a fault judgment module.
  • the inspection module is set to: obtain the data reported by one or more business systems, determine the first success rate of the interface call of one or more third-party systems based on the data reported by the business system, and judge whether the first success rate is low Based on the first threshold, a third-party system whose first success rate is lower than the first threshold is used as a target third-party system.
  • the detection module is configured to: notify the detection node to actively detect the target third-party system, so as to obtain a second success rate of the interface call of the target third-party system.
  • the fault judging module is configured to: judge whether the second success rate is lower than a second threshold, if it is lower than the second threshold, it is judged that the target third-party system has a fault, if it is higher than or equal to the second threshold, it is judged that the target third-party system There is no fault or the fault has been recovered.
  • various third-party system monitoring devices shown in the embodiments of the present application include modules and units corresponding to the methods described in the aforementioned multiple embodiments, and its detailed description and technical effects can be referred to in the aforementioned multiple embodiments Corresponding instructions will not be repeated here.
  • FIG. 6 is a schematic block diagram illustrating a third-party system monitoring device according to one embodiment of the present application.
  • a third-party system monitoring device 100 according to an embodiment of the present disclosure includes a memory 101 and a processor 102 .
  • the memory 101 is arranged to store non-transitory computer readable instructions.
  • memory 101 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and/or non-volatile memory.
  • the volatile memory may include, for example, random access memory (RAM) and/or cache memory (cache).
  • the non-volatile memory may include, for example, a read-only memory (ROM), a hard disk, a flash memory, and the like.
  • the processor 102 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and/or instruction execution capabilities, and may control other components in the third-party system monitoring device 100 to perform desired functions.
  • the processor 102 is configured to execute the computer-readable instructions stored in the memory 101, so that the third-party system monitoring device 100 performs the aforementioned third-party system monitoring in multiple embodiments of the present disclosure. All or part of the steps of the method.
  • Embodiments of the present application also provide a computer storage medium, in which computer instructions are stored, and when the computer instructions are run on the device, the device is made to perform the above-mentioned related method steps to realize the third-party system monitoring in the above-mentioned embodiments method.
  • Computer storage media may be non-transitory computer-readable storage media.
  • Embodiments of the present application also provide a computer program product, which, when running on a computer, causes the computer to execute the above-mentioned related steps, so as to implement the third-party system monitoring method in the above-mentioned embodiments.
  • the embodiments of the present application also provide a device, which may be a chip, component or module, and the device may include a connected processor and a memory; wherein the memory is configured to store computer-executable instructions, and when the device is running, process The processor can execute the computer-executed instructions stored in the memory, so that the chip executes the third-party system monitoring method in the above-mentioned multiple method embodiments.
  • the device, computer storage medium, computer program product or chip provided in this application are all used to execute the corresponding method provided above, therefore, the beneficial effects that it can achieve can refer to the corresponding method provided above The beneficial effects of this will not be repeated here.
  • the third-party system monitoring method and system proposed in this application is a monitoring solution integrating monitoring, diagnosis and automatic processing, and can further optimize business system functions.
  • the present application can accurately identify fault occurrence and fault recovery, and can accurately identify the occurrence of third-party system faults.
  • This application introduces a processing stage, and when a fault occurs and after recovery, it can respond in time and process it automatically.
  • This application supports the detection of nodes in multiple large regions around the world by deploying the detection area of detection nodes, and realizes unlimited regions, unlimited networks, and more flexible monitoring.
  • the present application monitors the third-party system by using multi-period or multi-region detection data, which can distinguish whether it is a problem of the business system or a problem of the third-party system, thereby improving the accuracy of fault judgment of the third-party system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请涉及一种第三方系统监控系统、方法、装置、设备及存储介质，该方法包括：获取至少一个业务系统上报的数据，基于所述业务系统上报的数据确定至少一个第三方系统的接口调用的第一成功率，并判断所述第一成功率是否低于第一阈值，将所述第一成功率低于第一阈值的第三方系统作为目标第三方系统；通知探测节点对所述目标第三方系统进行主动探测，以得到目标第三方系统的接口调用的第二成功率；判断所述第二成功率是否低于第二阈值，基于所述第二成功率低于所述第二阈值的判断结果，确定所述目标第三方系统存在故障；基于所述第二成功率高于或等于所述第二阈值的判断结果，确定所述目标第三方系统没有故障或者故障已恢复。

Description

第三方系统监控系统、方法、装置、设备及存储介质
本申请要求在2021年11月12日提交中国专利局、申请号为202111339204.4的中国专利申请的优先权，该申请的全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，例如涉及一种第三方系统监控系统、方法、装置、设备及存储介质。
背景技术
每一个业务系统的搭建和运行，都会或多或少地依赖第三方系统的功能。比如支付系统，会依赖多种第三方支付渠道来供用户支付。那么，第三方系统的稳定性就直接影响到业务系统的稳定性。所以，需要对第三方系统进行监控，在它们故障不可用的时候，业务系统自身可以进行相应的告警或自动处理。
相关技术中的一些系统监控工具，虽然提供了数据收集、展示和告警等功能，可以做到当第三方系统故障时进行告警，但缺少一定的自动化处理能力，无法与具体业务场景进行衔接，从而无法实现故障或故障恢复的自动处理。
发明内容
本申请提供一种新的第三方系统监控系统、方法、装置、设备及存储介质，用以识别、诊断第三方系统问题，能够对第三方系统故障的发生进行准确识别。
本公开提出的一种第三方系统监控系统，包括：业务系统，设置为提供业务功能，可调用第三方系统的接口；第三方系统，设置为提供至少一个接口，以为业务系统提供相应的第三方功能；监控装置，设置为对第三方系统进行监控；以及，探测节点，设置为根据所述监控装置的通知主动调用第三方系统的接口以进行探测。
本申请提出的一种第三方系统监控方法，包括以下步骤：获取至少一个业务系统上报的数据，基于所述业务系统上报的数据确定至少一个第三方系统的接口调用的第一成功率，并判断所述第一成功率是否低于第一阈值，将所述第一成功率低于第一阈值的第三方系统作为目标第三方系统；通知探测节点对所述目标第三方系统进行主动探测，以得到目标第三方系统的接口调用的第二成功率；判断所述第二成功率是否低于第二阈值，基于所述第二成功率低于所述第二阈值的判断结果，确定所述目标第三方系统存在故障；基于所述第二成功率高于或等于所述第二阈值的判断结果，确定所述目标第三方系统没有故障或者故障已恢复。
本公开提出的一种第三方系统监控装置，包括：检查模块，设置为获取至少一个业务系统上报的数据，基于所述业务系统上报的数据确定至少一个第三方系统的接口调用的第一成功率，并判断所述第一成功率是否低于第一阈值，将所述第一成功率低于第一阈值的第三方系统作为目标第三方系统；探测模块，设置为通知探测节点对所述目标第三方系统进行主动探测，以得到目标第三方 系统的接口调用的第二成功率；故障判断模块，设置为判断所述第二成功率是否低于第二阈值，基于所述第二成功率低于所述第二阈值的判断结果，确定所述目标第三方系统存在故障，基于所述第二成功率高于或等于所述第二阈值的判断结果，确定所述目标第三方系统没有故障或者故障已恢复。
本公开提出的一种第三方系统监控设备，包括：存储器，设置为存储非暂时性计算机可读指令；以及处理器，设置为运行所述计算机可读指令，使得所述处理器执行时实现前述任意一种第三方系统监控方法。
本公开提出的一种计算机可读存储介质，用于存储非暂时性计算机可读指令，当所述非暂时性计算机可读指令由计算机执行时，使得所述计算机执行前述任意一种第三方系统监控方法。
附图说明
图1是本申请一个实施例的第三方系统监控系统整体架构示意图；
图2是本申请另一实施例的第三方系统监控系统整体架构示意图；
图3是本申请一个实施例的第三方系统监控方法的流程示意图；
图4是本申请另一实施例的第三方系统监控方法的流程示意图；
图5是本申请一个实施例提供的全球节点探测的示意图；
图6是本申请一个实施例的第三方系统监控设备的示意图。
具体实施方式
为阐述本申请为达成预定申请目的所采取的技术手段及功效，以下结合附图及示例实施例，对依据本申请提出的第三方系统监控系统、方法、装置、设备及存储介质的示例实施方式、结构、特征及其功效，详细说明如后。
需要说明的是，在本文中，诸如“第一”、“第二”等关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。另外，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
图1为本申请一个实施例提出的第三方系统监控系统整体架构以及系统组件示意图。请参阅图1，在本申请的一些实施例中，第三方系统监控系统主要包括：业务系统、第三方系统、监控装置以及探测节点。
其中，该业务系统(Business System)设置为提供业务功能，能够调用一个或多个第三方系统的接口。需注意，一般来说，业务系统为用户提供了完整且具体的业务功能，其中部分业务功能可能需要通过调用第三方系统提供的接口来实现。
该第三方系统(Third Party System)设置为提供一个或多个接口，用以为业 务系统提供相应的第三方功能的接口实现。
该监控装置，也可称为监控系统(Monitor System)，设置为对第三方系统进行监控。实际中，监控装置设置为帮助业务系统实现对第三方系统进行监控、诊断，例如，还可以实现对第三方系统的故障和故障恢复进行自动处理。监控装置所进行的具体处理可以参阅监控方法部分内容。
该探测节点(Probe Node)设置为根据监控装置的通知来主动调用第三方系统接口以进行探测，提供了对第三方系统接口进行主动调用的能力。例如，探测节点的实现硬件包括但不限于服务器。
图2为本申请另一实施例提出的第三方系统监控系统整体架构以及系统组件示意图。请参阅图2，例如，第三方系统监控系统还可以包括：数据上报节点(Data Collecter Node)、数据存储节点(Storage)中的一个或多个。
其中，该数据上报节点设置为收集数据信息，以供监控装置使用，这部分数据主要是业务系统对第三方系统接口每次调用的统计信息，包括业务系统所调用的第三方系统接口的接口调用信息。例如，数据上报节点可以将业务系统对第三方系统进行的接口调用的信息发送到数据存储节点进行存储，以供监控装置使用。该数据上报节点可集成于业务系统。
该数据存储节点，也称为存储设备，设置为存储具体数据，包括对从业务系统中上报的信息和从探测节点上报的信息进行记录，以供监控装置使用。
作为一个示例实施例，上述多个系统组件之间可以包括如下的关系：
①业务系统与第三方系统之间
业务系统的一些功能会依赖第三方系统来实现。例如，第三方系统提供了一些接口，业务系统可以通过调用这些接口来完成特定的功能，比如查询用户信息，保存用户信息等等。
例如，业务系统可以集成数据上报节点的功能，设置为记录业务系统调用第三方系统接口的统计信息。
②数据上报节点与数据存储节点之间
数据上报节点可以将接口调用的统计信息记录到存储设备，供监控装置使用。
每次接口调用的统计信息包含但不限于：业务系统名称、业务类型、第三方系统名称、第三方系统接口名称、是否调用成功、所属区域信息(例如大区名称)、机房名称、时间、版本等等。其中，大区可以指的是：服务器机房所在区域，用来表示部署服务的环境。
③监控装置与探测节点之间
监控装置可以通过向探测节点发送消息，来通知探测节点来对第三方系统接口进行主动调用，进而可以间接的获取到实时接口调用数据。
④探测节点与第三方系统之间
探测节点主动调用第三方系统接口。作为一个示例，可以将示例探测策略设定为每隔20s调用一次接口，总共调用20次，然后将这20次调用结果记录下来。
⑤探测节点与数据存储节点之间
在探测节点完成对第三方系统接口调用后，可以将探测结果记录到存储设备。
记录的探测结果包含但不限于：业务系统名称、业务类型、第三方系统名称、第三方系统接口名称、所属区域信息(例如大区名称)、机房名称、接口调用次数、成功率、探测ID、时间、版本等等。
⑥监控装置与数据存储节点之间
监控装置可以从存储设备中获取统计信息，包括第三方系统接口调用的信息。
例如，第三方系统接口调用的信息可以包括两部分信息，一部分是从业务系统中上报的信息；另一部分是从探测节点中上报的信息。监控装置基于这两部分信息，就能判断出第三方系统是否故障，以及是否恢复，从而可以做相应的后置操作处理。
⑦监控装置与业务系统之间
监控装置可以基于探测的结果，通知业务系统进行相关自动化操作，比如通知业务系统对相应的第三方系统进行上线下线等处理。
需注意，本申请不限制第三方系统监控系统所包含的多个系统组件的数量。例如，第三方系统监控系统可以包括一个或多个业务系统、一个或多个第三方系统、一个或多个监控装置以及一个或多个探测节点；例如，第三方系统监控系统还可以包括一个或多个数据上报节点、一个或多个数据存储节点。
需注意，图1中的仅示意性地展示了涉及的第三方系统监控的一些方面，本申请并非限制多个系统模块节点之间的交互仅有上述方式和内容，而是还可以包括其他的信号传输和数据交互。例如，多个系统之间的交互均可以是双向的，交互的数据也不限于前述数据。
图3为本申请的第三方系统监控方法一个实施例的示意性流程图。图4为本申请的第三方系统监控方法一个实施例的监控系统核心处理流程的示意图。在本申请的一些实施例中，请参阅图3和图4，本申请示例的第三方系统监控方法主要包括以下步骤：
步骤S11，获取一个或多个业务系统上报的数据，基于该业务系统上报的该数据确定一个或多个第三方系统的接口调用的第一成功率，并判断该第一成功率是否低于第一阈值，将第一成功率低于第一阈值的第三方系统作为目标第三方系统。
其中，一个业务系统上报的数据中包括该业务系统对一个或多个第三方系统的一次或多次的接口调用的信息，例如包括每次接口调用是否成功的信息。在业务系统或第三方系统的数量为多个时，该上报数据还可以包括每次接口调用所对应的业务系统的标识、被调用的第三方系统的标识等信息。
其中，若业务系统对第三方系统接口的调用的成功率高于第一阈值，则表明该第三方系统的接口是可被该业务系统利用的，若业务系统对第三方系统接口的调用的成功率低于或等于第一阈值，则表明该第三方系统可能存在故障。
在一个示例中，业务系统可以定期将数据发送至存储设备进行记录，监控系统可以从该存储设备中获取业务系统上报的数据。
在一些示例中，可以基于一个时间段内的业务系统上报的数据来计算出一个或多个第三方系统的接口调用的第一成功率。例如，可以根据一个时间段(例如最近10分钟)内的一个业务系统与一个第三方系统之间的多次通信信息来确定第三方系统是否疑似故障。例如根据多次通信的信号收发是否成功来确定该业务系统对该第三方系统的接口调用是否成功，将该时间段内的成功率作为第一成功率，以避免仅凭单次通信情况来判断故障情况而造成误判。
例如，若第三方系统的第一成功率低于第一阈值，则将该第三方系统(即目标第三方系统)的信息、该第三方系统的被调用的接口的信息、和/或调用该第三方系统的业务系统的信息等信息作为标记信息存放到探测队列(Detect Queue)中。利用探测队列对第一成功率较低的第三方系统、第三方系统接口、业务系统的情况进行记录，有利于利用这些信息来进行后续的探测和处理。
其中，探测队列用来存放标记信息，存在该标记信息则表示第三方系统接口可能存在故障。例如，探测队列记录于数据存储节点(Storage)。例如，该标记信息包含但不限于：业务系统名称(或身份标识ID)、业务系统类型、第三方系统名称(或身份标识ID)、第三方系统接口名称(或身份标识ID)、和/或第三方系统的所属区域等等。
步骤S12，通知探测节点对该目标第三方系统进行主动探测，以得到目标第三方系统的接口调用的第二成功率。
其中，探测节点设置为：根据设定的探测规则对第三方系统进行探测，确定探测节点对第三方系统的接口调用是否成功，以确定前述的第二成功率。
在一些示例中，可以在一个时间段内多次通知探测节点对目标第三方系统进行主动探测，并根据多次主动探测时对目标第三方系统的接口调用是否成功的情况来计算出探测节点对目标第三方系统的接口调用的第二成功率，以避免仅凭单次通信情况来判断故障情况而造成误判。例如，每隔一个时间间隔(例如20秒)请求一次被监控的第三方系统(即前述的目标第三方系统)的接口调用，进行预设次数(例如10次)接口调用，每次的结果可以是接口调用成功或接口调用失败，根据多次接口调用的结果计算成功率，即为第二成功率。
在得到第二成功率后，可以将探测节点的探测结果信息记录到存储设备，进行持久化的存储，以便于在后续步骤中进行分析处理，也便于综合利用多次结果进行分析。
例如，可以将第二成功率记录于统一的存储位置。将第二成功率记录于统一的存储位置指的是：不是将探测节点的探测结果信息存储在探测节点所在服务器内存中，而是将多个探测节点的探测结果信息统一记录于一个预设的存储设备，例如存储在前述的数据存储节点。
例如，监控系统可以从探测队列中获取上一阶段存放的标记信息，从而确定目标第三方系统，然后监控系统通知探测节点开始对与标记信息对应的目标第三方系统进行主动探测，以得到接口调用的第二成功率。
步骤S13，判断第二成功率是否低于第二阈值，若低于第二阈值则判定该目标第三方系统存在故障，若高于或等于第二阈值则判定该目标第三方系统没有故障或者故障已恢复。
例如，若探测节点完成主动探测后将探测结果记录于一个存储设备，则监控系统可以从存储设备中获取到主动探测的数据，因为该数据中直接记录了接口调用的成功率(即前述的第二成功率)，所以可以直接判断第二成功率是否低于第二阈值。
需注意，一般来说，第一阈值与第二阈值没有直接的关系，可以根据具体的业务场景对第一阈值、第二阈值进行分别设置。例如，第二阈值可以大于第一阈值、小于第一阈值或等于第一阈值。
例如，无伦是业务系统还是探测节点，对第三系统的请求的成功或失败的结果数据都可以存储起来，这样通过读取存储数据就能进行相应的判断和处理。
例如，可以将已判定存在故障的第三方系统的信息，也记录于探测队列之中。例如将存在故障的第三方系统的标记信息、具体故障信息等信息记录于探测队列之中，以便于在后续处理阶段中根据这些信息进行对应处理。
需注意，在前述步骤S11和S12中，接口调用的发起方不同，一个是业务系统、一个是探测节点；另外，确定第一成功率和第二成功率所根据的数据不同，第一成功率是基于业务系统上报的数据中记录的关于某个第三方系统的接口调用情况，而得到的成功率；而第二成功率是探测节点实时地对某个第三方系统进行主动调用，并根据主动调用的情况得到的成功率。
在本申请的一些实施例中，本申请示例的第三方系统监控方法还包括：步骤S14，若判定目标第三方系统存在故障，则自动进行故障处理；并且周期性地通知探测节点对目标第三方系统进行主动探测，直到判定故障已恢复，或者，在进行前述自动进行故障处理后再次通知探测节点对目标第三方系统进行主动探测，以判别目标第三方系统当前是否存在故障；若再次判定目标第三方系统存在故障则再次自动进行故障处理；若判定故障已恢复，则自动进行故障恢复处理。
其中，前述步骤S14中的若判定目标第三方系统存在故障，则自动进行故障处理，可以包括但不限于：通过发送相应的控制信号来通知业务系统、目标第三方系统、和/或相关的系统或终端来自动进行相应的故障处理。而前述步骤S14中的若判定第三方系统接口故障已恢复，则自动进行故障恢复处理，可以包括但不限于：通知业务系统、目标第三方系统、和/或相关的系统或终端来自动进行相应的故障恢复处理。例如，故障时电话告警，自动停止对它的调用或替换成另一个可用的第三方系统；故障恢复时，可以自动恢复对它的调用等等。
其中，前述步骤S14中的周期性地通知探测节点对存在故障的第三方系统进行主动探测直到判定故障已恢复，可以包括：周期性地(例如每隔10分钟)通知探测节点对步骤S11确定出的目标第三方系统进行前述步骤S12和步骤S13的过程、或周期性地进行前述步骤S11至步骤S13的过程，以判断当前是否有一个或多个第三方系统是否存在故障，若判定有第三方系统存在故障时，再次 进行前述步骤S14的对存在故障的第三方系统自动进行故障处理，直到在一次步骤S13中根据当前数据判定故障已恢复，则停止进行故障判定并进行故障恢复处理。在进行故障恢复处理之后，还可以将刚才存在故障的该第三方系统(即目标第三方系统)的相关信息，例如该第三方系统的信息、该第三方系统的被调用的接口的信息、和/或调用该第三方系统的业务系统的信息等信息从探测队列中移出。
例如，前述的自动进行故障处理包括：自动发送通知报告、自动下架、流量自动转移、版本自动切换中的一个或多个，前述的自动进行故障恢复处理包括：自动发送通知报告、自动上架、流量自动转移、版本自动切换中的一个或多个。
自动发送通知报告：将第三方系统故障或恢复通知相关负责人、发送探测报告等。
自动上下架：第三方系统故障自动下架，包括通知业务系统将故障的第三方系统下架。例如在支付场景，若监测到某个第三方支付渠道有故障，监控系统就会通知业务系统将该支付渠道下架，防止用户继续使用，影响产品体验。同理，第三方系统故障恢复后自动上架，包括通知业务系统将恢复的第三方系统上架。
流量自动转移：当业务系统访问第三方系统失败，并且第三方系统是多机房部署的，且只存在部分机房失败的情况下，那么监控系统可以通知业务系统将访问故障机房的流量迁移到访问正常的机房，通过流量转移的方式来消除故障流量。同理，第三方系统故障机房恢复后，则将之前的流量再转移回去。
版本自动切换：当第三方系统刚发布新的软件版本时，业务系统访问第三方系统的失败，可能是新版本存在bug导致的。前述的步骤S12的探测阶段可以包括，通知探测节点对目标第三方系统的多个软件版本进行访问，若探测节点访问第三方系统的当前软件版本失败但是访问第三方系统的历史版本是成功的；那么，监控系统可以通知业务系统由访问新版本的第三方系统切换成访问之前版本的第三方系统，通过版本切换的方式来解决故障。同理，第三方系统新版本bug被解决后，则将历史版本切换成新版本。
在本申请的一些实施例中，可以利用多个时间段的第一成功率和/或利用多个时间段的第二成功率来判别第三方系统是否存在故障。
例如，前述步骤S11可以包括：基于业务系统在多个时间段(例如称为第一时间段)上报的数据，分别确定在每个第一时间段的第三方系统的接口调用的第一成功率，根据多个第一时间段对应的第一成功率来确定目标第三方系统。例如，可以分别判断多个第一时间段对应的第一成功率中的每个第一成功率是否低于第一阈值，并将具有低于第一阈值的第一成功率的数量超过第一时段数量阈值的第三方系统确定为目标第三方系统；或者也可以判断多个第一时间段对应的第一成功率的平均值是否低于第一阈值，并将多个第一成功率的平均值低于第一阈值的第三方系统作为目标第三方系统。需注意，该第一时段数量阈值不超过第一时间段的总数。例如，该第一时段数量阈值可以等于或略小于第 一时间段的总数，事实上在等于时，前述的“具有低于第一阈值的第一成功率的数量超过第一时段数量阈值的第三方系统”即为所有时间段对应的第一成功率均低于第一阈值的第三方系统。
例如，前述步骤S12可以包括：通知探测节点对目标第三方系统进行多次主动探测，以得到与多个时间段(例如称为第二时间段)对应的第二成功率；并且，前述步骤S13可以包括：根据多个第二时间段对应的第二成功率判断目标第三方系统是否存在故障。例如，可以分别判断多个第二时间段对应的多个第二成功率中的每个第二成功率是否低于第二阈值，若低于第二阈值的第二成功率的数量超过第二时段数量阈值，则判定对应的目标第三方系统存在故障；或者也可以判断多个第二时间段对应的第二成功率的平均值是否低于第二阈值、并将多个第二成功率的平均值低于第二阈值的第三方系统判定为存在故障。需注意，该第二时段数量阈值不超过第二时间段的总数。例如，该第二时段数量阈值可以等于或略小于第二时间段的总数，事实上在等于时，前述的“若低于第二阈值的第二成功率的数量超过第二时段数量阈值”即为：若与多个第二时间段对应的每个第二成功率都低于第二阈值。
在本申请前述的利用多个时间段的第一成功率并利用多个时间段的第二成功率来判别第三方系统是否存在故障的实施例中，如果业务系统请求一直失败，但是探测节点请求一直成功，那么很有可能就是业务系统本身的原因导致。为此，在本申请的一些示例中，如果多个第一时间段对应的多个第一成功率都很低、且多个第二时间段对应的多个第二成功率都很高，则可以判定是业务系统本身的原因导致请求第三方系统接口失败，并可以对业务系统进行自动故障处理。
作为一个示例实施例，本申请的第三方系统监控方法还包括：分别判断多个第二时间段对应的多个第二成功率中的每个第二成功率是否高于第三阈值，若高于第三阈值的第二成功率的数量超过第三时段数量阈值，并且若分别判断多个第一时间段对应的第一成功率是否低于第一阈值的结果是低于第一阈值的第一成功率的数量超过第一时段数量阈值，则判定目标第三方系统没有故障且业务系统本身存在故障。需注意，该第三时段数量阈值不超过第二时间段的总数。例如，该第三时段数量阈值可以等于或略小于第二时间段的总数，事实上在等于时，前述的“若高于第三阈值的第二成功率的数量超过第三时段数量阈值”即为：若与多个第二时间段对应的每个第二成功率都高于第三阈值。需注意，在本申请的前述的利用多个时间段的第一成功率和/或利用多个时间段的第二成功率来判别第三方系统是否存在故障的示例中，在得到与多个第二时间段对应的多个第二成功率后，并非必须同时进行前述的根据多个第二时间段对应的第二成功率判断目标第三方系统是否存在故障的过程、以及前述的如果多个第一时间段对应的多个第一成功率都很低且多个第二时间段对应的多个第二成功率都很高则可以判定是业务系统故障的过程，事实上，也可以仅利用进行与多个第二时间段对应的多个第二成功率上述两个过程中的一个过程。例如，不利用多个第二成功率来判断目标第三方系统是否存在故障，而仅利用多个第二成功 率来判断业务系统是否存在故障。
本申请的前述实施例，通过在多个时间段进行步骤S11的检测和/或步骤S12、S13的探测，并综合多个时间段的检测结果和/或探测结果进行故障判断，能够提高故障判断的准确性。
图5为本申请的第三方系统监控方法一个实施例的全球任意节点探测的实现逻辑的示意图。在本申请的一些实施例中，本申请示例的第三方系统监控方法还包括：对探测节点的探测区域进行部署。该步骤一般是预先进行的，或者也可以在前述步骤S11、或步骤S12之前进行。例如，对探测节点的探测区域进行部署可以包括：将探测节点部署于全球的多个区域，以便于进行全球探测。
例如，前述步骤S12可以包括：通知与目标第三方系统所属区域对应的探测节点进行主动探测。
需注意，关于前述的“探测节点的探测区域”、“第三方系统所属区域”，本申请并不限制具体的区域划分方式。例如，可以是根据探测节点、第三方系统的硬件所在的地理位置划分的区域，或者也可以是根据网络地址划分的区域。需注意也可以综合多种方式进行区域的划分，例如同时根据地理位置和网络地址来划分区域。
本申请中可将探测节点进行全球部署。监控系统是通过探测节点来实现主动探测的，并且探测节点本身是无状态的。无状态表示不将探测节点的状态信息存储在当前服务器内存中，考虑到相同功能在不同状态下的表现往往是不一样的，通过设置无状态的探测节点，可以使得全球不同区域的探测节点所表现的功能也都是一致的，从而可以实现全球部署。也就是说，我们需要从哪个大区发起探测，就在哪里部署上探测节点，当监控系统决定需要探测哪些大区时，就向对应大区的探测节点发送探测通知。
利用本申请提出的第三方系统监控方法，能够主动、针对性地探测全球多个大区服务问题，探测节点能主动探测全球多个大区服务情况，以此掌握每个大区的具体请求情况，进而能够高效率、针对性地定位和解决问题。
在一些实施例中，本申请的第三方系统监控方法还可以包括：预先在多个区域部署相同类型的第三方系统，并对第三方系统的部署情况进行记录，若判定一个区域的第三方系统存在故障，则在故障处理时利用另一区域的相同类型的第三方系统替代存在故障的第三方系统，从而能够实现请求流量转移。
例如，在判断出哪些大区正常哪些大区故障后，就能做针对性的处理。比如某个业务系统依赖的第三方系统，在亚洲和欧洲都有部署服务，其中亚洲的服务有问题，欧洲没有问题，那么业务系统就可将亚洲区域的请求发到欧洲区域。
例如，前述的记录于探测队列(或存储设备)的标记信息可以包括第三方系统的所属区域，以便于根据该标记信息来对探测节点进行调度。
在一些实施例中，前述步骤S12中的通知探测节点对目标第三方系统进行主动探测，以得到接口调用的第二成功率，可以包括：利用部署于多个不同的区域的多个探测节点对目标第三方系统进行主动探测，以得到与多个区域的多 个探测节点对应的多个第二成功率。
例如，在前述的得到与多个区域的多个探测节点对应的多个第二成功率的实施例中，前述步骤S13中的判断第二成功率是否低于第二阈值，若低于第二阈值则判定目标第三方系统存在故障可以包括：判断多个第二成功率中的每个第二成功率是否低于第二阈值，若有超过第一区域数量阈值的第二成功率低于第二阈值，则判定目标第三方系统存在故障。
需注意，该第一区域数量阈值不超过对目标第三方系统进行探测的探测节点的总数。例如，该第一区域数量阈值可以等于或略小于对目标第三方系统进行探测的探测节点的总数，事实上在等于时，前述的“若有超过第一区域数量阈值的第二成功率低于第二阈值”即为若与多个不同区域对应的每个第二成功率都低于第二阈值。
例如，在前述的得到与多个区域的多个探测节点对应的多个第二成功率的实施例中，本申请的第三方系统监控方法还可以包括：判断多个第二成功率中的每个第二成功率是否高于第三阈值，若有超过第二区域数量阈值的第二成功率高于第三阈值，则判定目标第三方系统没有故障且业务系统本身存在故障。因为，如果业务系统请求失败，但是多个区域的探测节点请求一致成功，那么很有可能就是业务系统本身的原因导致的。
需注意，该第二区域数量阈值不超过对目标第三方系统进行探测的探测节点的总数。例如，该第二区域数量阈值可以等于或略小于对目标第三方系统进行探测的探测节点的总数，事实上在等于时，前述的“若有超过第二区域数量阈值的第二成功率高于第三阈值”即为若与多个不同区域对应的每个第二成功率都高于第三阈值。
本申请的前述实施例，通过利用多个区域的探测节点进行探测和故障判定，能够提高故障判断的准确性。
在一些实施例中，可以根据不同的网络运营商来进行探测节点的部署和对第三方系统的探测。例如，在前述步骤S12之前，本申请的第三方系统监控方法还可以包括：将一个或多个探测节点部署于一个或多个网络运营商的区域；前述步骤S12中的通知探测节点对目标第三方系统进行主动探测可以包括：通知多个探测节点中的所属网络运营商与该目标第三方系统的网络运营商相同的一个或多个探测节点来进行主动探测。从而能够判断是否网络问题导致请求第三方系统接口失败。
例如，第三方系统接入的是第一运营商网络，但是业务系统使用的是第二运营商网络发起的请求，那么为了排除不是网络运营商的问题，我们可以将探测节点部署在使用第一运营商网络的云服务器来发起请求，若请求还是失败，那么就和网络没有关系，很有可能就是第三方系统的问题。
本申请的实施例还提供一种第三方系统监控装置，该装置主要包括：检查模块、探测模块以及故障判断模块。
其中，该检查模块设置为：获取一个或多个业务系统上报的数据，基于业务系统上报的数据确定一个或多个第三方系统的接口调用的第一成功率，并判 断第一成功率是否低于第一阈值，将第一成功率低于第一阈值的第三方系统作为目标第三方系统。
该探测模块设置为：通知探测节点对该目标第三方系统进行主动探测，以得到目标第三方系统的接口调用的第二成功率。
该故障判断模块设置为：判断第二成功率是否低于第二阈值，若低于第二阈值则判定该目标第三方系统存在故障，若高于或等于第二阈值则判定该目标第三方系统没有故障或者故障已恢复。
另外，本申请实施例示出的多种第三方系统监控装置的包括有用于执行前述多个实施例所述方法对应的模块和单元，而其详细说明和技术效果可以参考前述多个实施例中的相应说明，在此不再赘述。
图6是图示根据本申请的一个实施例的第三方系统监控设备的示意性框图。如图6所示，根据本公开实施例的第三方系统监控设备100包括存储器101和处理器102。
该存储器101设置为存储非暂时性计算机可读指令。例如，存储器101可以包括一个或多个计算机程序产品，该计算机程序产品可以包括多种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。该易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。该非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。
该处理器102可以是中央处理单元(CPU)或者具有数据处理能力和/或指令执行能力的其它形式的处理单元，并且可以控制第三方系统监控设备100中的其它组件以执行期望的功能。在本公开的一个实施例中，该处理器102设置为运行该存储器101中存储的该计算机可读指令，使得该第三方系统监控设备100执行前述的本公开多个实施例的第三方系统监控方法的全部或部分步骤。
有关本实施例的详细说明和技术效果可以参考前述多个实施例中的相应说明，在此不再赘述。
本申请的实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在设备上运行时，使得设备执行上述相关方法步骤实现上述实施例中的第三方系统监控方法。计算机存储介质可以为非暂态计算机可读存储介质。
本申请的实施例还提供一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的第三方系统监控方法。
另外，本申请的实施例还提供一种装置，这个装置可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器设置为存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述多个方法实施例中的第三方系统监控方法。
其中，本申请提供的装置、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
本申请提出的第三方系统监控方法和系统是一种集监控、诊断以及自动处理为一体的监控方案，进而能够优化业务系统功能。
本申请通过引入检测和探测两个监控阶段，能够准确识别出故障发生和故障恢复，能够对第三方系统故障的发生进行准确识别。
本申请通过引入处理阶段，当故障发生时和恢复后，能够及时的响应并自动处理。
本申请通过部署探测节点的探测区域，支持全球多个大区节点探测，实现不限区域、不限网络、更灵活的监控。
本申请通过利用多时段或多区域的探测数据来监控第三方系统，能够区分是业务系统的问题还是第三方系统的问题，进而提高第三方系统故障判断的准确性。

Claims (13)

  1. 一种第三方系统监控系统，包括：
    业务系统，设置为提供业务功能，可调用第三方系统的接口；
    所述第三方系统，设置为提供至少一个接口，以为所述业务系统提供相应的第三方功能；
    监控装置，设置为对所述第三方系统进行监控；以及，
    探测节点，设置为根据所述监控装置的通知主动调用所述第三方系统的接口以进行探测。
  2. 根据权利要求1所述的第三方系统监控系统，还包括：
    数据上报节点，设置为获取所述业务系统调用所述第三方系统的接口的接口调用信息、并将所述接口调用信息发送到数据存储节点进行存储，以供所述监控装置使用；
    所述数据存储节点，设置为记录从所述业务系统中上报的信息和从所述探测节点上报的信息，以供所述监控装置使用。
  3. 一种第三方系统监控方法，包括：
    获取至少一个业务系统上报的数据，基于所述业务系统上报的数据确定至少一个第三方系统的接口调用的第一成功率，并判断所述第一成功率是否低于第一阈值，将所述第一成功率低于所述第一阈值的第三方系统作为目标第三方系统；
    通知探测节点对所述目标第三方系统进行主动探测，以得到所述目标第三方系统的接口调用的第二成功率；
    判断所述第二成功率是否低于第二阈值，基于所述第二成功率低于所述第二阈值的判断结果，确定所述目标第三方系统存在故障；基于所述第二成功率高于或等于所述第二阈值的判断结果，确定所述目标第三方系统没有故障或者故障已恢复。
  4. 根据权利要求3所述的第三方系统监控方法，还包括：
    响应于确定所述目标第三方系统存在故障，自动进行故障处理；并且执行以下之一的操作：
    周期性地通知所述探测节点对所述目标第三方系统进行主动探测直到确定所述目标第三方系统的故障已恢复；
    在所述自动进行故障处理后再次通知所述探测节点对所述目标第三方系统进行主动探测，以判断所述目标第三方系统当前是否存在故障；基于所述目标第三方系统当前存在故障的判断结果，再次自动进行故障处理；基于所述目标第三方系统当前不存在故障的判断结果，自动进行故障恢复处理。
  5. 根据权利要求3所述的第三方系统监控方法，其中，所述自动进行故障处理包括以下至少之一：自动发送通知报告、自动下架、流量自动转移、版本自动切换；所述自动进行故障恢复处理包括以下至少之一：自动发送通知报告、自动上架、流量自动转移、版本自动切换。
  6. 根据权利要求3所述的第三方系统监控方法，其中，
    所述基于所述业务系统上报的数据确定至少一个第三方系统的接口调用的 第一成功率，并判断所述第一成功率是否低于第一阈值，将所述第一成功率低于所述第一阈值的第三方系统作为目标第三方系统，包括：基于所述业务系统在多个第一时间段上报的数据，分别确定在每个第一时间段的每个第三方系统的接口调用的第一成功率，并分别判断所述每个第三方系统在所述每个第一时间段对应的第一成功率是否低于第一阈值，将具有低于所述第一阈值的第一成功率的数量超过第一时段数量阈值的第三方系统确定为所述目标第三方系统；
    所述通知探测节点对所述目标第三方系统进行主动探测，以得到所述目标第三方系统的接口调用的第二成功率，包括：通知探测节点对所述目标第三方系统进行多次主动探测，以得到与多个第二时间段对应的第二成功率；
    所述判断所述第二成功率是否低于第二阈值，基于所述第二成功率低于所述第二阈值的判断结果，确定所述目标第三方系统存在故障，包括：分别判断每个第二时间段对应的第二成功率是否低于所述第二阈值，基于低于所述第二阈值的第二成功率的数量超过第二时段数量阈值的判断结果，确定所述目标第三方系统存在故障；
    所述方法还包括：分别判断所述每个第二时间段对应的第二成功率是否高于第三阈值，基于高于所述第三阈值的第二成功率的数量超过第三时段数量阈值的判断结果，确定所述目标第三方系统没有故障且所述业务系统本身存在故障。
  7. 根据权利要求3所述的第三方系统监控方法，
    在所述通知探测节点对所述目标第三方系统进行主动探测的步骤之前，所述方法还包括：将探测节点部署于全球的多个区域；
    所述通知探测节点对所述目标第三方系统进行主动探测包括：通知与所述目标第三方系统所属区域对应的探测节点对所述目标第三方系统进行主动探测。
  8. 根据权利要求7所述的第三方系统监控方法，还包括：
    预先在多个区域部署相同类型的所述第三方系统；
    响应于确定一个区域的第三方系统存在故障，在故障处理时利用除所述一个区域之外的其他区域的相同类型的第三方系统替代存在故障的第三方系统。
  9. 根据权利要求7所述的第三方系统监控方法，其中，
    所述通知探测节点对所述目标第三方系统进行主动探测包括：利用部署于多个不同的区域的多个探测节点对所述目标第三方系统进行主动探测，以得到对应的多个第二成功率；
    所述判断所述第二成功率是否低于第二阈值，基于所述第二成功率低于所述第二阈值的判断结果，确定所述目标第三方系统存在故障，包括：判断所述多个第二成功率中的每个第二成功率是否低于所述第二阈值，响应于确定有超过第一区域数量阈值的第二成功率低于所述第二阈值，确定所述目标第三方系统存在故障；
    所述方法还包括：判断所述多个第二成功率中的每个第二成功率是否高于第三阈值，响应于确定有超过第二区域数量阈值的第二成功率高于所述第三阈值，确定所述目标第三方系统没有故障且所述业务系统本身存在故障。
  10. 根据权利要求3所述的第三方系统监控方法，
    在所述通知探测节点对所述目标第三方系统进行主动探测的步骤之前，所述方法还包括，将至少一个探测节点部署于至少一个网络运营商的区域；
    所述通知探测节点对所述目标第三方系统进行主动探测，包括：通知多个探测节点中的所属网络运营商与所述目标第三方系统的网络运营商相同的探测节点对所述目标第三方系统进行主动探测。
  11. 一种第三方系统监控装置，包括：
    检查模块，设置为获取至少一个业务系统上报的数据，基于所述业务系统上报的数据确定至少一个第三方系统的接口调用的第一成功率，并判断所述第一成功率是否低于第一阈值，将所述第一成功率低于所述第一阈值的第三方系统作为目标第三方系统；
    探测模块，设置为通知探测节点对所述目标第三方系统进行主动探测，以得到所述目标第三方系统的接口调用的第二成功率；
    故障判断模块，设置为判断所述第二成功率是否低于第二阈值，基于所述第二成功率低于所述第二阈值的判断结果，确定所述目标第三方系统存在故障；基于所述第二成功率高于或等于所述第二阈值的判断结果，确定所述目标第三方系统没有故障或者故障已恢复。
  12. 一种第三方系统监控设备，包括：
    存储器，设置为存储非暂时性计算机可读指令；以及
    处理器，设置为运行所述计算机可读指令，使得所述计算机可读指令被所述处理器执行时实现权利要求3至10中任一项所述的第三方系统监控方法。
  13. 一种计算机存储介质，包括计算机指令，当所述计算机指令在设备上运行时，使得所述设备执行如权利要求3至10中任一项所述的第三方系统监控方法。
PCT/CN2022/129323 2021-11-12 2022-11-02 第三方系统监控系统、方法、装置、设备及存储介质 WO2023083079A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111339204.4A CN114118991A (zh) 2021-11-12 2021-11-12 第三方系统监控系统、方法、装置、设备及存储介质
CN202111339204.4 2021-11-12

Publications (1)

Publication Number Publication Date
WO2023083079A1 true WO2023083079A1 (zh) 2023-05-19

Family

ID=80379282

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/129323 WO2023083079A1 (zh) 2021-11-12 2022-11-02 第三方系统监控系统、方法、装置、设备及存储介质

Country Status (2)

Country Link
CN (1) CN114118991A (zh)
WO (1) WO2023083079A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114118991A (zh) * 2021-11-12 2022-03-01 百果园技术(新加坡)有限公司 第三方系统监控系统、方法、装置、设备及存储介质
CN115242621B (zh) * 2022-07-21 2024-01-02 北京天一恩华科技股份有限公司 网络专线监控方法、装置、设备及计算机可读存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050076052A1 (en) * 2002-11-14 2005-04-07 Nec Fielding, Ltd. Maintenance service system, method and program
CN108270840A (zh) * 2017-01-04 2018-07-10 阿里巴巴集团控股有限公司 一种业务监控、业务数据的搜索方法、装置和电子设备
CN109743358A (zh) * 2018-12-13 2019-05-10 平安普惠企业管理有限公司 异步消息接口熔断控制方法、装置、计算机设备及存储介质
CN110851311A (zh) * 2019-11-12 2020-02-28 深圳前海微众银行股份有限公司 服务故障的识别方法、装置、设备及存储介质
CN113485917A (zh) * 2021-06-25 2021-10-08 上海豹云网络信息服务有限公司 一种接口管理方法、装置、电子设备及存储介质
CN114118991A (zh) * 2021-11-12 2022-03-01 百果园技术(新加坡)有限公司 第三方系统监控系统、方法、装置、设备及存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107688899A (zh) * 2017-08-22 2018-02-13 北京潘达互娱科技有限公司 业务流程监控方法及装置
CN108255667B (zh) * 2017-12-27 2021-07-06 创新先进技术有限公司 一种业务监测方法、装置以及电子设备
CN109873717A (zh) * 2019-01-18 2019-06-11 深圳壹账通智能科技有限公司 监控方法、装置、计算机设备及存储介质
CN111694705A (zh) * 2019-03-15 2020-09-22 北京沃东天骏信息技术有限公司 监控方法、装置、设备及计算机可读存储介质
KR20210047207A (ko) * 2019-10-21 2021-04-29 디비에프아이에스 주식회사 업무 장애 모니터링 시스템 및 그 방법
CN112615737B (zh) * 2020-12-09 2023-06-09 苏宁金融科技(南京)有限公司 业务系统自动监控的方法及系统
CN113419889A (zh) * 2021-06-30 2021-09-21 中国工商银行股份有限公司 一种支付系统的故障自动切换方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050076052A1 (en) * 2002-11-14 2005-04-07 Nec Fielding, Ltd. Maintenance service system, method and program
CN108270840A (zh) * 2017-01-04 2018-07-10 阿里巴巴集团控股有限公司 一种业务监控、业务数据的搜索方法、装置和电子设备
CN109743358A (zh) * 2018-12-13 2019-05-10 平安普惠企业管理有限公司 异步消息接口熔断控制方法、装置、计算机设备及存储介质
CN110851311A (zh) * 2019-11-12 2020-02-28 深圳前海微众银行股份有限公司 服务故障的识别方法、装置、设备及存储介质
CN113485917A (zh) * 2021-06-25 2021-10-08 上海豹云网络信息服务有限公司 一种接口管理方法、装置、电子设备及存储介质
CN114118991A (zh) * 2021-11-12 2022-03-01 百果园技术(新加坡)有限公司 第三方系统监控系统、方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN114118991A (zh) 2022-03-01

Similar Documents

Publication Publication Date Title
WO2023083079A1 (zh) 第三方系统监控系统、方法、装置、设备及存储介质
TWI746512B (zh) 實體機器故障分類處理方法、裝置和虛擬機器恢復方法、系統
CN101800675B (zh) 故障监控方法、监控设备及通信系统
WO2017050130A1 (zh) 一种故障恢复方法及装置
CN109274544B (zh) 一种分布式存储系统的故障检测方法及装置
JP2015510201A (ja) クラウドネットワークにおける迅速な災害回復準備のための方法および装置
US20150019724A1 (en) Adaptive Analysis of Diagnostic Messages
US20080104285A1 (en) Method and system for monitoring device port
US20210105179A1 (en) Fault management method and related apparatus
US20110122761A1 (en) KPI Driven High Availability Method and apparatus for UMTS radio access networks
CN111176866A (zh) 数据交互方法和电子设备
CN104410550A (zh) Web服务监控方法和Web服务监控装置
CN107453906A (zh) 一种存储管理系统监控告警的设置方法及装置
CN110674149B (zh) 业务数据处理方法、装置、计算机设备和存储介质
CN114328110A (zh) 物联网网关的监控方法、系统及存储介质
GB2452025A (en) Alarm event management for a network with alarm event storm detection and management mode
JP5780553B2 (ja) 障害監視装置及び障害監視方法
US10277484B2 (en) Self organizing network event reporting
CN113660145B (zh) 基于话务管理系统动态探知与转移中继线路故障的方法
CN115150253B (zh) 一种故障根因确定方法、装置及电子设备
KR100500836B1 (ko) 매트로 이더넷망의 장애처리 장치 및 그 방법
CN113381884B (zh) 用于监控告警系统的全链路监控方法及装置
US10432472B1 (en) Network operation center (NOC) tool pattern detection and trigger to real-time monitoring operation mode
US20100153543A1 (en) Method and System for Intelligent Management of Performance Measurements In Communication Networks
WO2014040470A1 (zh) 告警消息的处理方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22891874

Country of ref document: EP

Kind code of ref document: A1