The Synthetic REST API is used to construct and maintain various forms of synthetic monitors, including ping (SIMPLE), simple browser (BROWSER), scripted browser (SCRIPT BROWSER), and API test (SCRIPT API). You can make API calls to alter or obtain secure credentials data using the Synthetics REST API.
Synthetic Monitoring uses behavioral scripts to simulate end-user transactions to assess and measure workflow performance over numerous test points. They can also record aggregate data, such as a ping monitor’s overview or summary, specific information for each page resource, and downtime instances. Custom response codes are also collected by synthetic monitoring for a more detailed look at your monitor runs. The REST API provides access to all synthetic monitoring data. You’ll need a user role with that capability and a user key to utilize the Synthetics REST API.
One option to increase API availability and data dependability is to use synthetic monitoring tools with multi-step API monitors. Just keep in mind that synthetic monitoring only employs a limited number of API calls. As a result, real-world traffic may differ from synthetic monitoring inputs.
Synthetic monitoring, on the other hand, isn’t intended to quantify consumption rates because it simulates individual transactions rather than monitoring the whole volume of transactions. The telemetry instrumentation used to measure and report the consumption rate is usually built into the API architecture from the start or monitored using an Application Performance Monitoring (APM) tool.
The Synthetics REST API sets a limit of three queries per second for each account. Requests that exceed this limit will receive a 429 response code.
Features of Synthetic REST API’s
Synthetic monitoring verifies the health of your application at all times of day, in all relevant locations, across all network providers, and for every significant and little transaction. It does not necessitate active users in order to assess performance. Synthetic monitoring gathers data that is segmented by network checkpoints discovered along the data flow. Without synthetic monitoring, vital network data is hazy at best, and performance blindspots are common.
- Similar to how these settings are provided in the UI, you can specify the options for SIMPLE and BROWSER type monitors.
- When a validation error occurs, the Synthetics API tries to return as much information as possible. This will assist you in determining what is wrong with the request.
- While your services are being tested in a staging environment prior to production release, conduct performance analysis.
- Instead of needing to specify the full monitor entity in a PUT, you can update only the fields of a monitor that you want to change.
- The payload size has a significant impact on delay. This is why both small and large payloads should be monitored with synthetic APIs.
- There are several APIs that answer with a 200 OK status code but were not designed with the correct HTTP status code. Beyond the status code, synthetic monitoring tools can compare the result of a test with an expected value to ensure the accuracy of the API response.
- Large API answers are paginated properly.
- Conducting a responsiveness competitive analysis to compare to other applications or websites.
Payload attributes for Synthetics REST API
|Synthetics API attribute||Type and Definition|
|apiVersion||String: The version number.|
|count||Integer: The number of monitors returned.|
|emails||Array of strings: Email addresses for alert notifications with New Relic.|
|frequency||Integer: Number of minutes between checks. Valid values include 1, 5, 15, 30, 60, 360, 720, and 1440.|
|id||The UUID for the specific synthetic monitor.|
|locations||Array of strings: Array of locations by full label.|
|name||String: The monitor’s name.|
|scriptLocations||String: The name and hmac values for private locations using Verified Script Execution.|
|scriptText||String: The BASE64 encoded text for scripted monitors.|
|slaThreshold||Double: Value for the Synthetics SLA report, in seconds.|
|status||String: Valid values include ENABLED, MUTED, and DISABLED.|
|type||String: Type of monitor. Valid values include:SIMPLE (Ping)BROWSERSCRIPT_BROWSERSCRIPT_API|
|uri||String: The URI for SIMPLE and BROWSER monitor types; for example, http://my-site.com. Optional for SCRIPT_BROWSER and SCRIPT_API.|
|userID||Integer: The specific user ID.|
|options||Object: options for SIMPLE and BROWSER monitor types. Options include:validationString : stringverifySSL : boolean (true,false)bypassHEADRequest : boolean (true,false)treatRedirectAsFailure : boolean (true, false)|
What Are Synthetic Transactions?
Synthetic transactions are the outcome of scripts replicating real-world user behavior on a website or application. These transactions are mostly used to test the performance of production settings, but they can also be used to test the functionality of newly released apps before they are deployed. You can see how your website or database might perform under varying loads that mimic real user activity by using synthetic transactions that run at regular intervals.
Synthetic Transactions vs. API Monitoring
There are similarities as well as differences found in Synthetic transactions and API monitoring.
Synthetic transactions and API monitoring both involve monitoring using software instead of real people and verifying if the application performs as expected and delivers a quality user experience.
Synthetic monitoring mimics application behavior through simulations and emulations. Wherein, API monitoring validates the internal and third-party APIs used for communication.
Synthetic transactions monitor applications that may use APIs. API transactions monitor an API usable by many applications. Together, they provide a comprehensive view of performance across a transaction’s full workflow.