aws / aws/amazon-cloudwatch-agent

Support specifying multiple Namespaces for EMF

Open
#377 4 comments 4 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.