Add const labels to metrics

[bergmannf]

This PR adds const labels to metrics:

• awsAccountId to identify which account is affected (this is an alternative to https://gitlab.cee.redhat.com/service/app-interface/-/merge_requests/47155 as that PR is proving very difficult to get working in CI)
• service_code to identify which service the metric comes from
• quota_code to identify which quota is affected

This is a newer version of #49, but I couldn't reopen the old PR, due to having force-pushed additional commits.

[maorfr]

https://coreos.slack.com/archives/CNJPJSG3Z/p1663055216498999
https://gitlab.cee.redhat.com/service/app-interface/-/merge_requests/47155

[mrWinston]

RecordsPerHostedZones acutally do have their own quota code: L-E209CC9F

I think, we should include that as well

[janboll]

Please also check this ongoing discussion, cause it seems related: #62 (comment)
Our intention is to add a metric, that holds the labels, as done i.e. in kube-state-metrics. I think this would be a good addition to it, WDYT?

[bergmannf]

@janboll thanks for the pointer - I think we can live with that solution - it would make the app-interface queries a bit more complex, but I think that shouldn't be a big issue, as we only have to get one working and the rest is 90% copy-paste.

So if that is the approach you will use, I will update our static labels to use the same approach - I certainly don't want 2 divergent solutions to the same problem in this codebase.

@mrWinston WDYT?

[bergmannf]

After trying to migrate the metrics to use a single metric for constant labels, I am not so sure this works well for the metrics in the privatelink exporters.
The problem I mainly see is, that the metrics do not have a common identifier like the RDS metrics do (dbinstance_indentifier), but instead some even have no real identifier at all:

• VpcPerRegion
• HostedZonesPerAccount
• TransitGateways

This makes writing the group expression quite annoying, as we either have to rename the (primary) identifier to id and add this to the constant label as well - or relabel the metrics - but I feel that might make it a lot more complex than the current solution.
So maybe it would be easier to stick to the current approach as the metrics are missing a common identifier that they could share with the constant metric.

[AlexVulaj]

Seconding @bergmannf 's point above - the lack of a common ID for our metrics would make writing the group expressions grow in complexity for what I don't see is much gain. I'm personally in favor with the current approach for our needs here.

For example, in the following metrics there is no common id in the labels that we could group our metrics on easily. We could add all of the IDs to the labels for every metric, but this would lead to empty labels in multiple places (which I'm not sure is posssible).

aws_resources_exporter_vpc_interfacevpcendpointspervpc_usage{aws_account_id="644306948063",aws_region="eu-central-1",quota_code="L-29B6F2EB",service_code="vpc",vpcid="vpc-e6e3758c"} 0

aws_resources_exporter_vpc_routesperroutetable_usage{aws_account_id="644306948063",aws_region="us-east-1",quota_code="L-93826ACB",routetableid="rtb-00d603cf395eb905e",service_code="vpc",vpcid="vpc-088317c5566cbd781"} 1

[bergmannf]

@janboll So I think the privatelink metrics are better of with the constant labels being duplicated between the metrics.
Not having a common ID to merge on is no issue for RDS so I think using the k8s approach there is a good idea to save some space, but here it would make the metrics for constant labels too complex.

Would also be great - if this is fine for you - to get this PR reviewed, because @AlexVulaj would like to start working on the app-interface updates to the prometheusrules.

[janboll]

Your argument makes sense! Also the account ID is somewhat of a special case. I added some review comments to get this merged.