Dependency analyzer in application dependency discovery, reporting, and management tool

Patent metadata

Field	Value
Publication number	US-12079668-B2
Application number	US-202318135816-A
Country	US
Kind code	B2
Filing date	Apr 18, 2023
Priority date	Jun 27, 2019
Publication date	Sep 3, 2024
Grant date	Sep 3, 2024

Abstract

Techniques for monitoring operating statuses of an application and its dependencies are provided. A monitoring application may collect and report the operating status of the monitored application and each dependency. Through use of existing monitoring interfaces, the monitoring application can collect operating status without requiring modification of the underlying monitored application or dependencies. The monitoring application may determine a problem service that is a root cause of an unhealthy state of the monitored application. Dependency analyzer and discovery crawler techniques may automatically configure and update the monitoring application. Machine learning techniques may be used to determine patterns of performance based on system state information associated with performance events and provide health reports relative to a baseline status of the monitored application. Also provided are techniques for testing a response of the monitored application through modifications to API calls. Such tests may be used to train the machine learning model.

First claim

What is claimed is:

1. A computer-implemented method comprising:
determining, using a machine learning model, a plurality of Application Programming Interfaces (APIs) that are dependencies of a first application based on a pattern of performance indicating that the first application relies on a service of a given API, wherein the machine learning model is trained to determine the pattern of performance based on clustering system state information associated with past events where the first application had an unhealthy operating status;
determining a dependency map for the first application based on the plurality of APIs, wherein one or more first APIs of the plurality of APIs are dependencies of the first application, and wherein one or more second APIs of the plurality of APIs are dependencies of each respective first API;
determining, by a monitoring application and using a monitoring interface configured to provide one or more metrics regarding the first application, that the first application has an unhealthy operating status;
determining, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding the plurality of APIs, that a third API in the dependency map for the first application is a root cause of the first application having the unhealthy operating status;
identifying a resource associated with the third API, wherein a first pattern of performance indicates that the first application depends on the third API to provide the resource to the first application;
determining, by the monitoring application, that the resource provided by the third API is also available from a fourth API, such that a same service is available from the third API and the fourth API; and
generating, by the monitoring application and based on determining that the third API is the root cause of the first application having the unhealthy operating status, a recommended action operable to cause the first application to retrieve the resource from the fourth API.

2. The method of claim 1 , further comprising:
generating, by the monitoring application, a notification that the first application can be reconfigured to obtain the resource from the fourth API.

3. The method of claim 1 , further comprising:
automatically reconfiguring the first application to implement the recommended action, such that the first application obtains the resource from the fourth API.

4. The method of claim 1 , wherein determining that the resource provided by the third API is also available from the fourth API comprises:
provisioning resources associated with the fourth API, such that the same service is available from the third API and the fourth API.

5. The method of claim 1 , wherein determining the plurality of APIs that are dependencies of the first application based on the pattern of performance comprises:
collecting, by one or more data collecting agents and during a prior incident where the first application had the unhealthy operating status, first system state information corresponding to the first application and one or more of the plurality of dependencies;
adding the collected first system state information to a training data set as a first incident record; and
training the machine learning model, based on the training data set, to determine one or more patterns of performance based on the system state information of the plurality of incident records, wherein a first pattern of performance of the one or more patterns of performance indicates a potential correlation between the first application entering the unhealthy status and a first attribute of the system state information corresponding to a first dependency of the plurality of dependencies.

6. The method of claim 5 , wherein the first incident record further comprises information indicating a corrective action taken in response to a corresponding first incident event, and
wherein determining that the resource provided by the third API is also available from the fourth API is based on the corrective action taken in response to the first incident event.

7. The method of claim 1 , wherein the first application is determined to have the unhealthy status based on whether one or more metrics associated with the first application satisfy one or more operating status thresholds.

8. The method of claim 1 , wherein the first pattern of performance is a pattern of failure and indicates a potential correlation between a first attribute of the system state information corresponding to the third API and the first application entering the unhealthy operating status.

9. The method of claim 1 , wherein the first pattern of performance is a pattern of risk and indicates a potential correlation between a first attribute of the system state information corresponding to the third dependency and a level of security risk to the first application.

10. The method of claim 1 , wherein the first pattern of performance is a pattern of latency and indicates a potential correlation between a first attribute of the system state information corresponding to the third dependency and a latency associated with requests to the first application.

11. The method of claim 1 , further comprising:
based on determining the one or more second APIs, that are dependencies of each respective first API, automatically configuring the monitoring application to utilize a plurality of monitoring interfaces configured to report one or more metrics corresponding to the one or more second APIs.

12. A computer-implemented method comprising:
determining, using a machine learning model, a plurality of Application Programming Interfaces (APIs) that are dependencies of a first application based on a pattern of performance indicating that the first application relies on a service of a given API, wherein the machine learning model is trained to determine the pattern of performance based on clustering system state information associated with past events where the first application had an unhealthy operating status;
determining a dependency map for the first application based on the plurality of APIs, wherein one or more first APIs of the plurality of APIs are dependencies of the first application, and wherein one or more second APIs of the plurality of APIs are dependencies of each respective first API;
determining, by a monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding the plurality of APIs, a likelihood that the first application will enter the unhealthy status based on metrics corresponding to a third API in the dependency map;
in response to determining that the likelihood that the first application will enter the unhealthy status satisfies a threshold, identifying a resource associated with the third API, wherein the first pattern of performance indicates that the first application depends on the third API to provide the resource to the first application;
determining, by the monitoring application, that the resource provided by the third API is also available from a fourth API, such that a same service is available from the third API and the fourth API; and
generating, by the monitoring application and based on determining that the third API is a root cause of the first application having an unhealthy operating status, a recommended action operable to cause the first application to retrieve the resource from the fourth API.

13. The method of claim 12 , further comprising:
generating, by the monitoring application, a notification that the first application can be reconfigured to obtain the resource from the fourth API.

Assignees

• Capital One Services Llc

Inventors

• Balasubramanian Muralidharan
• Barnum Eric K
• Dallen Julie
• Watson David

Classifications

• G06F18/23

  Clustering techniques · CPC title

• G06F9/542

  Event management; Broadcasting; Multicasting; Notifications · CPC title

• G06F11/079

  Root cause analysis, i.e. error or fault diagnosis (in a hardware test environment G06F11/22; in a software test environment G06F11/36) · CPC title

• G06N20/00

  Machine learning · CPC title

• G06F9/541

  via adapters, e.g. between incompatible applications · CPC title