This is the minimal set of actions required to start your NAM experience.
When running the NAM installation, pay attention to the order in which you install your components. The NAM Console and NAM Server are standard Windows installation packages. Make sure you have access to the Microsoft SQL Server before you start the installation. NAM Probe is a Linux installation package. See the detailed installation instructions below.
Get components work together
Get the licenses. See Licensing.
Set it all up in the NAM Console. Add all the installed components to your NAM Console and assign data sources to your report servers. Your primary data source will most probably be NAM Probe. However, depending on your monitoring needs, these can also be AppMon UEM, Synthetic, or Enterprise Synthetic. See Devices.
Obtain good traffic
Your NAM Probe needs to sniff good traffic in order to provide good monitoring data. You can use SPAN (port mirroring) or Tap to let your NAM Probe sniff the traffic.
You activated your SPAN or Tap and connected your NAM Probe using its sniffing interface. Good job! Now, make sure you feed your NAM Probe with good quality data. When your system is up and running, we provide a set of tools that will help you troubleshoot the SPAN configuration issues. See Traffic diagnostics report.
Check the resources of your switch first
Your switch needs free resources (processor, memory) to process port mirroring. You need to verify the current consumption before you activate your SPAN. Make sure there's a lot left for performing the port mirroring.
Get rid of non-IP traffic
First things first. What you really need for your NAM Probe is a client-server data exchange, which basically means IP traffic. Make sure you filter out the non-IP traffic on your SPAN
Get unicast traffic
Make sure you are getting unicast traffic for the services you're about to monitor. Just multicast traffic will not get you any good results.
Beware of duplicates
If you span different ports to a single destination port (or if you span a VLAN to a destination port), it is likely that some communication will be seen several times: as an example, if you span port A and port B to port C, all communications going from port A to / from port B will be copied twice to port C.
You must have a way to deduplicate traffic before you analyze, otherwise, you are likely to draw bad conclusions.
Make sure you are not dropping packets
If you are spanning several ports to one, it is likely that the sum of the capacity of all source ports exceeds the capacity of the destination port. In that case, you need to evaluate the risk of oversubscription of the destination port. Check Traffic diagnostics report and if you see dropped packets, see if this helps:
- Measure the level of usage of each source port before you activate the SPAN.
- Check that there is no oversubscription on the destination interface of the switch (the traffic sent is lower than the maximum capacity).
Avoid errors on the interfaces
You may get some errors on the source and destination ports: you should check that there is no checksum, CRC errors (in your switch management interface).
Make sure you are seeing traffic both ways
Response time measurement needs to see the requests… and the responses and to measure the time intervals between them. If you see traffic only Client to Server or Server to Client, you will not get any meaningful data.