Managing an Applications Traffic Management Services

Evaluating an application's traffic

When monitoring several applications in your BIG-IQ^® applications screen, you can quickly assess the overall traffic data of each application by viewing the application health and traffic statistics (for system admin Applications > APPLICATIONS ). You can further isolate a single application to evaluate data over time, based on general HTTP traffic statistics, client-side traffic statistics, Web Application Security policy statistics, and pool member activity.

Users with system administrator access can also evaluate the data of several applications at once, using the dashboards found in the Monitoring screens (click Monitoring > DASHBOARDS > Local Traffic > HTTP ).

Note: To view application health or traffic data, your application must be managed by a BIG-IP device version 13.1.0.5 or later, and HTTP statistics collection must be enabled.

Verify traffic performance for all your applications

You can verify that each application is managing traffic as expected, by monitoring the HTTP traffic and server configuration statistics in the all application screen.

Click Applications > APPLICATIONS ).
Locate the HEALTH area at the top left of the summary bar and verify that all your applications have a good health status.
You can click the Good health status to filter the applications listed on the screen.
1. Review the Health area to ensure that all your applications have a good health status.
2. Review LONGEST RESPONSE TIME, TOP HTTP TRANSACTIONS, and TOP CONNECTIONS areas to view the five applications that currently the highest average for each metric.
  Click one of these areas in the summary bar to sort the applications listed on the screen in descending order.
In the summary bar, locate the LONGEST RESPONSE TIME, TOP HTTP TRANSACTIONS, and TOP CONNECTIONS areas to view the five applications that currently the highest average for each metric
You can click one of these areas sort the applications listed on the screen in descending order.
In the application list, check the Active Alerts and area to ensure that no application performance thresholds have been violated.
You can also look at the Last Modified field to ensure that changes did not result in unexpected alerts and trends.
If you want to monitor a single application's traffic performance in the single application screen, select the application's name.
The screen for this application opens, where you can monitor the application's data and verify that it is performing as expected.

Evaluating an application's traffic data

The monitoring tools in a single application screen help you to evaluate your application's traffic data over time. Use these tools to ensure that a newly configured application, or application changes, are performing as expected.

For general traffic analysis, you can use the Traffic Management charts found in the ANALYTICS area of a single application screen. The charts include indicators of alerts within the chart's time line, and advanced data filtering options in the Dimensions pane. For example, you can monitor the average application response time of a single pool member, by selecting an entity from the Pool Member Address dimension.

To monitor traffic data changes over time, you can use the Alerts History to evaluate raised alerts and when they were mitigated.

Monitor an application's traffic data

You can monitor traffic data single application to verify that it is performing is as expected.

Open the application properties screen by selecting the application's name from the Applications screen ( click Applications > APPLICATIONS > <Application Name> ).
Review the ALERT HISTORY area at the top right of the summary bar to ensure that any raised alerts have been cleared.
Near the middle of the screen in the APPLICATION SERVICES area, select Traffic Management to display traffic information in the ANALYTICS and CONFIGURATION areas.
To view application traffic data, select from options to the left of the screen in the ANALYTICS area.
This displays charts for the application's traffic data.

Tip: Expand the chart view by collapsing the summary bar and/or application configuration map using the arrows to the right of these areas.

If you have administrative access, you can view the HTTP traffic data for all system application in the HTTP dashboard Monitoring > DASHBOARDS > Local Traffic > HTTP .

Application traffic management charts

This table lists and defines the charts found in the single application screen ( Applications > APPLICATIONS > <Application Name> ) for Traffic Management, in the APPLICATION SERVICES area. These charts display the trends of application traffic processed by the BIG-IP system. Each chart displays an aspect of application traffic as a function of the selected time period.

ANALYTICS Menu Option	Chart Title	Description
Transactions	HTTP Transaction Outcomes	The average outcome assigned by the BIG-IP system to the request and response exchange between the client, BIG-IP system and server. Metric Unit: Average Transactions per Second Legend: Passthrough: HTTP transactions that completed the request and response exchange using the BIG-IP system. Incomplete: HTTP transactions that did not complete the entire request and response exchange. Cached by BIG-IP: Requests stored by the BIG-IP system to reduce the traffic load on back-end servers. BIG-IP Response: HTTP requests that received a response directly from the BIG-IP.
Concurrent Connections	Concurrent Connections	The application's average number of active connections per second with the BIG-IP system virtual servers, either on the client or server side. Metric Unit: Number of connections Legend: Client Side: The average number of concurrent connections from the client side Server Side: The average number of concurrent connections from the server side.
Application Response Time	Application Response Time	The average time it takes for the server to send a response message once the server receives the request from the BIG-IP system. Metric Unit: ms Legend: Min: The lowest server latency observed. Avg: The average server latency observed. Max: The highest server latency observed.
Page Load Time	Page Load Time	The average time it takes for a client request to receive a full response from the server and BIG-IP system. Metric Unit: ms Legend: Avg: The average page load time observed. Max: The highest page load time observed.
Server Side RTT	Server Side Round-Trip Time	The time it takes for the BIG-IP system to send a request and receive a response from the server, not including the application response time. This is a system performance indicator. Metric Unit: ms Legend: Min: The lowest server RTT observed. Avg: The average server RTT observed. Max: The highest server RTT observed.
Client Side RTT	Client Side Round-Trip Time	The time it takes for a client to send a request and receive a response over the BIG-IP system. This includes the time it takes for client's request to reach the BIG-IP system and the time it takes for the client to receive a response from the BIG-IP system. Metric Unit: ms Legend: Min: The lowest server RTT observed. Avg: The average server RTT observed. Max: The highest server RTT observed.
Response Codes	Transaction Response Code Families	The average server HTTP status code grouping responses received per second. Metric Unit: Average Transactions per Second Legend: 2XX: Server successfully connected and responded to the request. 3XX: Connection was refreshed or updated on the client's side after sending a request. 4XX: Client-side error that does not allow the server to complete the request. 5XX: Server-side error that does not allow the server to complete the request. NA: Incomplete transaction.
E2E Time	End-to-End-Time	The time required for an application request and response transaction, not including system latency and transmission times. Metric Unit: ms Legend: Client RTT: The average time it takes for a client to send a request and receive a response over the BIG-IP system. Server RTT: The average time it takes for a client to send a request and receive a response over the BIG-IP system. Application Response Time: The average time it takes for a server to send a response, after receiving a request.

Detecting applications with health and performance issues

A low application health status indicates that an application's performance data values violated a defined alert threshold. When monitoring several applications from the F5^® BIG-IQ ^® Centralized Management all application screen, you can quickly detect issues in the performance by isolating the applications that have a low health status. Once you have isolated a specific application with a health status of moderate or critical, you can isolate changes in the application's traffic data that led to a lower health status, and determine if mitigation is required.

Note: To view application health or traffic data, your application must be managed by a BIG-IP device version 13.1.0.5 or later, and HTTP statistics collection must be enabled.

Isolate applications with health issues

You can use the application health status settings to isolate a specific application that has surpassed an application performance threshold.

Click Applications > APPLICATIONS ).
Locate the HEALTH area at the top left of the summary bar.
Click Critical and Moderate to filter the application list by applications with the selected health statuses.

Note: In the applications list, the Active Alerts field indicates the current number of alerts for an application.
Click the application's name.
The screen for this application opens, where you can identify the issue that is affecting your application's health, and for how long it has been affecting it.

Identify the performance issues impacting an application's health

You can use the application alerts from the single application screen to identify when a performance issue began. You can then use the application's transaction to evaluate how the issue is currently affecting your application's health.

Open the application properties screen by selecting the application's name from the Applications screen ( click Applications > APPLICATIONS > <Application Name> ).
To view the application's most severe, active alerts, view the Active Alerts area at the far right of the summary bar.
Click See All to view the application's Active Alert screen.
This displays a log of all alerts that have crossed a defined threshold.
Click the row for the most recent health alert, and view the alert details on the lower part of the screen.
- The Description field displays the affected performance indicator.
- The Value field displays the value when the alert was triggered
- The Log Level filed indicate the alert's severity.
Return to the single application screen by clicking the back arrow next to Active Alerts screen title.

From the application screen, you can use the alert information to analyze and isolate if the issue is related to one or more pool members.

About application health alerts

Application health alerts are based on specific traffic data. Active application alerts reflect an application performance issue. A critical or warning alert that is active indicates that there has been a sustained threshold violation for over five minutes.

A metric threshold violation must be sustained for 5 minutes to trigger an alert. A subsequent alert is triggered once another threshold is crossed (either an increase or decrease in severity, or cleared). To ensure that conditions are improving, an alert for declining severity (critical to warning) or a cleared alert, is triggered only when the value is sustained for five minutes at ten percent below the threshold value. For example, if a threshold value is configured for greater than 60 percent, a declining severity must be sustained at 54 percent or less to trigger an alert.

If the performance indicator or threshold does not reflect your application's performance, you can customize the application's alert rule settings. (Click the health icon at the top left of the application screen.) The application health is defined in the application template.

Application alerts

Application alerts notify you of changes in application metrics that can affect the overall application performance. You can view application alerts from the single application screen ( Applications > APPLICATIONS > <Application Name> ), or the alerts screens ( Applications > ALERT MANAGEMENT > Active Alerts or Alert History).

Alert	Description	Indication	Default Thresholds	Action (if applicable)
`Application Response Time`	The average time from when the server receives the request from the BIG-IP system until the server sends the response. This is usually a result of pool member activity.	An application's pool member exceeded the defined application response time.	Critical > 500ms Warning > 100ms Cleared < 100ms	Investigate pool member activity.
`Server Side RTT`	The average round trip time (RTT) for network communication between the BIG-IP system and the application server.	An application's pool member exceeded the defined server side RTT.	Critical > 50ms Warning > 10ms Cleared < 10ms	Investigate issues with BIG-IP device performance.
`Client Side RTT`	The average round trip time (RTT) for network communication between the BIG-IP system and the client application request.	The average network response to a client request exceeded the defined client side RTT.	Critical > 1500ms Warning > 750ms Cleared < 750ms	Investigate issues with BIG-IP device performance.
`Incomplete Transactions`	The average rate of transactions that did not complete the request and response exchange, out of the overall transactions.	The average number of incomplete transactions exceeded the defined rate.	Critical > 0.05% Warning > 0.01% Cleared < 0.01%	Troubleshoot using the Transaction Outcomes data for the affected application.
`Server Errors`	The average rate of transactions that returned a server error response code (5XX) out of all the overall transactions.	The rate of requests receiving 5XX response codes exceeded the defined rate.	Critical > 0.05% Warning > 0.01% Cleared < 0.01%	Investigate pool member activity and adjust pool configurations as necessary.
`Request Errors`	The average rate of transactions that returned a request error response code (4XX) out of all the overall transactions.	The rate of requests receiving 4XX response codes exceeded the defined rate.	Critical > 0.05% Warning > 0.01% Cleared < 0.01%	Troubleshoot Client IP addresses with request errors using Enhanced Analytics.
`High TPS`	The number of transactions per second (TPS) is higher than the expected average.	The rate of application activity is higher that expected.	No default
`Low TPS`	The number of transactions per second (TPS) is lower than the expected average.	The rate of application activity is lower than expected.	No default
`Network Access Reconnects`	The number of times Network Access session reconnects in the last 60 minutes.	Reconnects are higher than expected.	Critical > 750 Warning > 500 Cleared < 500	Check the Network Access Reconnect Detail monitoring screen ( Monitoring > DASHBOARDS > Remote Access > Network Access > Network Access Reconnect Detail ).
`Network Access Errors`	The number of errors in Network Access session processing in the last 60 minutes.	Errors are higher than expected, which could indicate a misconfiguration in Network Access.	Critical > 1000 Warning > 500 Cleared < 500	Check the Network Access Errors monitoring screen ( Monitoring > DASHBOARDS > Access > Remote Access > Network Access > Network Access Errors ).
`Bad IP Reputations`	The number of Bad IP Reputation IP addresses identified in the last 60 minutes.	Excessive bad IP addresses are attempting access.	Critical > 1000 Warning > 500 Cleared < 500	Check the Bad IP Reputation monitoring screen ( Monitoring > DASHBOARDS > Access > Sessions > Bad IP Reputation ).
`Denied Sessions`	The number of denied access sessions in the last 60 minutes.	Denied Access sessions are higher than expected.	Critical > 100 Warning > 50 Cleared < 50	Check the Sessions Denied monitoring screen ( Monitoring > DASHBOARDS > Access > Sessions > Denied ).
`SAML-IdP Errors`	The number of SAML IdP errors in the last 60 minutes.	Errors in SAML IdP processing are higher than expected.	Critical > 200 Warning > 100 Cleared < 100	Check the SAML IdP Error Report monitoring screen ( Monitoring > DASHBOARDS > Access > Federation > SAML > IdP > Error Report ).
`SAML-SP Errors`	The number of SAML SP errors in the last 60 minutes.	Errors in SAML SP processing are higher than expected.	Critical > 200 Warning > 100 Cleared < 100	Check the SAML SP Error Report monitoring screen ( Monitoring > DASHBOARDS > Access > Federation > SAML > SP > Error Report ).
`Access Usage`	The percentage of Access licenses in use over the last 5 minutes.	Check Access licenses.	Critical > 85 Warning > 70 Cleared < 70	Check the Network Access Usage monitoring screen ( Monitoring > DASHBOARDS > Access > Remote Access > Network Access > Network Access Usage ).
`Connectivity Usage`	The percentage of Connectivity licenses in use over the last 5 minutes.	Check Connectivity licenses.	Critical > 85 Warning > 70 Cleared < 70	Check the License Usage monitoring screen ( Monitoring > DASHBOARDS > Sessions > License Usage )
`SWG Usage`	The percentage of SWG licenses in use over the last 5 minutes.	Check SWG licenses.	Critical > 85 Warning > 70 Cleared < 85	Check the Bad IP Reputation monitoring screen ( Monitoring > DASHBOARDS > Access > Secure Web Gateway > Users ).

Managing application traffic monitoring settings

The health of your applications is determined by metric thresholds that monitor your application's traffic processing capabilities. Each metric provides information about latency of your application's pool members, latency of the BIG-IP^® system, total number of connections, and transaction outcomes. These metrics and corresponding thresholds use a default application health alert rule set. You can modify the default rule set for all applications, or add a new alert rule for a single application.

Tip: You can view and edit a single application's health rules by clicking the health icon located at the far left of the application's summary bar (for system admins click Applications > APPLICATIONS > <Application Name> ).

Modify the default application alerts

You can monitor your applications' health status based on the status of its connected objects and traffic performance metrics. The health alerts rules for your application can be adjusted based on your monitoring needs.

Go to the Alert Management screen Applications > ALERT MANAGEMENT > Alert Rules .
Click the alert rule name.
This opens the alert rule's properties screen.
View the Metric Conditions area at the center of the screen, which displays the current metrics and thresholds for the default application alerts rule.
By default, all the metrics are enabled.
Note: BIG-IP devices earlier than version 13.1.0.5 do not collect data that supports metric alerts. Applications that are managed by earlier versions of a BIG-IP device do not receive metric alerts.
To disable metrics, clear the check box to the right of the metric column.
This stops any device alerts for this metric.
To adjust the Warning and Critical threshold values for enabled metrics, specify a different value for the metric in the appropriate fields.
In the Events area, you can enable or disable status alerts for application objects.
Use the Actions area to enable alert notifications by SNMP and Email.
Click Save at the bottom of the screen, or click Save & Close to save and return to the Alert Rules screen.

The health and metric rules trigger new alerts according to the saved modifications. This clears active alerts associated with this rule set, and triggers an Alert Rule Changes alert.

Add a new health rule set for an application

When you configure an application to the BIG-IQ, the application is monitored by a default health alert rule set. You can create a new health alert rule set to customize the alert notifications for a specific application.

At the top of the screen, click Applications.
On the left, click ALERT MANAGEMENT > Alert Rules .
At the top left of the screen, click the Add button.
The New Alert Rule screen opens.
Type aName and an optional Description .
Select the Rule Type (Device Health or Device Access-health).
In the Metric Conditions area, enable and disable metrics as needed by selecting or clearing the box to the right of the Metric column.

Note: BIG-IP devices earlier than version 13.1.0.5 do not collect data that supports metric alerts. Applications that are managed by earlier versions of a BIG-IP device do not receive metric alerts.
Use the Actions area to enable alert notifications by SNMP and Email.
Use the Devices area at the bottom of the screen to view the available devices for the new alert rule set, and move a device from the Available list to the Selected list.
You can filter the device lists by selecting from the Filter list.
Click Save at the bottom of the screen, or click Save & Close to save and return to the Alert Rules screen.

The health and metric rules trigger new alerts according to the saved modifications. This clears active alerts for the associated application, which triggers the Alert Rule Changes alert.

Application health alerts

The device health alerts notify you of changes in your application traffic that impact the health of the application. When there is a threshold violation for application traffic thresholds, the application health status changes. You can view application alerts from the single application screen ( Applications > APPLICATIONS > <Application Name> ), or the alerts screens ( Applications > ALERT MANAGEMENT > Active Alerts or Alert History).

Alert	Description	Indication	Default Thresholds	Action (if applicable)
`Application Health`	One or more of the application's health performance metrics has changed.	One or more of the enabled application traffic metrics exceeded a defined threshold, which might impact the application's overall performance.	Applies the default-active-application- health rules.	Investigate the application's active alerts for traffic metrics.

Detecting application performance issues that require mitigation

An application's performance issues might be caused by changes in a pool member's status. Issues with a pool member can lead to increases in application response time, server-side round trip time (RTT), incomplete transactions, and server errors. An application that sustains these increases can result in a Critical or Moderate health status. You can use application alerts to isolate managed objects, such as pool members, or BIG-IP virtual servers that led to performance issues. You can use your findings to adjust your application's managed objects (LTM pool members) in order to improve performance.

You isolate an application with changes in pool member status by using the application health status screen ( Applications > APPLICATONS ). Once an application is isolated ( Applications > APPLICATONS > <Application Name> ), you can identify which pool member(s) is affecting performance.

Note: To view application health or traffic data, your application must be managed by a BIG-IP device version 13.1.0.5 or later, and HTTP statistics collection must be enabled.

Isolate applications with health issues

You can use the application health status settings to isolate a specific application that has surpassed an application performance threshold.

Click Applications > APPLICATIONS ).
Locate the HEALTH area at the top left of the summary bar.
Click Critical and Moderate to filter the application list by applications with the selected health statuses.

Note: In the applications list, the Active Alerts field indicates the current number of alerts for an application.
Click the application's name.
The screen for this application opens, where you can identify the issue that is affecting your application's health, and for how long it has been affecting it.

Detecting application pool member issues

BIG-IQ indicates changes in a pool member's status with pool member events. Pool member events within the Analytics charts of the single application screen indicate whether changes affect traffic performance. You can isolate these events to identify the pool member(s) that require mitigation.

Note: When multiple pool members display events, the issue might be caused by the BIG-IP virtual servers. You can isolate virtual server events in the charts to verify if the issue is caused by a virtual server.

Identify application pool members causing traffic performance issues

You can isolate an application's pool members that are causing performance issues to mitigate the performance impact on your application.

Open the application properties screen by selecting the application's name from the Applications screen ( click Applications > APPLICATIONS > <Application Name> ).
Near the middle of the screen in the SERVERS area, click the numbered icon below to display pool member information in the ANALYTICS area.
To view pool member traffic data, select from menu to the left of the screen in the ANALYTICS area (Server Latency, Application Response Time, or Server Side RTT).
In the time settings above the chart, ensure that the Events button is set to ON.
You can click the Category buttons below the chart such that only the System button is active.

Note: The buttons below the chart have a gray background when disabled, and a blue background, when enabled.

This action filters out all other alert and event categories displayed in the charts.
Click an event icon in the chart to display the events and alerts that correspond with the traffic data.
This displays the event table below the chart, which includes details about the events and alerts that occurred at that time.

Tip: You can further filter so that only pool member and virtual server events appear, use the Search events field, and type "server-readiness".
Isolate the affected pool member address from the Title column in the event table, or click the event row to view event details in the Description area.
You can analyze additional data for the isolated pool member by expanding the Dimension pane to the right of the chart and selecting the pool member address from the Pool Members Address list.

Mitigating a traffic performance issue

To manage LTM objects to mitigate a performance issue that you isolated using analytics, you use essentially the same screens that you used to find the problem. But instead of using the ANALYTICS option in the details area, you use the CONFIGURATION option.

The workflow for resolving the issue is essentially the same, regardless of what kind of object is triggering the issue.

Create a replacement for the object triggering the issue.
Delete or remove the object from service.

In these tasks, we provide an example of a problem pool member. But you can use essentially the same strategy for other LTM object types in your application.

Create a replacement pool member

When you isolate a pool member that is affecting traffic performance, you can create a replacement for the member that is triggering the performance issues.

Select the application that needs attention from the all applications screen ( Applications > APPLICATIONS > Application Name ).
Find the pool member that needs attention: At the right, center of the screen, click the number in the Servers circle.
This displays the pool member information in the CONFIGURATION area.
Create a new pool member.
1. At the left click CONFIGURATION.
2. Under Servers, click Create (a Create Servers popup screen opens).
3. Type the IP Address and Port for the new pool member.
4. Click Create. (This creates the pool member and closes the popup screen.)

The next thing you probably want to do is take this pool member out of service so that your application traffic can return to normal.

Solve a performance problem stemming from pool member issues

Before you start, you probably want to create a replacement pool member to handle the traffic of the problem member.

When you isolate a pool member that is affecting traffic performance, you have a couple of ways to remedy the issue. Depending on what kind of issues the pool member is experiencing, you might want to delete it immediately, disable it, or force it offline.

Select the application that needs attention from the all applications screen ( Applications > APPLICATIONS > Application Name ).
Find the pool member that needs attention: At the right, center of the screen, click the number in the Servers circle.
This displays the pool member information in the CONFIGURATION area.
Select the pool member that needs attention:
1. Click CONFIGURATION.
2. Select the check box for the pool member.

Determine what you want to do with this pool member based on the nature of the performance issue, and take the most appropriate action.

What do you want the member to do?	Select this option
Cease all traffic immediately	Select Delete. BIG-IQ removes the pool member from the pool, but does not delete the associated node. This option is most appropriate when an issue requires a quick response. Current connections will be interrupted.
Stop processing new connections but continue to process persistent or active connections.	Select Disable. BIG-IQ continues to process persistent and active connections for this member. New connections are accepted only if they belong to an existing persistence session. This option is appropriate when you can afford the time for traffic to dissipate before the member stops processing traffic.
Stop processing new connections but continue to process active connections.	Select Force Offline. BIG-IQ continues to process active connections for this member. New connections are accepted only if they belong to an existing persistence session. This option is appropriate when you can afford the time for traffic to dissipate before the member stops processing traffic.

What do you want the member to do?

Select this option

Cease all traffic immediately

Select Delete.

BIG-IQ removes the pool member from the pool, but does not delete the associated node.

This option is most appropriate when an issue requires a quick response. Current connections will be interrupted.

Stop processing new connections but continue to process persistent or active connections.

Select Disable.

BIG-IQ continues to process persistent and active connections for this member. New connections are accepted only if they belong to an existing persistence session.

This option is appropriate when you can afford the time for traffic to dissipate before the member stops processing traffic.

Stop processing new connections but continue to process active connections.

Select Force Offline.

BIG-IQ continues to process active connections for this member. New connections are accepted only if they belong to an existing persistence session.

This option is appropriate when you can afford the time for traffic to dissipate before the member stops processing traffic.

The next thing you probably want to do is repeat the troubleshooting steps you used to isolate this pool member as the problem source and confirm that the issue is resolved.

Application server charts

This table describes the charts found in the ANALYTICS area of the application properties screen ( Applications > Applications > <Application Name> ) when SERVERS is selected. These charts display the trends of the application pool members. Each chart displays an aspect of pool member performance, as function of the selected time period.

ANALYTICS Menu Options	Chart Title	Description
Server Latency	Top 5 Pool Members by Server Latency	The average number of milliseconds (ms) it took for the BIG-IP system to receive a response message from a pool member once a request was sent. This includes application response time and server RTT. Metric Unit: ms Legend: Top 5 pool member IP addresses
Application Response Time	Top 5 Pool Members by Application Response Time	The average time it takes for the pool member to send a response message once the pool member receives the request from the BIG-IP system. Metric Unit: ms Legend: Top 5 pool member IP addresses
Server Side RTT	Top 5 Pool Members by Server Side Round-Trip Time	The time it takes for the BIG-IP system to send a request and receive a response from the pool member, not including the application response time. This is a system performance indicator. Metric Unit: ms Legend: Pool member addresses
TPS	Top 5 Pool Members by TPS	The average number of request transactions per second (TPS) received by a pool member. Metric Unit: TPS Legend: Pool member addresses

Pool member status events

Pool member events indicate that a pool member is offline, and are followed by an event that diagnoses the offline status. You can see these events in the charts of the application properties screen ( Applications > APPLICATIONS > <Application Name> ) and in the Local Traffic dashboards ( Monitoring > DASHBOARDS > Local Traffic ).

Alert	Description	Indication	Default Thresholds	Action (if applicable)
`Pool Member Offline`	The pool member (server) is offline as a result of status or configuration changes. The system then updates the pool member status with one of the following messages: `Online- The pool member is back online.` `Disabled- The pool member is disabled.` `Pool monitor disabled- The pool member monitor, which is configured on the BIG-IP system, is disabled.` `Pool member deleted- The pool member has been deleted from the pool's configuration.`	Pool member issues can lead to increases in application response time, server-side round trip time (RTT), incomplete transactions, and server errors.	Critical: Offline	Prolonged impact on application performance might require the addition of a new pool member.

Alert

Description

Indication

Default Thresholds

Action (if applicable)

Pool Member Offline

The pool member (server) is offline as a result of status or configuration changes. The system then updates the pool member status with one of the following messages:

Online- The pool member is back online.
Disabled- The pool member is disabled.
Pool monitor disabled- The pool member monitor, which is configured on the BIG-IP system, is disabled.
Pool member deleted- The pool member has been deleted from the pool's configuration.

Pool member issues can lead to increases in application response time, server-side round trip time (RTT), incomplete transactions, and server errors.

Critical:

Offline

Prolonged impact on application performance might require the addition of a new pool member.

Virtual server status events

Virtual Server events indicate that a virtual server is offline, and are followed by an event that diagnoses the offline status. You can see these events in the charts of the application properties screen ( Applications > APPLICATIONS > <Application Name> ) and in the Local Traffic dashboards ( Monitoring > DASHBOARDS > Local Traffic ).

Alert	Description	Indication	Default Thresholds	Action (if applicable)
`Virtual Server is Offline`	The virtual server is offline as a result of status or configuration changes. The system then updates the virtual server status with one of the following messages: `Online- Virtual server is online.` `Disabled- Virtual server was disabled.` `Monitor disabled- The virtual server monitor, was disabled.` Note: The virtual server monitor is configured on the BIG-IP system. `Virtual server deleted- Virtual server was deleted.`	Virtual server issues cause pool member performance issues.	Critical: Offline	Prolonged issues that impact application pool member performance require virtual server mitigation for BIG-IP device.

Alert

Description

Indication

Default Thresholds

Action (if applicable)

Virtual Server is Offline

The virtual server is offline as a result of status or configuration changes. The system then updates the virtual server status with one of the following messages:

Online- Virtual server is online.
Disabled- Virtual server was disabled.
Monitor disabled- The virtual server monitor, was disabled.
Note: The virtual server monitor is configured on the BIG-IP system.
Virtual server deleted- Virtual server was deleted.

Virtual server issues cause pool member performance issues.

Critical:

Offline

Prolonged issues that impact application pool member performance require virtual server mitigation for BIG-IP device.

Detecting reported application latency issues

A client-reported application latency issue might already be reflected in your application's health. You can identify which issues are affecting your the application's performance for a specific client, by isolating the application from the all application screen (for system admins click Applications > APPLICATIONS ). Once the application is isolated, you can evaluate the client-side transaction data in the single application screen charts ( Applications > APPLICATIONS > <Application Name> ).

Note: To view application health or traffic data, your application must be managed by a BIG-IP version 13.1.0.5 or later, and HTTP statistics collection must be enabled.

To collect transaction data for the specific reported Client IP, you can enable Enhanced Analytics data collection to troubleshoot the reported issue.

Note: Enhanced analytics is only available for applications managed by BIG-IP version 13.1.0.5 or later.

Isolate applications with health issues

You can use the application health status settings to isolate a specific application that has surpassed an application performance threshold.

Click Applications > APPLICATIONS ).
Locate the HEALTH area at the top left of the summary bar.
Click Critical and Moderate to filter the application list by applications with the selected health statuses.

Note: In the applications list, the Active Alerts field indicates the current number of alerts for an application.
Click the application's name.
The screen for this application opens, where you can identify the issue that is affecting your application's health, and for how long it has been affecting it.

Identifying additional application traffic parameters

When you are troubleshooting the traffic performance of an application, additional data can help you isolate details that characterize potential, or ongoing, issues. On the Application screen, the Enhanced Analytics option provides you with the ability to collect more information about the HTTP traffic management from your application's BIG-IP^® host device. When this feature is enabled, the enhanced data displays additional dimension objects and data for the HTTP traffic management dimensions found in the ANALYTICS area.

The Enhanced Analytics option does not impact your BIG-IQ^® system performance. By default,you can enable up to 20 applications simultaneously in Enhanced Analytics mode.

Note: System administrators can adjust the maximum number of applications by modifying the maxNumberOfApps parameter value in the /var/config/rest/config/restjavad.properties.json file.

Identify an application latency issue reported by a client

You can identify issues that have been reported by clients, by troubleshooting transaction data for a specific Client IP.

Open the application properties screen by selecting the application's name from the Applications screen ( click Applications > APPLICATIONS > <Application Name> ).
Click the Enhanced Analytics button to open the Enhanced Analytics Settings popup screen.
To collect additional HTTP traffic data, select the Collect HTTP metrics for <Application Name>.
Select Limit collection to a single client IP address and type the client IP in the field below.
To view specific data in the charts of the Analytics area, select the options you want, and click Start.

Note: By default, all HTTP metrics are enabled. Selecting just one, or a limited number of metrics, improves the quality of the data collected. If security metrics are not relevant, clear the check box for Collect Security metrics of all devices hosting <application name>.
In the CLIENT circle near the center of the screen click the All Types text to display client-side transaction information in the ANALYTICS area.
Expand the Dimensions pane using the tabs to the right of the chart, and expand the Client IPs dimension to filter by that client IP in the charts.
You can view data for the selected client IP by expanding the other dimensions and viewing transaction data for specific dimension objects (for example, URLs).
To monitor HTTP traffic data, and then to evaluate all transaction data, and to identify where latency is highest in the transaction process, click an option from the menu to the left.
To view the average outcomes of the client IP address's requests click Transactions from the menu to the left.

HTTP metrics provided in Enhanced Analytics settings

This table lists and describes HTTP options in the Enhanced Analytics Settings popup screen displays additional metric data for the corresponding dimensions, when enabled. The added data is displayed in the HTTP traffic charts. When disabled, these dimensions display aggregated data.

Enhanced Metric Setting	Affected Dimension(s)	Description	Value displayed when disabled
IP Address	Client IPs	The IP addresses from which your application receives requests. Suggested Uses: General application performance testing.	N/A
Geolocation	Countries	The countries from which your application receives requests. Suggested Uses: General application performance testing, identifying user personas, security validation.	N/A
Operating System & Browser	OSs Browsers	The operating systems and browsers from which your application receives requests. Suggested Uses: General application performance testing, testing performance of URLs with high resource requirements.	N/A
HTTP Method	Methods	The HTTP request methods to your application's resources. Suggested Uses: General application performance testing, identifying user personas.	N/A
Subnet	Subnets	The client subnets from which your application receives requests. Suggested Uses: General application performance testing.	N/A
URL	URLs	The URLs from which your application receives requests. Suggested Uses: General application performance testing, testing performance of URLs with high resource requirements.	N/A

Application client traffic charts

This table describes the charts found in the ANALYTICS area of the application properties screen ( Applications > APPLICATIONS > <Application Name> ) if you click All Types in the CLIENT area. These charts display the trends of application traffic processed by the BIG-IP system. Each chart displays an aspect of application traffic as a function of the selected time period.

ANALYTICS Menu Options	Chart Title	Description
Transactions	HTTP Transaction Outcomes	The average outcome assigned by the BIG-IP system to the request and response between the client, BIG-IP system and server. Metric Unit: Average Transactions per Second Legend: Passthrough: HTTP transactions that completed the request and response exchange using the BIG-IP system. Incomplete: HTTP transactions that did not complete the entire request and response exchange. Cached by BIG-IP: Requests stored by the BIG-IP system to reduce the traffic load on back-end servers. BIG-IP Response: HTTP requests that received a response directly from the BIG-IP.
Page Load Time	Page Load Time	The average time it takes for a client request to receive a full response from the server and BIG-IP system. Metric Unit: ms Legend: Avg: The average page load time observed. Max: The highest page load time observed.
Client Side RTT	Client Side Round-Trip Time	The time it takes for a client to send a request and receive a response over the BIG-IP system. This includes the time it takes for client's request to reach the BIG-IP system and the time it takes for the client to receive a response from the BIG-IP system. Metric Unit: ms Legend: Min:The lowest server RTT observed. Avg: The average server RTT observed. Max: The highest server RTT observed.
E2E Time	End-to-End-Time	The time required for an application request and response transaction, not including system latency and transmission times. Metric Unit: ms Legend: Client RTT: The average time it takes for a client to send a request and receive a response over the BIG-IP system. Server RTT: The average time it takes for a client to send a request and receive a response over the BIG-IP system. Application Response Time: The average time it takes for a server to send a response, after receiving a request.

Detecting a BIG-IP service that is affecting your application performance

An application's performance might be affected by a BIG-IP device that is providing services to your application. The impact on your application is reflected in the active alerts and corresponding application data.

Application alerts and data for application response time, server and client side RTT, low TPS, or incomplete transactions can indicate issues with the BIG-IP device's traffic management. The initial indication is an application with critical or moderate health. If one or more of your applications have pool members that are performing as expected, but there are multiple active alerts, this can be an indication that your applications are affected by a BIG-IP device issue.

Note: To view application health or traffic data, your application must be managed by a BIG-IP device version 13.1.0.5 or later, and HTTP statistics collection must be enabled.

Isolate applications with health issues

You can use the application health status settings to isolate a specific application that has surpassed an application performance threshold.

Click Applications > APPLICATIONS ).
Locate the HEALTH area at the top left of the summary bar.
Click Critical and Moderate to filter the application list by applications with the selected health statuses.

Note: In the applications list, the Active Alerts field indicates the current number of alerts for an application.
Click the application's name.
The screen for this application opens, where you can identify the issue that is affecting your application's health, and for how long it has been affecting it.

Identify a BIG-IP service that is affecting an application

You can identify whether a BIG-IP device is experiencing a performance issue that impacts your application's performance.

Open the application properties screen by selecting the application's name from the Applications screen ( click Applications > APPLICATIONS > <Application Name> ).
In the ENVIRONMENT area at the center of the screen, click the text inside the circle.
The Analytics area displays information about the BIG-IP devices that are providing services to your application.
In the ANALYTICS menu at the left, click Throughput, Connections, or HTTP to identify changes in the average BIG-IP devices' throughput.
To see whether there was an increase in the average rate of packets that were discarded over the transaction process, click Dropped or Errors.

Application environment charts

This table describes the menu options and charts found in the application properties screen ( Applications > APPLICATIONS > <Application Name> ), in the ANALYTICS area. These charts display the trends of a service scaling group's BIG-IP VE devices. Each chart displays an aspect of the devices as a function of the selected time period.

ANALYTICS Menu Option	Chart Title	Description
CPU Usage	CPU Usage (percent)	The percentage of CPU usage based on overall and specific activities of the BIG-IP system devices. Metric Unit: Percent Legend: User: The average percentage of CPU usage for the all the BIG-IP user space programs over a given time period. System: The average percentage of CPU usage for all the running BIG-IP systems over a given time period I/O Wait: The percentage of time (during the selected time period) that a given CPU is idle for an I/O wait operation. This occurs when at least one outstanding I/O disk operation is requested by a task scheduled on system CPU. Stolen: The percentage of time a virtual CPU waits for real CPU when the hypervisor is servicing another virtual machine.
Top Cores	Top 6 CPU Cores	The six, most active CPU cores for all monitored BIG-IP devices. Metric Unit: Percent Legend: CPU core
Memory	Memory Usage (percent)	The percentage of RAM used by system processes of the monitored BIG-IP devices. Metric Unit: Percent Legend: TMM: The average percentage of RAM used by device TMM processes. Total: The average percentage of RAM used by all devices Other: The average percentage of used RAM from non-TMM processes.
Throughput	Throughput Bytes (average/s)	The average rate of traffic (in bytes) processed by the BIG-IP device interfaces. Metric Unit: Average/s Legend: In: The average rate of incoming traffic to the BIG-IP devices. Out: The average rate of outgoing traffic from the BIG-IP devices.
Connections	Concurrent Connections (count)	The average number of connections that are open at the same time, on either the client-side or the server-side. Metric Unit: Count Legend: Client Side: The average number of concurrent connections at the client side. Server Side: The average number of concurrent connections at the server side.
HTTP	HTTP Transactions (average/sec)	The transaction includes all HTTP request and response messages passed between the client, BIG-IP system, and server. Metric Unit: Average/s Legend: Transactions: Average number of HTTP transactions per second that were processed by the BIG-IP devices.
Dropped	Throughput Drops (average/sec)	The average rate of packets per second (pps) that were dropped by the BIG-IP device interfaces or discarded by the TMM over the course of the transaction. Metric Unit: Average/s Legend: In: The average rate of packets per second that were dropped by the BIG-IP interface. Out: The average rate of packets per second that were accepted by the BIG-IP interface, but discarded by the TMM.
Errors	Throughput Errors (average/sec)	The average rate packets per second (pps) that were corrupted or arrived incomplete over the course of the transaction across the network, Metric Unit: Average/s Legend: In: The average packets per second received as throughput error. Out: The average packets per second transmitted out at throughput error.

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

BIG-IQ Centralized Management

Managing an Application's Traffic Management Services

Evaluating an application's traffic

Verify traffic performance for all your applications

Evaluating an application's traffic data

Monitor an application's traffic data

Application traffic management charts

Detecting applications with health and performance issues

Isolate applications with health issues

Identify the performance issues impacting an application's health

About application health alerts

Application alerts

Managing application traffic monitoring settings

Modify the default application alerts

Add a new health rule set for an application

Application health alerts

Detecting application performance issues that require mitigation

Isolate applications with health issues

Detecting application pool member issues

Identify application pool members causing traffic performance issues

Mitigating a traffic performance issue

Create a replacement pool member

Solve a performance problem stemming from pool member issues

Application server charts

Pool member status events

Virtual server status events

Detecting reported application latency issues

Isolate applications with health issues

Identifying additional application traffic parameters

Identify an application latency issue reported by a client

HTTP metrics provided in Enhanced Analytics settings

Application client traffic charts

Detecting a BIG-IP service that is affecting your application performance

Isolate applications with health issues

Identify a BIG-IP service that is affecting an application

Application environment charts

Have a Question?

Follow Us

About F5

Education

F5 Sites

Support Tasks