Monitoring the Endpoints of Private APIs
API Functional Monitoring (AFM) lets you monitor private APIs if you have a subscription to Anypoint Virtual Private Cloud (Anypoint VPC).
Private APIs are APIs with endpoints that are accessible only within your network inside an Anypoint VPC.
A private location is a Mule application that runs in an environment in CloudHub 1.0 or Cloudhub 2.0. You can run tests against APIs that are accessible only within the private location. The private location environment might have an Anypoint VPC associated with it. You can create multiple private locations in a single instance of Anypoint VPC.
To test private endpoints, use the internal URLs of the applications. These are the internal/VPC IP addresses of the Mule workers, in the form of mule-worker-internal-myapp.region.cloudhub.io. The VPC must also have access to the applications' ports. See the CloudHub Networking Guide.
| You can also test public APIs using private locations. Public APIs are APIs with endpoints that are exposed to the internet. |
Association of Private Locations with Schedules
When you use private locations, you can run as many workers as your allotment of vCores allows. By default, each worker consumes 0.2 vCores. Therefore, MuleSoft does not limit the number of schedules that you can create for tests that are run from private locations.
Also, you can run tests from private locations with intervals of five minutes.
Creation of Private Locations
Before you can run tests of private APIs from a private location, you must create a private location, which involves specifying a name and an environment for the worker to run in. The environment must be associated with an instance of Anypoint VPC and must be the same environment that an API to be tested is deployed in. For example, you might create a private location that you name myLocation and set it to run in environment myEnvironment. When you choose to run a test in myLocation, AFM allocates a worker in myEnvironment in Anypoint Virtual Private Cloud.
| In early versions of private locations, for tests to run, you had to allow incoming HTTP traffic into the private location’s environment. If you update your private location, you no longer need to allow incoming HTTP traffic. |
Possible Test Configurations
The following diagram depicts the types of relationships that monitors of private APIs can have with their schedules, public locations, APIs, and environments. Each type of relationship is indicated with a unique line style.
-
Monitor 1’s relationships (indicated with solid black arrows): single schedule, single location, single environment
Monitor 1 runs on a single schedule, Schedule A. The schedule is associated with Private Location 1. The monitor is written to test one or more endpoints in Private API 1 and in Private API 2, although it could also test endpoints in more private APIs. The private location and APIs are in a single environment, environment A.
-
Monitor 2’s relationships (indicated with dashed green arrows): multiple schedules, single location, single environment
Monitor 2 runs on two separate schedules, Schedule B and Schedule C, and each is associated with the same private location, Private Location 1. The private location is shared with the schedule that runs Monitor 1. Monitor 2 is written to test one or more endpoints in private API 3 and in private API 4, although it could also test endpoints in more private APIs. The private locations and APIs are in a single environment, environment A.
-
Monitor 3’s relationships (indicated with dashed-and-dotted light blue arrows): multiple schedules, multiple locations, single environment
Monitor 3 runs on two separate schedules, Schedule D and Schedule E, and each is associated with a different private location, Private Location 2 and Private Location 3. Monitor 3 is written to test one or more endpoints in API 5 and in API 6, although it could also test endpoints in more private APIs. The private locations and APIs are in a single environment, environment A.
-
Monitor 4’s relationships (indicated with dotted orange arrows): multiple schedules, multiple environments
Monitor 4 runs on two separate schedules, Schedule F and Schedule G, and each is associated with a different private location. Private Location 4 and Private API 7 are in Environment A and Private Location 5 and Private API 8 are in Environment B. One environment could be a test environment, and the other environment could be a production environment, where Private API 7 and Private API 8 are copies of the same API. Monitor 4 is written to test one or more endpoints in Private API 7 and the same endpoints in Private API 8, although it could also test endpoints in more private APIs.
-
Monitor 5’s relationships (indicated with solid violet arrows): tests private and public APIs
Monitor 5 runs on one schedule, Schedule H, although it could run on multiple schedules. The schedule is associated with a private location, Private Location 5. Monitor 5 is written to test one or more endpoints in Private API 9 and in Public API 10. Private Location 5 and Private API 9 are in Environment B, and Public API 10 is on the web.
Length of Time Before Tests Time Out
When tests are run by private locations in an instance of Anypoint VPC, the workers do not share resources with other MuleSoft customers. Therefore, AFM allows tests to wait for a default of thirty minutes for a response from an endpoint. You can increase this time in Anypoint Runtime Manager. To do so, follow these steps:
-
Go to Anypoint Runtime Manager.
-
Open the settings for the private location for which you want to increase the timeout.
-
In the executionTimeout field, specify a longer timeout in milliseconds.
Update Private Locations
As updates become available, you are notified in the Locations modal dialog. Follow the prompts to apply the update to all private locations.