SCOM F5 Objects Not Consistent with Objects on F5

The extra logs (with the long GUID names) helped to fill in the blanks. Sometimes we have to create a separate logging file from the main trace.log if the the file gets locked for some reason. The service can end up competing with itself for the trace log sometimes if it restarts quickly.

 

 

It definitely appears that the "failed to find entity" errors were fixed by the rediscovery. The rediscovery worked despite the error that was displayed which as I mentioned is a known issue when there is a large number of objects on the BIG-IP. The side effect is only that the service initially could not start getting statistics and is self-fixing over time (or you can use the Refresh Collection Rules task to work around).

 

 

As for the pool member that is not showing the correct health, I see the following health updates from the BIG-IP:

 

 

12/09 3:12:23 PM -- Monitor is up (GREEN)

 

12/10 7:24:23 PM -- Monitor is down (RED)

 

12/10 7:24:27 PM -- Monitor is up (GREEN)

 

 

The end result of this is that the pool member should show green. It seems possible that the BIG-IP did not send a notification that the monitor went down again. Does this timeline concur with what you know about the pool member?

 

 

I would recommend selecting the pool that the pool member is in (in OpsMgr) and using the Refresh Health task to sync it up. If that does not cause it to show the same health as on the BIG-IP, I can investigate further.