ACM-14962: init MCOA metrics #1659
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: thibaultmg The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
thibaultmg
force-pushed
the
ACM_14962_init_mocoa_metrics
branch
from
553efbb
to
413717f
Compare
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
|
/retest |
Signed-off-by: Thibault Mange <[email protected]>
Signed-off-by: Thibault Mange <[email protected]>
|
|
@thibaultmg: The following test failed, say
Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
| { | ||
| ConfigGroupResource: addonapiv1alpha1.ConfigGroupResource{ | ||
| Group: prometheusalpha1.SchemeGroupVersion.Group, | ||
| Resource: prometheusalpha1.ScrapeConfigName, | ||
| }, | ||
| ConfigReferent: addonapiv1alpha1.ConfigReferent{ | ||
| Name: "platform-metrics-default", | ||
| Namespace: mcoconfig.GetDefaultNamespace(), | ||
| }, | ||
| }, | ||
| { | ||
| ConfigGroupResource: addonapiv1alpha1.ConfigGroupResource{ | ||
| Group: prometheusv1.SchemeGroupVersion.Group, | ||
| Resource: prometheusv1.PrometheusRuleName, | ||
| }, | ||
| ConfigReferent: addonapiv1alpha1.ConfigReferent{ | ||
| Name: "platform-rules-default", | ||
| Namespace: mcoconfig.GetDefaultNamespace(), | ||
| }, | ||
| }, |
There was a problem hiding this comment.
Do you really want to reference these ones out of the get go?
| @@ -212,6 +341,14 @@ func (r *MCORenderer) renderAddonDeploymentConfig( | |||
| } | |||
| } | |||
|
|
|||
| if (cs.Platform != nil && cs.Platform.Metrics.Collection.Enabled) || (cs.UserWorkloads != nil && cs.UserWorkloads.Metrics.Collection.Enabled) { | |||
| obsAPIURL, err := mcoconfig.GetObsAPIExternalURL(context.TODO(), r.kubeClient, namespace) | |||
There was a problem hiding this comment.
Instead of getting this value here could we add a field to the renderOptions.MCOAOptions and use it directly here? This would:
- Make progress to eventually stop using ctx.TODO()
- Simplify the code path for this function making it testing also simpler
There was a problem hiding this comment.
On the value itself I'm still not sure about the use of the key signalsHubEndpoint to represent it, mainly because this is still a very metrics oriented value. I'm thinking if we could split it so that on the short term would be more useful to more signals.
Taking the following two endpoints on the hub:
https://obs-api-open-cluster-management-observability.apps.myhubcom/api/metrics/v1https://mcoa-managed-instance-openshift-logging.apps.myhub.foo.com/api/logs/v1/cluster-1/otlp/v1/logs
Then:
hubHostname(would be there if any Managed Storage is enabled):apps.myhub.fooormyhub.foohubMetricsRoute:obs-api-open-cluster-management-observability
WDYT? I'm suggesting something like this because then logs&traces would be able to re-use hubHostname. Regardless if we do unified OBS Api or separated ones. (This could also be addressed in a follow up)
| // PlatformMetricsCollectionSpec defines the spec for the addon to collect and forward metrics | ||
| // from fleet managed clusters. | ||
| type PlatformMetricsCollectionSpec struct { | ||
| // Enabled defines a flag to enable/disable the platform metrics collection. | ||
| // | ||
| // +optional | ||
| // +kubebuilder:validation:Optional | ||
| Enabled bool `json:"enabled,omitempty"` | ||
| } |
There was a problem hiding this comment.
In this initial version since metrics will be taking a managed approach to metric collection I wonder if these values are the best ones to use since the equivalent for logs & traces currently correlates to an unmanaged approach where the user fully controls the root resources. I would be in favor of deliberating a bit how we want these different scenarios to be exposed to users. This correlates with stolostron/multicluster-observability-addon#88 (comment) maybe a discussion for the nexus syncs
This PR initialises metrics collection for MCOA. More precisely, it:
Relates to the MCOA PR: stolostron/multicluster-observability-addon#77
Notes: