-
Notifications
You must be signed in to change notification settings - Fork 394
Return string for trace_id
and span_id
from Correlation::Identifier
#3322
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
Changes from all commits
92fbc34
2735aea
5849dc8
996bba3
c8bf1dc
988934b
48c8b77
5e1a480
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,6 +6,8 @@ module Datadog | |
module Tracing | ||
# Contains behavior for managing correlations with tracing | ||
# e.g. Retrieve a correlation to the current trace for logging, etc. | ||
# This class is for usage with log correlation. | ||
# To continue from a trace, users should use TraceDigest instead. | ||
module Correlation | ||
# Represents current trace state with key identifiers | ||
# @public_api | ||
|
@@ -21,42 +23,21 @@ class Identifier | |
:env, | ||
:service, | ||
:span_id, | ||
:span_name, | ||
:span_resource, | ||
:span_service, | ||
:span_type, | ||
:trace_name, | ||
:trace_resource, | ||
:trace_service, | ||
:version | ||
|
||
# @!visibility private | ||
def initialize( | ||
env: nil, | ||
service: nil, | ||
span_id: nil, | ||
span_name: nil, | ||
span_resource: nil, | ||
span_service: nil, | ||
span_type: nil, | ||
trace_id: nil, | ||
trace_name: nil, | ||
trace_resource: nil, | ||
trace_service: nil, | ||
version: nil | ||
) | ||
# Dup and freeze strings so they aren't modified by reference. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's document that "this class is for usage with log correlation. To continue from a trace, users should use TraceDigest instead." |
||
@env = Core::Utils::SafeDup.frozen_dup(env || Datadog.configuration.env) | ||
@service = Core::Utils::SafeDup.frozen_dup(service || Datadog.configuration.service) | ||
@span_id = span_id || 0 | ||
@span_name = Core::Utils::SafeDup.frozen_dup(span_name) | ||
@span_resource = Core::Utils::SafeDup.frozen_dup(span_resource) | ||
@span_service = Core::Utils::SafeDup.frozen_dup(span_service) | ||
@span_type = Core::Utils::SafeDup.frozen_dup(span_type) | ||
@span_id = (span_id || 0).to_s | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @TonyCTHsu I don't remember: why are we converting the numbers to strings? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @marcotc's question suggests that we should include that in the release notes somewhere. Apparently, Ruby integers can natively handle 128-bit numbers, so I agree. It's not clear why we need to convert them to strings. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Is that the only supported use for the return value? This is part of the public API, so should we be considering more generic usage? Generally speaking, I don't think public API methods should be too opinionated on what is done with their return values (within reason) and we should be returning values as the types that best reflect what they are. This contributes to an API being predictable and intuitive for an engineer to use. If I know It should be the responsibility of the calling method to convert it to a string and/or encode it a particular way unless we have a good reason to do otherwise. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ekump we have the method There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here an interesting bit, OTel uses 128-bit trace ids as well, but it represents them as 16-char strings. |
||
@trace_id = trace_id || 0 | ||
@trace_name = Core::Utils::SafeDup.frozen_dup(trace_name) | ||
@trace_resource = Core::Utils::SafeDup.frozen_dup(trace_resource) | ||
@trace_service = Core::Utils::SafeDup.frozen_dup(trace_service) | ||
@version = Core::Utils::SafeDup.frozen_dup(version || Datadog.configuration.version) | ||
end | ||
|
||
|
@@ -90,13 +71,12 @@ def to_log_format | |
end | ||
end | ||
|
||
# DEV-2.0: This public method was returning an Integer, but with 128 bit trace id it would return a String. | ||
def trace_id | ||
if Datadog.configuration.tracing.trace_id_128_bit_logging_enabled && | ||
!Tracing::Utils::TraceId.to_high_order(@trace_id).zero? | ||
Kernel.format('%032x', @trace_id) | ||
else | ||
Tracing::Utils::TraceId.to_low_order(@trace_id) | ||
Tracing::Utils::TraceId.to_low_order(@trace_id).to_s | ||
end | ||
end | ||
end | ||
|
@@ -113,14 +93,7 @@ def identifier_from_digest(digest) | |
|
||
Identifier.new( | ||
span_id: digest.span_id, | ||
span_name: digest.span_name, | ||
span_resource: digest.span_resource, | ||
span_service: digest.span_service, | ||
span_type: digest.span_type, | ||
trace_id: digest.trace_id, | ||
trace_name: digest.trace_name, | ||
trace_resource: digest.trace_resource, | ||
trace_service: digest.trace_service | ||
) | ||
end | ||
end | ||
|
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.
@TonyCTHsu Hi there, may I ask the reason these fields are removed? Reason I asked was because we use them in our semantic logger formatter to enrich the log so that we can view the logs by resource or service.
Is it possible to add them back or is there away for correlation to retrieve trace details so we can continue to enrich our log?
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.
@kloktech-mark I think you will get a better answer to your question if you create a new issue (https://github.com/DataDog/dd-trace-rb/issues/new/choose).