Applies To:
Show Versions
BIG-IQ Centralized Management
- 6.0.0
Managing an Application's Traffic Managment 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
). 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
).Verify traffic performance for all your applications
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
Application traffic management charts
This table lists and defines the charts found in the single application screen (
) 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 use the application's traffic data that led to a lower health status in order to determine if mitigation is required.
Isolate applications with health issues
Identify the performance issues impacting an application's health
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 (Alert History).
), or the alerts screens ( orAlert | 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 |
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.
Modify the default application alerts
Add a new health rule set for an application
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 (Alert History).
), or the alerts screens ( orAlert | 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 (
). Once an application is isolated ( ), you can identify which pool member(s) is affecting performance.Isolate applications with health issues
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.
Identify application pool members causing traffic performance issues
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.
- 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
Solve a performance problem stemming from pool member issues
Application server charts
This table describes the charts found in the ANALYTICS area of the single application screen (
) 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 single application screen (
) and in the Local Traffic dashboards ( ).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:
|
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 single application screen (
) and in the Local Traffic dashboards ( ).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:
|
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. |
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
). Once the application is isolated, you can evaluate the client-side transaction data in the single application screen charts ( ).To collect transaction data for the specific reported Client IP, you can enable Enhanced Analytics data collection to troubleshoot the reported issue.
Isolate applications with health issues
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.
Identify an application latency issue reported by a client
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 single application screen (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.
) if you clickANALYTICS 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.
Isolate applications with health issues
Identify a BIG-IP service that is affecting an application
Application environment charts
This table describes the menu options and charts found in the single application screen (
), 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. |