Situation
Elastic offers multiple integrations to collect metrics from CloudWatch in the AWS integration package.
Some are "specialized" and only collect metrics from one AWS service, like the EC2, ECS, Redshift, and others. However, one "generic" integration allows users to write the integration configs to collect metrics from any AWS service. The generic integration is excellent for collecting metrics from services we have not supported.
All integrations (specialized and generic), collect metric dimensions as aws.dimentions.* fields.
Problem
Unfortunately, not all metrics integrations use the exact mapping for the aws.dimentions field.
| Integration |
Type |
Mapping for aws.dimentions |
| Collect EC2 logs from CloudWatch |
Specialized |
object |
| Collect metrics from CloudWatch |
Generic |
flattened |
With different mappings, it's hard for users to correlate dimensions and build dashboards.
Solution
Work in progress.
We need to identify:
- What is the best mapping to represent AWS metric dimensions
- Describe a custom mapping to work around the issue in the short term (if it exists).
- Identify a mid-long term solution to bring uniformity to dimensions field mapping.
References
Related:
Situation
Elastic offers multiple integrations to collect metrics from CloudWatch in the AWS integration package.
Some are "specialized" and only collect metrics from one AWS service, like the EC2, ECS, Redshift, and others. However, one "generic" integration allows users to write the integration configs to collect metrics from any AWS service. The generic integration is excellent for collecting metrics from services we have not supported.
All integrations (specialized and generic), collect metric dimensions as
aws.dimentions.*fields.Problem
Unfortunately, not all metrics integrations use the exact mapping for the
aws.dimentionsfield.objectflattenedWith different mappings, it's hard for users to correlate dimensions and build dashboards.
Solution
Work in progress.
We need to identify:
References
Related: