Operator-sdk: Operator specific metrics as part of the operator-metering story

[lilic]

The main problem right now is that, kube-state-metrics only exposes upstream metrics, not the operator specific metrics. We should create a helper function to easily register custom metrics that will expose the needed information for the operator-metering to create billing reports. That would live in the operator, and the kube-state-metrics -style metrics will then be exposed by the operator itself instead of kube-state-metrics.

We can start by extracting common logic in kube-state-metrics into a library and use that in the helper function in operator-sdk.

Any thoughts or opinions on the above would be helpful @chancez @brancz @hasbro17 @spahl (or anyone else really)

[brancz]

I think this would be very helpful, in fact there is already an effort to also have an "openshift-state-metrics" exporter being written which is aiming to extract the same set of libraries from kube-state-metrics. We already have an example in the Prometheus Operator for these types of metrics, for the Prometheus and Alertmanager objects. I'm not entirely clear on what we want to "meter", but my idea would be to meter on let's say JBoss usage (in the example of a JBoss Operator let's say), which could just be an info metric that would be:

jboss_info{namespace="default", jboss="my-jboss"} 1

For each object managed by the particular jboss operator. Then we could meter on usage of that particular operator.

In specific the library that would be extracted out of kube-state-metrics that I'm imagining is a simplification of the "collector" as all collectors are primarily about extracting information out of a Kubernetes object and creating a metric directly out of that, so we should optimize for that use case.

@mxinden is currently working on a performance optimization on kube-state-metrics that impacts the architecture rather heavily, but we're getting closer to merging this, so I would suggest to hold off on extracting the library until this is merged (RE: https://github.com/kubernetes/kube-state-metrics/pull/534).

[chancez]

I like what's been suggested. I also think we'll want to start discussion on how we get serviceMonitors created as that will be a very useful piece as well I imagine.

[lilic]

@chancez not sure if this is what you meant, but there is already a PR out for ServiceMonitor helpers https://github.com/operator-framework/operator-sdk/pull/590 Sorry did not ping you on it!

[chancez]

Ah, yes that would be what I mean.

[mxinden]

As a heads up https://github.com/kubernetes/kube-state-metrics/pull/534 just merged. Feel free to reach out to me in regards to reusing parts of the optimized metrics exposition logic for the operator framework.

[lilic]

@mxinden Thanks, will do!

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[lilic]

/remove-lifecycle stale