Yes the server still appears.
192.168.198.76 s:472 sb:26160 cb:1757174 sp:276 cp:8553 ud:78 e:7 dcr:0 pg:0
192.168.198.77 s:452 sb:26160 cb:585463 sp:278 cp:2970 ud:72 e:0 dcr:0 pg:0
192.168.198.78 s:379 sb:26160 cb:1129116 sp:268 cp:5010 ud:70 e:2 dcr:0 pg:0
192.168.198.79 s:435 sb:26160 cb:1182774 sp:275 cp:4162 ud:70 e:0 dcr:0 pg:0
These are the 4 servers that are monitored for the software service.
First check your Software Service definition and write down the TCP/IP addresses of the service. Then start a PUTTY session to the AMD and start up RCON. In RCON, you type "lsrv" which should generate a quite long list for you.
In that list, see if you can find the addresses you wrote down for that service. If they are not there, either the IP has changed or the way (SPAN/TAP) you get the traffic into the AMD has changed.
Hint - you can use filters if the list is very long - just type "lsrv /?" and you will get the syntax.
Oups - didn't catch that last response :-)!
So the sb: means ServerBytes and the cb: means Client Bytes.
Which is good because at least you are getting the traffic still.
Since you get the traffic but fail to get any reported data, I would take a trace and look at what is coming in. Perhaps the content or the URL have changed (are the URL's hard coded?)
Are those the URLs as in the definition?
If they're meant to be regex's you'll need some ( and ) to determine what the CAS will report. e.g.
if you want to report everything uniquely - noting that this can exceed server cache and grow the database excessively.
@Chris Vidler @Ulf Thornander Thank you all for the help. The network team changed some of the port spanning and therefore we were not getting the traffic. It was the last thing that I would have thought about since this DC RUM setup has been there for the last 5 years
Thank you so much for the time!