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

fix(otel): Exporter creating Monitored Resource with task_id for Cloud Run #14923

Merged
merged 2 commits into from
Jan 16, 2025

Conversation

DouglasHeriot
Copy link
Contributor

@DouglasHeriot DouglasHeriot commented Jan 10, 2025

Fixes #14925

When inside a Cloud Run environment, the MonitoredResource in a CreateTimeSeriesRequest to the Cloud Monitoring API does not include the necessary fields for the generic_task resource type, and is rejected.

Also updating the GenericNode mapping to match Golang.


This change is Reviewable

@DouglasHeriot DouglasHeriot changed the title Fix OTel Exporter creating Monitored Resource for Cloud Run. fix(otel): Exporter creating Monitored Resource with task_id for Cloud Run Jan 10, 2025
@DouglasHeriot DouglasHeriot force-pushed the cloudrun branch 2 times, most recently from 7a8688d to 644efe9 Compare January 10, 2025 02:34
@DouglasHeriot DouglasHeriot marked this pull request as ready for review January 10, 2025 08:13
@DouglasHeriot DouglasHeriot requested a review from a team as a code owner January 10, 2025 08:13
@scotthart
Copy link
Member

/gcbrun

Copy link
Member

@dbolduc dbolduc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

The code looks good, although I offered an optional refactor. Unit tests for the new code paths would be nice. Either way, we need to fix the tests that are now broken.

You can run the unit test with:

bazelisk test --test_output=all //google/cloud/opentelemetry:internal_monitored_resource_test

@dbolduc
Copy link
Member

dbolduc commented Jan 15, 2025

/gcbrun

Copy link
Member

@dbolduc dbolduc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To lint/format the code (and make our checkers-pr build pass):

ci/cloudbuild/build.sh -t checkers-pr

@@ -52,7 +52,7 @@ struct AsStringVisitor {

struct OTelKeyMatch {
std::vector<std::string> otel_keys;
absl::optional<std::string> fallback = absl::nullopt;
std::string fallback;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might need to explicitly say std::string fallback = {} for our initializer lists to work

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this works already – std::string default constructs to empty string and the compiler doesn’t complain?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I am not smart enough to tell you why the compiler is complaining. (and only in cmake-based builds 🤷). But it is complaining:

image

e.g. this build: https://github.com/googleapis/google-cloud-cpp/pull/14923/checks?check_run_id=35680003918

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the simplest build to test on is:

ci/cloudbuild/build.sh -t demo-fedora-pr

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like we had to do the same thing (explicitly initialize the field to its default value) when the type was absl::optional<std::string>. 🤷

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah you’re right. Fixed now. Thanks for the build command.

Copy link
Contributor Author

@DouglasHeriot DouglasHeriot Jan 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha, clang-tidy doesn’t like this:

error: initializer for member 'fallback' is redundant [readability-redundant-member-init,-warnings-as-errors]
Step #2:    55 |   std::string fallback = {};

I guess I’ll have to make it ignore this warning? Probably a better solution than ignoring the above -Wmissing-field-initializers warnings. // NOLINT(readability-redundant-member-init)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uuuuuuuggghh...... I just added a commit to silence the compiler warning. I will deal with it later.1

Footnotes

  1. if I feel like it.

@DouglasHeriot
Copy link
Contributor Author

Sorry about the formatting, I think it’s fixed now.

@dbolduc
Copy link
Member

dbolduc commented Jan 15, 2025

/gcbrun

Copy link

codecov bot commented Jan 15, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.91%. Comparing base (5a7ce3b) to head (7f6e884).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #14923      +/-   ##
==========================================
- Coverage   92.92%   92.91%   -0.01%     
==========================================
  Files        2351     2351              
  Lines      210072   210072              
==========================================
- Hits       195204   195197       -7     
- Misses      14868    14875       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Fixes googleapis#14925

When inside a Cloud Run environment, the `MonitoredResource` in a `CreateTimeSeriesRequest` to the Cloud Monitoring API does not include the necessary fields for the `generic_task` resource type, and is rejected.

Should follow the well-tested Golang implementation where the `faas.instance` OTel Resource Attribute is mapped to `MonitoredResource` `task_id`. As the `service.namespace` OTel Resource Attribute is not set by the Resource Detector from within Cloud Run, it should be mapped as an empty string, rather than being left absent.

https://github.com/GoogleCloudPlatform/opentelemetry-operations-go/blob/8da0f42dab085c916987891419461d583a2aa96e/internal/resourcemapping/resourcemapping.go#L153
@dbolduc
Copy link
Member

dbolduc commented Jan 16, 2025

/gcbrun

Copy link
Member

@dbolduc dbolduc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@dbolduc
Copy link
Member

dbolduc commented Jan 16, 2025

/gcbrun

@dbolduc dbolduc merged commit 63bc533 into googleapis:main Jan 16, 2025
72 of 74 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OpenTelemetry on Cloud Run does not include task_id in Monitored Resource
3 participants