-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Break out the telemetry during sample processing #106
Conversation
The "packets" metric had heavily overloaded meaning for different "outcomes", and would often be incremented multiple times, sometimes even with a single (per-line) increment in one outcome corresponding to multiple increments in another. This removes the broken metric, and replaces it with separate total and error counters for each level of processing. This allows monitoring the network traffic handled separately from the samples incurred by it.
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.
LGTM
@bakins WDYT about getting this into the 0.5.0 release? I'd either merge it now & then you can rebase the release branch, or I hold it back for the next release. it's technically another breaking chagne, and I kinda prefer bunching them up, OTOH the old metric was so bad I'm not too worried about breaking it. |
@matthiasr is fine with me to include in 0.5.0 |
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.
LGTM. I guess we should have an issue to fix the reading of long TCP packets.
log.Debugf("Read %s failed: %v", c.RemoteAddr(), err) | ||
} | ||
break | ||
} | ||
if isPrefix { | ||
networkStats.WithLabelValues("tcp_line_too_long").Inc() | ||
tcpLineTooLong.Inc() |
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.
Uhm, we should just fix the reader though, no need to abort on a long line. https://golang.org/pkg/bufio/#Reader.ReadLine
Yes, this should be really easy to fix, but this PR is about the metrics. |
The "packets" metric had heavily overloaded meaning for different
"outcomes", and would often be incremented multiple times, sometimes
even with a single (per-line) increment in one outcome corresponding to
multiple increments in another.
This removes the broken metric, and replaces it with separate total and
error counters for each level of processing. This allows monitoring the
network traffic handled separately from the samples incurred by it.
Supersedes #54 based on the discussion there.