You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Essentially what's happening is the receiver sets the resource attributes based on the first row, and all following rows are given the same resource attributes. However, this is a bug as the database_name, a resource attribute, changes for different rows. The result is that all of the metrics are simply considered to be a part of the first database name, rather than their correct value.
There could be two main ways to fix this:
Emit the given resource on each row. This will be the least impactful option, but results in multiple resource metrics having the same resource attributes.
Create an in-memory data structure to represent the resource attributes, and deduplicate when going row-by-row. The logic would be considerably more complicated, but it would result in a single resource metric for a set of resource attributes.
My general preference would be to go with option number 1 as it's simpler and less prone to errors, but I'm not sure if this breaks the required format of emitted metrics.
Note: This is a result of #30297, and only relevant for direct connection configurations.
The text was updated successfully, but these errors were encountered:
I've posted #35038 implementing my proposed approach option 1. View the updated testdata files to see the resulting resources. I'd appreciate input on whether this is the right or wrong approach to solve this bug.
…pen-telemetry#35038)
**Description:** <Describe what has changed.>
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
As explained in the bug description, the receiver was incorrectly
setting the database name resource attribute based on the first row
returned from the query. The returned rows may have different database
names, which means metrics were being labeled as being from the wrong
database.
**Link to tracking Issue:** <Issue number if applicable>
Fixesopen-telemetry#35036
**Testing:** <Describe what testing was performed and which tests were
added.>
Updated tests for new expected resource metrics. View changed
`testdata/` files to see changed output.
Component(s)
receiver/sqlserver
Describe the issue you're reporting
The bug is here:
opentelemetry-collector-contrib/receiver/sqlserverreceiver/scraper.go
Line 136 in 55482cb
Essentially what's happening is the receiver sets the resource attributes based on the first row, and all following rows are given the same resource attributes. However, this is a bug as the
database_name
, a resource attribute, changes for different rows. The result is that all of the metrics are simply considered to be a part of the first database name, rather than their correct value.There could be two main ways to fix this:
My general preference would be to go with option number 1 as it's simpler and less prone to errors, but I'm not sure if this breaks the required format of emitted metrics.
Note: This is a result of #30297, and only relevant for direct connection configurations.
The text was updated successfully, but these errors were encountered: