Changes to add count of A records of source and registry as metrics

[adityask2]

Changes to count of add A records of registry and source as gauge metric
external_dns_registry_a_records, external_dns_source_a_records

Description

The existing metrics -
external_dns_registry_endpoints_total & external_dns_source_endpoints_total gives a cumulative count of records all records (A, SRV, CNAME, TXT).

We have a metric - external_dns_controller_verified_records which gives the intersection of A records between source & regsitry. However, in order to determined how many records are yet to be synced to registry, we need count of total A records in registry & source.

Testing - Tested the changes.

Checklist

• Unit tests updated
• End user documentation updated

[Raffo]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adityask2, Raffo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Raffo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[timbunce]

Was there some reason this didn't use a vector label for the type, eg external_dns_registry_records{type="A"}

[adityask2]

@timbunce No specific reason. The current name appeared to convey the required info.

[timbunce]

The current name appeared to convey the required info.

Thanks. It does.

My concern is that it doesn't follow best practice in metric naming. That'll become more of a concern if/when metrics for more answer types are desired (eg CNAME, AAAA, etc). Adding two more metrics for each new type places extra load on the metrics system. It's also much harder to query, e.g. "sum across record types excluding AAAA" would simply be sum(external_dns_registry_records{type!="AAAA"}) with vector based metrics.

I may be adding metrics myself before long. In which case I'd add new vector based metrics and mark these as deprecated. That way anyone using them can migrate to the new ones in their own time.

Thanks again @adityask2.