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

logging: OpenTelemetry spans are ignored as parents for LogRecords #1490

Open
cindy-peng opened this issue Feb 6, 2024 · 1 comment · May be fixed by #1497
Open

logging: OpenTelemetry spans are ignored as parents for LogRecords #1490

cindy-peng opened this issue Feb 6, 2024 · 1 comment · May be fixed by #1497
Assignees
Labels
api: logging Issues related to the googleapis/nodejs-logging API. priority: p3 Desirable enhancement or fix. May not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@cindy-peng
Copy link
Contributor

cindy-peng commented Feb 6, 2024

Tracking the same issue as 9302 to propagate correct TraceId and SpanId for logging and tracing correlation.

Client

nodejs-logging

Context

In nodejs-logging libraries, the current implementation will always use a remote trace ID and span ID parsed from HTTP headers that originate from outside the application:

export function getOrInjectContext(

As a result, logs are associated with the parent span rather than the span of interest.

Expected behavior

If the user is using opentelemetry instrumentation, we want to use the traceID and spanID of the span that OpenTelemetry created. This way, when a user looks for logs associated with that span, the logs produced by this logging library will appear.

@cindy-peng cindy-peng added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Feb 6, 2024
@product-auto-label product-auto-label bot added the api: logging Issues related to the googleapis/nodejs-logging API. label Feb 6, 2024
@cindy-peng cindy-peng added priority: p3 Desirable enhancement or fix. May not be included in next release. and removed priority: p2 Moderately-important priority. Fix may not be included in next release. labels Feb 6, 2024
@cindy-peng
Copy link
Contributor Author

cindy-peng commented Feb 12, 2024

To fix this issue in nodejs logging repo, @dashpole suggested importing OpenTelemetry Api and using nodejs spanContext to retrieve current traceId and spanId:googleapis/google-cloud-go#9302 (comment)

@aabmass David mentioned that you may help review the fixes for nodejs and java. I added the following logic to retrieve spanContext locally and it seemed working fine locally:

import { trace, context, isSpanContextValid} from '@opentelemetry/api';
import { isTracingSuppressed } from '@opentelemetry/core';

   const activeContext = context.active();
    const spanContext = trace.getSpanContext(activeContext);

    if (spanContext != undefined && isSpanContextValid(spanContext) && !isTracingSuppressed(activeContext)) {
      const otelSpanContext = {
        trace: spanContext?.traceId,
        spanId: spanContext?.spanId,
        traceSampled: spanContext?.traceFlags === 1,
      };
    }

I am wondering if you can help with a couple of questions:

  1. is context.active() the correct way to get the current active context and we can then use it to retrieve spanContext? It's mentioned that context.active() will work only with context Manager configured, otherwise it will always return ROOT_CONTEXT: https://opentelemetry.io/docs/languages/js/context/#active-context
    Do we need to configure context Manger in that case?

  2. Do you think we need to validate !isTracingSuppressed(activeContext) as well? Looks like this is introduced from opentelemetry-core

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: logging Issues related to the googleapis/nodejs-logging API. priority: p3 Desirable enhancement or fix. May not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
1 participant