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

Patent metadata

Field	Value
Publication number	US-11221854-B2
Application number	US-202016891475-A
Country	US
Kind code	B2
Filing date	Jun 3, 2020
Priority date	Jun 27, 2019
Publication date	Jan 11, 2022
Grant date	Jan 11, 2022

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 a dependency map for a first application based on one or more first Application Programming Interfaces (APIs) and one or more second APIs, wherein the one or more first APIs are dependencies of the first application, and wherein the one or more second APIs are dependencies of each respective first API;
identifying data resources associated with each respective API in the dependency map, wherein each data resource corresponds to a data element that the corresponding API provides to the first application;
determining, by a monitoring application and using a monitoring interface configured to provide one or more metrics regarding a third API in the dependency map for the first application, that the third API has an unhealthy operating status based on the one or more metrics satisfying one or more unhealthy operating status thresholds;
determining, by the monitoring application, that a particular data resource provided by the third API is also available from a fourth API, such that a same data element is available from the third API and the fourth API; and
generating, by the monitoring application and based on determining that the third API has an unhealthy operating status, a notification that the particular data resource is available from the fourth API.

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

3. The method of claim 1 , further comprising:
automatically reconfiguring the first application to obtain the particular data resource from the fourth API.

4. The method of claim 1 , further comprising:
determining an error status message provided by the third API or the particular data resource,
wherein the notification that the particular data resource is available from the fourth API comprises the error status message.

5. The method of claim 1 , wherein determining the dependency map for the first application comprises:
identifying the one or more first APIs is based on data lineage documentation associated with the first application; and
determining the one or more second APIs based on data lineage documentation associated with each respective first API.

6. The method of claim 1 , further comprising:
determining the one or more second APIs based on an API call log associated with an API call made by the first application.

7. The method of claim 6 , wherein the API call log indicates a message ID of the API call made by the first application and comprises a record of each API involved in processing the API call.

8. The method of claim 1 , further comprising:
identifying the one or more first APIs, that are dependencies of the first application, based on determining APIs that are associated with a first plurality of monitoring interfaces configured to monitor the first application.

9. The method of claim 8 , further comprising:
determining the one or more second APIs, that are dependencies of each respective first API, based on determining APIs that are associated with respective second pluralities of monitoring interfaces configured to monitor the respective first APIs.

10. The method of claim 1 , wherein determining the dependency map for the first application is based on a pattern of performance indicating that the first application relies on a service of a given API, wherein the pattern of performance is determined using a machine learning model trained based on clustering system status information associated with past events where the first application had an unhealthy operating status.

11. The method of claim 1 , wherein determining the dependency map for the first application is based on:
causing a given API to simulate an unhealthy operating status; and
determining that the first application develops an unhealthy operating status based on the simulated unhealthy operating status of the given API.

12. The method of claim 1 , wherein determining the dependency map for the first application comprises:
adding the one or more first APIs to the dependency map as dependencies of the first application;
adding the one or more second APIs to the dependency map as dependencies of a corresponding first API; and
adding one or more other APIs to the dependency map as further dependencies of the one or more second APIs.

13. The method of claim 12 , wherein adding the one or more second APIs or one or more other APIs comprises:
determining, for a fifth API of the one or more second APIs or one or more other APIs, that a same API is already present in the dependency map; and
omitting the fifth API from the dependency map based on the same API being present in the dependency map.

14. 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.

15. A monitoring device comprising:
one or more processors; and
memory storing instructions that, when executed by the one or more processors, cause the monitoring device to:
determine a dependency map for a first application based on one or more first Application Programming Interfaces (APIs) and one or more second APIs, wherein the one or more first APIs are dependencies of the first application, and wherein the one or more second APIs are dependencies of each respective first API;
identify data resources associated with each respective API in the dependency map;
determine, by a monitoring application and using a monitoring interface configured to provide one or more metrics regarding a third API included in the dependency map, that the third API has an unhealthy operating status based on the one or more metrics satisfying one or more unhealthy operating status thresholds;
determine, by the monitoring application, that a particular data resource provided by the third API is also available from a fourth API, such that a same data element is available from the third API and the fourth API; and
generate, by the monitoring application and based on determining that the third API has an unhealthy operating status, a notification that the particular data resource is available from the fourth API.

16. The monitoring device of claim 15 , wherein the instructions further cause the monitoring device to:
automatically reconfigure the first application to obtain the particular data resource from the fourth API.

17. The monitoring device of claim 15 , wherein the instructions further cause the monitoring device to:
determine an error status message provided by the third API or the particular data resource,
wherein the notification that the particular data resource is available from the fourth API comprises the error status message.

18. The monitoring device of claim 15 , wherein the instructions cause the monitoring device to:
identify the one or more first APIs based on data lineage documentation associated with the first application; and
determine the one or more second APIs based on data lineage documentation associated with each respective first API.

19. One or more non-transitory computer readable media storing instructions that, when executed by one or more processors, cause a monitoring device to perform steps comprising:
determining a dependency m

Assignees

• Capital One Services Llc

Inventors

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

Classifications

• G06F9/3838 Primary

  Dependency mechanisms, e.g. register scoreboarding · CPC title

• G06F9/54 Primary

  Interprogram communication · CPC title

• G06N5/01

  Dynamic search techniques; Heuristics; Dynamic trees; Branch-and-bound · CPC title

• G06F18/23

  Clustering techniques · CPC title

• G06F9/541

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