Skip to content

Expose Operator metrics out-of-the-box #323

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jmesnil opened this issue Jan 26, 2021 · 5 comments · Fixed by #486
Closed

Expose Operator metrics out-of-the-box #323

jmesnil opened this issue Jan 26, 2021 · 5 comments · Fixed by #486
Assignees
Labels

Comments

@jmesnil
Copy link

jmesnil commented Jan 26, 2021

The operator should leverage MicroProfile Metrics to expose metrics out-of-the-box if they are supported on the cluster.

In particular for the Quarkus extension, the smallrye-metrics extension should be installed.
If metrics are supported (by checking whether the ServiceMonitor CRD is installed), when the operator starts it should automatically create a ServiceMonitor (and a corresponding Service) that would point to its /metrics HTTP endpoints.

@metacosm
Copy link
Collaborator

@jmesnil could you point me to the documentation on that topic, please?

@jmesnil
Copy link
Author

jmesnil commented Mar 29, 2021

@metacosm for the (Go-based) WildFly operator, we added this feature: wildfly/wildfly-operator#25 (and the corresponding PR jmesnil/wildfly-operator@d859a33)

The whole idea is that if the application can expose Metrics (so for us, it would be having microprofile-metrics enabled), we create a ServiceMonitor resource that advertise to Prometheus how to reach the metrics endpoint.

So we check that the ServiceMonitor CRD is installed on the cluster (that can be on either OpenShift or a vanilla k8s cluster) and create all the required resources:

  • a Service that exposes the metrics endpoint (:80 /metrics by default iirc)
  • a ServiceMonitor that exposes this endpoint and selector labels to find the matching services

With that done, you can start using OpenShift monitoring stack to monitor Operator-controlled applications (provided you have enabled monitoring for user-defined projects)

If the operator is written in Java, we should also provide metrics for itself automatically if ServiceMonitor is available.

As the same logic applies to both the operator and the CR owned by the operator implementation, having a reusable library to do that would be great.

@csviri
Copy link
Collaborator

csviri commented Apr 9, 2021

Hi @jmesnil we originally planned to use micrometer to expose metrics about the internals of the operator, see issue:
#64
It's a nice abstraction over metrics. Unfortunatelly I never get to that. I'm not very familiar with microprofile metrics, not sure how does it compare with micrometer.

@jmesnil
Copy link
Author

jmesnil commented Apr 12, 2021

@csviri I'm not sure whether using micrometer or MP metrics really matter as long as the operator sdk provides the configuration to specify the metrics endpoint that will be consumed by the ServiceMonitor.

@laxmikantbpandhare
Copy link
Member

working on the similar issue #64

@laxmikantbpandhare laxmikantbpandhare self-assigned this Jul 29, 2021
@laxmikantbpandhare laxmikantbpandhare added feature triage/duplicate Indicates an issue is a duplicate of other open issue. labels Jul 29, 2021
@laxmikantbpandhare laxmikantbpandhare linked a pull request Aug 6, 2021 that will close this issue
@metacosm metacosm removed the triage/duplicate Indicates an issue is a duplicate of other open issue. label Aug 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants