-
Notifications
You must be signed in to change notification settings - Fork 220
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
Comments
@jmesnil could you point me to the documentation on that topic, please? |
@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 So we check that the
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 As the same logic applies to both the |
@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 |
working on the similar issue #64 |
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 aServiceMonitor
(and a correspondingService
) that would point to its/metrics
HTTP endpoints.The text was updated successfully, but these errors were encountered: