Skip to content

STAC-25469: map all span attrs #15

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.

Sign up for GitHub

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

Closed
deontaljaard wants to merge 2 commits into from
Closed

STAC-25469: map all span attrs #15

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f9042a2
STAC-25469: map all span attrs
deontaljaard Aug 4, 2026
ea428d1
STAC-25469: bump version
deontaljaard Aug 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions stackpacks/open-telemetry/settings/component-mappings/databases.sty
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -99,8 +99,8 @@ nodes:
pattern: "(.*)"

@rb3ckers rb3ckers Aug 5, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I see we also, already, include all resource attributes (on the original otel stackpack we only had a few). I'm still in doubt if that's a good idea or not (a restart will trigger an update because PID, etc will change). In the end I think I actually like it.

@deontaljaard deontaljaard Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good observation. Tbh, I don't think a lot of deep thought has gone into the tag mappings until now - mostly copy-paste from the first component mapping that was created. With semconv, we should be able to reliably declare fixed tag mapping target/pattern pairs so the mappings/presentations remain stable - we can be selective with the lifecycle attributes like you've pointed out so we don't have "no-op"/heartbeat updates that are unnecessary.

target: "${1}"
- source: "span.attributes"
pattern: "db.(.*)"
target: "db.${1}"
pattern: (.*)"
target: "${1}"

@rb3ckers rb3ckers Aug 5, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Won't this pull in way too many attributes? These spans can also contain attributes with the SQL query template as value (this was already a problem with db.* I realize now), so would result in tons of updates to the component (every database call might trigger an update now).

@deontaljaard deontaljaard Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

A valid concern, but not that many from what I've observed. I first added more pattern/target pairs for server.* and net.*, but then thought we could be missing other useful info while still in this "maturing" phase.

An alternative is to have a specific tag map of all the attributes we want (covering legacy and new attributes), but then they need to go under optional. But since db attributes could theoretically change, I'm not sure we want to be that restrictive right now.

@rb3ckers rb3ckers Aug 5, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Copying in all attributes can have much worse effects: it triggers updates to the component (and change events) for potentially every span that comes in (which can be every query that is executed, so hundreds or more per second). This will eat up resources (processing and disk)

Look at our own HBase for example (this one I hadn't even expected): it has an attribute with the thread name, which looks like a fork-join pool that has a counter for each new thread it creates.

https://stackpacks2.dev.stackstate.io/#/components/urn:opentelemetry:namespace%2Fsuse-observability-branch-master:service%2Fstackstate-server:database%2Fdefault/traces?rightPane=hidden-0__active_tab-selection__chain-span%3Ae4c1f115250e3fd14be585a940c1cd60%3A2407d93398682931%3A2407d93398682931&timeRange=1785903072844_1785913872844&timestamp=1785913872844.

Thinking more about this, for the long term we probably need to come up with a protection against this. We can't expect everyone to think through all the consequences either.

@deontaljaard deontaljaard Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Well, not can, has - already observed this while trying out this mapping. Being specific in the tag mappings is necessary it seems.

@deontaljaard deontaljaard Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Regarding the protection: I think it should be doable to extend the existing tag mapping validation with a gate that prevents all attributes to be mapped (for dev/debug purposes it would be nice to disable such a gate).

optional:
tags:
- source: "resource.attributes['k8s.namespace.name']"
Expand Down
4 changes: 2 additions & 2 deletions stackpacks/open-telemetry/settings/presentations/databases.sty
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,13 +103,13 @@ nodes:
order: 84.0
projection:
_type: TextProjection
value: "'net.peer.name' in tags ? tags.singleValue('net.peer.name') : tags.singleValue('server.address')"
value: "'server.address' in tags ? tags.singleValue('server.address') : tags.singleValue('net.peer.name')"
- fieldId: otel_db_server_port
title: "Server port"
order: 83.0
projection:
_type: TextProjection
value: "'net.peer.port' in tags ? tags.singleValue('net.peer.port') : tags.singleValue('server.port')"
value: "'server.port' in tags ? tags.singleValue('server.port') : tags.singleValue('net.peer.port')"
- fieldId: "k8s_cluster"
title: "K8s Cluster"
order: 77.5
Expand Down
2 changes: 1 addition & 1 deletion stackpacks/open-telemetry/stackpack.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
name: "open-telemetry"
version: "0.1.3"
version: "0.1.4"
schemaVersion: "2.0"
displayName: "Open Telemetry"
categories: [ "Open Telemetry" ]
Expand Down
Loading