Conversation
markdroth
left a comment
There was a problem hiding this comment.
This looks good! My comments are mostly minor cosmetic things, but there are two small substantive comments.
Please let me know if you have any questions. Thanks!
ejona86
left a comment
There was a problem hiding this comment.
So you understand why I'm looking at this so much more closely now vs before: Earlier this was "some metrics y'all wanted for yourselves". And I knew why you'd want them, and why they'd be useful to others, but there wasn't an idea we'd move quickly to implement this cross-language for wide availability. With the idea these are going to be on by default, that means these are seen as being more important/widely used metrics. They are now intended for the masses. Thus I started reviewing them as such.
Since I'm going to be unavailable next week: I'd said the comments I need to say. Once the threads are actually resolved (not just marked resolved), it seems it would be good to go.
ejona86
left a comment
There was a problem hiding this comment.
I had thought grpc.tcp.connections_created would be paired with a closed counter, as that's what we've done in the past instead of UpDown counters. But I can live with this.
Thank you!
| * For each new connected TCP socket, set an initial alarm of 10% to 110% (randomly selected) of TCP\_CONNECTION\_METRICS\_RECORD\_INTERVAL. | ||
| * When the alarm fires \- | ||
| * Use `getsockopt(TCP_INFO)` or equivalent method to retrieve and record connection metrics. | ||
| * Re-arm the alarm with 10% to 110% (randomly selected) of TCP\_CONNECTION\_METRICS\_RECORD\_INTERVAL and repeat. |
There was a problem hiding this comment.
I can understand why the initial alarm might be set to 10%. Why would we let the re-arming be as low as 10%?
No description provided.