Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to deal with "Connection establishment timeout errors" in TCP failure.



We have configured Availability (Total) alert on DCRUM. People receives alert if threshold for Availability gets breached. After drilling down further it is Connection establishment timeout errors

most of time. (Availability TCP is down)

In response application team says these are false alerts as application is working perfectly fine.

Can somebody help & let me know how to deal with this.




From CAS point of view

Connection establishment timeout errors

is one component of "Failures (TCP)" (second is "Connection refused errors"), which has an impact at "Availability (TCP)" and this has an impact at "Availability (total)".

Dynatrace Pro
Dynatrace Pro

Connection establishment timeout occurs when client sends TCP SYN packet, but server never responds with TCP SYNACK. That is, there is a client knocking at te door, but nobody opens.

The app team may not be aware of these at all because request may never trach the application stack. For example, OS level firewall rules may prevent accepting TCP connections from not-designated clients.

This may need further investigation to see who the clients are and whether requests they try to establish are legitimate for this server. These may be real clients and it is possible that connection is eventually established (in this situation it would be the server or firewall issue, but not the app issue). Ot these may be unimportant clients, e.g. some prot scanners that are indeed legitimately excluded by firewall rules.

Hope this helps

@Kris Z.

Did I understand it correctly that when we are monitoring around a firewall and these firewall is blocking certain ports (like port 25 for smtp) we will see failed transaction with "connection establishment timeout errors" for SMTP service?

Dynatrace Consultant and Center of Excellence Expert

That is correct. There is a client who wants to establish a connection to port 25 and nobody is responding (firewall drops such SYN packets). From the client perspective it's a failure to connect. Either the client is really affected - the job he tried to do can't be done - or the client shall not be doing what he is trying to so. Either way, I wouldn't say it's "normal" situation.