-
Notifications
You must be signed in to change notification settings - Fork 28
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was the motivation here? Usually, we just pull metrics out of the kernel itself.
Metrics are usually aggregate. I'm not sure aggregate RTT, congestion, etc. is really all that useful. |
(maybe aggregate bandwidth would be useful?) |
Apparently, RTT etc distributions (which will help us pick better timeouts, etc) conn lifetime (may help with connection management choices) etc. So yeah, useful. |
In terms of making this work with things that aren't |
I created a fork of mikioh/tcp that includes mikioh/tcp#2, so we don't have to use any unsafe type castings here. Not my preferred resolution, but until @mikioh merges the PR our options are limited. |
We have a lot of forks that fall into that category. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delayed review.
52891c1
to
596fdb4
Compare
596fdb4
to
62fde9e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me from the Prometheus perspective!
"sync" | ||
"time" | ||
|
||
"github.com/marten-seemann/tcp" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this to libp2p? Our forks like this have a tendency to live longer than intended.
This PR exposes some basic TCP transport metrics to Prometheus.
We're using the TCP_INFO socket option to query the kernel for TCP metrics (things like the RTT, congestion window, etc).
In the future, I'm planning to add more metrics, to mirror what we're measuring for QUIC wherever possible.