`ManagedMetric` Not Filtering by kind/group/version

[rouzbehsedighi]

The ManagedMetric resource does not respect the spec's kind, group, or version fields. It appears to collect metrics from all Crossplane-managed resources, regardless of the specified fields.

Expected Behavior:

Given the following ManagedMetric:

apiVersion: metrics.openmcp.cloud/v1alpha1
kind: ManagedMetric
metadata:
  name: managed-metric-subaccount
  namespace: metrics-operator
spec:
  name: managed-metric-subaccount
  description: Status metric created by an Operator
  kind: Subaccount
  group: account.btp.sap.crossplane.io
  version: v1alpha1
  interval: "1m"

It should only collect metrics from resources of:

apiVersion: account.btp.sap.crossplane.io
kind: Subaccount

Actual Behavior:

The ManagedMetric is collecting metrics from all managed resources, including unrelated kinds like Azure PostgreSQL.

Additionally, all the retrieved metrics are reported as if the resource kind is Subaccount, even when the actual resource is, for example, Azure Keyvault.

[rdksap]

The ManagedMetric is collecting metrics from all managed resources, including unrelated kinds like Azure PostgreSQL.

It seems filtering by GKV is missing and could be added when filtering for categories, i.e. here:

metrics-operator/internal/orchestrator/managedhandler.go

Lines 153 to 158 in 73f1f7e

	var resourceCRDs []apiextensionsv1.CustomResourceDefinition
	for _, crd := range crds.Items {
	if h.hasCategory("crossplane", crd) && h.hasCategory("managed", crd) { // filter previously acquired crds
	resourceCRDs = append(resourceCRDs, crd)
	}
	}

Additionally, all the retrieved metrics are reported as if the resource kind is Subaccount, even when the actual resource is, for example, Azure Keyvault.

GVK of each managed resource is set based on spec, instead of actual resource in:

metrics-operator/internal/orchestrator/managedhandler.go

Lines 68 to 71 in 73f1f7e

	// Add GVK dimensions
	dataPoint.AddDimension(KIND, h.metric.Spec.Kind)
	dataPoint.AddDimension(GROUP, h.metric.Spec.Group)
	dataPoint.AddDimension(VERSION, h.metric.Spec.Version)

Should be e.g. cr.MangedResource.Kind/Group/Version

[maximiliantech]

I have synced about this bug with @mirzakopic and it seems that we have multiple bugs here at the same time:

Background to ManagedMetric API

The ManagedMetric API is important to cover the specific parts that are unique to the Crossplane framework of handling resources. For example: The ManagedMetric will always add the dimensions Synced and Ready and sends this to the data sink. These status conditions are unique for resources that come from any Crossplane provider. You will not see these fields in standard Kubernetes resources.

Therefore, @mirzakopic introduced the ManagedMetric resource kind as way to define an "extension" for more specific metrics in the Kubernetes ecosystem instead of blowing up the standard Metric resource spec.

Bugs that are occurring in this issue

1. Resource kind gets overwritten

As @rdksap pointed out in #47 (comment), we need to fix these lines in order to not overwrite the name of a resource kind in every ManagedResource we collect.

But additionally, this leads to...

2. Bug in filtering resources

There seems to be a bug in the filtering. The GVK in the ManagedMetric.spec is meant to be used to filter resources in each of the dimensions. Let's have a look at the actually expected output for the given ManagedMetric configuration.

Input

apiVersion: metrics.openmcp.cloud/v1alpha1
kind: ManagedMetric
metadata:
  name: managed-metric-subaccount
  namespace: metrics-operator
spec:
  name: managed-metric-subaccount
  description: Status metric created by an Operator
  kind: Subaccount
  group: account.btp.sap.crossplane.io
  version: v1alpha1
  interval: "1m"

Expected Output

The output should be the number of resources in exactly this group, version, kind.

apiVersion	kind	count
account.btp.sap.crossplane.io/v1alpha1	Subaccount	1

Input

apiVersion: metrics.openmcp.cloud/v1alpha1
kind: ManagedMetric
metadata:
  name: managed-metric-subaccount
  namespace: metrics-operator
spec:
  name: managed-metric-subaccount
  description: Status metric created by an Operator
  # no kind configured
  group: account.btp.sap.crossplane.io
  version: v1alpha1
  interval: "1m"

Expected Output

All Managed Resources in group account.btp.sap.crossplane.io and version v1alpha1.

apiVersion	kind	count
account.btp.sap.crossplane.io/v1alpha1	Subaccount	1
account.btp.sap.crossplane.io/v1alpha1	Entitlement	4

Input

apiVersion: metrics.openmcp.cloud/v1alpha1
kind: ManagedMetric
metadata:
  name: managed-metric-subaccount
  namespace: metrics-operator
spec:
  name: managed-metric-subaccount
  description: Status metric created by an Operator
  # no kind configured
  # no group configured
  version: v1alpha1
  interval: "1m"

Expected Output

All Managed Resources in version v1alpha1, e.g. resources from BTP provider and Kubernetes provider.

apiVersion	kind	count
account.btp.sap.crossplane.io/v1alpha1	Subaccount	1
account.btp.sap.crossplane.io/v1alpha1	Entitlement	4
kubernetes.m.crossplane.io/v1alpha1	Object	2

Input

apiVersion: metrics.openmcp.cloud/v1alpha1
kind: ManagedMetric
metadata:
  name: managed-metric-subaccount
  namespace: metrics-operator
spec:
  name: managed-metric-subaccount
  description: Status metric created by an Operator
  # no kind configured
  # no group configured
  # no version configured
  interval: "1m"

Expected Output

All Managed Resources in any group, any version and any kind.

apiVersion	kind	count
account.btp.sap.crossplane.io/v1alpha1	Subaccount	1
account.btp.sap.crossplane.io/v1alpha1	Entitlement	4
kubernetes.m.crossplane.io/v1alpha1	Object	2
s3.aws.m.upbound.io/v1beta1	Bucket	11

➡️ This can go on for more combinations of GVK configuration in the ManagedMetric resource.

Task

The task of this ticket would be to solve the filtering (Second bug) and with that also the first bug described in #47 (comment)

[maximiliantech]

Just linking #79 to this issue since this one will resolve the inconsistencies in the spec for configuring GVK.