Automatic integration with OpenTelemetry

[domdomegg]

Is your feature request related to a problem? Please describe.

When setting up my tracing and logging following the Google Cloud documentation in the recommended way for Node.js, they don't appear to integrate with each other.

The docs recommend using OpenTelemetry for traces, and this seems to be a nice standards-based way to collect trace data:

• https://cloud.google.com/trace/docs/setup states 'Use OpenTelemetry and the associated Cloud Trace client library. This is the recommended way to instrument your applications.'
• https://cloud.google.com/trace/docs/setup/nodejs-ot is the page under OpenTelemetry > Node.js. It sets up OpenTelemetry with @google-cloud/opentelemetry-cloud-trace-exporter.

Describe the solution you'd like

The logging library works out of the box with OpenTelemetry, set up in the way recommended by the Google Cloud documentation.

There's straightforward docs which guide the user on how to set up logging and tracing, such that logs go to Google Cloud Logging and traces go to Google Cloud Trace and they integrate with each other.

Additional context

OpenTelemetry was previously mentioned in #597, but I couldn't quite follow what that was requesting. The docs from the PR suggest one might have to override certain properties to get tracing working - this should work out of the box.

[dschnare]

Yeah I found this too. I had to use the special keys on the info object.

I have also found that I have a big problem with timestamps of the log entry not being within the span. I have a transporter that writes to the console and another transporter that integrates with Cloud Logging. The console reports timestamps of each log entry such that each log occurs within the span. However, in Cloud Logging the timestamps are inflated by around 200ms so they are pushed outside the span, so when you click the "View Logs" link from Cloud Trace, no log entries are ever found, and no dots are shown on the span bar in the timeline. It's so frustrating. I can "remedy" the situation by adding an artificial delay just before responding to the HTTP request by say 500ms.

[Apokalypt]

@dschnare Did you find any solutions ? I'm facing the same issue regarding the delay visible in the timestamps

EDIT: I just found a solution when looking on the code of nodejs-logging-winston. To be sure that the timestamp is "valid" you need to provide it in the metadata (make sure it's an instance of Date)

    const date = new Date();
    logger.info(`test log - ${date.toISOString()}`, {
        [LoggingWinston.LOGGING_TRACE_KEY]: `projects/${'mod-glitch-dev'}/traces/${span.spanContext().traceId}`,
        [LoggingWinston.LOGGING_SPAN_KEY]: span.spanContext().spanId,
        timestamp: date
    });