[connector/servicegraph] New labels for service disambiguation and identification #31889
Comments
t00mas
added
enhancement
|
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
I understand this wouldn't be a breaking change, right? All the changes are about adding new labels when specific values are specified. |
|
Absolutely, the idea is for this to be fully optional, and about just adding a new label if enabled. Also as an update to the issue, I think the change would only affect adding 1 new label, |
…n extra label for virtual node identification (#32826) **Description:** - A new configuration option `enable_virtual_node_label` is added. When enabled, it will add an extra label to the metrics, `virtual_node`, indicating if the `client` or the `server` was the missing span. **Link to tracking Issue:** [31889](#31889) **Testing:** - Adding tests with `github.com/open-telemetry/opentelemetry-collector-contrib/pkg/golden`. - Testing the addition of `virtual_node` labels to the metrics, as well as `connection_type: virtual_node` (as I think it was untested before). - Also testing extra dimensions regarding client/server attributes. **Documentation:** - Added the new configuration option to the README **Note to reviewers** I have a suspicion that `connection_type: virtual_node` was broken. There was a race condition on `store.Expire` so the expired edges were completing after the metrics were built. I have added a `p.store.Expire()` just at the start of `flushMetrics` to allow these edges to contribute to the metrics. Please advise if you see something wrong with this approach. --------- Signed-off-by: Juraci Paixão Kröhling <[email protected]> Co-authored-by: Juraci Paixão Kröhling <[email protected]>
|
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Component(s)
connector/servicegraph
Is your feature request related to a problem? Please describe.
The
connection_typelabel currently allowsdatabase,messaging_system, andvirtual_nodevalues.For
virtual_nodevalues, there’s no clear distinction between which of the nodes is thevirtual_node(e.g. client vs server), and has to be inferred from other attributes.There’s also the case where just having a value of
databaseormessaging_systemfalls short to identify if it’s also un-instrumented /virtual_node.Describe the solution you'd like
connection_typehad the value ofvirtual_node, generate a new labelvirtual_nodewith a value of eitherclientorserver.2.1. In the cases where
connection_typeis of valuedatabase, surface eitherclient_db_systemorserver_db_systemlabels, with the same value as thedb.systemresource attribute.2.2. In the cases where
connection_typeis of value messaging_system, then surface eitherclient_messaging_systemorserver_messaging_systemlabels, with the same value as the messaging.system resource attribute.Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: