feat(gcp-detector): add Cloud Run support with faas.* and cloud.platform

[kaspernissen]

Which problem is this PR solving?

The resource detector for gcp did not previously support Cloud Run–specific resource attributes, although these are supported in other SDKs (e.g. Go, Java). This PR adds support for setting the faas.* along with cloud.platform resource attributes when running in a Cloud Run environment.

Short description of the changes

• Detects faas.name from K_SERVICE environment variable.
• Detects faas.version from K_REVISION environment variable
• Detects faas.instance from GCP metadata server (/instance/id) reusing the existing method.
• Sets cloud.platform using the semantic conventions static variables.
• Adds unit test for Cloud Run detection, following existing patterns
• Keeps full backward compatibility and aligns behavior with the Go SDK implementation (using env vars)

For more information, see the container runtime contract: https://cloud.google.com/run/docs/container-contract#env-vars.

This is my first PR 🙏

I've added another PR for the extension of the assertCloudResource helper with cloud.platform. For now just manually asserting in the test case.

[mmanciop]

I am looking forward to seeing this merged :-)

[pichlermarc]

cc @punya and @aabmass (component owners)

[punya]

I am no longer working in this area, @aabmass could you please take a look, and also update component owners?

[david-luna]

@aabmass could you have a look at this one? I could volunteer to review it but I think you feedback would be better

[aabmass]

Hey, apologies for the confusion. We have already implemented this in @google-cloud/opentelemetry-resource-util detector.

I would actually like to make the resource detector here in contrib just re-expose the one from @google-cloud/opentelemetry-resource-util: GoogleCloudPlatform/opentelemetry-operations-js#518

I previously discussed this with the maintainers and it wasn't contentious but haven't found the time to do it. To recap, the reason to use it as a library vs copying the code is that we have a bunch of integration tests that would be really difficult to move to this repo.

[kaspernissen]

Thanks for the update and for clarifying the intent to centralize this logic in the @google-cloud/opentelemetry-resource-util package, @aabmass. I can see the benefits in terms of reusing test infrastructure and avoiding code duplication.

That said, I’d like to raise a few points for consideration - especially as someone who's still relatively new to the inner workings of this project.

From the outside, it feels a bit problematic that Cloud Run support isn't discoverable or available out-of-the-box when using the standard auto-instrumentation entry point (e.g., node --require '@opentelemetry/auto-instrumentations-node/register' app.js). This is something that’s been on the radar for over two years, so I’m just wondering a bit about the timeline and when it’s likely to get done. In the meantime, keeping the detector implementation in a vendor-specific package feels like it limits visibility and adoption - especially for new users who expect OpenTelemetry to “just work” for major platforms like Cloud Run.

I’m also trying to better understand whether the broader architectural goal for this repo is to become a collection of thin wrappers around vendor-specific detectors, or whether upstream detectors are still expected to house meaningful logic directly. If the former, what’s the long-term vision for user experience and cross-SDK consistency? For example, the Go SDK includes Cloud Run detection directly.

I don’t mean to push back unnecessarily - just trying to better understand the direction and see if there’s a path forward that balances reuse with user experience and visibility. Would love to hear your thoughts on how we might reconcile these concerns.

[dyladan]

I’m also trying to better understand whether the broader architectural goal for this repo is to become a collection of thin wrappers around vendor-specific detectors, or whether upstream detectors are still expected to house meaningful logic directly.

We actually talked about this at the JS SIG meeting last week. We really don't want to be in the situation where we're publishing thin wrappers around code we don't control or understand. At the same time, we don't really have the bandwidth to maintain instrumentations for every possible module, service, and app. It is much easier for us as maintainers if these are externally hosted. Ideally, we would be able to load these automatically with the SDK if the user installs them, but right now there is no such mechanism for that automation. It's been something we've talked about periodically though. Some things like ESM complicate this story even further. The other advantage of having things in this repo is discoverability. There is a registry to solve this problem, but I think it isn't particularly well used or known by users.

[kaspernissen]

Thank you, @dyladan for the explanation. I saw in the meeting notes that this PR was actually discussed 🙈 I’ll try to start joining the JS SIG meetings to stay more in the loop.

I totally get that this is a tradeoff - and I understand the concern about maintaining wrappers for code the SIG doesn’t directly own. At the same time, it does feel like we’re missing out on visibility and adoption when commonly expected detectors (like for Cloud Run) aren’t available through the default experience, especially in something like @opentelemetry/auto-instrumentations-node.

I also checked the registry, but I don’t see the GCP resource detector listed there - which might contribute to the discoverability issue for new users.

I’d be happy to try and help push this forward in some way - though, like everyone else, I also have limited bandwidth (and knowledge in this area). But if there’s something small I can do to help improve the situation, I’m definitely open to it.

Thanks again for the context - and for all the work you’re doing on this!

[dyladan]

I think at a minimum you should add your detector to the registry. We're discussing ways to make a more automated experience for non-otel-hosted packages, but so far nothing is implemented. I'll try to keep you updated but I don't have a lot more on that right now. For now, it's up to you if you want to maintain both packages, but I don't think we're likely to accept a thin wrapper in this repo without further discussion.

On a somewhat related note, this package currently supports SDK 2.0 and it looks like the GCP-hosted one only supports SDK 1.0

[aabmass]

Thanks for the discussion. I can try to join next Wednesday if you'd like to discuss again, or I'll just pay closer attention here.

I agree there are pro/cons to each approach. Unfortunately GCP resource detection is just kind of complicated–we would either depend on gcp-metadata, or have to re-implement metadata fetching regardless of where the OTel logic lives.

For example, the Go SDK includes Cloud Run detection directly.

If you look closely, the GCP detector for Go does something pretty similar (Java too) but the implementation of the actual interface is still in the contrib repo. Daniel, would a similar level of logic split between a GCP repo and here be reasonable to you?

[aabmass]

Quick update, I would be happy to just move the resource detector code we have in the Google repo directly into this package. We can do integration tests out of tree.

@dyladan does that sound OK to you?

[dyladan]

I almost feel like this needs input from GC/TC or something. I wish there was a way we could solve the discoverability and automatic setup for external packages. Might have to finally start eating that elephant.

[aabmass]

We discussed in the JS SIG on Wed July 23rd. The decision was to move the Google repo code into this package. I'll send a PR and we can close this one at that point.

I will also take a shot at avoiding the gcp-metadata dependency to see if we can reduce the dependency burden and make dual bundling easier. Thank you all for your patience!