How to Drop Specific Endpoints from AWS CloudWatch Signals?

Select Language:

If you’re trying to filter out certain telemetry data in CloudWatch Application Signals, there are a few effective ways to do this without relying on drop rules that might not be standard for this service.

One of the simplest methods is to control what data is sent from your application by adjusting environment variables within your container. For example, in a Java app running on ECS Fargate, you can set these key variables:

Set OTEL_AWS_APPLICATION_SIGNALS_ENABLED to enable or disable Application Signals telemetry.
Use OTEL_METRICS_EXPORTER set to none to stop exporting metrics you don’t need.
Use OTEL_LOGS_EXPORTER set to none to prevent logs from being exported if they’re unnecessary.

Applying these settings ensures you’re only sending the telemetry that matters, reducing noise and saving costs.

Another approach is to filter data at the application level or within your OpenTelemetry setup. Instead of filtering after the data arrives at CloudWatch, you can:

Configure the OpenTelemetry Java agent to skip collecting certain endpoints, like health checks.
Use sampling strategies in OpenTelemetry to ignore traces matching specific patterns.
Implement custom span processors that filter out health check endpoints before the data is exported.

It’s best to ensure your application or your instrumentation setup is only capturing what you need, instead of attempting to filter at the CloudWatch agent level.

You also want to confirm that your metrics and traces are being sent to the correct endpoints. For instance:

Make sure OTEL_AWS_APPLICATION_SIGNALS_EXPORTER_ENDPOINT points to your sidecar’s metrics endpoint, such as http://localhost:4316/v1/metrics.
Set OTEL_EXPORTER_OTLP_TRACES_ENDPOINT to the traces endpoint, like http://localhost:4316/v1/traces.

Don’t forget to set the protocol correctly with OTEL_EXPORTER_OTLP_PROTOCOL to http/protobuf to ensure data is sent properly.

Lastly, make sure you’re using version 1.32.2 or newer of the AWS Distro for OpenTelemetry Java agent, as this supports all the necessary Application Signals features.

Since filtering at the configuration level through drop rules isn’t well-documented and might not be supported, it’s better to leverage OpenTelemetry’s built-in filtering options. This way, unwanted data is filtered out early, reducing network traffic and costs.

Keep in mind, the standard guides don’t specify syntax for drop rules in Application Signals, which indicates this isn’t the recommended approach. Instead, focus on configuring your application directly or using OpenTelemetry’s native filtering options for better results.