Runtimes

What are Runtimes?

Runtimes are individual instances that are running as part of a typical API Management deployment setup. The API management setup comprises various products such as API Gateway, Developer Portal, and Microgateway. Each product can be deployed as single node or clustered for high availability. Irrespective of the number of nodes, a complete deployment of each product represents one runtime. These runtimes can be deployed in varying landscapes such as multi-region, multi-cloud, hybrid environments, and so on.

Assume that John Doe Enterprises makes use of the AWS and Azure versions of the Software AG Cloud platform. It has runtimes scattered in three different regions -in the United States, Europe, and Australia as shown in the figure. There are three staging runtime environments for each region, including development, pre-production, and production. These existing runtimes in varying landscape are added to the API Control Plane. After these runtimes are added, API Control Plane captures the details of all the nine runtimes in the landscape. API Control Plane offers the ability to manage and monitor all the nine runtimes and the specifics of the associated assets in a single UI without logging into individual runtimes.

Manage Runtimes

The Manage runtimes page lists the runtimes in API Control Plane.

The runtimes get auto populated in API Control Plane when the connectivity between runtimes and API Control Plane is established. To establish connectivity from API Gateway (On premise) to API Control Plane, see Configuring API Control Plane section in API Gateway Administration guide. To establish connectivity from webMethods.io API Gateway (Cloud) to API Control Plane, see Configuring API Control Plane. To connect any third-party gateways with API Control Plane, see Agent SDK.

As shown in the following figure, the highlighted areas on the Manage runtimes page allow you to customize the rows and columns of the runtime list, add, search, filter, view, edit, and delete the runtime.

Editing a runtime

Runtimes are automatically populated in API Control Plane when the runtime establishes connectivity with API Control Plane. The API Control Plane agent, embedded in each runtime, starts sending data to API Control Plane, with the information received from each runtime. For details about how to establish a connection between runtimes and API Control Plane, see Connecting webMethods.io API Gateway to API Control Plane section in API Gateway Administration guide. For details about how to establish a connection between runtimes and API Control Plane using SDK see Agent SDK.As a user, you might want to customize the runtimes based on the project requirements, like adding additional tag names, modifying the deployment type, changing the location, and so on.

API Control Plane allows you to modify the auto-populated runtime details of runtimes.

Before you begin:

Ensure that you are assigned to the API platform providers user group to perform this task.

To edit a runtime

1. Click the Runtimes tab.
   The Manage runtimes page appears.

   

2. Click Action menu > Edit on any runtime.
   The Edit page appears, displaying the Step 1 Basic Details section.

   

3. Edit the following details as required:

   • Name*. Name is mandatory.
   • Description.

   • Upload the file in the Icon drop area using one of the following method:

     • Drag and drop the files
     • Click Browse files and select the file
       

     If the file is not uploaded, API Control Plane uses the icon.

     Note

     Make sure the file size does not exceed 1 MB. Also, make sure the file you upload is in the svg, jpeg, jpg, or png format.

4. Click Next.
   The Step 2 Tags section appears.

   

5. Edit the following details as required:

   • Tags. Tag name of the runtime.
   • Type *. Runtime type. API Gateway is selected as the default. This field is disabled when you edit a runtime.
   • Deployment type *. The runtime deployment type. Permitted values are On premises, Software AG Cloud, and Private cloud.
   • Host. Specify the host name. This field accepts valid URLs, hostnames, and IPv4 and IPv6 address formats.
     

   • Capacity. The approximate estimate of the throughput that a runtime can handle. You can configure the Capacity value with any non-negative integer and for any duration which can be in the following units:

     • per second
     • per minute
     • per hour
     • per day
     • per week
     • per month
     • per year
       

     A data plane’s total capacity is the sum of all of its separate runtime capacities. The aggregate capacity value is displayed on the dashboard and the monitoring screens.

     If the Capacity value is not set or set to 0, the used capacity of the runtime in the Dashboard’s Capacity widget is displayed as 0. For more information on Capacity, see Capacity.

     Note

     • In case of API Gateway, the capacity value is loaded from API Gateway agent when it estabilishes the connection with API Control Plane.
     • You can modify the capacity value loaded from API Gateway agent. When API Gateway agent restarts, the modified capacity value is overwritten.

6. Click Next.
   The Step 3 Location section appears.

   

7. Edit the following details as required.

   • Region. Region of the runtime. For example, AWS-US
   • Location. Location of the runtime. For example, Oregon
     

8. Click Save.
   The runtime details are modified and saved.

Deleting a runtime

API Control Plane allows you to delete the runtimes and the APIs associated with the runtimes in API Control Plane. The data planes will no longer be associated with the runtime when you delete a runtime that is linked to multiple data planes.

Before you begin:

• Ensure that you are assigned to the API platform providers user group to perform this task.
• If there are any APIs associated with the runtime you are deleting, ensure that you are assigned to
  API platform providers and API product managers user group to delete the runtime and the associated APIs.

To delete a runtime

1. Click the Runtimes tab.
   The Manage runtimes page appears.

   

2. Click Action menu > Delete on the runtime that you want to delete.
   The Delete runtime confirmation window appears.

3. Click Yes, delete runtime.
   The runtime and the APIs associated with it are deleted.

   Note

   You can also delete a runtime using a REST endpoint. For more information on the delete runtime REST endpoint, see Administration APIs. Deleting a user removes the user information and can not be retrieved through audit logs.

Viewing the APIs associated with a runtime

To manage and monitor the APIs across runtimes efficiently, API Control Plane gives a consolidated view of the APIs associated with a specific runtime.

Before you begin

Ensure that you are assigned to the API platform providers, API product managers, or API Control Plane administrators user group to perform this task.

To view the APIs associated with a runtime

1. Click the Runtimes tab.
   A list of all the available runtimes in API Control Plane appears.

2. Click Action menu > Details on any runtime.
   The runtime details page appears.

   

3. Click APIs.
   A list of all the APIs associated with the runtime appears.

   

Next steps

• The API Control Plane user can use the information displayed to view the status of APIs, gain insights of the API performance, monitor the API usage and performance of APIs.

• You can open the APIs in API Gateway if the runtime hostname is defined in API Control Plane. Click the ellipsis icon in the Action column to open the API in API Gateway.

  Note

  If the API is associated with just webMethods Developer Portal runtime and not with any other runtimes, then Open in gateway option is not applicable.

  

Monitor Runtimes

Monitor runtime enables you to monitor and track the key performance indicators of the runtimes. It helps you to make informed business decisions by analyzing the performance metrics of the runtimes.

API Control Plane lets you to monitor the runtimes in following ways:

• Monitor all runtimes lets you to monitor the availability of all the runtimes and their business metrics in a single view. It also allows you to infer insights about the performance of the runtimes.

• Monitor a specific runtime lets you to monitor the performance and business metrics of a specific runtime.

Before you begin

Ensure that you have the API platform providers or the API product managers user group assigned to perform this task.

Monitoring all runtimes

API Control Plane provides you with the ability to oversee the performance of all runtimes in a unified view. This consolidated perspective allows you to pinpoint the highest and lowest performing runtimes, facilitating data-driven business decisions.

To monitor all the runtimes in the landscape

1. Click the Runtimes tab.
   The Manage runtimes page appears.

   

2. Click the icon in the top right corner of the page.

   By default, the Monitor runtimes page renders the metrics of all the runtimes pertaining to last 1 hour. If you want to render the metrics for a different time range, select the predefined or custom time range from the Time Range drop-down menu (that appears in the top right corner of the page) based on your requirement and click the Apply button.

   

   Note

   Since webMethods.io Developer Portal does not send performance metrics to API Control Plane, only the Status and Availability widgets are applicable for Developer Portal runtime type. Therefore, data is populated only in these two widgets. If API Control Plane contains only Developer Portal runtime type and no other runtime types, only the Status and Availability widgets will be rendered on the Monitor runtimes page; the remaining widgets will not be displayed.

Widgets in detail

The widgets in the Monitor runtimes page are explained in detail as follows:

Status, performance & used capacity

This widget provides a comprehensive view of all runtimes by displaying their status, performance, and used capacity.

Status
The status of runtime indicates the health of the runtime. It is determined based on the availability of the runtime. The status of the runtime can be one of the following:

Status	Description
	Green indicates that the runtime’s availability is 100%.
	Amber indicates that the runtime’s availability is greater than 99% and lesser than 100%.
	Red indicates that runtime’s availability is less than 99%.
	Grey indicates that there is no adequate data to compute the availability of runtimes. For example, if you register a runtime an hour ago and try to view the dashboard by applying the default Last 1 hour time range, the status appears grey due to the lack of available data during that time period.

How to determine the availability of the runtime?

The availability is determined based on the sum of the heartbeat status value of the runtime. If API Control Plane:

• receives the heartbeat status from the runtime. The value of the heartbeat status is represented as 1.
• doesn’t receive the heartbeat status from the runtime. The value of the heartbeat status is represented as 0.

The frequency at which the runtime must send the heartbeat status to API Control Plane is defined in the API Control Plane Agent configuration. For details about how to configure the API Control Plane Agent, see Connecting webMethods.io API Gateway to API Control Plane section in API Gateway Administration guide. For details about how to develop agent using SDK, see Agent SDK. .

For example, if the heartbeat interval is defined as 60 seconds in the API Control Plane agent configuration, then for an hour, the expected heartbeat status value must be 3600.

$$\text{Availability of a runtime} = \frac{\displaystyle\sum_{i=1}^{n}\left(\text{Actual heartbeat value of the runtime in the time stamp }i\right)}{\displaystyle\sum_{i=1}^{n}\left(\text{Expected heartbeat value of the runtime in the time stamp }i\right)}\times 100$$

Example:

Let’s determine the availability of the runtime A for 4 hours based on the following metrics. Let’s assume:

$\text{Availability of the runtime A for 4 hours} = (\frac{1800+3600+1200+3600}{3600+3600+3600+3600})*100 = 70.83\%$

The status of the runtime is displayed as red.

Performance
Performance shows how good each runtime is performing based on two metrics - error rate and latency. The threshold for the latency and error rate are set based on the user preference. For details about setting the performance threshold, see Change threshold settings. For details about how to determine the error rate and latency, see Error rate, Latency.

The performance status of the runtime can be one of the following:

Performance status	Description
	Green indicates that both latency and error rate threshold values are within the acceptable limit.
	Amber indicates that either latency or error rate threshold value is within warning limit or above the unacceptable limit.
	Red indicates that both latency and error rate threshold values are within warning limit or above the unacceptable limit.
	Grey indicates that there is no adequate data to compute the performance of the runtimes in the data plane. For example, if you register a runtime an hour ago and you try to view the dashboard by applying the default Last 1 hour time range, the status appears as grey due to the lack of available data during that time period.

Used capacity
Capacity displays the used capacity rate of the runtime. Capacity is the number of transactions that a runtime can handle. The used capacity status of the runtime can be one of the following:

Used capacity status	Description
	Green indicates that the capacity rate is lesser than or equal to 30%
	Amber indicates that the capacity rate is greater than 30% and lesser than or equal to 70%
	Red indicates that the capacity rate is greater than 70%
	Grey indicates one of the following: there is no adequate data to compute the capacity rate. For example, if you register a runtime an hour ago and try to view the dashboard by applying the default Last 1 hour time range, the status appears grey due to the lack of available data during that time period. the capacity is not defined for all runtimes in the data plane.

How to determine the used capacity of the runtime?

$$\text{Used capacity of the runtime} = (\frac{\text{Actual TPS of the runtime}} {\text{Expected TPS of the runtime}})*100$$

Example: Let’s see how to determine the used capacity of a runtime. Assume that you have defined the capacity as 10000 transactions per hour for runtime A. For more details about how to define the capacity of a runtime, see Editing a runtime.

The expected TPS of the runtime A = $\frac{10000}{1hr * 60 min * 60secs} = 2.77$ transactions per second.

Let’s assume that runtime A has performed 39000 transactions in the last 6 hours.

The actual TPS of the runtime A = $\frac{39000}{6hrs * 60 min * 60secs} = 1.81$ transactions per second.

Used Capacity of the runtime A =$(\frac{1.81}{2.77})*100 = 65\%$

The capacity of the runtime A is displayed as 65% in amber.

Problematic runtimes by

This widget helps identify issues across runtimes by analyzing total transaction volumes, error rate, response time, and latency of all associated runtimes. Choose a business metric to view its corresponding least and most problematic runtime. The runtime split and line graph display runtime in a sequence from the most problematic to the least.

For details about how to determine the error rate, response time, latency, and transactions, see Error rate, Response Time, Latency, and Transactions.

Transactions

This widget provides a comprehensive overview of total transaction volumes across all runtimes with a trend percentage, along with detailed insights into the top-performing and under-performing runtimes to help you make informed business decisions. It presents both pictorial and graphical representations of the runtimes based on performance, highlighting maximum and minimum transaction counts for easy comparison. Click Top runtimes or All runtimes tab to view its respective transactions in the runtime split and line graph.

You can customize the number of Top runtimes to display using Row settings under User preferences. For more details, see Customizing Row settings.

The Upward Trending tab displays the list of runtimes for which the transaction trend percentage is greater than the set transaction trend threshold in the Runtime: Upward trending/improving section of the User preference - Threshold page. The Downward trending tab displays the list of runtimes for which the transaction trend percentage is lesser than the set transaction trend threshold in the Runtime: Downward trending / deteriorating by section of the User preference - Threshold page. For more details on how to set the trend threshold, see Change threshold settings.

How to determine the total transactions and trend analysis for all runtimes?

$$\text{Total transactions of the runtime} = {\sum_{i=1}^{n} \left(\text{Total transactions of the runtime in the time stamp } i\right)}$$

Example:

Let’s determine the total transactions of the runtime A for 4 hours based on the following metrics. Let’s assume:

$\text{Total transaction of the runtime A for 4 hours} = {100+200+250+100} = 550$

Similarly, let’s assume, the total transactions of the runtime B for 4 hours is 450

$$\text{Total transactions of all runtimes} = {\displaystyle\sum_{i=A}^{n} \left(\text{Total transactions of runtime } i\right)}$$

Let’s determine the total transactions of all runtimes for 4 hours. Let’s assume:

$\text{Total transaction of all runtimes for 4 hours} = {550+450} = 1000$

Transactions trend analysis allows you to compare current and past transactions based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

$$\text{Transactions trend percentage for all runtimes for 24 hours} = (\frac{\text{Total transactions of runtime in last 24 hours} - \text{Total transactions of runtime in previous 24 hours}}{\text{Total transactions of runtime in previous 24 hours}})*100$$

You can replace 24 hours with the time range you select in the time range. If the determined trend percentage of transactions is a

• positive value, it is displayed in green with an upward arrow, indicating that transaction volume is increasing.
• negative value, it is displayed in red with a downward arrow, indicating that transaction volume is decreasing.

Example:
Let’s determine the transactions trend percentage for all runtimes for 24 hours:

Let’s assume:

$\text{Transactions trend percentage for 24 hours for all runtimes} = (\frac{1000-500}{500} )*100 = 100\%$

The determined transactions trend percentage, 100% (positive), appears in green with an upward arrow indicating increased transactions compared to the previous 24 hours.

Error rate

Error rate indicates the percentage of errors that occurred during API transactions. This widget provides a comprehensive overview of error rate of all runtimes along with the details of the runtime with maximum and minimum error rate to make informed business decisions. Click Top runtimes or All runtimes tab to view its respective error rate in the runtime split and line graph.

You can customize the number of Top runtimes to display using Row settings under User preferences - Display. For more details, see Customizing Row settings.

The Upward Trending tab displays the list of runtimes for which the error rate trend percentage is lesser than the set error rate trend threshold in the Runtime: Upward trending/improving section of the User preference - Threshold page. The Downward trending tab displays the list of runtimes for which the error rate trend percentage is greater than the set error rate trend threshold in the Runtime: Downward trending / deteriorating by section of the User preference - Threshold page. For more details on how to set the trend threshold, see Change threshold settings.

How to determine the error rate and trend analysis for all runtimes?

$$\text{Error rate of the runtime} = \frac{\displaystyle\sum_{i=1}^{n} \left(\text{Error count of the runtime in the time stamp } i\right)}{\displaystyle\sum_{i=1}^{n} \left(\text{Transactions count of the runtime in the time stamp } i\right)} \times 100$$

Example:

Let’s determine the error rate of the runtime A for 4 hours based on the following metrics. Let’s assume:

$\text{Error rate of the runtime A for 4 hours} = (\frac{150+115+30+100}{300+200+500+300})*100 = 35.90\%$

Similarly, let’s assume, the error rate of the runtime B for 4 hours is 50%

$$\text{Error rate of all runtimes} = \frac{\displaystyle\sum_{i=A}^{n} \left(\text{Error count of the runtime } i\right)} {\displaystyle\sum_{i=A}^{n} \left(\text{Transactions count of the runtime } i\right)} \times 100$$

Let’s determine the error rate of all runtimes for 4 hours. Let’s assume:

$\text{Error rate of all runtimes for 4 hours} =(\frac{395 + 250}{1100 + 500})*100 = 40.31\%$

Error rate trend analysis allows you to compare current and past error rates based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

$$\text{Error rate trend percentage for all runtimes for 24 hours time range} = (\frac{\text{Error rate of all runtimes in last 24 hours} -\text{Error rate of all runtimes in previous 24 hours}}{\text{Error rate of all runtimes in previous 24 hours}})*100$$

You can replace 24 hours with the time range that you select. If the determined error rate trend percentage is a

• positive value, it is displayed in red with an upward arrow, indicating that the error rate is increasing.
• negative value, it is displayed in green with a downward arrow, indicating that the error rate is decreasing.

Example:

Let’s determine the error rate trend percentage for all runtimes for 24 hours. Let’s assume:

$\text{Error rate trend percentage for 24 hours time range for all runtimes} = (\frac{0.35-0.50}{0.50})*100 = -30\%$

The determined error rate trend percentage, -30% (negative), appears in green with an downward arrow indicating that the error rate has decreased compared to the previous 24 hours.

Availability

This widget shows the availability of all runtimes, which enables you to monitor the health status of all associated runtimes.

The availability is determined based on the sum of the heartbeat status value of the runtime. If API Control Plane:

• receives the heartbeat status from the runtime. The value of the heartbeat status is represented as 1
• doesn’t receive the heartbeat status from the runtime. The value of the heartbeat status is represented as 0

The frequency at which the runtime must send the heartbeat status to API Control Plane is defined in the API Control Plane Agent configuration. For details about how to configure the API Control Plane Agent, see Connecting webMethods.io API Gateway to API Control Plane section in API Gateway Administration guide. For details about how to develop agent using SDK, see Agent SDK.

For example, if the heartbeat interval is defined as 60 seconds in the API Control Plane agent configuration. Then for an hour the expected heartbeat status value must be 3600.

$$\text{Availability of a runtime} = \frac{\displaystyle\sum_{i=1}^{n} \left(\text{Actual heartbeat value of the runtime in the time stamp } i\right)}{\displaystyle\sum_{i=1}^{n} \left(\text{Expected heartbeat value of the runtime in the time stamp } i\right)} \times 100$$

Example:

Let’s determine the availability of the runtime A for 4 hours based on the following metrics. Let’s assume:

$\text{Availability of the runtime A for 4 hours} = (\frac{1800+3600+3000+3600}{3600+3600+3600+3600})*100 = 83.33\%$

Similarly, let’s assume, the availability of the runtime B for 4 hours is 100%

$$\text{Availability of all runtimes} = \frac{\displaystyle\sum_{i=A}^{n} \text{Availability of Runtime } i} {\text{Total Number of Runtimes}}$$

Let’s assume:

$\text{Availability of all runtimes} = (\frac{83.33+100}{2})*100 = 91.66\%$

Availability trend analysis allows you to compare current and past availability status based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

$$\text{Availability trend percentage for all runtimes for 24 hours time range} = (\frac{\text{Availability of all runtimes in last 24 hours} - \text{Availability of all runtimes in previous 24 hours}}{\text{Availability of all runtimes in previous 24 hours}})*100$$

You can replace 24 hours with the time range that you select. If the determined trend percentage of availability is

• positive value, it is displayed in green with an upward arrow, indicating that availability is increasing.
• negative value, it is displayed in red with a downward arrow, indicating that availability is decreasing.

Example:

Let’s determine the availability trend percentage for all runtimes for 24 hours. Let’s assume:

$\text{Availability Trend percentage for runtimes for 24 hours time range} = (\frac{0.98-0.80}{0.80})*100 = 22\%$

The determined availability trend percentage, 22% (positive), appears in green with an upward arrow indicating that the availability has increased compared to the previous 24 hours.

Response time

Response time indicates total time taken to process an incoming API request and send the response to the client during API transactions. This includes the time taken by API Gateway and the backend service to process the request. This widget provides a comprehensive overview of response time of all runtimes along with the details of the runtime with maximum and minimum latency to make informed business decisions. Click Top runtimes or All runtimes tab to view its respective response time in the runtime split and line graph.

You can customize the number of Top runtimes to display using Row settings under User preferences - Display. For more details, see Customizing Row settings.

The Upward Trending tab displays the list of runtimes for which the response time trend percentage is lesser than the set response time trend threshold in the Runtime: Upward trending/improving section of the User preference - Threshold page. The Downward trending tab displays the list of runtimes for which the response time trend% is greater than the set response time trend threshold in the Runtime: Downward trending / deteriorating by section of the User preference - Threshold page. For more details on how to set the trend threshold, see Change threshold settings.

How to determine the response time and trend analysis for all runtimes?

$$\text{Response time of a runtime} = \frac{\displaystyle\sum_{i=1}^{n} \left(\text{Response time of the runtime in time stamp } i \times \text{Total transaction count of the runtime in time stamp } i\right)}{\displaystyle\sum_{i=A}^{n} \left(\text{Transaction count of runtime } i\right)}$$

Example:

Let’s determine the response time of the runtime A for 4 hours based on the following metrics. Let’s assume:

$\text{Response time of the runtime A for 4 hours} = (\frac{(1.05*10)+(2.07*15)+(0.08*20)+(1.07*30)}{75}) =1.00ms$

Similarly, let’s assume, the response time of the runtime B for 4 hours is 0.05ms

$$\text{Response time of all runtimes} = \frac{\displaystyle\sum_{i=A}^{n} (\text{Response time of runtime } i \times \text{Total transaction count of runtime } i)}{\displaystyle\sum_{i=A}^{n} \text{Transaction count of runtime } i}$$

Let’s assume:

$\text{Response time of all runtimes} = (\frac{(1.00*75)+(0.05*60)}{135}) = 0.57ms$

Response time trend analysis allows you to compare current and past response time based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

$$\text{Response time trend percentage for all runtimes for 24 hours time range} = (\frac{\text{Response time of all runtimes in last 24 hours} - \text{Response time of all runtimes in previous 24 hours}}{\text{Response time of all runtimes in previous 24 hours}})*100$$

You can replace 24 hours with the time range that you select. If the determined trend percentage of response time is

• positive value, it is displayed in red with an upward arrow, indicating that response time is increasing.
• negative value, it is displayed in green with a downward arrow, indicating that response time is decreasing.

Example:

Let’s determine the response time trend percentage for all runtimes for 24 hours. Let’s assume:

$\text{Response time Trend percentage for runtimes for 24 hours time range} = (\frac{0.57-3.41}{3.41})*100 = -83.28\%$

The determined response time trend percentage, -83.28% (negative), appears in green with an downward arrow indicating that the response time has decreased compared to the previous 24 hours.

Latency

Latency indicates time taken by API Gateway to process an API request during API transactions. This does not include the time taken by the backend service to process the request. This widget provides a comprehensive overview of latency of all runtimes along with the details of the runtime with maximum and minimum latency to make informed business decisions. Click Top runtimes or All runtimes tab to view its respective latency in the runtime split and line graph.

You can customize the number of Top runtimes to display using Row settings under User preferences - Display. For more details, see Customizing Row settings.

The Upward Trending tab displays the list of runtimes for which the latency trend percentage is lesser than the set latency trend threshold in the Runtime: Upward trending/improving section of the User preference - Threshold page. The Downward trending tab displays the list of runtimes for which the latency trend% is greater than the set latency trend threshold in the Runtime: Downward trending / deteriorating by section of the User preference - Threshold page. For more details on how to set the trend threshold, see Change threshold settings.

How to determine the latency and trend analysis for all runtimes?

$$\text{Latency of a runtime} = \frac{\displaystyle\sum_{i=1}^{n} \left(\text{Latency of the runtime in time stamp } i \times \text{Total transaction count of the runtime in time stamp } i\right)}{\displaystyle\sum_{i=A}^{n} \left(\text{Transaction count of runtime } i\right)}$$

Example:

Let’s determine the latency of the runtime A for 4 hours based on the following metrics. Let’s assume:

$\text{Latency of the runtime A for 4 hours} = (\frac{(0.05*10)+(0.07*15)+(0.08*20)+(0.07*30)}{75}) = 0.04ms$

Similarly, let’s assume, the latency of the runtime B for 4 hours is 0.05ms

$$\text{Latency of all runtimes} = \frac{\displaystyle\sum_{i=A}^{n} \left(\text{Latency of runtime } i \times \text{Total transaction count of runtime } i\right)}{\displaystyle\sum_{i=A}^{n} \left(\text{Transaction count of runtime } i\right)}$$

Let’s assume:

$\text{Latency of all runtimes} = (\frac{(0.04*75)+(0.05*60)}{135}) = 0.04ms$

Latency trend analysis allows you to compare current and past latency based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

$$\text{Latency trend percentage for all runtimes for 24 hours time range} = (\frac{\text{Latency of all runtimes in last 24 hours} - \text{Latency of all runtimes in previous 24 hours}}{\text{Latency of all runtimes in previous 24 hours}})*100$$

You can replace 24 hours with the time range that you select. If the determined trend percentage of latency is

• positive value, it is displayed in red with an upward arrow, indicating that latency is increasing.
• negative value, it is displayed in green with a downward arrow, indicating that latency is decreasing.

Example:

Let’s determine the latency trend percentage for all runtimes for 24 hours. Let’s assume:

$\text{Latency trend percentage for runtimes for 24 hours time range} = (\frac{0.04-3.41}{3.41})*100 = -98.82\%$

The determined latency trend percentage, -98.82% (negative), appears in green with an downward arrow indicating that the latency has decreased compared to the previous 24 hours.

Monitoring a specific runtime

API Control Plane provides guidance on monitoring the performance of a particular runtime. This monitoring capability helps you pinpoint the highest and lowest performing APIs within that runtime, empowering you to make well-informed business decisions.

To monitor a specific runtime

1. Click the Runtimes tab.
   The Manage runtimes page appears.

   

2. Click the icon under the Action column corresponding to the runtime for which you want view the performance metrics.

   By default, the Runtime specific monitoring page renders the metrics of all the runtimes pertaining to last 1 hour. If you want to render the metrics for a different time range, select the predefined or custom time range from the Time Range drop-down menu (that appears in the top right corner of the page) based on your requirement and click the Apply button.

   

For more details on how each widget is represented, see Widgets in detail section under Monitoring all runtimes

Runtime specific Monitoring: Activities