[FEATURE] Ensure info metrics will have compatibility with prometheus OTEL implementation

[kgeckhart]

Is there an existing issue for this?

• I have searched the existing issues

Feature description

YACE exports info for resource metadata like tags. This normalizes the data off of the CloudWatch metrics and produces a simplified metric model that can be built up via prometheus joins.

As a part of making Prometheus more otel compatible they have developed a more standardized info function to dramatically reduce the complexity of these joins, https://prometheus.io/docs/prometheus/latest/querying/functions/#info-experimental. The current experimental version considers metrics named target_info and expects to be able to join on an instance and job. The syntax allows you to override the metric to use as the info allowing the current aws_<service>_info metrics to function ex. info(aws_ec2_metric, {__name__=~"aws_ec2_info"}). But, ATM yace uses a name label where we need instance. We have a few steps to take,

Step 1: Ensure we provide compatibility with the info function.

The simplest solution here is to duplicate the name label as instance on metrics and info metrics.
We can then look to deprecate the name label and remove it at a later date

Step 2: Consider exporting target_info over aws_<service>_info

This isn't a true requirement for compatibility but it would ensure the query syntax is a simple as possible to use.

Using a config flag we could optionally export target_info or aws_<service>_info. We would slowly look to deprecate aws_<service>_info for the more standardized target_info.

What might the configuration look like?

• useTargetInfo

Anything else?

If we wait long enough this is more than likely to be considered a bug rather than a feature.

[Pokom]

I actually just ran into this trying to join data from https://github.com/grafana/cloudcost-exporter/blob/main/docs/metrics/aws/ec2.md to calculate the costs of an instance and was surprised to see the value is returned as zero. Is there any specific reason why info metrics are exported as zero? IE will it be a backwards incompatible change?

Appreciate that you dropped a breadcrumb on how to overcome it using the + operator. I've usually used a count or group hack to get the value back to one.

[kgeckhart]

Is there any specific reason why info metrics are exported as zero? IE will it be a backwards incompatible change?

I'm not sure as I think this one largely predates me and @cristiangreco. I found that it's been 0 for at least 6 years now, https://github.com/nerdswords/yet-another-cloudwatch-exporter/pull/4/files#diff-dec443ff93e42df03c5316555338fccf81a2cb1ec4a646276a02cf034e6895cdR88-R127. Pretty sure it's been zero since the info metrics existed.

Changing it to 1 now is going to break anyone who currently has queries which depend on the value being zero 😬

[jeschkies]

Would we have to add deployment_environment?

[kgeckhart]

Would we have to add deployment_environment?

Edit: Yes It doesn't look like it's a requirement for info function compatibility and I don't think we could safely introduce it with any meaningful value. I think for now we can leave it off.

I'll take a pass at the ticket now that the info function implementation is better understood. ATM the value being 0 isn't a problem but the structure of the current info metric is. The function expects an instance label + job label where we currently use name + job. We should also look to move to target_info vs aws_<service>_info which will work very cleanly with info vs needing more complex joins still.