filterprocessor

package module
v0.151.0 Latest Latest
Warning

This package is not in the latest version of its module.

 Go to latest Published: Apr 28, 2026 License: Apache-2.0 Imports: 44 Imported by: 30

README

Filter Processor

The Filter Processor allows dropping spans, span events, metrics, datapoints, and logs from the collector.

Status
Stability development: profiles
alpha: traces, metrics, logs
Distributions core, contrib, k8s
Warnings Orphaned Telemetry, Other
Issues Open issues Closed issues
Code coverage codecov
Code Owners @TylerHelmuth, @evan-bradley, @edmocosta, @bogdandrutu
Emeritus @boostchicken

[!NOTE] This documentation applies only to version 0.146.0 and later. Configuration from previous version is still supported, but no longer documented in this README. For information on earlier versions, please refer to the previous documentation.

Configuration

The Filter Processor utilizes the OpenTelemetry Transformation Language to create conditions that determine when telemetry should be dropped. If any condition is met, the telemetry is dropped (each condition is ORed together).

General Config
filter:
  error_mode: propagate
  <trace|metric|log|profile>_conditions: []

The Filter Processor's primary configuration is broken down by signal (traces, metrics, logs, and profiles) and allows you to configure a list of conditions for the processor to evaluate. The list can be made of:

  • OTTL conditions. This option will meet most user's needs. See Basic Config for more details.
  • Objects, which allows users to apply configuration options to a specific list of conditions. See Advanced Config for more details.

The OTTL allows the use of and, or, and () in conditions. See OTTL Boolean Expressions for more details.

Context

Within each <signal>_conditions list, only certain OTTL Contexts can be used. Each context provides access to different telemetry fields. Click the context name for detailed documentation.

Signal Available Contexts
trace_conditions resource, scope, span, and spanevent
metric_conditions resource, scope, metric, and datapoint
log_conditions resource, scope, and log
profile_conditions resource, scope, and profile

Telemetry is evaluated hierarchically, from higher to lower levels. The hierarchy may vary by signal type; examples include:

Logs: resource → scope → log

Metrics: resource → scope → metric → datapoint

Traces: resource → scope → span → spanevent

For conditions that apply to the same signal, such as spans and span events, if the "higher" level telemetry matches a condition and is dropped, the "lower" level condition will not be checked. This means that if a span is dropped but a span event condition was defined, the span event condition will not be checked for that span. The same relationship applies to other signals.

If all span events for a span are dropped, the span will be left intact.

If all datapoints for a metric are dropped, the metric will also be dropped.

Note that when a single condition contains paths from different contexts, resource and spanevent for example, the condition is evaluated in the lower context spanevent.

filter:
  trace_conditions:
    - resource.attributes["host.name"] == "localhost" or spanevent.name == "grpc.timeout"

This condition translates to: For each span event, check whether its parent span's resource attribute host.name is localhost or whether the span event's name is grpc.timeout. Drop the span event if either condition is true.

Error Modes

The filter processor also allows configuring an optional field, error_mode, which will determine how the processor reacts to errors that occur while processing an OTTL condition. propagate is the default mode.

error_mode description
ignore The processor ignores errors returned by conditions, logs them, and continues on to the next condition. This is the recommended mode.
silent The processor ignores errors returned by conditions, does not log them, and continues on to the next condition.
propagate The processor returns the error up the pipeline. This will result in the payload being dropped from the collector.
Feature Gate
processor.filter.defaultErrorModeIgnore

The processor.filter.defaultErrorModeIgnore feature gate changes the default error_mode of the filter processor from propagate to ignore. ignore is the recommended mode to improve resiliency, as errors are logged for visibility but valid data is preserved, and processing continues with the next condition. This feature gate is currently in Alpha (disabled by default) and must be explicitly enabled.

Example Usage

Run the collector with the feature gate enabled: ./otelcol --config config.yaml --feature-gates=processor.filter.defaultErrorModeIgnore.

Basic Config

The basic configuration style allows you to configure OTTL conditions as a flat, OR-ed list, without worrying about extra configurations.

This is the simplest way to configure the Filter Processor. If you need explicit context specification or specific error modes, see Advanced Config.

Format:

filter:
  error_mode: propagate
  <trace|metric|log|profile>_conditions:
    - string
    - string
    - string

Example:

processors:
  filter:
    error_mode: propagate
    trace_conditions:
      - span.attributes["container.name"] == "app_container_1"
      - resource.attributes["host.name"] == "localhost"
      - span.name == "app_3"
    metric_conditions:
      - metric.name == "my.metric" and resource.attributes["my_label"] == "abc123"
      - metric.type == METRIC_DATA_TYPE_HISTOGRAM
      - resource.attributes["service.name"] == "my_service_name"
    log_conditions:
      - IsMatch(log.body, ".*password.*")
      - log.severity_number < SEVERITY_NUMBER_WARN
    profile_conditions:
      - profile.duration_unix_nano > 3000
Advanced Config

For more complex use cases you may need to use the Filter Processor's advanced configuration style to explicitly specify the context and apply additional settings to a group of conditions.

Format:

filter:
  error_mode: ignore
  <trace|metric|log|profile>_conditions:
    - context: string
      error_mode: propagate
      conditions:
        - string
        - string
    - context: string
      conditions:
        - string

context: specifies the OTTL context for the conditions. See the Context table for valid values per signal type. Note: In most cases, you should not set this field manually. The processor's context inferrer will automatically determine the correct context based on the paths used in your conditions. Only set this field if you have a specific need to set the context.

error_mode: allows overriding the top-level error_mode for this specific group of conditions. Valid values are ignore, silent, and propagate. See the Error Modes table for more details.

conditions: a list of OTTL conditions. If any condition is met, the telemetry is dropped (conditions are OR-ed together).

Example:

processors:
  filter:
    error_mode: propagate
    trace_conditions:
      - conditions:
          - resource.attributes["host.name"] == "localhost"
      - error_mode: ignore
        conditions:
          - span.attributes["container.name"] == "container_1"
          - span.name == "app_3"
      - conditions:
          - spanevent.attributes["grpc"] == true
          - IsMatch(spanevent.name, ".*grpc.*")
    metric_conditions:
      - conditions:
          - metric.name == "my.metric" and resource.attributes["my_label"] == "abc123"
          - metric.type == METRIC_DATA_TYPE_HISTOGRAM
      - conditions:
          - metric.type == METRIC_DATA_TYPE_SUMMARY
    log_conditions:
      - conditions:
          - IsMatch(log.body, ".*password.*")
          - log.severity_number < SEVERITY_NUMBER_WARN
Context Inference

[!NOTE] This is an advanced topic and is not necessary to get started using the Filter Processor. Read on if you're interested in how the Filter Processor parses your OTTL conditions.

An OTTL Context defines which Paths, functions, and enums are available when parsing the condition. The Filter Processor automatically infers the OTTL Context based on the paths defined in a condition.

This inference is based on the Path names, functions, and enums present in the condition.

The inference happens automatically because Path names are prefixed with the context name. For example:

trace_conditions:
  - span.attributes["container.name"] == "container_1" and spanevent.attributes["grpc"] == true

In this configuration, the inferred context value is spanevent, as it is the only context that supports parsing both spanevent and span Paths.

In Filter processor, each condition in a list is parsed individually and grouped by its inferred context. Conditions are executed by context group in hierarchical order (resource → scope → signal-specific). For example:

trace_conditions:
  - scope.name == "my.scope"                          # inferred as scope context
  - span.name == "app_3"                              # inferred as span context
  - spanevent.name == "grpc.timeout"                  # inferred as spanevent context
  - resource.attributes["host.name"] == "localhost"   # inferred as resource context

Resource condition is executed first, followed by scope, span, and finally spanevent conditions.

The primary benefit of context inference is that it enhances the efficiency of data filtering by linking them to the most suitable context. This optimization ensures that the processing are both accurate and performant, leveraging the hierarchical structure of contexts to avoid unnecessary iterations and improve overall processing efficiency. All of this happens automatically, leaving you to write OTTL conditions without worrying about context.

In some situations a combination of Paths, functions, or enums is not allowed. For example:

trace_conditions:
  - IsRootSpan() or spanevent.name == "bar"

This condition fails because IsRootSpan() is only available in the span context, not span events, while the spanevent Path prefix requires the condition to evaluate in the span event context.

The solution is to split into separate span and span event conditions:

trace_conditions:
  - context: span
    conditions:
      - IsRootSpan()
  - conditions:
      - spanevent.name == "bar"

The advanced configuration is required for IsRootSpan() because there is no Path prefix in the condition, so the context must be set explicitly to span.

Examples
Dropping data based on a resource attribute
processors:
  filter:
    error_mode: ignore
    trace_conditions:
      - resource.attributes["k8s.pod.name"] == "my-pod-name"
Dropping metrics with invalid type
processors:
  filter:
    error_mode: ignore
    metric_conditions:
      - metric.type == METRIC_DATA_TYPE_NONE
Dropping specific metric and value
processors:
  filter:
    error_mode: ignore
    metric_conditions:
      - metric.name == "k8s.pod.phase" and datapoint.value_int == 4
Dropping non-HTTP spans
processors:
  filter:
    error_mode: ignore
    trace_conditions:
      - span.attributes["http.request.method"] == nil
Dropping HTTP spans
processors:
  filter:
    error_mode: ignore
    trace_conditions:
      - span.attributes["http.request.method"] != nil
Dropping non-error spans with a duration of less than 1 second
processors:
  filter:
    error_mode: ignore
    trace_conditions:
      - (span.end_time - span.start_time) < Duration("1s") and span.status.code != STATUS_CODE_ERROR
OTTL Functions

The filter processor has access to all OTTL Converter functions

In addition, the processor defines a few of its own functions:

Metrics only functions

HasAttrKeyOnDatapoint

HasAttrKeyOnDatapoint(key)

Returns true if the given key appears in the attribute map of any datapoint on a metric. key must be a string. You must use the metrics.metric context.

Examples:

  • HasAttrKeyOnDatapoint("http.method")
# Drops metrics containing the 'bad.metric' attribute key
filter/keep_good_metrics:
  error_mode: ignore
  metrics:
    metric:
      - HasAttrKeyOnDatapoint("bad.metric")
HasAttrOnDatapoint

HasAttrOnDatapoint(key, value)

Returns true if the given key and value appears in the attribute map of any datapoint on a metric. key and value must both be strings. If the value of the attribute on the datapoint is not a string, value will be compared to "". You must use the metrics.metric context.

Examples:

  • HasAttrOnDatapoint("http.method", "GET")
# Drops metrics containing the 'bad.metric' attribute key and 'true' value
filter/keep_good_metrics:
  error_mode: ignore
  metrics:
    metric:
      - HasAttrOnDatapoint("bad.metric", "true")

Legacy Configuration

The following configuration options are deprecated and will be removed in a future release. Please migrate to the new *_conditions format.

Deprecated Config Migrate To
traces.resource trace_conditions with resource. prefix
traces.span trace_conditions with span. prefix
traces.spanevent trace_conditions with spanevent. prefix
metrics.resource metric_conditions with resource. prefix
metrics.metric metric_conditions with metric. prefix
metrics.datapoint metric_conditions with datapoint. prefix
logs.resource log_conditions with resource. prefix
logs.log_record log_conditions with log. prefix
profiles.resource profile_conditions with resource. prefix
profiles.profile profile_conditions with profile. prefix

Troubleshooting

When using OTTL you can enable debug logging in the collector to print out useful information, such as if the condition matched and the TransformContext used in the condition, to help you troubleshoot why a condition is not behaving as you expect. This feature is very verbose, but provides you an accurate view into how OTTL views the underlying data.

receivers:
  file_log:
    start_at: beginning
    include: [ /Users/tylerhelmuth/projects/opentelemetry-collector-contrib/local/test.log ]


processors:
  filter:
    error_mode: ignore
    log_conditions:
      - log.body == "test"

exporters:
  debug:

service:
  telemetry:
    logs:
      level: debug
  pipelines:
    logs:
      receivers:
        - file_log
      processors:
        - filter
      exporters:
        - debug

2024-05-29T16:47:04.362-0600    debug   ottl@v0.101.0/parser.go:338     condition evaluation result     {"kind": "processor", "name": "filter", "pipeline": "logs", "condition": "body == \"test\"", "match": true, "TransformContext": {"resource": {"attributes": {}, "dropped_attribute_count": 0}, "scope": {"attributes": {}, "dropped_attribute_count": 0, "name": "", "version": ""}, "log_record": {"attributes": {"log.file.name": "test.log"}, "body": "test", "dropped_attribute_count": 0, "flags": 0, "observed_time_unix_nano": 1717022824262063000, "severity_number": 0, "severity_text": "", "span_id": "", "time_unix_nano": 0, "trace_id": ""}, "cache": {}}}

Warnings

In general, understand your data before using the filter processor.

  • When using the Filter Processor make sure you understand the look of your incoming data and test the configuration thoroughly. In general, use as specific a configuration as possible to lower the risk of the wrong data being dropped.
  • Orphaned Telemetry: The processor allows dropping spans. Dropping a span may lead to orphaned spans if the dropped span is a parent. Dropping a span may lead to orphaned logs if the log references the dropped span.

Documentation

Overview

Package filterprocessor implements a processor for filtering (dropping) metrics and/or spans by various properties.

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

func DefaultDataPointFunctions added in v0.133.0 

func DefaultDataPointFunctions() []ottl.Factory[*ottldatapoint.TransformContext]

func DefaultDataPointFunctionsNew deprecated added in v0.142.0 

func DefaultDataPointFunctionsNew() []ottl.Factory[*ottldatapoint.TransformContext]

Deprecated: [v0.152.0] use DefaultDataPointFunctions.

func DefaultLogFunctions added in v0.133.0 

func DefaultLogFunctions() []ottl.Factory[*ottllog.TransformContext]

func DefaultLogFunctionsNew deprecated added in v0.142.0 

func DefaultLogFunctionsNew() []ottl.Factory[*ottllog.TransformContext]

Deprecated: [v0.152.0] use DefaultLogFunctions.

func DefaultMetricFunctions added in v0.133.0 

func DefaultMetricFunctions() []ottl.Factory[*ottlmetric.TransformContext]

func DefaultMetricFunctionsNew deprecated added in v0.142.0 

func DefaultMetricFunctionsNew() []ottl.Factory[*ottlmetric.TransformContext]

Deprecated: [v0.152.0] use DefaultMetricFunctions.

func DefaultProfileFunctions added in v0.138.0 

func DefaultProfileFunctions() []ottl.Factory[*ottlprofile.TransformContext]

func DefaultProfileFunctionsNew deprecated added in v0.145.0 

func DefaultProfileFunctionsNew() []ottl.Factory[*ottlprofile.TransformContext]

Deprecated: [v0.152.0] use DefaultProfileFunctions.

func DefaultResourceFunctions added in v0.139.0 

func DefaultResourceFunctions() []ottl.Factory[*ottlresource.TransformContext]

func DefaultSpanEventFunctions added in v0.133.0 

func DefaultSpanEventFunctions() []ottl.Factory[*ottlspanevent.TransformContext]

func DefaultSpanEventFunctionsNew deprecated added in v0.142.0 

func DefaultSpanEventFunctionsNew() []ottl.Factory[*ottlspanevent.TransformContext]

Deprecated: [v0.152.0] use DefaultSpanEventFunctions.

func DefaultSpanFunctions added in v0.133.0 

func DefaultSpanFunctions() []ottl.Factory[*ottlspan.TransformContext]

func DefaultSpanFunctionsNew deprecated added in v0.142.0 

func DefaultSpanFunctionsNew() []ottl.Factory[*ottlspan.TransformContext]

Deprecated: [v0.152.0] use DefaultSpanFunctions.

func NewFactory 

func NewFactory() processor.Factory

NewFactory returns a new factory for the Filter processor.

func NewFactoryWithOptions added in v0.133.0 

func NewFactoryWithOptions(options ...FactoryOption) processor.Factory

NewFactoryWithOptions can receive FactoryOption like With*Functions to register non-default OTTL functions in the resulting processor.

Types

type Config 

type Config struct {
	// ErrorMode determines how the processor reacts to errors that occur while processing an OTTL condition.
	// Valid values are `ignore` and `propagate`.
	// `ignore` means the processor ignores errors returned by conditions and continues on to the next condition. This is the recommended mode.
	// `propagate` means the processor returns the error up the pipeline.  This will result in the payload being dropped from the collector.
	// The default value is `propagate`. It will change to `ignore` when the `processor.filter.defaultErrorModeIgnore` feature gate is stable.
	ErrorMode ottl.ErrorMode `mapstructure:"error_mode"`

	// Deprecated: use TraceConditions instead.
	Spans filterconfig.MatchConfig `mapstructure:"spans"`
	// Deprecated: use MetricConditions instead.
	Metrics MetricFilters `mapstructure:"metrics"`
	// Deprecated: use LogConditions instead.
	Logs LogFilters `mapstructure:"logs"`
	// Deprecated: use TraceConditions instead.
	Traces TraceFilters `mapstructure:"traces"`
	// Deprecated: use ProfileConditions instead.
	Profiles ProfileFilters `mapstructure:"profiles"`

	MetricConditions  []condition.ContextConditions `mapstructure:"metric_conditions"`
	LogConditions     []condition.ContextConditions `mapstructure:"log_conditions"`
	TraceConditions   []condition.ContextConditions `mapstructure:"trace_conditions"`
	ProfileConditions []condition.ContextConditions `mapstructure:"profile_conditions"`
	// contains filtered or unexported fields
}

Config defines configuration for Resource processor.

func (*Config) Unmarshal added in v0.146.0 

func (cfg *Config) Unmarshal(conf *confmap.Conf) error

Unmarshal is used internally by mapstructure to parse the filterprocessor configuration (Config), adding support to structured and flat configuration styles. When the flat configuration style is used, all conditions are grouped into a common.ContextConditions object, with empty [common.ContextConditions.Context] value. On the other hand, structured configurations are parsed following the mapstructure Config format.

Example of flat configuration: 

log_conditions:
  - resource.attributes["key1"] == "value"
  - resource.attributes["key2"] == "value"

Example of structured configuration: 

log_conditions:
  - context: "resource"
    conditions:
      - attributes["key1"] == "value"
      - attributes["key2"] == "value"

func (*Config) Validate 

func (cfg *Config) Validate() error

Validate checks if the processor configuration is valid

type FactoryOption added in v0.133.0 

type FactoryOption func(factory *filterProcessorFactory)

FactoryOption applies changes to filterProcessorFactory.

func WithDataPointFunctions added in v0.133.0 

func WithDataPointFunctions(dataPointFunctions []ottl.Factory[*ottldatapoint.TransformContext]) FactoryOption

WithDataPointFunctions will override the default OTTL datapoint context functions with the provided dataPointFunctions in resulting processor. Subsequent uses of WithDataPointFunctions will merge the provided dataPointFunctions with the previously registered functions.

func WithDataPointFunctionsNew deprecated added in v0.142.0 

func WithDataPointFunctionsNew(dataPointFunctions []ottl.Factory[*ottldatapoint.TransformContext]) FactoryOption

Deprecated: [v0.152.0] Use WithDataPointFunctions.

func WithLogFunctions added in v0.133.0 

func WithLogFunctions(logFunctions []ottl.Factory[*ottllog.TransformContext]) FactoryOption

WithLogFunctions will override the default OTTL log context functions with the provided logFunctions in the resulting processor. Subsequent uses of WithLogFunctions will merge the provided logFunctions with the previously registered functions.

func WithLogFunctionsNew deprecated added in v0.142.0 

func WithLogFunctionsNew(logFunctions []ottl.Factory[*ottllog.TransformContext]) FactoryOption

Deprecated: [v0.152.0] Use WithLogFunctions.

func WithMetricFunctions added in v0.133.0 

func WithMetricFunctions(metricFunctions []ottl.Factory[*ottlmetric.TransformContext]) FactoryOption

WithMetricFunctions will override the default OTTL metric context functions with the provided metricFunctions in the resulting processor. Subsequent uses of WithMetricFunctions will merge the provided metricFunctions with the previously registered functions.

func WithMetricFunctionsNew deprecated added in v0.142.0 

func WithMetricFunctionsNew(metricFunctions []ottl.Factory[*ottlmetric.TransformContext]) FactoryOption

Deprecated: [v0.152.0] Use WithMetricFunctions.

func WithProfileFunctions added in v0.138.0 

func WithProfileFunctions(profileFunctions []ottl.Factory[*ottlprofile.TransformContext]) FactoryOption

WithProfileFunctions will override the default OTTL profile context functions with the provided profileFunctions in the resulting processor. Subsequent uses of WithProfileFunctions will merge the provided profileFunctions with the previously registered functions.

func WithProfileFunctionsNew deprecated added in v0.145.0 

func WithProfileFunctionsNew(profileFunctions []ottl.Factory[*ottlprofile.TransformContext]) FactoryOption

Deprecated: [v0.152.0] use WithProfileFunctions.

func WithResourceFunctions added in v0.139.0 

func WithResourceFunctions(resourceFunctions []ottl.Factory[*ottlresource.TransformContext]) FactoryOption

WithResourceFunctions will override the default OTTL resource context functions with the provided resourceFunctions in resulting processor. Subsequent uses of WithResourceFunctions will merge the provided resourceFunctions with the previously registered functions.

func WithResourceFunctionsNew deprecated added in v0.142.0 

func WithResourceFunctionsNew(resourceFunctions []ottl.Factory[*ottlresource.TransformContext]) FactoryOption

Deprecated: [v0.152.0] Use WithResourceFunctions.

func WithSpanEventFunctions added in v0.133.0 

func WithSpanEventFunctions(spanEventFunctions []ottl.Factory[*ottlspanevent.TransformContext]) FactoryOption

WithSpanEventFunctions will override the default OTTL spanevent context functions with the provided spanEventFunctions in the resulting processor. Subsequent uses of WithSpanEventFunctions will merge the provided spanEventFunctions with the previously registered functions.

func WithSpanEventFunctionsNew deprecated added in v0.142.0 

func WithSpanEventFunctionsNew(spanEventFunctions []ottl.Factory[*ottlspanevent.TransformContext]) FactoryOption

Deprecated: [v0.152.0] Use WithSpanEventFunctions.

func WithSpanFunctions added in v0.133.0 

func WithSpanFunctions(spanFunctions []ottl.Factory[*ottlspan.TransformContext]) FactoryOption

WithSpanFunctions will override the default OTTL span context functions with the provided spanFunctions in the resulting processor. Subsequent uses of WithSpanFunctions will merge the provided spanFunctions with the previously registered functions.

func WithSpanFunctionsNew deprecated added in v0.142.0 

func WithSpanFunctionsNew(spanFunctions []ottl.Factory[*ottlspan.TransformContext]) FactoryOption

Deprecated: [v0.152.0] use WithSpanFunctions.

type LogFilters 

type LogFilters struct {
	// Include match properties describe logs that should be included in the Collector Service pipeline,
	// all other logs should be dropped from further processing.
	// If both Include and Exclude are specified, Include filtering occurs first.
	Include *LogMatchProperties `mapstructure:"include"`
	// Exclude match properties describe logs that should be excluded from the Collector Service pipeline,
	// all other logs should be included.
	// If both Include and Exclude are specified, Include filtering occurs first.
	Exclude *LogMatchProperties `mapstructure:"exclude"`

	// ResourceConditions is a list of OTTL conditions for an ottlresource context.
	// If any condition resolves to true, the whole resource will be dropped.
	// Supports `and`, `or`, and `()`
	ResourceConditions []string `mapstructure:"resource"`

	// LogConditions is a list of OTTL conditions for an ottllog context.
	// If any condition resolves to true, the log event will be dropped.
	// Supports `and`, `or`, and `()`
	LogConditions []string `mapstructure:"log_record"`
}

LogFilters filters by Log properties.

type LogMatchProperties added in v0.36.0 

type LogMatchProperties struct {
	// LogMatchType specifies the type of matching desired
	LogMatchType LogMatchType `mapstructure:"match_type"`

	// ResourceAttributes defines a list of possible resource attributes to match logs against.
	// A match occurs if any resource attribute matches all expressions in this given list.
	ResourceAttributes []filterconfig.Attribute `mapstructure:"resource_attributes"`

	// RecordAttributes defines a list of possible record attributes to match logs against.
	// A match occurs if any record attribute matches at least one expression in this given list.
	RecordAttributes []filterconfig.Attribute `mapstructure:"record_attributes"`

	// SeverityTexts is a list of strings that the LogRecord's severity text field must match
	// against.
	SeverityTexts []string `mapstructure:"severity_texts"`

	// SeverityNumberProperties defines how to match against a log record's SeverityNumber, if defined.
	SeverityNumberProperties *LogSeverityNumberMatchProperties `mapstructure:"severity_number"`

	// LogBodies is a list of strings that the LogRecord's body field must match
	// against.
	LogBodies []string `mapstructure:"bodies"`
}

LogMatchProperties specifies the set of properties in a log to match against and the type of string pattern matching to use.

type LogMatchType added in v0.36.0 

type LogMatchType string

LogMatchType specifies the strategy for matching against `plog.Log`s.

type LogSeverityNumberMatchProperties added in v0.58.0 

type LogSeverityNumberMatchProperties struct {
	// Min is the minimum severity needed for the log record to match.
	// This corresponds to the short names specified here:
	// https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#displaying-severity
	// this field is case-insensitive ("INFO" == "info")
	Min logSeverity `mapstructure:"min"`

	// MatchUndefined lets logs records with "unknown" severity match.
	// If MinSeverity is not set, this field is ignored, as fields are not matched based on severity.
	MatchUndefined bool `mapstructure:"match_undefined"`
}

type MetricFilters 

type MetricFilters struct {
	// Include match properties describe metrics that should be included in the Collector Service pipeline,
	// all other metrics should be dropped from further processing.
	// If both Include and Exclude are specified, Include filtering occurs first.
	Include *filterconfig.MetricMatchProperties `mapstructure:"include"`

	// Exclude match properties describe metrics that should be excluded from the Collector Service pipeline,
	// all other metrics should be included.
	// If both Include and Exclude are specified, Include filtering occurs first.
	Exclude *filterconfig.MetricMatchProperties `mapstructure:"exclude"`

	// RegexpConfig specifies options for the regexp match type
	RegexpConfig *regexp.Config `mapstructure:"regexp"`

	// ResourceConditions is a list of OTTL conditions for an ottlresource context.
	// If any condition resolves to true, the whole resource will be dropped.
	// Supports `and`, `or`, and `()`
	ResourceConditions []string `mapstructure:"resource"`

	// MetricConditions is a list of OTTL conditions for an ottlmetric context.
	// If any condition resolves to true, the metric will be dropped.
	// Supports `and`, `or`, and `()`
	MetricConditions []string `mapstructure:"metric"`

	// DataPointConditions is a list of OTTL conditions for an ottldatapoint context.
	// If any condition resolves to true, the datapoint will be dropped.
	// Supports `and`, `or`, and `()`
	DataPointConditions []string `mapstructure:"datapoint"`
}

MetricFilters filters by Metric properties.

type ProfileFilters added in v0.138.0 

type ProfileFilters struct {

	// ResourceConditions is a list of OTTL conditions for an ottlresource context.
	// If any condition resolves to true, the whole resource will be dropped.
	// Supports `and`, `or`, and `()`
	ResourceConditions []string `mapstructure:"resource"`

	// ProfileConditions is a list of OTTL conditions for an ottlprofile context.
	// If any condition resolves to true, the profile will be dropped.
	// Supports `and`, `or`, and `()`
	ProfileConditions []string `mapstructure:"profile"`
	// contains filtered or unexported fields
}

ProfileFilters filters by OTTL conditions

type TraceFilters added in v0.65.0 

type TraceFilters struct {
	// ResourceConditions is a list of OTTL conditions for an ottlresource context.
	// If any condition resolves to true, the whole resource will be dropped.
	// Supports `and`, `or`, and `()`
	ResourceConditions []string `mapstructure:"resource"`

	// SpanConditions is a list of OTTL conditions for an ottlspan context.
	// If any condition resolves to true, the span will be dropped.
	// Supports `and`, `or`, and `()`
	SpanConditions []string `mapstructure:"span"`

	// SpanEventConditions is a list of OTTL conditions for an ottlspanevent context.
	// If any condition resolves to true, the span event will be dropped.
	// Supports `and`, `or`, and `()`
	SpanEventConditions []string `mapstructure:"spanevent"`
}

TraceFilters filters by OTTL conditions

Source Files

View all Source files

Directories

Path Synopsis
internal
condition
metadata
Package metadata contains the autogenerated telemetry and build information for the processor/filter component.
 Package metadata contains the autogenerated telemetry and build information for the processor/filter component.
metadatatest

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL
go.dev uses cookies from Google to deliver and enhance the quality of its services and to analyze traffic. Learn more.