Add support for aggregations.

[tcolgate]

This adds support for setting an aggregation. This aggregation is used
for all metrics collection by the exporter. It adjust the resulting
metric names into prometheus recording rule style to allow for
different exporters to collect different aggregations.

We add support for passing the fields, reducer, aligner and align
duration as per other options.

resulting metrics look as follows

'''target_proxy_name_response_code:stackdriver_https_lb_rule_loadbalancing_googleapis_com_https_backend_latencies:sum_bucket{...}```

[tcolgate]

This is just work in progress to see if you would be interested in this, and if so, to discuss the overall design. Issues with this implementaiton:

• The aggregation is applied to the entire exporter, not per metrics prefix (it would make more sense, but the resulting UI could be a big gnarly)
• The metrics names aren't quite right, this could be fixed by manuall producing the const histsogram metrics.
• Not fixed up the tests as yet.

[SuperQ]

This is an interesting idea. It looks like the change needs to be rebaesd.

One comment, exporters should not use : in metric names, since this is reserved for recording rules.

[tcolgate]

@SuperQ so, my thinking here was that the metric is already aggregated so that the names attempt to match what you'd get if you created a recording rule for the same purpose. Other than replacing with an underscore, do you have any other ideas regarding naming?

[tcolgate]

FWIW, we never used this code, because I didn't really ant to maintain yet another fork in house, but I'd be happy to polish this PR , since it does seem like useful functionality. May not have time in the next two weeks though.

[SuperQ]

I think we can just close this. I think aggregating in the exporter might be a bit more than we want to support.

[SuperQ]

After having a discussion on Slack, and looking at some of the use of Stackdriver data we have, this is more useful than I previously thought.

[SuperQ]

Any interest in reviving this?

[SuperQ]

I experimented with this a bit, I think there needs to be some changes.

In order for this to be useful generally, we need to supply per-metrics-prefix aggregation requests. Otherwise it will try and apply aggregations to prefixes that don't make sense.

I'm thinking something along the lines of this:

networking.googleapis.com/vm_flow/egress_bytes_count|fields=metric.label.remote_subnetwork;aligner=ALIGN_DELTA;reducer=REDUCE_SUM;period=1m

Part of the problem here, is we still accept ENV vars for input. This makes command line parsing much more difficult, as we need a lot of string separators.

IMO, I think we need to drop the ENV vars, and change the --monitoring.metrics-type-prefixes to a single input, multi-flag.

[tcolgate]

Sorry for the late response, I'll need to take some time to get my head around this again.

[SuperQ]

@tcolgate No worries. I had some more thoughts about this, and I think the best way forward would be to move the metrics prefixes to a config file. I've filed #106 to track this idea.

Basically, it would be more like the balckbox/snmp exporters. Rather than just a list of "metrics prefixes", there would be scrape modules with different prefixes and aggregations.

[priximmo]

Hi, @tcolgate have you find another solution to collect stackdriver_https_lb_rule_loadbalancing_googleapis_com_https_backend_latencies. I search to scrape the same metric with prometheus. Cardinalities of this metric don't help us.

Maybe have you found another solution ?

Thank you for your help.

[yyzh1]

sorry for digging up an old thread. is this still being worked on?

[SuperQ]

This needs a rebase.