Proposal for tcp_long_connection_metrics #1224
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Some questions:
|
The accesslog is printed after connection closed. Can keep it as now Integrate with OTEL sounds reasonable to me. |
|
|
|
||
| - Reporting of metrics and access logs, at periodic time or based on throughput (e.g. after transfer of 1mb of data). | ||
|
|
||
| - User can fine tune the time and throughput using yaml during kmesh deployment or can use CLI tool kmeshctl anytime. |
There was a problem hiding this comment.
What's this mean? How to fine tune the time and throughput?
There was a problem hiding this comment.
I was thinking to, give users options to set their prefered periodic time and threshold values during the start of kmesh daemon, be setting the values in values.yaml file
There was a problem hiding this comment.
understand.
You can change the description
| } | ||
| ``` | ||
|
|
||
| The value of the period or the threshold is provided by the user, if not a default value of 5 seconds and 1 mb is chosen. |
There was a problem hiding this comment.
Can you able to explain in the proposal why 1MB is the threshold?
There was a problem hiding this comment.
If the threshold were set too low, the system might generate too many reports, leading to noise and increased processing overhead, 1 mb threshold sounds appropriate to me. We are also giving users options to set their own threshold if he is not satisfied with 1mb
|
@nlgwcy PTAL |
|
Sorry for inactivity i am sick from last 6 days, i will reply to all your queries and complete my proposal asap. |
| authors: | ||
| - "yp969803" | ||
| reviewers: | ||
| - "nglwcy" |
There was a problem hiding this comment.
| - "nglwcy" | |
| - "nlgwcy" |
| know that this has succeeded? | ||
| --> | ||
|
|
||
| - Collect detailed traffic metrics (e.g. bytes send/recieved, direction, throughput, round-trip time, latency , state-change) continously during the lifetime of long TCP connections using ebpf. |
There was a problem hiding this comment.
It is recommended that TCP retransmission and packet loss measurement indicators be added.
|
@LiZhenCheng9527 can you review the ebpf code in the proposal! |
What type of PR is this?
Proposal for "Metrics for TCP Long Connection"
LFX 2025 term-1
/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #1211
Special notes for your reviewer:
Does this PR introduce a user-facing change?: