Skip to content
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

Misc tracing improvements #906

Merged
merged 7 commits into from
Nov 14, 2024
Merged

Conversation

danielocfb
Copy link
Collaborator

Please see individual commits for descriptions.

Copy link

codecov bot commented Nov 14, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.50%. Comparing base (b1f9f91) to head (6b39bf2).
Report is 7 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #906      +/-   ##
==========================================
- Coverage   94.53%   94.50%   -0.03%     
==========================================
  Files          56       56              
  Lines       10140    10126      -14     
==========================================
- Hits         9586     9570      -16     
- Misses        554      556       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@danielocfb danielocfb force-pushed the topic/tracing-improvements branch 3 times, most recently from 6f939f7 to 8a78dd6 Compare November 14, 2024 23:21
The Debug representation of ElfResolver looks awkward and not in line
with how objects are generally represented. Fix it up to make traces
somewhat more appealing to the eye.

Signed-off-by: Daniel Müller <deso@posteo.net>
From the point of view of a user, the Resolver enum has no meaning: it's
pretty much just an implementation detail of how we manage memory. As
such, all the current representation in traces does is add clutter.
Simplify it by only printing the inner value (i.e., the resolver).

Signed-off-by: Daniel Müller <deso@posteo.net>
We document supported "formats" not just in the README but also in the
Symbolizer type's documentation. Mirror what commit a9d9811 ("Add
BPF programs to "format" matrix in README") did to the README there as
well, to keep both matrices in sync.

Signed-off-by: Daniel Müller <deso@posteo.net>
The ElfResolver::find_sym trace point doesn't really buy us anything:
other resolvers don't have it and we effectively already have the
functionality captured by the trace in
Symbolizer::symbolize_with_resolver. As such, let's just remove it.

Signed-off-by: Daniel Müller <deso@posteo.net>
The occurrence of errors is generally something that we should include
in our traces, but doing so requires special annotation. Add it to
relevant entry points to the crate. The created spans/events will be
emitted at log level ERROR by default, which is what we want.

Signed-off-by: Daniel Müller <deso@posteo.net>
It can be useful for introspection matters to get a quick understanding
of what /proc/<pid>/maps entry an address gets mapped to as part of
process symbolization. Attach a span to the handle_entry_addr() method
to emit this information.

Signed-off-by: Daniel Müller <deso@posteo.net>
Make sure that we capture the reason why a symbolization maps to
"unknown" in traces, as that can be relevant information when trying to
understand what the library is reporting.

Signed-off-by: Daniel Müller <deso@posteo.net>
@danielocfb danielocfb force-pushed the topic/tracing-improvements branch from 8a78dd6 to 6b39bf2 Compare November 14, 2024 23:30
@danielocfb danielocfb merged commit 51384ef into libbpf:main Nov 14, 2024
41 checks passed
@danielocfb danielocfb deleted the topic/tracing-improvements branch November 14, 2024 23:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants