topic Re: Unable to Select Existing Namespace "gcxi" While Creating Metric Event Alert for Pod Restarts in Container platforms

Unable to Select Existing Namespace "gcxi" While Creating Metric Event Alert for Pod Restarts

Aboud — Tue, 29 Apr 2025 07:48:47 GMT

Hi,

I am trying to create a custom metric event alert in Dynatrace to notify us when pods in the "gcxi" namespace restart.

I attempted to filter the dimension by Kubernetes namespace = gcxi, but this namespace does not appear in the list of available values, even though it exists in our OpenShift cluster and contains active pod.

Goal: Trigger alert when any pod in gcxi namespace restarts
Issue: Namespace gcxi not available in the “dimension filter” value list
Namespace status: Confirmed existing and active in the cluster

Request:
Could you help confirm:

Why the gcxi namespace is not showing in the dimension selector?
Is there a delay in Dynatrace discovering new namespaces or metrics from them?
How can we create a working alert for pod restarts specifically in gcxi?

Re: Unable to Select Existing Namespace "gcxi" While Creating Metric Event Alert for Pod Restarts

dannemca — Tue, 29 Apr 2025 20:42:38 GMT

Could you please paste here the metric you are using for this?

Are you able to see the namespace as a dimension for this metric? And if yes, in data explorer, are you able to see all others namespace as dimension value? Is this namespace appearing when you navigate thru the cluster/workload data?

Re: Unable to Select Existing Namespace "gcxi" While Creating Metric Event Alert for Pod Restarts

Aboud — Wed, 30 Apr 2025 06:15:33 GMT

After further investigation, we identified that the issue with the non-functional OneAgent pod restart alert was due to the selection of a specific Management Zone during the alert configuration. The namespace (cxi) and its associated pods were not included in that Management Zone, which caused the alert to return no data and appear inactive.

Once we removed the Management Zone filter from the alert, it began working as expected, and the restart data was properly reflected.

The issue is now resolved on our side.