feat(attributes): Add sentry.app.url.domain attribute

[Lms24]

Description

Today, all/most of our url, server or http attributes are interchangeably used to describe incoming and outgoing requests. This is (mostly) in line with OTel's definition. To differentiate, OTel uses span.kind and we use sentry.op (as well as sentry.kind for OTLP AFAIK).

Why do we need yet another URL attribute then?

This PR adds a new attribute to serve a specific purpose: Provide the URL of the instrumented application on every span, regardless of its kind/op. We need this to be able to make Sentry's "filter out events from localhost" inbound filter work. This includes http.client (outgoing request) spans. Their url.* attributes point to the request URL, so we can't set them to the application's URL. There are other spans like this, where we have similar issues (resource spans, db spans to a degree, etc).

Why the sentry.* Prefix?

Initially I wanted to go with app.url.domain, but then saw that OTel defines the app namespace as "attributes related to client-side applications". So I'd prefer not "misusing" this namespace for server-side applications.

Why this specific name?

• url.domain already exists. Prefixing it with sentry.app. means we re-use an established pattern for a more specific purpose.
• We need some kind of prefix but I'm happy to change it if anyone has a better idea

Alternatives considered?

• Having two attributes, one for server, one for client.
  • would work with inbound filters
  • For example: browser.document.url.domain (something similar is in OTel) and http.server.url.domain for the server-side.
  • There's no precedence for this in OTel for the server side, and no server namespace exists for this, that isn't also used in e.g. browser-side outfoing request spans.
  • That being said, this is still an option and we can also use this if anyone prefers
• A very specific "filtering attribute", something like sentry.inbound_filter.url.domain
  • Also an option I'm not opposed to
  • The counter argument is, attributes should describe a concept/semantic, not the purpose for what they are potentially used.

PR Checklist

• I have run yarn test and verified that the tests pass.
• I have run yarn generate to generate and format code and docs.

If an attribute was added:

• The attribute is in a namespace (e.g. nextjs.function_id, not function_id)
• I have used the correct value for apply_scrubbing (i.e. manual or auto. Use never only for values that should never be scrubbed such as IDs)

If an attribute was deprecated:

• I've followed the policies described in CONTRIBUTING.md

[github-actions]

Semver Impact of This PR

🟡 Minor (new features)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

New Features ✨

Attributes

• Add sentry.app.url.domain attribute by Lms24 in #636

• Add cache.item_age and cache.tags by s1gr1d in #637

Bug Fixes 🐛

• (attributes) Remove accidentally merged attribute transformation by Lms24 in #638

Other

• release: 0.23.0 by Lms24 in cbb53e98

---

_{🤖 This preview updates automatically when you update the PR.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 9ed996d. Configure here.}

[buenaflor]

lgtm, I don't have a strong opinion on the naming but given the constraints I think it is the "lesser evil" like you described