-
Notifications
You must be signed in to change notification settings - Fork 440
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
Add a Recordable interface, implementation, and tests for logs #438
Conversation
Codecov Report
@@ Coverage Diff @@
## master #438 +/- ##
==========================================
- Coverage 94.52% 94.19% -0.33%
==========================================
Files 178 182 +4
Lines 7701 7853 +152
==========================================
+ Hits 7279 7397 +118
- Misses 422 456 +34
|
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.
Good, with minor suggestions.
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.
Thanks for working on this PR. We are now using the right approach to propagate logs to exporter : )
resource.begin(), resource.end()}, | ||
nostd::span<const std::pair<nostd::string_view, common::AttributeValue>>{ | ||
attributes.begin(), attributes.end()}, | ||
trace_id, span_id, trace_flags); |
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.
Nice to see this initializer_list
for resource
and attributes
.
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.
Thanks for refactoring this! That's much closer to a design that is production-ready.
|
||
log(r); | ||
// Set default values for unspecified fields, then call the base Log() method | ||
void Log(Severity severity, nostd::string_view message, core::SystemTimestamp time) noexcept |
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.
Why do we have time
first in the virtual Log
call, but severity
first here? I think we should keep the order of the arguments consistent.
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.
Hmm since it seems most ergonomic/common use case is to users to specify severity, then message, since timestamp would be set by default in common use cases. I can move timestamp to the end of the main Log() method for consistent ordering with this method here
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.
Nice work! Just a few minor nits from me, but thanks very much for tackling this!!
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.
Great work!
e4e746d
to
a03d17e
Compare
@pyohannes @lalitb Would this be good to merge now? |
@xukaren - Please rebase the branch with base, so we should be ready to merge it. thanks. |
Done! |
This PR implements a recordable for logs, as part of the logging prototype, and also resolving issue #412.
This PR:
LogRecord
Recordable implementation, with unit testsRecordable
instead of the previousLogRecord
struct, across the processor and exporter filesAPI/SDK changes:
Severity::kDefault
enum value (originally set as kInfo), and added aSeverity::kInvalid
= 0. (Setting the default Severity to kInfo has been moved to the SDK instead of the API)Other minor changes:
LogRecord
struct from the APIlog()
methods toLog()
, and addsthis->
before calling Log() methodsThis PR introduces changes that blocks a few other open PRs: #422, #430, #434, and #435.
cc @MarkSeufert @alolita