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!