Skip to content
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

feat(contrib/opentelemetry): add TraceID and SpanID fields to the logger #1232

Merged
merged 1 commit into from
Sep 18, 2023
Merged

Conversation

mlcdf
Copy link
Contributor

@mlcdf mlcdf commented Sep 11, 2023

Hello :)

What was changed

This PR adds the TraceID and the SpanID to the logger fields.

Why?

From the opentelemetry spec:

It is a standard practice to record the execution context (trace and span ids as well as user-defined context) in the spans. OpenTelemetry extends this practice to logs where possible by including TraceId and SpanId in the LogRecords. This allows to directly correlate logs and traces that correspond to the same execution context. It also allows to correlate logs from different components of a distributed system that participated in the particular request execution.

Checklist

  1. How was this tested:

I added a test to make sure the fields are indeed present.

To test this, I needed a logger that could fill the log.Logger and I didn't wanted to add an extra dependency or roll out my own. So I relied on the new slog package (that's why I had to create new file and add the build annotation). Let me know if it's ok for you.

  1. Any docs updates needed?

I'm not sure.

@mlcdf mlcdf requested a review from a team as a code owner September 11, 2023 15:07
@CLAassistant
Copy link

CLAassistant commented Sep 11, 2023

CLA assistant check
All committers have signed the CLA.

}

logger = log.With(logger,
"TraceID", span.SpanContext().TraceID(),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if I should call HasTraceID/HasSpanID first

I'm not sure when they would be empty

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add an IsValid() check If this is a concern. I don't believe this function will get called if ref is not valid

@Quinn-With-Two-Ns
Copy link
Contributor

@mlcdf Thanks for the contribution! looks good to me. @cretz any comments?

Copy link
Contributor

@Quinn-With-Two-Ns Quinn-With-Two-Ns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll leave open for a couple days before merging if @cretz has any comments

Copy link
Member

@cretz cretz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

I would originally be hesitant to add log multiple tags to all existing logs, but this is a good case for doing it and I can't see a good enough reason to provide an opt-out at this time.

@cretz cretz merged commit f1d6480 into temporalio:master Sep 18, 2023
6 checks passed
@mlcdf
Copy link
Contributor Author

mlcdf commented Sep 18, 2023

When may I expect a new release of the sdk?

@cretz
Copy link
Member

cretz commented Sep 18, 2023

No exact time, but hopefully soon. In the meantime, you can depend on this commit (or go get + @master) in your go.mod.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants