aws / aws/amazon-cloudwatch-agent
Add support for metric filtering (e.g., namepass / namedrop) for StatsD listener in CloudWatch Agent
- Dominant language
- Go
- Stars
- 550
- Forks
- 271
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 13
Description
**Is your feature request related to a problem? Please describe.**
The CloudWatch Agent’s StatsD listener currently forwards all received metrics to CloudWatch without any option to filter them. I only want to publish specific metrics, but there’s no built-in way to include or exclude metrics based on their names or patterns.
In our environment, multiple StatsD listeners consume the same metrics (including the CloudWatch Agent). Updating all application StatsD clients to support multiple destinations and apply filtering rules specific to each destination is not a viable solution.
**Describe the solution you'd like**
I would like the CloudWatch Agent to support metric filtering for StatsD metrics, similar to [Telegraf’s metric filtering](https://github.com/influxdata/telegraf/blob/master/docs/CONFIGURATION.md#metric-filtering).
At a minimum, support for namepass (include list) and optionally namedrop (exclude list) would be very useful.
Example configuration:
```
"statsd": {
"service_address": ":8125",
"metrics_collection_interval": 60,
"metric_filter": {
"namepass": ["app.requests.*", "app.latency.mean"]
}
}
```
This would allow publishing only the desired metrics to CloudWatch.
**Describe alternatives you've considered**
Filtering in the application layer: Updating all StatsD clients across multiple applications to handle filtering and multiple destinations is not viable.
**Additional context**
This feature would allow more precise control over metric publication and avoid sending unnecessary data to CloudWatch.
Contributor guide
Research direction
Start by locating the StatsD listener and its configuration handling, then compare the requested namepass and namedrop behavior with the linked Telegraf metric-filtering documentation. Done means the example metric_filter configuration is accepted and StatsD metrics are included or excluded by name before publication to CloudWatch, with coverage for the filtering behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- observability-sre
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100