Monitoring the Endpoints of Public APIs
Public APIs are APIs with endpoints that are exposed to the public internet. Tests of such endpoints are run by workers that themselves run in public locations or private locations.
A public location is a region, or resource pool, that is shared with other MuleSoft customers. Examples of such regions are us-east-1, us-east-2, and eu-central-1.
For information about private locations, see Monitoring the Endpoints of Private APIs.
The tests in monitors are run on schedules. For a worker to run in a public location according to a schedule, a schedule must be associated with it. A public location can be associated with more than one schedule for more than one monitor.
The following diagram depicts the types of relationships that monitors of public 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, which is associated with Public Location 1. The monitor is written to test one or more endpoints in public API 1 and public API 2, although it could also test endpoints in more public APIs. The two 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, each of which is associated with the same public location, Public Location 1. Monitor 2 is written to test one or more endpoints in public API 3 and public API 4, although it could also test endpoints in more public APIs. The two 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, each of which is associated with a different public location, Public Location 1 and Public Location 2. Monitor 3 is written to test one or more endpoints in public API 5 and public API 6, although it could also test endpoints in more public APIs. The two 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. Each of the schedules is associated with the same public location, Public Location 2, although each could be associated with a different public location. Each of the two tested public APIs is in a different environment, Environment A and Environment B. One environment could be a test environment, and the other environment could be a production environment, where public API 7 and public API 8 are copies of the same API. Monitor 4 is written to test one or more endpoints in public API 7 and the same endpoints in public API 8, although it could also test endpoints in more public APIs.
-
Monitor 5’s relationships (indicated with dashed dark blue arrows): tests APIs in CloudHub 1.0 environments and on the web
Monitor 5 runs on a single schedule, Schedule H, although it could run on multiple schedules. The schedule is associated with Public Location 2. Monitor 5 is written to test one or more endpoints in public API 9 and in public API 10, although it could also test endpoints in more public APIs. Both APIs are accessible on the web.
Testing Private APIs from Public Locations
You can test private APIs from public locations if you allow the IP addresses of those locations. You can test a private API from a public location if you don’t want to use vCores for testing private APIs, or if you have no vCores available.
In Runtime Manager, add a new rule to the firewall for Anypoint Virtual Private Cloud (Anypoint VPC). The type must be https.port, the source must be Custom, and the port range 8081. For the source, use one of the following IP addresses:
| Public Location | IP Address |
|---|---|
us-east-1 |
3.82.89.58 |
us-east-2 |
3.128.151.139 |
eu-central-1 |
18.156.106.167 |
For instructions on adding firewall rules, refer to VPC Firewall Rules
Length of Time Before Tests Time Out
To prevent tests run in public locations from consuming too many resources, AFM prevents tests from executing for more than 120 seconds. A test fails if this maximum length of time is reached. You cannot increase this wait time.
Scheduling Tests
Tests are run at fixed intervals that you define in schedules. Each test is associated with a schedule. When you run tests from public locations, AFM sets limits on the following aspects of scheduling:
-
Number of Schedules: By default, your organization can run up to five schedules simultaneously for testing from public locations. If you reach the limit of five schedules and want to run more monitors simultaneously, contact your MuleSoft Customer Success Manager about raising your maximum.
-
Duration of Intervals Between Executions of Tests: You can schedule test intervals using a cron expression. The minimum duration of intervals between tests is set by account type. See Limits for Schedule Intervals by Location.
You can also run monitors from private locations if you have access to Anypoint Virtual Private Cloud. There is no limit to the number of schedules that you can create to use private locations. For details, see Monitoring the Endpoints of Private APIs.
You can monitor public APIs from private locations, too, not just private APIs.