feat: add support for OTel context propagation and harmonized spans (v3.x)

[feywind]

Work in progress, converting the existing OTel support to use context propagation and more finely grained spans.

Fixes #1389

[weyert]

@feywind Any way I can help with progressing this PR?

[feywind]

@weyert Hey, glad to see you're interested :D This is an effort to sync across all the supported languages, so it might be a while before it's fully merged/released. When it's a bit further along though, I'd be interested in testing help, since you're one of the people who's more into OTel usage. This is my main project right now, so I'm hoping I can get a preview branch going soon, at the least.

[weyert]

Awesome happy to try out a preview version when it is available :)

[generated-files-bot]

Warning: This pull request is touching the following templated files:

• .kokoro/continuous/node12/samples-test.cfg - .kokoro files are templated and should be updated in synthtool
• .kokoro/presubmit/node12/samples-test.cfg - .kokoro files are templated and should be updated in synthtool
• .kokoro/samples-test.sh - .kokoro files are templated and should be updated in synthtool

[feywind]

I'm going to go ahead and base this off the 3.x branch to get it merged into that, and then I'll up-port it to 4.x.

[hongalex]

I think we shouldn't do console output and just focus on Cloud Trace as the default sample (since that's also what our open telemetry team's documentation points to).

[SimenB]

any particular reason these are locked down from ^?

[feywind]

Yeah, it had to do with Node 12 compatibility. I found that there were some semver issues, in practice, though I'll be revisiting this for the 4.x version of the PR, so I'll probably recheck these for 3.x too.

approved code changes but still need to review tests

[weyert]

Can't wait for this one to get merged. I have run it locally and works well. I haven't been able to run it in the wild as we had some maddening memory issues but that might have been better

I assume it adheres to the messaging outline of opentelemetry? I have to admit I don't fully understand that one

[feywind]

Can't wait for this one to get merged.

You and I both :)

I have run it locally and works well. I haven't been able to run it in the wild as we had some maddening memory issues but that might have been better

Memory issue caused by the OTel PR or something unrelated?

I assume it adheres to the messaging outline of opentelemetry? I have to admit I don't fully understand that one

Such as it is, yeah. The inner workings of the GCP Pub/Sub libraries are represented in the span layout, but I don't think that's particularly specified by OTel. It's our intent to support the standard span attributes and W3C trace propagation attribute.

TBD if the span structure will be identical across client libraries, like C++ has a different thing going that's based on their method call structure.

Given that the 3.x release machinery is just about going, I'm planning to bring this PR up to the main branch at some point and then back-port the finished one to 3.x.

[weyert]

I have run it locally and works well. I haven't been able to run it in the wild as we had some maddening memory issues but that might have been better

Memory issue caused by the OTel PR or something unrelated?

Oh no, work code related issue. Nothing related to this PR sorry for confusing you.

I assume it adheres to the messaging outline of opentelemetry? I have to admit I don't fully understand that one

Such as it is, yeah. The inner workings of the GCP Pub/Sub libraries are represented in the span layout, but I don't think that's particularly specified by OTel. It's our intent to support the standard span attributes and W3C trace propagation attribute.

TBD if the span structure will be identical across client libraries, like C++ has a different thing going that's based on their method call structure.

Yeah, I understood their is this messaging semantic convention they are working on, like https://github.com/open-telemetry/semantic-conventions/blob/main/docs/messaging/messaging-spans.md

Makes sense the span structure is the same structure between libraries :))

Given that the 3.x release machinery is just about going, I'm planning to bring this PR up to the main branch at some point and then back-port the finished one to 3.x.

Makes sense but to be honest I can also fully understand it's a v4 thing

[feywind]

Will re-open this later when the 4.x one is done.

[feywind]

I didn't plan it this way 😹 but it's past the year support window for 3.x, and a lot of changes have happened since OTel started, so I won't be doing this back-porting work.