Split metrics on last client write #116
Conversation
Record virtual network relevance time in a more precise way: 1. When doing a sync with pre-existing network interfaces at start up, correctly pick the earliest relevance time rather than the one associated to the first local attachment to be processed. 2. Add a prometheus gauge to track the delay of the recorded relevance time wrt the real relevance time. 3. Log a warning when a relevance delay is detected.
staging/kos/pkg/controllers/connectionagent/connection_agent.go
Outdated
Show resolved
Hide resolved
staging/kos/pkg/controllers/connectionagent/connection_agent.go
Outdated
Show resolved
Hide resolved
staging/kos/pkg/controllers/connectionagent/connection_agent.go
Outdated
Show resolved
Hide resolved
Follows a list of changes. Rename: "creat" -> "create". Access to Prometheus histograms and counters: from "With(...)" -> "WithLabelValues(...)". Refactorings to streamline code and reduce duplication. Better wording of comments on Prometheus metrics. Enforce consistent pass order of related function parameters. Print VNI consistently in hex in logs and error messages. Get rid of uninteresting Prometheus metrics.
| return | ||
| } | ||
|
|
||
| func getAttLastClientWriteInfo(att *netv1a1.NetworkAttachment, naLastClientWrVal, naSubnetLastClientWrVal string) (lastClientWr string, lastClientWrTime time.Time) { |
There was a problem hiding this comment.
The name of this func, "getAttLastClientWriteInfo", when compared with the preceding "getLastClientWriteInfo", differs only in the presence of "Att" --- which does not identify the difference between these two funcs. Perhaps this one should be named something more distintive. Perhaps something like "lastClientWriteInfoSwitch"?
There was a problem hiding this comment.
The reasoning behind the name "getAttLastClientWriteInfo" is that it returns the last client write concerning an attachment, whereas the enclosing func returns the last client write among a group of writes that is related not (necessarily) just to the attachment being processed.
There was a problem hiding this comment.
Both are rooted at the NA, and even getAttLastClientWriteInfo looks further.
It is not just how far the func looks, but getAttLastClientWriteInfo takes parameters to use in characterizing the answer.
|
We can improve that func name later. |
This PR is the first step towards the changes discussed in #111 .
It splits metrics on the latencies of the lifecycles of NetAtts and subnets (NAs) on the basis of the last client precursor.
This PR self-contained and mergeable, but it's partial. It does not take into account in any way the fact that client precursors could be deletions of API objects as well (as pointed out here). It does not take into account the fact that implementation of API objects could be delayed because controllers could fail. Let's merge this and do remaining things in follow-up PRs.