Expose kernel ringbuffer errors in metrics #2839
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lambdanis
added
area/metrics
✅ Deploy Preview for tetragon ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There are two metrics counting events lost in the ringbuffer: * tetragon_missed_events_total, collected in BPF based on perf_event_output error * tetragon_ringbuf_perf_event_lost_total, collected in observer based on Record.LostSamples from cilium/ebpf When testing, I saw the former being higher than the latter. This might mean there are failed writes to the ringbuffer that are not lost events seen by Record.LostSamples. To investigate such issues, I'm adding error label to tetragon_missed_events_total, representing kernel error returned by perf_event_output. According to @olsajiri EBUSY and ENOSPC would be the only we could really hit, the rest is most likely due config error. So let's start with counting these two, and aggregating other errors as "unknown". We can always split out more errors in the future if needed. Signed-off-by: Anna Kapuscinska <[email protected]>
lambdanis
force-pushed
the
pr/lambdanis/missed-metric
branch
from
607c0bd to
c270528
Compare
There are a few places where events be "missed", so let's make it clear in the metric name that's it's counting kernel misses. Signed-off-by: Anna Kapuscinska <[email protected]>
olsajiri
approved these changes
Aug 26, 2024
| #define SENT_FAILED_UNKNOWN 0 // unknown error | ||
| #define SENT_FAILED_EBUSY 1 // EBUSY | ||
| #define SENT_FAILED_ENOSPC 2 // ENOSPC | ||
| #define SENT_FAILED_MAX 3 |
There was a problem hiding this comment.
nit, extra tab screwing the diff in terminal
| struct kernel_stats { | ||
| __u64 sent_failed[256]; | ||
| __u64 sent_failed[256][SENT_FAILED_MAX]; | ||
| }; |
There was a problem hiding this comment.
just a note.. I think it's ok because it's still small map, but it is per cpu and this change multiplies the memory usage by 3
|
adding @tpapagian because I think he added those metrics originally |
tpapagian
approved these changes
Aug 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are two metrics counting events lost in the ringbuffer:
error
Record.LostSamples from cilium/ebpf
When testing, I saw the former being higher than the latter. This might mean
there are failed writes to the ringbuffer that are not lost events seen by
Record.LostSamples. To investigate such issues, I'm adding error label to
tetragon_missed_events_total, representing kernel error returned by
perf_event_output.
According to @olsajiri EBUSY and ENOSPC would be the only we could really hit,
the rest is most likely due config error. So let's start with counting these
two, and aggregating other errors as "unknown". We can always split out more
errors in the future if needed.