add kcp operator custom metrics

[olamilekan000]

Summary

Change adds custom kcp operator metrics to Prometheus

What Type of PR Is This?

Related Issue(s)

Fixes 25

Release Notes

Added custom kcp-operator metrics to prometheus

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign xrstf for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[mjudeikis]

@embik @xrstf your take here would be appreciated

[mjudeikis]

Can we use cache (all below too) here?

[olamilekan000]

We might not get the actual metric values if they're cached, and besides, I think the Controller-runtime already implements caching by default

[mjudeikis]

Any reason why this is just (I think this is open to discussion @embik )

kcp_operator_object_count{type=rootshard}

Status of these rootshard, shardl frontproxy cache server should be same ?

[mjudeikis]

This would save us a bit of cardinality:
currently:
4 metrics * 2 dimension = 8
suggested:
1 metrcic * 3 dimensions = 3.

Kubeconfig and certificates would stay separate.

[xrstf]

I am entirely unconvinced that a _count metric is even useful. Users could simple count() other metrics.

[olamilekan000]

So, this can be removed?

[xrstf]

If we have other metrics with one instance per object, then I'd say yes.

[mjudeikis]

This is still a bit verbose. One metrics with counts with component types would enough.

I am entirely unconvinced that a _count metric is even useful. Users could simple count() other metrics
Yes, but it's easier for the user than having an explicit metric. Otherwise, they need to go and "reverse engineer" what they need to count to get the desired result.

[mjudeikis]

Not sure what this metric is about. Need better docs

[olamilekan000]

It shows the status of objects installed.
For example, you can have something like this.

kcp_operator_condition_status{condition_type="Available",namespace="default",resource_name="frontproxy-sample",resource_type="frontproxy"} 1
kcp_operator_condition_status{condition_type="Available",namespace="default",resource_name="shard-sample",resource_type="rootshard"} 0
kcp_operator_condition_status{condition_type="RootShard",namespace="default",resource_name="frontproxy-sample",resource_type="frontproxy"} 1

[xrstf]

I wouldbe fine with one metric for the conditions.

[olamilekan000]

I wouldbe fine with one metric for the conditions.

This is not too clear. Does it mean you're okay with the current implementation?

[xrstf]

Yep.

[olamilekan000]

/retest

[mjudeikis]

still same few comments

[mjudeikis]

This is still a bit verbose. One metrics with counts with component types would enough.

I am entirely unconvinced that a _count metric is even useful. Users could simple count() other metrics
Yes, but it's easier for the user than having an explicit metric. Otherwise, they need to go and "reverse engineer" what they need to count to get the desired result.