aws / aws/amazon-cloudwatch-agent
Support specifying multiple Namespaces for EMF
- Dominant language
- Go
- Stars
- 550
- Forks
- 271
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 13
Description
### Context
Currently, when configuring EMF Processor, we can only do this:
```
"logs": {
"metrics_collected": {
"prometheus": {
"log_group_name": "myLogGroup",
"prometheus_config_path": "env:PROMETHEUS_CONFIG_CONTENT",
"emf_processor": {
"metric_namespace": "prod/Namespace"
"metric_declaration": [
{
source_labels = ["job1"]
label_matcher = ...
dimensions = ...
metric_selectors = ...
},
{
source_labels = ["job2"]
label_matcher = ...
dimensions = ...
metric_selectors = ...
},
]
}
}
}
}
```
As a result, metrics from both prometheus scrapper jobs will be stored in the same Cloudwatch Namespace.
### Feature request
It would be nice to have the possibility to specify the `metric_namespace` inside the `metric_declaration` JSON, to allow metrics scrapped by different jobs to go to different namespaces.
### Justification / use-case
We're running ECS/Fargate services with AppMesh. The ECS Task consists of:
- Service container
- Envoy container
- Cloudwatch Agent Sidecar
- X-Ray Sidecar
I'd like to configure Cloudwatch Agent to send Prometheus metrics published by Envoy to `prod/AppMesh` Namespace, so that I have all AppMesh-related metrics in one place, and can then use Cloudwatch `SEARCH` feature to group them on a single Dashboard Widget.
At the same time, however, the Service container may expose its own Prometheus metrics, and these should go to another Namespace (most likely named after the Service itself). This is currently not possible.
Contributor guide
Research direction
Start by tracing the EMF Processor configuration and the prometheus metric_declaration handling described in the issue. Determine how a namespace currently applies to declarations and identify the related configuration and validation tests. Done means separate declarations can route metrics from different scrape jobs to distinct CloudWatch namespaces without breaking the existing single-namespace configuration.
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
- 25/100