-
Notifications
You must be signed in to change notification settings - Fork 417
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
[SDK] support for the new OTel log API #2123
[SDK] support for the new OTel log API #2123
Conversation
}; | ||
|
||
template <> | ||
struct LogRecordSetterTrait<int64_t> |
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.
Is it conflicted with Body?Log body can also be converted from int64_t
implicitly.
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, thanks for the catch. Seems the template part of filling logging record requires each parameter to be in different type, and the any
type on body make it conflict with other parameters. Do you have any suggestion for this problem?
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 have no idea for this problem by now, and I only avoided to specialize templates for these types before.
Maybe we can add a unit test to check the mistake.
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 removed the passing of int64_t to SDK, instead, a temporary EventId struct will be constructed which should fix the issue.
For unittest, do you mean to cover all the variant types of body
field?
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, use EmitLogRecord to cover all the variant types of body field.
Maybe we can also add it in another PR 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.
FYI, I added an integration test to cover if the EventId passed to the user-facing API is passed correctly to the SDK.
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.
LGTM. Thanks
* @param id the event Id to set | ||
* @param name the event name to set | ||
*/ | ||
void SetEventId(int64_t /* id */, nostd::string_view /* name */) noexcept override |
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.
Sorry but did I miss anything? I can find any specification about event id in OTLP, should we add it just like semantic convention for event 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.
Yes, the idea is adding it as attribute to OTLP recordable, mark it as TODO for now.
@owent please let me know if there is any comments I missed. |
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.
Sorry for the delay, LGTM.
Fixes #2122
Changes
Please provide a brief description of the changes here.
For significant contributions please make sure you have completed the following items:
CHANGELOG.md
updated for non-trivial changes