[processor/filter] Ensure OTTL configuration provides same features as existing configuration

[TylerHelmuth]

Component(s)

processor/filter

Is your feature request related to a problem? Please describe.

The OTTL package is being added to the filterprocessor to support generic filtering of spans, span events, metrics, data points, and log records. To simplify the filterprocessor and its config, I propose that only the OTTL is needed, but before any existing configuration can be deprecated and removed the existing feature set of the processor must be reviewed to ensure that OTTL can handle all existing user situations. Any missing features must be added to the OTTL before this issue can be closed.

Describe the solution you'd like

Filterprocessor feature set is reviewed and it is confirmed that OTTL can handle all existing features.

Feature gaps:

• Support for include statements
• Regex matching where the input is converted to a string if it is a bool, int, or double. [pkg/ottl] update IsMatch to convert bool, double, and int to string. #16434
• OTTL metric conditions support dropping the metric if any of the metrics datapoints have a specific attribute or have a specific attribute with a specific value.

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Pinging code owners:

• processor/filter: @boostchicken

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[TylerHelmuth]

The filterprocessor configuration for spans, metrics, and logs allows for include conditions and exclude conditions.

From the README:

• include: Any names NOT matching filters are excluded from remainder of pipeline
• exclude: Any names matching filters are excluded from remainder of pipeline

The OTTL implementation acts like exclude; if telemetry matches the OTTL condition, then it is dropped.

OTTL Conditions can be written in such a way that include functionality is preserved. Given this filter configuration

processors:
  filter:
    spans:
      include:
        match_type: strict
        services:
          - app_3
      exclude:
        match_type: regexp
        services:
          - app_1
          - app_2
        span_names:
          - hello_world
          - hello/world
        attributes:
          - Key: container.name
            Value: app_container_1
        libraries:
          - Name: opentelemetry
            Version: 0.0-beta
        resources:
          - Key: container.host
            Value: 127.0.0.1

The filter processor will drop any span that does not have a service name of app_3 AND any span with a service name of app_3 that also has a span name of hello_world or hello/world, an attribute of container.name with a value of app_container_1, a scope with a version of 0.0-beta, or a resource attribute name container.host with a value of 127.0.0.1.

This would be written as OTTL statements like:

processors:
  filter:
    traces:
      span:
        - 'resource.attributes["service.name"] != "app_3"'
        - name == "hello_world"
        - name == "hello/world"
        - attributes["container.name"] == "app_container_1"
        - scope.version == "0.0-beta"
        - resource.attributes["container.host"] == "127.0.0.1")'

[TylerHelmuth]

When filtering span, the filterprocessor configuration allows matching by service name, span name, attributes, scopes, resource attributes, and span kind. Both strict and regex is supported. When checking attributes, converting attribute values from bool, double, and int to string is supported

The OTTL has access to each of these properties. The Factory Function, IsMatch, can be used to perform regex matching, but it does not support converting bool, double, or int to string.

OTTL needs to be able to perform regex where the input is converted to the string if it is a bool, int, or double.

There are other situations in the transformprocessor where type conversion is needed, so adding a String conversion function could be a solution. Or IsMatch can be made more intelligent.

[TylerHelmuth]

When filtering logs, the filterprocessor configuration allows matching by resource attributes, attributes, severity text, body, and severity number. Both strict and regex is supported. When checking attributes, converting attribute values from bool, double, and int to string is supported. When matching severity number, a minimum log severity can be used and any values equal to or greater than the severity match. You can also specify if an undefined severity number can be match.

The OTTL has access to all of these fields for logs. Like before, regex matching will need to be improved to handle type conversion. The OTTL supports inequalities and the severity number ENUMS so it can handle the existing severity number logic.

[TylerHelmuth]

When filtering metrics the filter processor configuration allows matching by metric name, resource attributes and datapoint attributes via expressions. When checking attributes, converting attribute values from bool, double, and int to string is supported. The expression allows for checking a datapoint's attribute value or the presence of an attribute. If any datapoint within a metric matches then the entire metric is dropped.

The OTTL has access to all of these fields. Like before, regex matching will need to be improved to handle type conversion. The OTTL metric context has access to the datapoints for the metric, but there are not any functions that can check the attributes of these data points. The datapoint context has access to the datapoint attributes, but there is no way to drop the entire metric if a single datapoint matches.

The OTTL will need to be able to handle an ottlmetric condition that can check individual attributes.

[bogdandrutu]

I agree about the "OTTL needs to be able to perform regex where the input is converted to the string if it is a bool, int, or double.".

I do understand the difference between include/exclude which were added because we could not do "!=" in the filters language. But we the current OTTL this seem reasonable to me 'resource.attributes["service.name"] != "app_3"'.

"The OTTL will need to be able to handle an ottlmetric condition that can check individual attributes." this may be very hard, let's focus on the first 2 first.

[TylerHelmuth]

@bogdandrutu with negation and the IsMatch updates I believe we've covered the first 2 gaps.

How do you want to handle the third? A function could be made specifically for the metric context that can use the datapoints accessor and loop through looking for the specified attributes.

[github-actions]

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 @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/filter: @TylerHelmuth @boostchicken

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[TylerHelmuth]

All gaps have been addressed. Old configs can now be deprecated.