-
Notifications
You must be signed in to change notification settings - Fork 488
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.
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
Clarify that attribute processor does not drop signals #5178
Conversation
@@ -164,6 +164,10 @@ For example, adding a `span_names` filter could cause the component to error if | |||
|
|||
The `exclude` block provides an option to exclude data from being fed into the [action] blocks based on the properties of a span, log, or metric records. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this true?
The `exclude` block provides an option to exclude data from being fed into the [action] blocks based on the properties of a span, log, or metric records. | |
The `exclude` block provides an option to exclude data from being fed into the [action] blocks based on the properties of a span, log, or metric records. Excluded data will be forwarded as-is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is true, but I will add it to the new block that I'm adding now, since clarifying this is the whole purpose of the block. I'm also not sure if readers would know what is meant by "forwarded". I'll change this:
Signals excluded by the
exclude
block will still be propagated to downstream components.
To:
Signals excluded by the
exclude
block will still be propagated to downstream components as-is.
> **NOTE**: Signals excluded by the `exclude` block will still be propagated to downstream components. | ||
> If you would like to not propagate certain signals to downstream components, | ||
> consider a processor such as [otelcol.processor.tail_sampling](../otelcol.processor.tail_sampling/). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
> **NOTE**: Signals excluded by the `exclude` block will still be propagated to downstream components. | |
> If you would like to not propagate certain signals to downstream components, | |
> consider a processor such as [otelcol.processor.tail_sampling](../otelcol.processor.tail_sampling/). | |
{{% admonition type="note" %}} | |
Signals excluded by the `exclude` block are still be sent to downstream components. | |
To prevent specific signals from being sent to downstream components, you can use a processor | |
such as [otelcol.processor.tail_sampling](../otelcol.processor.tail_sampling/). | |
{{% /admonition %}} |
Better to use the admonition shortcode for notes where we can.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ptodev Docs look ok. Are there more changes pending?
Nope! This is all I wanted to add. |
PR Description
There has been some confusion regarding the attributes processor. It contains an
exclude
block, and people sometimes get confused that this means the data will be excluded in downstream components. This is not the case.I mention the tail sampling processor as a processor which can do this. However, it only works for traces. It would have been nice to also point to similar processors for logs and metrics, but I don't think we have such components in Flow at the moment. I think the otel components for dropping metrics and logs are metricstransform processor and probabilisticsampler processor.
PR Checklist