Pass `aws_dimension_select` filter values in `ListMetricsRequest`.

Currently, we use aws_dimension_select values to filter out metrics after we list all the metrics with given dimensions. The scarpe becomes time consuming when there more metrics with a given dimension… for example dynamodb SuccessfulRequestLatency metric with TableName, Operation as dimensions. There are around 6k metrics and scare takes around 5min. But, Here we are intrested in getting metrics for a single table even if specify the table name in aws_dimension_select it stll takes same amount of time due to below reason.

In getDimensions() (line 211) function, while creating the ListMetricsRequest object we just add dimension Name but not the filter Value even if they are specified as part of aws_dimension_select.

      for (String dimension: rule.awsDimensions) {
        dimensionFilters.add(new DimensionFilter().withName(dimension));
      }

and filter out it afterwards in useMetric() function. I don’t what is the intention doing this way.

We can reduce the scrape time by passing the filter values in the scrape request itself. Something like below.

        for (String dimension: rule.awsDimensions) {
            if (rule.awsDimensionSelect != null && rule.awsDimensionSelect.get(dimension) != null) {
                List<String> filterValues = rule.awsDimensionSelect.get(dimension);
                for (String value : filterValues) {
                    dimensionFilters.add(new DimensionFilter().withName(dimension).withValue(value));
                }
            }
            else {
                dimensionFilters.add(new DimensionFilter().withName(dimension));
            }
        }

after the above changes my scrape took under a sec from 5 min. That’s a drastic improvement.

If the maintainers feel this is a valid issue I can raise a PR with this changes.

[brian-brazil]

Unlike Go, Java regexes do support negative lookaheads so I don’t see a need to add more options for something that’s already possible.

[brian-brazil]

This was done.