Application Traffic Analytics and Insights¶
A10 Lightning ADC provides detailed insights into the application traffic. Since the LADS is front-ending the application servers, insights are available even for traffic that does not reach the servers due to any security or other traffic management policies applied by LADS. Additionally, if all the micro-services of the application are modeled properly, these insights will provide application performance management (APM) capabilities as well. Analytics and Insights are summarized based on a time interval selection. Time Selection is available in the user interface (UI) at the top-right corner. A few predefined intervals are provided for convenience, but the custom selection is always available where the time range may be chosen at the granularity of a minute.
The A10 Analytics Dashboard is segmented into three parts Traffic, Security, and Health dashboard each catering analytics aggregated at an application level as shown. It also provides analytics for Metrics, Blue/Green, Alerts, Events and Logs. The application selection can be made from the left panel.
Per Request Analysis¶
The Analytics dashboard is mechanized to provide Per Request Analysis logs, the user can now customize the per request log collection policies according to their needs. The per request log collection policies offers different options for the user to choose from such as OnErrors Logs, OnEvents Logs, and Manual Control Logs. OnError logs are collected in the event when traffic hits the server and the server throws an error response due to various reasons. OnEvent logs are collected after initial application onboarding for the time in minutes, or after every application change for the time in minutes. Manual control logs are collected between the defined time frame by the user.
The figure below is Per Request Analysis Log chart, in this, the Absent logs are the logs which are not collected.
You can create the Per Request Log policies from this screen. To reach here click the Per Request Log policies from the above screen.
The most noticeable are the top panel of numerical displays on the landing page of the Dashboard. Here the most relevant information are presented.
First one on the top left being the end-to-end response time that is most critical for any application. The number indicates the average time taken by requests and responses in flight i.e. from the client back to the client. Clicking on this takes you to Response-time drill-down dashboard.
The second one is the application server health index. This is computed based on a combination of various normalized health parameters of application servers serving traffic for this application. Clicking on this takes the user to the Server Health drill-down dashboard.
The third one shows some Blocked requests. This can be clicked even if the number shown is zero. Clicking here takes the user to the Security Dashboard that shows all the relevant trend charts and tables displaying security issues found over the interval. Next one shows the total bandwidth processed (incoming + outgoing) by LADCs for this application during the selected period. Next two are overall request rate and error rate averaged over the selected period.
The main body of the dashboard has a series of charts that give a quick statistical overview of the behavior of the chosen application traffic. The screen is broadly divided into three sections to provide this overview at a glance. Abnormal behaviors can be quickly picked up visually:
- The best and the worst view (or Top-Ten) in term of traffic performances
- The App server and service facing statistical indicators
- The Client facing statistical indicators
Four charts in the top row of charts provide information about the areas of the application that receive the maximum amount of traffic, including clients that generate the most traffic.
Users can use these charts to analyze the visibility on application traffic distribution and to optimize these areas for best performance and scaling.
Next three charts provide information about areas of application for which the average response time is maximum. Indicates potential sources of application latency seen by clients.
With the information provided by these charts, the user can debug these areas using per request analysis to improve overall client perception of application response.
Next two charts provide information about the distribution of the response codes being returned to the clients.
If a user sees more errors with error code (4xx and 5xx), then a user can debug these errors using per request analysis and fix them.
Next two charts display the performance of the servers based on errors and latency.
Next two charts provide information about what part of the application traffic is exposed without SSL, are there any unsuccessful SSL connection attempts, and what is the average time spent in SSL negotiation.
If the user notices any deviation in performance, say if the SSL parameter crosses beyond the expected level; then the user needs to check for SSL protocol, ciphers and SSL certificates. It may also be an indicator of a potential DoS attack.
Next row provides information about how many client connections are coming to LADCs (front-end), and how many connections are created by LADC to the server (back-end).
For high traffic, the difference between front-end and back-end connections should be high. If not, the user needs to check server?s connection closing settings for reducing the load on the server.
Next chart shows if the system has experienced any threat. Details of threats are available on the security dashboard that can be reached by clicking on the Blocked Requests in Top Panel.
Clicking on Total Response Time at top-left of the dashboard takes you to Response-time Drill-down. Data shown is in the context of a Service of the Application that can be selected from a dropdown at the top-left of this page.
Charts on this page help the user visualize the breakup of all the client?s response time providing a quick summary to quickly figure out if there are any issues one needs to investigate. The diagram on the top right on this page shows the various portions of an HTTP request-response process and provides the average time taken in each of those portions.
The chart below displays the various time duration of how much time is consumed on the average in various portions of the request to response period.
Identifies areas of issues in the request-response path. Optimize the portion of a period where on the average maximum time is being spent.
The other chart below the diagram on the top right focuses on the server response time for each of the server in the pool which is under the control of the user and this information can be used to improve performance, optimize resources, or troubleshoot servers by taking subjective measures.
Next, there are a few tables showing segmentation of the traffic response time based on various parameters: by type of response, by the client, by URL, by the server, by client geolocations. Rows of these tables are sorted such that the ones having highest response time show up on the top row. In case if the list is long, then only top few entries are shown.
Clicking on any row takes the user to the next level of drill-down where individual logs are shown filtered by criterion selected by the particular row clicked.
This filtering and ability to look into individual transaction details help you figure out if there is a general problem with the system and you need to debug it further, or it was an anomaly that you can ignore.
Server Health Drill-down¶
Clicking on App Server Health in the Top Panel of the dashboard takes you to a page that details and displays individual aspects that contribute to the calculation of the application server health index. Data shown here is in the context of a Service of the Application that can be selected from a drop-down at top-let of this page.
The charts below display the various health metrics for the application server on the average and for individual servers. Also, provides the information about the behavior of the server. So, if any metrics goes beyond the limit, the user can debug the server and fix.
Clicking on a particular data point in the health index chart at the top, updates the details charts at the bottom that contribute to it around the time clicked.
Allows the user to access logs for each request along with details of request size, response size, source and referrer information, information of the server served the request along with the time taken in each portion of the transaction. Also, user can access the WAF logs and WAF acknowledged logs. Helps user to get to the root of the problem and points user to the problem area.
Analytics > Logs displayes the Per Request logs, the WAF logs and the WAF acknowledged logs. You can use the filters at the top to narrow down the scope for your analysis.
To access WAF logs from the dropdown select Only WAF Logs as shown.
To filter a specific WAF log user can create an exception by opting the check box under create exception and save it as shown.
To access the WAF logs with an exception user can use the Acknowledged WAF Logs option from the filter as shown.
Logs can be filtered on any field by entering the specific values to be filtered as shown below.
Clicking on individual log row opens a popup providing detailed information about the request and response.