In this section, we will explore how to use the Filter Processor to selectively drop spans based on certain conditions.
Specifically, we will drop traces based on the span name, which is commonly used to filter out unwanted spans such as health checks or internal communication traces. In this case, we will be filtering out spans whose name is "/_healthz", typically associated with health check requests and usually are quite “noisy”.
Exercise
Inside the [WORKSHOP] directory, create a new subdirectory named 5-dropping-spans.
Next, copy all contents from the 4-resilience directory into 5-dropping-spans.
After copying, remove any *.out and *.log files.
Change all terminal windows to the [WORKSHOP]/5-dropping-spans directory.
Your updated directory structure will now look like this:
Next, we will configure the filter processor and the respective pipelines.
Subsections of 5. Dropping Spans
5.1 Configuration
Exercise
Switch to your Gateway terminal window. Navigate to the [WORKSHOP]/5-dropping-spans directory and open the gateway.yaml and add the following configuration to the processors section:
Add a filter processor: Configure the OpenTelemetry Collector to drop spans with the name "/_healthz":
filter/health:# Defines a filter processorerror_mode:ignore # Ignore errorstraces:# Filtering rules for tracesspan:# Exclude spans named "/_healthz" - 'name == "/_healthz"'
Add the filter processor: Make sure you add the filter to the traces pipeline. Filtering should be applied as early as possible, ideally right after the memory_limiter and before the batch processor:
traces:receivers:- otlp # OTLP Receiverprocessors:- memory_limiter # Manage memory usage- filter/health # Filter Processor. Filter's out Data based on rules- resource/add_mode # Add metadata about collector mode- batch # Groups Data before sendexporters:- debug # Debug Exporter- file/traces # File Exporter for Trace
Validate the agent configuration using otelbin.io. For reference, the traces: section of your pipelines will look similar to this:
Start the Gateway: In the Gateway terminal window navigate to the [WORKSHOP]/5-dropping-spans directory and run:
../otelcol --config=gateway.yaml
Start the Agent: In the Agent terminal window navigate to the [WORKSHOP]/5-dropping-spans directory and run:
../otelcol --config=agent.yaml
Send the new health.json payload: In the Test terminal window navigate to the [WORKSHOP]/5-dropping-spans directory and run the curl command below. (Windows use curl.exe).
curl -X POST -i http://localhost:4318/v1/traces -H "Content-Type: application/json" -d "@health.json"
Verify Agent Debug output shows the healthz span: Confirm that the span span payload is sent, Check the agent’s debug output to see the span data like the snippet below:
<snip>
Span #0
Trace ID : 5b8efff798038103d269b633813fc60c
Parent ID : eee19b7ec3c1b173
ID : eee19b7ec3c1b174
Name : /_healthz
Kind : Server
<snip>
The Agent has forward the span to the Gateway.
Check the Gateway Debug output:
The Gateway should NOT show any span data received. This is because the Gateway is configured with a filter to drop spans named "/_healthz", so the span will be discarded/dropped and not processed further.
Confirm normal span are processed by using the cURL command with the trace.json file again. This time, you should see both the agent and gateway process the spans successfully.
Tip
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.
You can further extend this configuration to filter out spans based on different attributes, tags, or other criteria, making the OpenTelemetry Collector more customizable and efficient for your observability needs.