This page describes how to configure an API monitoring job.
You can configure these details for an API monitoring job:
- Schedule when, where, and how often a job runs
- Set timeouts
- Set performance thresholds to trigger warning and critical events
Create a Job
- On the Controller UI, click User Experience > API Monitoring.
- Click Add Collection and specify a collection name.
- Click Add.
- Select the newly created collection and add a job.
A new job configuration page appears; proceed with the following steps:
Configure API Requests
You can select one or more locations in which the job runs. You can configure the job to test all of the locations every time or one location each time the job runs. For a complete list of Synthetic Agent locations, see Synthetic Agent Locations.
Use the hosted agents to monitor public API endpoints. You can use hosted agents to monitor the API jobs from locations where the real API traffic or request is generated.
Use the private agents to monitor the private APIs. For example, APIs used within a customer network.
The Hosted Agent Locations are where AppDynamics hosts public synthetic agents. AppDynamics has hosted agents in 17 locations (AWS locations only). You can execute the API monitoring jobs from these 17 hosted agent locations.
- If you have deployed an API Monitoring Private Synthetic Agent, you can choose from Hosted Agent Locations or Private Agent Locations.
The Private Agent Locations are where you host your private synthetic agents. You can set up private synthetic agents in any of these environments.
Set a Schedule
The multiple schedules feature is supported only in SaaS Controllers 22.2.0 and later versions.
You can define the job schedule when you create or edit your job.
You can create multiple schedules for the same job. Each schedule can have its own time zone, frequency, and execution interval. This allows you to execute the job in different frequencies:
|Different intervals in a day|
Schedule 1: Execute the job in 1-minute frequency from 8 AM to 8 PM
Schedule 2: Execute the job in 5-minute frequency from 8:01 PM to 7.59 AM
|Different days of the week|
Schedule 1: Execute the job in 1-minute frequency on weekdays
Schedule 2: Execute the job in 5-minute frequency on weekends
|Different time zones|
Schedule 1: Execute the job in 1-minute frequency from 8 AM to 8 PM in the PST time zone
Schedule 2: Execute the job in 5-minute frequency from 8 AM to 8 PM in the BST time zone
|Different date interval|
Schedule 1: Execute the job in 1-minute frequency from February 21, 2022, to March 31, 2022
Schedule 2: Execute the job in 5-minute frequency from April 1, 2022, to March 31, 2026
You can create a maximum of three schedules per job.
Click Add Schedule to configure another schedule for the same job. You must create at least one schedule.
You can prevent the execution of jobs during the maintenance period.
Let us assume you have a four-hour maintenance period on March 21, 2022 (1:01 AM - 5:00 AM). Then, you can configure multiple schedules as follows:
- Schedule 1: Execute the job in 1-minute frequency from 8:00 AM on February 21, 2022, to 1:00 AM on March 21, 2022
- Schedule 2: Execute the job in 1-minute frequency from 5:01 AM on February 21, 2022, to 12:00 AM on March 21, 2026
Set Timeout Period
You can configure timeout to make the jobs fail if the time taken to execute the jobs exceeds a certain duration. By default, the API jobs timeout if the job execution does not complete within 5 minutes.
A job that fails because of timeout is considered an availability issue.
This is an optional step. You can configure performance thresholds that will trigger warning or critical synthetic events when the thresholds are exceeded.
API jobs failure irrespective of the reason, namely, invalid status code, response content validation, response size validation, and so on, are configured to be reported as an availability event by default. To avoid false positives, you can configure to re-test the jobs a specific number of times before triggering the events.
You can configure API jobs to trigger warning or critical error events based on the response time of the API jobs. To avoid false positives, you can configure to re-test the jobs a specific number of times before triggering the events.