tracing: add new ability to customize span operation with formatter#42303
tracing: add new ability to customize span operation with formatter#42303wbpcode merged 18 commits intoenvoyproxy:mainfrom
Conversation
Signed-off-by: wbpcode <wbphub@gmail.com>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
|
cc @zirain |
Signed-off-by: wbpcode <wbphub@gmail.com>
|
/retest |
… dev-span-operation
|
/retest |
| } | ||
|
|
||
| EXPECT_CALL(config, modifySpan(_)).WillOnce(Invoke([this](Span& span) { | ||
| EXPECT_CALL(config, modifySpan(_, _)).WillOnce(Invoke([this](Span& span, bool) { |
There was a problem hiding this comment.
FYI (no need for a change here but you can if you want), when doing an EXPECT_CALL with all the args wildcarded, you can just do
EXPECT_CALL(config, modifySpan)
instead of
EXPECT_CALL(config, modifySpan(_, _))
which can sometimes make this sort of update require fewer touches. In this case it wouldn't help much because the action invokes a function anyway so you'd have to change the args there, but still, slightly less fragile.
There was a problem hiding this comment.
I never learned this before. Good suggestion.
| if (operation_ != nullptr) { | ||
| return makeOptRef<const Formatter::Formatter>(*operation_); | ||
| } | ||
| return OptRef<const Formatter::Formatter>(); |
There was a problem hiding this comment.
I think this block (and same for upstreamOperation below) could just be return makeOptRefFromPtr(operation_.get());
| - source/common/event/file_event_impl.cc | ||
| - source/common/http/async_client_impl.cc | ||
| - source/common/grpc/google_async_client_impl.cc | ||
| - source/common/tracing/tracer_config_impl.h |
There was a problem hiding this comment.
Could you move the implementation of the ConnectionManagerTracingConfig constructor into a cc file so that this exception is legitimate here? (Also because it's grown to be a pretty big constructor to be implemented in a header file.)
Otherwise the exception should be in the block above labeled
# Header files that can throw exceptions. These should be limited; the only
# valid situation identified so far is template functions used for config
# processing.
(Even better would be to do the StatusOr thing and the validation in the function that calls the constructor and transform it to an exception a little bit further up the callstack where things are already thrown, so that a new exception isn't needed.)
… dev-span-operation
Signed-off-by: wbpcode <wbphub@gmail.com>
… dev-span-operation
Signed-off-by: wbpcode <wbphub@gmail.com>
Signed-off-by: wbpcode <wbphub@gmail.com>
… dev-span-operation
Signed-off-by: wbpcode <wbphub@gmail.com>
Signed-off-by: code <wbphub@gmail.com>
|
/retest |
… dev-span-operation
…/envoy into dev-span-operation
|
/retest |
|
gently ping @adisuissa for an API review. |
adisuissa
left a comment
There was a problem hiding this comment.
Thanks!
Overall API lgtm. Left some minor comments
| enum OperationName { | ||
| // The HTTP listener is used for ingress/incoming requests. | ||
| INGRESS = 0; | ||
| INGRESS = 0 [deprecated = true, (envoy.annotations.deprecated_at_minor_version_enum) = "3.0"]; |
There was a problem hiding this comment.
These changes are not needed. If there was a field using the enum, it should've been deprecated. The not-implemented-hide is sufficient.
There was a problem hiding this comment.
Coming to think about it again, if this enum isn't used anywhere, what will be the implications of removing that completely?
There was a problem hiding this comment.
Coming to think about it again, if this enum isn't used anywhere, what will be the implications of removing that completely?
We rarely remove API and only mark it as un-implemented and deprecated to ensure it will not be used again. But, yeah, maybe not-implemented-hide is sufficient.
There was a problem hiding this comment.
I was also going to suggest removing it completely (since the field that used it has been removed completely), but the enum is still used in code. I think probably those usages should be cleaned up too, but that seems like a followup thing rather than something to include in this PR.
| // | ||
| // The same :ref:`format specifier <config_access_log_format>` as used for | ||
| // :ref:`HTTP access logging <config_access_log>` applies here, however | ||
| // unknown specifier values are replaced with the empty string instead of ``-``. |
There was a problem hiding this comment.
OOC why is there an edge case here with replacement value for unknown specifier?
If this is for backwards compatibility, SGTM.
However, if this is something that is added because the implementation is a bit different, then I think the argument of keeping a consistent replacement strategy may outweigh the implementation complexity cost. (the main reason is that if someone has a tool that looks at traces and looks for those "-" that are now an empty string, it makes their tools harder to maintain).
There was a problem hiding this comment.
It's not a new behavior. Except the access log, in all other substitution formatters (header mutation, custom tag, and so on), unknown specifier values are replaced with the empty string instead of -. Even the comment self, I copied it from header mutation/custom tag. 🤣
There was a problem hiding this comment.
yeah, you have more context on formatter features than I do.
Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: code <wbphub@gmail.com>
…3/http_connection_manager.proto Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: code <wbphub@gmail.com>
Signed-off-by: wbpcode <wbphub@gmail.com>
|
/retesst |
|
/retest |
| // | ||
| // The same :ref:`format specifier <config_access_log_format>` as used for | ||
| // :ref:`HTTP access logging <config_access_log>` applies here, however | ||
| // unknown specifier values are replaced with the empty string instead of ``-``. |
There was a problem hiding this comment.
yeah, you have more context on formatter features than I do.
|
/retest |
1 similar comment
|
/retest |
… dev-span-operation
|
/retest |
|
friendly ping another approval cc @ravenblackx 🌷 |
…nvoyproxy#42303) Commit Message: tracing: add new ability to customize span operation with formatter Additional Description: To close envoyproxy#42288 Risk Level: low. Testing: unit. Docs Changes: n/a. Release Notes: added. Platform Specific Features: n/a. --------- Signed-off-by: wbpcode <wbphub@gmail.com> Signed-off-by: code <wbphub@gmail.com> Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: MayorFaj <mayorfaj@gmail.com>
…nvoyproxy#42303) Commit Message: tracing: add new ability to customize span operation with formatter Additional Description: To close envoyproxy#42288 Risk Level: low. Testing: unit. Docs Changes: n/a. Release Notes: added. Platform Specific Features: n/a. --------- Signed-off-by: wbpcode <wbphub@gmail.com> Signed-off-by: code <wbphub@gmail.com> Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: Gustavo <grnmeira@gmail.com>
Commit Message: tracing: add new ability to customize span operation with formatter
Additional Description:
To close #42288
Risk Level: low.
Testing: unit.
Docs Changes: n/a.
Release Notes: added.
Platform Specific Features: n/a.