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
[DNM] tracing: use LTTng for logging #22458
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
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
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
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
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
#ifndef CEPH_LOGGING_IMPL_H | ||
#define CEPH_LOGGING_IMPL_H | ||
|
||
#include <string> | ||
#include <stdarg.h> | ||
#include <fmt/include/fmt/format.h> | ||
#include <fmt/include/fmt/ostream.h> | ||
|
||
#include "tracing/ceph_logging.h" | ||
|
||
using fmt::format; | ||
|
||
#define trace(ll, ss, fmt, ...) __trace(ll, ss, format(fmt, __VA_ARGS__)) | ||
#define trace_error(ss, fmt, ...) __trace(-1, ss, format(fmt, __VA_ARGS__)) | ||
|
||
//static inline void trace(int loglevel, string subsys, const char *fmt, void *arg, ...) | ||
static inline void __trace(int loglevel, string subsys, string str) | ||
{ | ||
str = subsys + ": " + str; | ||
if (loglevel <= -1) { | ||
str = "Error: " + str; | ||
tracepoint(ceph_logging, log_error, (char*)str.c_str()); | ||
} else if (loglevel <= 1) { | ||
tracepoint(ceph_logging, log_critical, (char*)str.c_str()); | ||
} else if (loglevel <= 5) { | ||
tracepoint(ceph_logging, log_warning, (char*)str.c_str()); | ||
} else if (loglevel <= 10) { | ||
tracepoint(ceph_logging, log_info, (char*)str.c_str()); | ||
} else if (loglevel <= 15) { | ||
tracepoint(ceph_logging, log_debug, (char*)str.c_str()); | ||
} else { | ||
tracepoint(ceph_logging, log_verbose, (char*)str.c_str()); | ||
} | ||
} | ||
|
||
#endif // CEPH_LOGGING_IMPL_H |
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
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
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
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
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
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
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
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
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
Oops, something went wrong.
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 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.
nit, we could use CRTP for this idiom, like
so we don't need to repeat this method for every class that needs to be printed in the new logging system.
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.
Yes that would make sense. OTOH this comment suggests to use a
str()
method instead of relying on the implicitoperator std::string()
to avoid surprises. What are your thoughts?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.
i am also for the str()
method
, or at least make theoperator std::string
explicit, like. @mogeb have you considered reusing a single trace point everywhere and send the fmt string to it, i.e. use it as an alternative of
syslog(3)
without the...
parameters. if we are fine with this, we can avoid all these troubles. but the downside of this apporach.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.
@tchaikov sure, that's the very first solution I explored (pre-Cephalocon). I initially changed the implementation of
dout()
to just record a tracepoint. With that approach, none of the actual has to be changed. Another alternative could be to use LTTng'stracef()
(similar toprintf
), but it also needs/uses strings.My objective here though is to avoid passing strings around for performance reasons.
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.
Right. I think if the legacy dout lines degenerate into a slow string op, we can focus our efforts on replacing dout calls in the fast path and leave the less frequently-run and slow-path code alone until later (e.g., peering).
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 guys. after re-reading
tracing/tracetool/{README.md,parsetool.py}
, now i understand the objective and rationale behind this design.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.
@mogeb i agree with @liewegas on this. and i was thinking about how to ease the pain to add a logging message in ceph in future. i even explored the possibility to use libclang to parse the source for creating the
.tp
file. with it, we can coin the event name using the filename, and lineno, and deduce the name of argument type from the argument in thetrace_*(...)
expression, so we can extract information interesting to us and create the.tp
,.h
and_impl.h
files for us. but this dependency is kind of heavy weight for us at this moment. probably we can revisit it in future.but, we can always have a compromise here by differentiating following two use cases:
trace_${event_name}(loglevel, subsys, [arg_type, arg_name]...)
, so we don't need to render the values of primitive types in string before passing them to LTTng.trace(loglevel, subsys, fmt_str, [arg]...)
. we can usefmt::format()
offered by libfmt in thepasrsetool.py
. as libfmt is already included by ceph as a submodule. and maketrace()
a template function. which callstracepoint(subsys, ${default_event_name}_at_${log_evel})
, assuming all combinations of${default_event_name}_at_${log_level}
TRACEPOINT_EVENT
s of different${subsys}
s and${log_level}
s combinations have been defined byparsetool.py
. they only have a singleTP_FIELD
.in this way, we can have
what do you think?
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.
I think the clang approach would be great. Sounds good, let's rethink it later as you said.
For having a critical and non-critical paths: just to make sure I understand, the non-critical path uses a formatted string using the arguments'
operator <<()
functions, correct? If that's the case, we could change the implementation ofdout
to record a tracepoint instead of usingtrace(loglevel, subsys, fmt_str, [arg]...)
. This becomes even easier for the developers as nothing changes:dout()
just takes the string passed to it and ends up callingtracepoint()
at the end. I'd need to figure out the details, but I was able to achieve that at the very beginning. Any thought?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.
yes. at this moment, we can use the argument's
operator<<()
, so minimum change is needed. in short and long term, i'd suggest use libfmt'sfmt::format()
instead, it has better performance than that ofstd::iostream
. probably we can expose two more interfacestrace(bluestore, 1, "{0} rock{1}{2}", "ceph", 5, '!');
trace_ceph_rocks(1, bluestore, string, who, "ceph", int, s, 5, uint_8, wow, '!', "%s rock %d%d");
so, i'd suggest start using the
trace()
ortrace_${event_name}
interface in the new code. and replace the implementaion ofdout(1)
for the existing code.