Right now all CKF charms, which implements the metrics-endpoint, are using ServicePort and KubernetesServicePatch to expose metrics port. However, the MetricsEndpointProvider is using the unit IP address if "*" was provided.
This is why I believe that the exposing metrics port via service is not needed, and it could be dropped. When using "*", we only need to think about setting any additional event, which can cause unit IP to change, via refresh_event parameter.
Another option would be to use that service instead of "*" to define the target. e.g. f"istiod.{self.model.name}.svc:{METRICS_PORT}" from istio-pilot.
Option one has another benefit, when we do not need to hide metrics behind rbac-proxy, since the port do not need to be exposed.
Right now all CKF charms, which implements the
metrics-endpoint
, are usingServicePort
andKubernetesServicePatch
to expose metrics port. However, the MetricsEndpointProvider is using the unit IP address if"*"
was provided.For example:
will be translated to something like this:
at Grafana agent targets.
This is why I believe that the exposing metrics port via service is not needed, and it could be dropped. When using
"*"
, we only need to think about setting any additional event, which can cause unit IP to change, viarefresh_event
parameter.Another option would be to use that service instead of
"*"
to define the target. e.g.f"istiod.{self.model.name}.svc:{METRICS_PORT}"
from istio-pilot.Option one has another benefit, when we do not need to hide metrics behind rbac-proxy, since the port do not need to be exposed.
Charms using
"*"
:Charms using service name:
Charms using pod IP: