-
Notifications
You must be signed in to change notification settings - Fork 135
Adding support for --listen-metrics-url parameter #157
Comments
I agree, exposing the metrics endpoint would be useful. It's a great idea, thanks for suggesting it @suhrud-kumar!
I'm skeptical of this motivation. Can you explain why someone might not want to "add etcd certs in their monitoring system?" (Thinking out loud: The etcd metrics endpoint could be used by a "pull" monitoring system (like Prometheus), and that system would only need a client certificate. The metrics client certificate, as far as I can tell, would have to be the same as the normal client certificate. So, unless etcd authorization is enabled, the monitoring system would have access to etcd data. I see why that's not desirable.) I found some related discussion here: etcd-io/etcd#8060 (comment) If you're able to work on it, please use the "/lifecycle active" command. If you have any implementation questions, please ask in #etcdadm channel in Kubernetes slack. /priority important-longterm |
Just to clarify, metrics endpoint will be exposed by default but in https (if installed using etcdadm), by adding this parameter an additional metrics endpoint will be exposed in http
Yes that's correct, since these certs can be used to access etcd data (thereby k8s secrets), we don't want to use them in other places unless absolutely required. And etcd provides a way to not use them for metrics endpoint (using above parameter). Before starting working on this, I have a query on implementation. I have thought of adding one of three below arguments to implement this parameter in etcdadm.
This requires user to know ip address of node for etcd init or join (can be done using automation scripts) but most configurable.
@dlipovetsky |
As you point out, this is the most configurable option. And etcdadm can provide a sane default (as it would have to do, if we chose one of the other options). The URL breaks down into
|
Well technically it can also be https, and users will have to access endpoint using etcd client certs. But a https /metrics endpoint will be available by default anyway, so this may not be much useful. We can keep default scheme as http. /lifecycle active |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
etcd has support for providing separate address for metrics endpoint.
This can be useful if the standard endpoint is configured with mutual (client) TLS authentication, but a load balancer or monitoring service still needs access to the metrics or health check. (etcd api will be served over https but /metrics endpoint will served over http )
Since etcdadm creates etcd in TLS be default, this will be useful for folks who don't to add etcd certs in their monitoring systems (for security reasons).
Currently we implemented a small hack to get around this, but it would be great if this is supported by etcdadm.
Let me know what you guys think, I can try to implement this with some guidance.
References:
https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/configuration.md#--listen-metrics-urls
https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/monitoring.md#metrics-endpoint
The text was updated successfully, but these errors were encountered: