-
Damien Grisonnet authored
The current implementation of prometheus-adapter exposes a lot of metrics about the health of its aggregated apiserver. The issue is that the some of these metrics are not very useful in the context of prometheus-adapter, and we currently can't avoid exposing them since they are registered to the Kubernetes global Prometheus registry. Until this is improved in upstream Kubernetes, we could benefit from dropping some of the metrics that are not very useful. Before this change, in a default kube-prometheus installation, we would have 800+ series for prometheus-adapter against 400+, so we divided the number of series by two will focusing on the most valuable metrics for prometheus-adapter. Signed-off-by:
Damien Grisonnet <dgrisonn@redhat.com>
Damien Grisonnet authoredThe current implementation of prometheus-adapter exposes a lot of metrics about the health of its aggregated apiserver. The issue is that the some of these metrics are not very useful in the context of prometheus-adapter, and we currently can't avoid exposing them since they are registered to the Kubernetes global Prometheus registry. Until this is improved in upstream Kubernetes, we could benefit from dropping some of the metrics that are not very useful. Before this change, in a default kube-prometheus installation, we would have 800+ series for prometheus-adapter against 400+, so we divided the number of series by two will focusing on the most valuable metrics for prometheus-adapter. Signed-off-by:
Damien Grisonnet <dgrisonn@redhat.com>