Manual Chapter :
Troubleshooting Applications by Capturing Traffic
Applies To:
Show VersionsBIG-IP AAM
- 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
BIG-IP APM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
BIG-IP Analytics
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
BIG-IP Link Controller
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
BIG-IP LTM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
BIG-IP PEM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
BIG-IP AFM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
BIG-IP DNS
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
BIG-IP ASM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0
Troubleshooting Applications by Capturing Traffic
Overview: Troubleshooting applications by capturing traffic
This implementation describes how to set up the BIG-IP system to collect
application traffic so that you can troubleshoot problems that have become apparent by monitoring
application statistics. For example, by examining captured requests and responses, you can
investigate issues with latency, throughput, or reduced transactions per second to understand
what is affecting application performance.
When Application Visibility and Reporting (AVR) is provisioned, you can create an Analytics
profile that includes traffic capturing instructions. The system can collect application traffic
locally, remotely, or both. If the system is already monitoring applications, you can also update
an existing Analytics profile to make it so that it captures traffic.
If logging locally, the system logs the first 1000 transactions and displays charts based on
the analysis of those transactions. For VIPRION systems, the local logging consists of the first 1000 transactions multiplied by however many blades are installed. If logging remotely, the system logs information on that
system; log size is limited only by any constraints of the remote logging system. To see updated
application statistics, you can clear the existing data to display the current statistics.
About prerequisites for capturing application traffic
After you finish a basic networking configuration of the BIG-IP system,
you must complete these prerequisites for setting up application statistics collection:
- Provision Application Visibility and Reporting (AVR):.
- Create an iApps application service (go to), or configure at least one virtual server with a pool pointing to one or more application servers.
You can set up the system for capturing application traffic either locally or remotely (or
both).
Before setting up, clear the captured transaction log. On the Captured
Transactions screen, click
Clear All
to clear all previously captured data
records.Capturing traffic for troubleshooting
Traffic capturing prompts the system to log traffic request and response headers and payload data, based on specific collection requirements. You typically use traffic capturing to monitor a known application issue, such as trouble with throughput or latency, or a known factor that can impact application performance, such as HTTP method, or client IP address. You can specify these traffic aspects to later examine application statistics, and troubleshoot captured transactions.
You can configure the BIG-IP system to capture application traffic and store the information locally or remotely (on Syslog servers or SIEM devices, such as Splunk). To do this, you create an Analytics profile designed for capturing traffic. The profile instructs the BIG-IP system to collect a portion of application traffic using the Application Visibility and Reporting (AVR) module.
- On the Main tab, click.IfAnalyticsis not listed, this indicates that Application Visibility and Reporting (AVR) is not provisioned, or you do not have rights to create profiles.The HTTP Analytics screen opens.
- In the Profile Name column, clickanalytics(the name of the default profile).If you are creating or editing a profile other than the defaultanalyticsprofile, you will need to select theCustombox located to the top right of the screen.
- In the General Configuration area, clear theSamplecheck box from theTransaction Samplingfield.The system now analyzes all traffic to the associated virtual servers. This can improve the troubleshooting accuracy for captured traffic.
- Above the menu bar, click theProfiles: Analyticslink to return to the Analytics list screen.
- ClickCreate.The New HTTP Analytics profile screen opens.
- In theProfile Namefield, type a unique name for the Analytics profile.
- ForTraffic Capturing Logging Type, specify where to store captured traffic.
- To store traffic locally, clickInternal. You can view details on the Captured Transactions screen ( ).
- To store traffic on a remote logging server, clickExternaland provide the requested information.
- In the Associated Virtual Servers area, specify the virtual servers for which to capture application statistics:
- For theVirtual Serverssetting, clickAdd.
- From the Select Virtual Server popup that opens, select the virtual servers to include and then clickDone.
Only virtual servers previously configured with an HTTP profile display in the list (because the data being collected applies to HTTP traffic). Also, you can assign only one HTTP Analytics profile to a virtual server; therefore, the list displays only virtual servers that have not been assigned an Analytics profile.Special considerations apply if using Analytics on a BIG-IP system with both Application Security Manager and Access Policy Manager, where security settings (in Portal Access webtop or an iRule) redirect traffic from one virtual server to another. In this case, you need to attach the HTTP Analytics profile to the second virtual server to ensure that the charts show accurate statistics. - If you added virtual servers in step 8, and want to make changes to any of the selections, above the Statistics Gathering Configuration area, select theCustomcheck box.
- In the Capture Filter area, enter a unique name for the capturing profile in theCapturing Profile Namearea.
- From theCapture Request DetailsandCapture Response Detailslists, select the options that indicate the part of the traffic to capture.OptionDescriptionNoneSpecifies that the system does not capture request (or response) data.HeadersSpecifies that the system captures request (or response) header data only.BodySpecifies that the system captures the body of requests (or responses) only.AllSpecifies that the system captures all request (or response) data, including header and body.
- ForDoS Activity, select the option that indicates which DoS traffic is captured.OptionDescriptionAnySpecifies that the system captures any traffic regardless of DoS activity.Mitigated by Application DoSSpecifies that the system only captures DoS traffic if it was mitigated.
- ForProtocols, specify whether the system only captures traffic withHTTP, orHTTPSprotocols.
- ForQualified for JavaScript Injection, selectQualified onlyto specify that the system only captures traffic that qualifies for JavaScript injection, which includes the following conditions:
- The HTTP content is not compressed
- The HTTP content-type istext/html.
- The HTTP content contains an HTML<head>tag
- Customize the dimension filters, according to your application needs, to capture the portion of traffic to that you need for troubleshooting.Dimension filters capture traffic according to defined aspects of the transaction's configuration, or header/payload contents. By focusing in on the data and limiting the type of information that is captured, you can troubleshoot particular areas of an application more efficiently. For example, capture only requests or responses, specific status codes or methods, or headers containing a specific string.Virtual ServersSelectAllto capture traffic for all Virtual servers.SelectOnlyto capture traffic from specific virtual servers. To specify, add virtual servers to theSelected Virtual Serverslist from theAvailable Virtual Serverslist.NodesSelectAllto capture traffic from all nodes.SelectOnlyto capture traffic from specific nodes. To specify, add nodes to theSelected Nodeslist from theAvailable Nodeslist.Response Status CodesSelectAllto capture traffic, regardless of the HTTP status response code.SelectOnlyto capture traffic with specific response status codes. To specify, add response status codes to theSelected Status Codeslist from theAvailable Status Codeslist.HTTP MethodsSelectAllto capture traffic, regardless of the HTTP request method.SelectOnlyto capture traffic with requests that contain a specific HTTP method. To specify, add methods to theSelected Methodslist from theAvailable Methodslist.URLSelectAllto capture traffic with requests for any URL.SelectStarts Withto only capture traffic with requests for URLs that start with a specific string.If you select this option, and leave the list blank, the system will not capture any traffic.SelectDoes not start withto capture traffic with requests for URLs except for those that start with a specific string.You can add up to 10 different strings to the list. If the list is blank, the system will capture traffic with requests for any URL.User AgentSelectAllto capture traffic sent from any browser.SelectContainsto only capture traffic sent from a browser that contains a specific string.You can add up to 10 different strings to the list. If the list is blank, the system will capture traffic sent from any browser.Client IP AddressSelectAllto capture traffic sent to, or from, any client IP address.SelectOnlyto only capture traffic sent to or from a specific client IP address.You can add up to 10 different IP addresses to the list. If the list is blank, the system will capture traffic sent to, or from, any IP address.Request Containing StringSelectAllto capture all traffic.SelectSearch infilter captured traffic that includes a specific string contained in the request.Response Containing StringSelectAllto capture all traffic.SelectSearch infilter captured traffic that includes a specific string contained in the response.
- Customize the metric filters, to capture traffic based on statistic thresholds for a defined measurement over time. See the table below for a definition of each metric.
- To capture traffic based on a metric that is greater than a certain value, enter a number (0 or greater) under theMinfield.
- To capture traffic based on a metric that is less than a certain value, select the check box next to theMaxfield and enter a value.If you do not select the check box, the max value setting will not be enabled.
- To capture traffic based on a metric range, enter values in both theMinandMaxfields. Ensure you have select the box for enabling a maximum value.
Application Response TimeThe time (in ms) from when the server receives the first request byte from the BIG-IP system until the server sends the first byte of the response.Client TTBFClient time to first byte (TTFB) is the time (in ms) from when the client sends the first byte of a request until the client receives the first byte of the response.Client Side Network LatencyThe client side network latency is the time (in ms) from when the client send the request to BIG-IP, until BIG-IP sends the response to the client (not including response/request duration times).Request DurationThe time it takes (in ms) the BIG-IP system to send the first byte until the last byte of a request to the server.Response DurationThe time it takes (in ms) the BIG-IP system to send the first byte until the last byte of a response to the client.Server LatencyServer latency is the time (in ms) from when the BIG-IP system sends the first request byte to the web application server, until the BIG-IP system receives the first response byte.Server Side Network LatencyThe server side network latency the time (in ms) from when BIG-IP sends the client request to the server, until BIG-IP sends the response to the client (not including response duration and application response time).Request SizeThe detected request size.Response SizeThe detected response size. - ClickFinished.
The BIG-IP system captures the application traffic described by the Analytics profile for 1000 transactions locally (or until system limits are reached). If logging remotely, the system logs information on that system; log size is limited only by constraints of the remote logging system.
System
performance is affected when traffic is being captured.
Reviewing captured traffic
Before you can review captured
traffic details on the BIG-IP system, you need to create an HTTP
Analytics profile that is capturing application traffic locally. The settings you enable
in the Capture Filter area of the profile determine what information the system
captures. You need to associate the Analytics profile with one or more virtual servers,
or with an iApps application service.
The system starts capturing
application traffic as soon as you enable it on the HTTP Analytics profile. You can
review the captured transactions locally on the BIG-IP system. The system logs the first
1000 transactions. On a VIPRION system, the system logs the first
1000 transactions multiplied by however many blades are installed.
- On the Main tab, click.The Captured Transactions screen opens and lists all of the captured transactions.
- Optionally, use the time period and filter settings to limit which transactions are listed.
- In the Captured Traffic area, click any transaction that you want to examine.Details of the request display on the screen.
- Review the general details of the request.The general details, such as the response code or the size of the request and response, help with troubleshooting.
- For more information, clickRequestorResponseto view the contents of the actual transaction.Review the data for anything unexpected, and other details that can help troubleshoot the application.
- On the Captured Transactions screen, clickClear Allto clear all previously captured data records (including those not displayed on the screen) and start collecting transactions again.The system captures up to 1000 transactions locally and displays them on the screen. Captured transactions are visible a few seconds after they occur.