Network tap — The preferred method, a network tap copies traffic for the purpose of monitoring. It is a passive device that, if it breaks, does not interrupt network traffic or the functioning of your application.
If you use a smart tap (from companies such Gigamon, Net Optics, Network Critical, and Network Instruments), you can filter on IP addresses and port numbers to reduce traffic. BMC Real End User Experience Monitoring monitors only HTTP and HTTPS traffic, so you can configure a smart tap to copy only traffic on ports 80 and 443. See also Sizing Real User Collector instances.
Taps are fast and purpose-built for copying traffic. However, installing or replacing a tap forces you to take a segment of your network offline for a time.
Mirror port — You can configure a mirror port on a switch to copy traffic, such as Switched Port Analyzer (SPAN) for Cisco systems or a Roving Analysis Port (RAP) port on 3com devices. In many cases, a switch already has a spare port that you can set up as a mirror. However, the device considers mirroring a secondary function, and if the device becomes overloaded, it might suspend mirroring, and the Collector will experience packet drops.
You must be sure that the mirror port is copying traffic both to and from the application (bidirectional).
You can set up tapping in front of or behind the load balancer, as shown in the following illustration.
The following table describes requirements for secure traffic and how the placement of tapping points affects the traffic data collected and the reported by BMC Real End User Experience Monitoring.
|Tapping point||Effect on traffic data||Secure traffic requirements||Effect on metrics|
Tapping in front of the load balancer is the recommended method. It provides the best visibility of end-user traffic. From this point, it is possible to collect SSL traffic.
Data collected in front of the load balancer is as close to the edge of your network as possible. You can consider all time spent after this point in the network as time the user spent in your infrastructure, including the load balancer, which is considered host latency. The time spent in the network before the load balancer is considered network latency. For a definition of the these latency metrics, see.
In order to see which server responded to a particular request, this information will need to be sent through the load balancer. If you tap in front of the load balancer, the IP address of the web server handling the request will not be visible. To have that visibility, you must add an HTTP cookie or an HTTP header to either the load balancer or the web server so it can be parsed.
|To monitor HTTPS traffic, if the load balancer or web servers are performing encryption and decryption, you must upload a copy of SSL private keys to the Collector.||To report back all metrics, including SSL time, tapping at point 1 is recommended.|
You can also tap behind the load balancer, but you must tap incoming and outgoing traffic in the same place. Tapping in this way reduces the visibility of end-user traffic, particularly between the end user and the load balancer.
To monitor HTTPS traffic, if encryption and decryption occur on the load balancer, you do not need to upload a copy of SSL private keys to the Collector.
In some cases for SSL decryption acceleration, the load balancer will decrypt the data on behalf of the servers. The load balancer might also be the end point for the request and re-request it on behalf of the end user for increased security.
Data fed from this point is closer to your servers. This means that the network time metric will also include some latencies that are contributed from your infrastructure.
If the load balancer does the decryption on behalf of the servers, the SSL latency metric will be lost.
|1 and 2|
Tapping both in front of and behind the load balancer is more complicated and is dependent upon being able tobefore and after the load balancer. For example, if you sessionize a cookie, the cookie will be detected on both sides of the load balancer, which results in duplicate reports of a hit in the same session.
The recommendations are the same as 1 and 2.
In this case, you get the benefit of monitoring the end user experience from the customer’s point of view. You also have a tap that is closer to your servers so you can get a Host Latency metric that more closely represents only the request time spent in the server.
Note: Either tapping point does not change the end-to-end time of the request/response.