Add cloud resource context

[smeubank]

Problem Statement

When a user gets an error or transacation (performance event) in Sentry they may not know the specific of where that particular service is hosted. Where possible it would be great to know some contextual information about where that service is hosted to speed up problem solving and eventually deploying a fix

example data

cloud:
  provider: aws|gcp|azure
  region: ...
  [account|project]_id: ...
  service: ec2, cloud-functions, ...
  resource: <ARN>

Solution Brainstorm

Add this data using the Contexts Interface of the event payload

• Define a standard set of contextual data:
  • example above
• determine how to fetch that data from top hosting platforms
  • AWS
  • GCP
  • Azure
  • Vercel
  • Netlify
  • others?
• Python SDK should check for this context and populate it in the event when possible
• relay changes needed prior to

Future considerations:

• contexts should be searchable in product, changes will be needed in sentry backend so this data can be used to filter issues

[mwarkentin]

Netlify Functions doesn't support Python so we can remove that from the list:

Netlify Functions are files you write in JavaScript, TypeScript, or Go ...

Some other platforms to consider:

• Heroku
• Render
• Fly.io

[sl0thentr0py]

Resources (will update as I find more):

• GCP opentelemetry resource detector uses GCP metadata querying

[mwarkentin]

AWS has similar: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

[AbhiPrasad]

In OpenTelemetry they have the resource entity, which represent the env that produces a set of telemetry data: https://opentelemetry.io/docs/reference/specification/resource/semantic_conventions/

We can model our solution after this.

[antonpirker]

Here the PR for develop docs of cloud hosting context: getsentry/develop#825

[antonpirker]

For AWS stuff to keep in mind:

• EC2 uses the above mentioned instance metadata API
• for our AWS Lambda integration this should not be done, because making HTTP request on every lambda execution is too slow. But we can probably just read some env vars in our AWS Lambda layer we deploy to get most of the information.
• AWS ECS (and thus fargate) have a different api: https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-metadata-endpoint-fargate.html
• Amazon EKS (hosted kubernetes) supports the same instance metadata API as linked above.

When we have this, I think we covered AWS.

Note: maybe some documentation changes for AWS Lambda setup without our layer are needed.

[antonpirker]

Open question: how to auto detect if the cloud context should be added?

[mwarkentin]

Default lambda env vars: https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html#configuration-envvars-runtime

[antonpirker]

This is now the data we get from AWS EC2:

And this is the data we get from GCE:

[antonpirker]

Just fyi @mwarkentin : We will start with "only" ECS and GCE to be supported. The implementation is a CloudContextIntegration the users have to add to the sentry_sdk.init(integrations=[...]) list by hand for the cloud context to be added.