Would folks be open to additional phase metrics for TCP probes, similar to the resolve, connect, etc. phases in http prober and the resolve etc. phase metrics in the icmp prober?
I've got a case where it would be helpful to have insight into the connect (TCP connection established) vs. closed phases. On low latency connections, the initial TCP connection 3-way handshake hits about 2-3 ms for me on a set of targets (I'm assuming it's iniital flow entry, like conntrack), whereas the connection close (FIN+ACK both ways, then final ACK) is significantly quicker (around 0.3 ms). So the connection close phase is closer to the real network RTT, whereas the initial TCP connection establishment has about an order of magnitude overhead. I could try to add ICMP probes on for these hosts as well, and hopefully with low enough frequency could bypass that initial overhead as later ICMP probes reuse existing flow/session entries, but it would be ideal to be able to get this additional info from the existing TCP probes. I'm just starting to dive into golang, but if it's not something that others would want to take up I could try my hand at it, modeling after the trace model used in the http prober, if this would be something useful for others and that has a shot at getting approved as a PR. -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/b149ab13-d629-4889-9423-08b8a16fc39cn%40googlegroups.com.
