The host has a connectivity below the 100%, I can not find any cause. All processes are on 100% connectivity and I do not see any tcp refused or tcp time-out, messages. In other words, no process is affected so why show me this info anyway?
There is also no info in the windows log files,
Below a screen print as example:
Solved! Go to Solution.
From the documentation:
Overloaded or poorly configured processes can have trouble accepting new network connections. This results in timeouts or resets of TCP handshakes. Such issues are tracked as TCP connection refused and TCP connection timeout errors.
Dynatrace also compares the number of such errors with the total number of connection attempts to calculate Connectivity metrics—the percentage of connections that have been successfully established. Ideally, Connection metrics are never lower than 100%. Anything less suggests failed user actions that will be obvious to your customers.
Situation described above will happen if some client attempts to make connections to a port that is no longer open by any process on monitored host. According to definition provided above by Rocky, this will result in drop of connectivity (because the TCP sessions are getting rejected).
We calculate this that way, because if it occurs regularly (resulting in larger drop in connectivity) it indicates an actual problem in monitored infrastructure - something is expecting that there is a service exposed on port in question of monitored host. Please note, that in above light minor drops in connectivity are usually not something to worry about, and at least in the attached screenshot we can see, that a connectivity problem was not reported by Dynatrace in this case.
Clearly in such situation it is impossible to assign the rejected sessions to any PGI (as most likely they are reaching to a process that no longer exists or at least does not have the expected port open), hence the connectivity is 100% for all PGIs. Note, that we report connectivity problems for PGIs for some time after it disappeared, but after some time it is simply impossible to tell, what PGI is supposed to respond on given port.
We are considering adding a list of calling TCP addresses, that result in drop of host connectivity, but this is a loose idea for now so if you would find it useful, please do not hesitate to create a RFE in that area.