Ah, ok, this is a bit different. So, this GET request is requesting "/" from the server, which means that the hostname isn't defined in the request, meaning that the request goes to the current device. Cool, this isn't a problem with the command/DataSource then.
So, what's happening is that for all the devices that don't have alerts, requesting "/" results in a 200. Meaning that you can go to that device like this in your browser and it works: "https://devicenameoripaddress/".
However, for these 5 servers with alerts, when someone/something requests "https://devicenameoripaddress/", the server responds with a 503 - service unavailable. Likely it's configured to respond to "https://devicenameoripaddress/s/login.asp", but not "https://devicenameoripaddress/". This is bad practice on the application developer who developed the websites running on those 5 servers. They should at least redirect from the root to /s/login.asp.
As for fixing it, this isn't technically a false positive. LM is trying to pull up https://devicenameoripaddress/ and it's failing. Since that's not really a problem, there are several options for changing the behavior:
-
You can exclude these 5 servers by modifying the appliesto.
-
You can exclude these 5 servers by modifying the appliesto and instead include them in a clone of this DS with a modified path so that the request goes to "/s/login.asp".
-
You can change the alert thresholds on the group level or the instance level.
-
You can disable alerting or monitoring on these 5 servers on the group or instance level.
There are probably a couple more options depending on the outcome you want.