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
Is your feature request related to a problem? Please describe.
While signals can be included/excluded from the attributes processor, there is no similar option in the resource processor. This can be inconvenient at times if there are some signals that need to have their resource attributes updated, but other signals that need to preserve their original resource attributes.
Describe the solution you'd like
It would be nice if the resource processor config allowed using include/exclude matching from the attributes processor.
Describe alternatives you've considered
A workaround to this is by configuring one signal pipeline which includes the resource processor, and another pipeline which does not include the resource processor. The signals that need resource attribute processing would be ingested from one receiver, and those that do not need it from a different receiver.
This causes some duplicated configuration and requires a client-side change (which sends data to the collector) to use a different receiver port, which is not ideal,
The resource processor works at the resource level, and the include/exclude is going to apply at the span or metric level. You can't really apply those things together.
An example is to use the services include filter, which is going to add an attribute based on the span service.name attribute. That doesn't work well unless all your spans have the same service name.
Workaround: use the attributes processor, and apply groupbyattrs processor to group batches back together and move attributes to the resource.
The resource processor works at the resource level, and the include/exclude is going to apply at the span or metric level. You can't really apply those things together.
An example is to use the services include filter, which is going to add an attribute based on the span service.name attribute. That doesn't work well unless all your spans have the same service name.
Workaround: use the attributes processor, and apply groupbyattrs processor to group batches back together and move attributes to the resource.
Understood, I think I need to read up a bit more on how OpenTelemetry resources work in the official docs. I will also give the workaround a try. Thank you for the help!
Component(s)
processor/resource
Is your feature request related to a problem? Please describe.
While signals can be included/excluded from the attributes processor, there is no similar option in the resource processor. This can be inconvenient at times if there are some signals that need to have their resource attributes updated, but other signals that need to preserve their original resource attributes.
Describe the solution you'd like
It would be nice if the resource processor config allowed using include/exclude matching from the attributes processor.
Describe alternatives you've considered
A workaround to this is by configuring one signal pipeline which includes the resource processor, and another pipeline which does not include the resource processor. The signals that need resource attribute processing would be ingested from one receiver, and those that do not need it from a different receiver.
This causes some duplicated configuration and requires a client-side change (which sends data to the collector) to use a different receiver port, which is not ideal,
See the below example:
Additional context
No response
The text was updated successfully, but these errors were encountered: