@oneuptime/common 12.0.33 → 12.0.34

package/Tests/Types/Monitor/KubernetesMetricCatalog.test.ts

@@ -115,4 +115,193 @@ describe("KubernetesMetricCatalog", () => {
       getKubernetesMetricByMetricName("k8s.pod.memory.usage"),
     ).toBeDefined();
   });
+
+  /*
+   * The catalog's `unit` is rendered straight into the metric picker's
+   * dropdown label (`${friendlyName} (${unit})`), and its `description`
+   * into the help text below it. Both used to claim `k8s.*.cpu.utilization`
+   * was a percentage. It is not: kubeletstats emits it as CPU *cores in
+   * use* (UsageNanoCores / 1e9) carrying UCUM unit "1". A user who read
+   * "(%)" and typed 90 built a monitor comparing 90 against values around
+   * 0.18 — a silently dead monitor with no error surfaced anywhere.
+   */
+  describe("the kubeletstats cores gauges are not labelled as percentages", () => {
+    const coresGaugeNamePattern: RegExp = /\.cpu\.utilization$/i;
+
+    const coresGauges: Array<KubernetesMetricDefinition> = allMetrics.filter(
+      (m: KubernetesMetricDefinition) => {
+        return coresGaugeNamePattern.test(m.metricName);
+      },
+    );
+
+    test("the catalog still carries both of them", () => {
+      expect(coresGauges.length).toBeGreaterThan(0);
+    });
+
+    test("no .cpu.utilization entry declares a percent unit", () => {
+      for (const metric of coresGauges) {
+        expect(metric.unit).not.toBe("%");
+        expect(metric.unit).not.toBe("percent");
+      }
+    });
+
+    test("no .cpu.utilization description calls the value a percentage", () => {
+      /*
+       * The unit was only half the lie — the description said "CPU usage
+       * percentage for pods" too, and a unit-only assertion would miss it.
+       * The word may still appear while explaining how to DERIVE one, so
+       * the guard is on the claim, not the word.
+       */
+      for (const metric of coresGauges) {
+        expect(metric.description.toLowerCase()).not.toContain(
+          "usage percentage",
+        );
+        expect(metric.description.toLowerCase()).toContain("cores");
+      }
+    });
+
+    test("both cores gauges are declared in cores", () => {
+      expect(
+        getKubernetesMetricByMetricName("k8s.pod.cpu.utilization")?.unit,
+      ).toBe("cores");
+      expect(
+        getKubernetesMetricByMetricName("k8s.node.cpu.utilization")?.unit,
+      ).toBe("cores");
+    });
+
+    test("the friendlyName does not repeat the unit the picker appends", () => {
+      /*
+       * KubernetesMetricPicker builds its label as
+       * `${friendlyName}${unit ? ` (${unit})` : ""}`. A friendlyName of
+       * "Pod CPU Usage (Cores)" would render "Pod CPU Usage (Cores) (cores)".
+       */
+      for (const metric of allMetrics) {
+        if (!metric.unit) {
+          continue;
+        }
+        expect(metric.friendlyName.toLowerCase()).not.toContain(
+          `(${metric.unit.toLowerCase()})`,
+        );
+      }
+    });
+  });
+
+  /*
+   * "Node Disk I/O" was wired to `k8s.node.filesystem.available` — free
+   * space remaining, not I/O. A user alerting on node disk activity built
+   * a "greater than" monitor on headroom, which fires when the disk is
+   * EMPTY and stays silent as it fills.
+   */
+  describe("entries are named for the metric they are actually wired to", () => {
+    test("the mislabelled Node Disk I/O entry is gone", () => {
+      expect(getKubernetesMetricById("node-disk-io")).toBeUndefined();
+    });
+
+    test("it is replaced by an honest free-space entry", () => {
+      const entry: KubernetesMetricDefinition | undefined =
+        getKubernetesMetricById("node-filesystem-available");
+
+      expect(entry).toBeDefined();
+      expect(entry?.metricName).toBe("k8s.node.filesystem.available");
+      expect(entry?.friendlyName).toBe("Node Filesystem Available");
+      // Headroom alerts ask "how low did it get", not "what was the mean".
+      expect(entry?.defaultAggregation).toBe(AggregationType.Min);
+    });
+
+    test("no throughput-sounding name points at a level/limit gauge", () => {
+      /*
+       * The generalised guard: catches the NEXT entry named for one thing
+       * and wired to another, rather than just this one.
+       */
+      const throughputSoundingName: RegExp = /disk i\/o|network|throughput/i;
+
+      for (const metric of allMetrics) {
+        if (throughputSoundingName.test(metric.friendlyName)) {
+          expect(metric.metricName).not.toMatch(
+            /\.(available|capacity|limit|request)$/,
+          );
+        }
+      }
+    });
+  });
+
+  /*
+   * DashboardTemplates documents this trap after being bitten by it: these
+   * are per-resource gauges that re-emit on every scrape, so summing across
+   * the window multiplies (resources x scrapes) and produces numbers in the
+   * hundreds for a tiny cluster. `k8s.pod.phase` is worse still — its value
+   * is an enum code (1 = Pending ... 5 = Unknown), so a Sum is an arithmetic
+   * total of category labels.
+   */
+  describe("categorical and cumulative gauges are never summed", () => {
+    test("k8s.pod.phase does not default to Sum", () => {
+      const phase: KubernetesMetricDefinition | undefined =
+        getKubernetesMetricByMetricName("k8s.pod.phase");
+
+      expect(phase).toBeDefined();
+      expect(phase?.defaultAggregation).not.toBe(AggregationType.Sum);
+      // A phase code is dimensionless; "count" was the wrong dimension.
+      expect(phase?.unit).not.toBe("count");
+    });
+
+    test("no state/phase/condition gauge defaults to Sum", () => {
+      const describesAState: RegExp = /\bphase\b|\bcondition\b|\bstate\b|1 = /i;
+
+      for (const metric of allMetrics) {
+        if (describesAState.test(metric.description)) {
+          expect(metric.defaultAggregation).not.toBe(AggregationType.Sum);
+        }
+      }
+    });
+
+    test("no cumulative counter defaults to Sum", () => {
+      const describesACounter: RegExp = /cumulative/i;
+
+      for (const metric of allMetrics) {
+        if (describesACounter.test(metric.description)) {
+          expect(metric.defaultAggregation).not.toBe(AggregationType.Sum);
+        }
+      }
+    });
+  });
+
+  /*
+   * KubernetesMetricDefinition has no field for a datapoint-attribute
+   * filter, and KubernetesMonitorStepForm passes none, so every entry
+   * queries EVERY series of its metric. "Pod Network Receive" therefore
+   * summed receive AND transmit together over a cumulative counter —
+   * roughly double the real receive volume, and a chatty transmitter
+   * tripping a receive threshold it never crossed.
+   */
+  describe("no entry promises a filter the definition cannot express", () => {
+    test("the undeliverable directional entry is gone", () => {
+      expect(getKubernetesMetricById("pod-network-io-receive")).toBeUndefined();
+      expect(getKubernetesMetricById("pod-network-io")).toBeDefined();
+    });
+
+    test("no friendlyName claims a direction while carrying no filter", () => {
+      /*
+       * Becomes a real per-entry filter check the moment an optional
+       * `attributes` field lands on KubernetesMetricDefinition.
+       */
+      const hasAttributeFilterField: boolean = allMetrics.some(
+        (m: KubernetesMetricDefinition) => {
+          return (
+            (m as KubernetesMetricDefinition & { attributes?: unknown })
+              .attributes !== undefined
+          );
+        },
+      );
+
+      if (hasAttributeFilterField) {
+        return;
+      }
+
+      for (const metric of allMetrics) {
+        expect(metric.friendlyName).not.toMatch(
+          /\b(receive|transmit|ingress|egress)\b/i,
+        );
+      }
+    });
+  });
 });

package/Tests/Types/Monitor/KubernetesTemplateGroupByKeys.test.ts

@@ -30,6 +30,23 @@ import ObjectID from "../../../Types/ObjectID";
  *   - Cluster-scalar templates must stay UNGROUPED. etcd leadership, API
  *     server throttling and scheduler queue depth are one value for the
  *     cluster; splitting them invents series that do not exist.
+ *
+ *   - The key set is also the ALERT'S VOCABULARY. Series labels are
+ *     stored on the alert and rendered into its title and description
+ *     (SeriesLabelDisplay / SeriesContextEnricher), so a key left out
+ *     here is a fact the on-call engineer does not get. That is why the
+ *     namespace-scoped objects group by namespace as well as their own
+ *     name: `k8s.pod.name` alone is not a Kubernetes identity, and
+ *     "Pod: checkout-7d9f-2xk" with no namespace is a `kubectl` guess.
+ *
+ *   - A key that only ONE side of a RATIO template carries is worse than
+ *     a missing label: the two queries join by series fingerprint, so
+ *     the formula silently stops producing values and the monitor stops
+ *     alerting entirely. `k8s.namespace.name` is stamped directly by
+ *     both kubeletstats and the k8s_cluster receiver and is safe;
+ *     `k8s.node.name` on the k8s_cluster side only arrives via the
+ *     best-effort k8sattributes processor and is deliberately NOT in any
+ *     ratio template's key set. See buildKubernetesRatioMonitorConfig.
  */
 
 interface TemplateGroupByCase {
@@ -42,8 +59,12 @@ interface TemplateGroupByCase {
 const EXPECTED_GROUP_BY: Array<TemplateGroupByCase> = [
   {
     id: "k8s-crashloopbackoff",
-    groupByKeys: ["resource.k8s.pod.name"],
-    why: "restarts belong to one pod's containers",
+    groupByKeys: [
+      "resource.k8s.namespace.name",
+      "resource.k8s.pod.name",
+      "resource.k8s.container.name",
+    ],
+    why: "restarts belong to one CONTAINER of one pod, and the alert has to name which",
   },
   {
     id: "k8s-pod-pending",
@@ -67,13 +88,16 @@ const EXPECTED_GROUP_BY: Array<TemplateGroupByCase> = [
   },
   {
     id: "k8s-deployment-replica-mismatch",
-    groupByKeys: ["resource.k8s.deployment.name"],
-    why: "a stuck rollout belongs to one Deployment object",
+    groupByKeys: [
+      "resource.k8s.namespace.name",
+      "resource.k8s.deployment.name",
+    ],
+    why: "a stuck rollout belongs to one Deployment object, which is namespace-scoped",
   },
   {
     id: "k8s-job-failures",
-    groupByKeys: ["resource.k8s.job.name"],
-    why: "one failing Job must not hide the next",
+    groupByKeys: ["resource.k8s.namespace.name", "resource.k8s.job.name"],
+    why: "one failing Job must not hide the next; Job names repeat across namespaces",
   },
   {
     id: "k8s-etcd-no-leader",
@@ -97,8 +121,8 @@ const EXPECTED_GROUP_BY: Array<TemplateGroupByCase> = [
   },
   {
     id: "k8s-daemonset-unavailable",
-    groupByKeys: ["resource.k8s.daemonset.name"],
-    why: "the incident names one DaemonSet",
+    groupByKeys: ["resource.k8s.namespace.name", "resource.k8s.daemonset.name"],
+    why: "the incident names one DaemonSet, which is namespace-scoped",
   },
   {
     id: "k8s-node-cpu-request-utilization",
@@ -112,18 +136,18 @@ const EXPECTED_GROUP_BY: Array<TemplateGroupByCase> = [
   },
   {
     id: "k8s-hpa-at-max-replicas",
-    groupByKeys: ["resource.k8s.hpa.name"],
-    why: "saturation belongs to one HPA object",
+    groupByKeys: ["resource.k8s.namespace.name", "resource.k8s.hpa.name"],
+    why: "saturation belongs to one HPA object, which is namespace-scoped",
   },
   {
     id: "k8s-pod-memory-limit-saturation",
-    groupByKeys: ["resource.k8s.pod.name"],
-    why: "the pod about to be OOMKilled is the one to page on",
+    groupByKeys: ["resource.k8s.namespace.name", "resource.k8s.pod.name"],
+    why: "the pod about to be OOMKilled is the one to page on, and a pod name alone is not an identity",
   },
   {
     id: "k8s-pod-cpu-limit-saturation",
-    groupByKeys: ["resource.k8s.pod.name"],
-    why: "the throttled pod is the one to page on",
+    groupByKeys: ["resource.k8s.namespace.name", "resource.k8s.pod.name"],
+    why: "the throttled pod is the one to page on, and a pod name alone is not an identity",
   },
 ];
 
@@ -205,6 +229,63 @@ describe("KubernetesAlertTemplates - per-series group-by keys", () => {
     },
   );
 
+  /*
+   * Kubernetes object names are unique per (namespace, kind), not
+   * globally. A template that groups by a namespace-scoped object's name
+   * alone therefore does two wrong things at once: two same-named
+   * objects in different namespaces collapse into one series (so the
+   * second one's breach is silenced behind the first one's open alert),
+   * and the alert it does raise cannot be acted on without guessing the
+   * namespace.
+   */
+  const NAMESPACE_SCOPED_OBJECT_KEYS: Array<string> = [
+    "resource.k8s.pod.name",
+    "resource.k8s.container.name",
+    "resource.k8s.deployment.name",
+    "resource.k8s.statefulset.name",
+    "resource.k8s.daemonset.name",
+    "resource.k8s.job.name",
+    "resource.k8s.cronjob.name",
+    "resource.k8s.hpa.name",
+  ];
+
+  test.each(
+    EXPECTED_GROUP_BY.filter((tc: TemplateGroupByCase) => {
+      return tc.groupByKeys.some((key: string) => {
+        return NAMESPACE_SCOPED_OBJECT_KEYS.includes(key);
+      });
+    }),
+  )(
+    "$id groups a namespace-scoped object and therefore also by namespace",
+    (tc: TemplateGroupByCase) => {
+      expect(tc.groupByKeys).toContain("resource.k8s.namespace.name");
+    },
+  );
+
+  test("every query of a template shares one group-by key set", () => {
+    /*
+     * Ratio templates join their two queries by series fingerprint,
+     * which is computed from this key set. Two queries with different
+     * key sets produce fingerprints that never meet, the formula
+     * evaluates against an empty operand, and the monitor stops
+     * alerting without any error anywhere.
+     */
+    for (const template of getAllKubernetesAlertTemplates()) {
+      const step: MonitorStep = template.getMonitorStep(buildArgs());
+
+      const keySets: Array<string> = (
+        (step.data?.kubernetesMonitor?.metricViewConfig?.queryConfigs ||
+          []) as Array<any>
+      ).map((queryConfig: any) => {
+        return JSON.stringify(
+          queryConfig.metricQueryData.groupByAttributeKeys || [],
+        );
+      });
+
+      expect(new Set(keySets).size).toBeLessThanOrEqual(1);
+    }
+  });
+
   test("grouped templates are the majority of the shipped set", () => {
     const grouped: number = EXPECTED_GROUP_BY.filter(
       (tc: TemplateGroupByCase) => {

package/Tests/Types/Monitor/PodmanAlertTemplates.test.ts

@@ -7,6 +7,8 @@ import {
   getPodmanAlertTemplatesByCategory,
 } from "../../../Types/Monitor/PodmanAlertTemplates";
 import MonitorStep from "../../../Types/Monitor/MonitorStep";
+import { getPodmanMetricByMetricName } from "../../../Types/Monitor/PodmanMetricCatalog";
+import { hasRecoveryDeadBand } from "./Utils/RecommendationCriteriaAssertions";
 import MonitorStepPodmanMonitor from "../../../Types/Monitor/MonitorStepPodmanMonitor";
 import MetricsAggregationType from "../../../Types/Metrics/MetricsAggregationType";
 import RollingTime from "../../../Types/RollingTime/RollingTime";
@@ -42,7 +44,7 @@ const PODMAN_TEMPLATES: Array<PodmanTemplateCase> = [
     severity: "Warning",
     metricName: "container.cpu.utilization",
     metricAlias: "container_cpu",
-    aggregation: MetricsAggregationType.Max,
+    aggregation: MetricsAggregationType.Avg,
     rollingTime: RollingTime.Past5Minutes,
     offlineFilterType: FilterType.GreaterThan,
     onlineFilterType: FilterType.LessThanOrEqualTo,
@@ -54,7 +56,7 @@ const PODMAN_TEMPLATES: Array<PodmanTemplateCase> = [
     severity: "Warning",
     metricName: "container.memory.percent",
     metricAlias: "container_memory",
-    aggregation: MetricsAggregationType.Max,
+    aggregation: MetricsAggregationType.Avg,
     rollingTime: RollingTime.Past5Minutes,
     offlineFilterType: FilterType.GreaterThan,
     onlineFilterType: FilterType.LessThanOrEqualTo,
@@ -72,19 +74,6 @@ const PODMAN_TEMPLATES: Array<PodmanTemplateCase> = [
     onlineFilterType: FilterType.LessThanOrEqualTo,
     threshold: 5,
   },
-  {
-    id: "podman-cpu-throttling",
-    category: "Resource",
-    severity: "Warning",
-    metricName: "container.cpu.throttling_data.throttled_time",
-    metricAlias: "cpu_throttled",
-    aggregation: MetricsAggregationType.Max,
-    rollingTime: RollingTime.Past5Minutes,
-    // throttled_time is non-negative: (> 0) unhealthy, (= 0) healthy partitions it.
-    offlineFilterType: FilterType.GreaterThan,
-    onlineFilterType: FilterType.EqualTo,
-    threshold: 0,
-  },
   {
     id: "podman-high-pids",
     category: "Container",
@@ -105,10 +94,15 @@ const PODMAN_TEMPLATES: Array<PodmanTemplateCase> = [
     metricAlias: "container_uptime",
     aggregation: MetricsAggregationType.Min,
     rollingTime: RollingTime.Past1Minute,
-    // uptime is non-negative: (= 0) unhealthy, (> 0) healthy partitions it.
-    offlineFilterType: FilterType.EqualTo,
-    onlineFilterType: FilterType.GreaterThan,
-    threshold: 0,
+    /*
+     * uptime is never 0: the docker_stats receiver scrapes only RUNNING
+     * containers, so a stopped one emits nothing rather than a zero, and a
+     * running one is never sampled at the instant it started. The fire test
+     * is a low-uptime (restart) test, not an equality against zero.
+     */
+    offlineFilterType: FilterType.LessThan,
+    onlineFilterType: FilterType.GreaterThanOrEqualTo,
+    threshold: 120,
   },
 ];
 
@@ -217,7 +211,7 @@ describe("PodmanAlertTemplates", () => {
   );
 
   test.each(PODMAN_TEMPLATES)(
-    "$id unhealthy/healthy criteria partition the range at $threshold",
+    "$id unhealthy/healthy criteria leave a recovery dead band around $threshold",
     (tc: PodmanTemplateCase) => {
       const template: PodmanAlertTemplate = getPodmanAlertTemplateById(tc.id)!;
       const step: MonitorStep = template.getMonitorStep(buildArgs());
@@ -237,7 +231,26 @@ describe("PodmanAlertTemplates", () => {
         tc.metricAlias,
       );
       expect(offlineFilter.value).toBe(tc.threshold);
-      expect(onlineFilter.value).toBe(tc.threshold);
+      /*
+       * The healthy criteria recovers at a threshold strictly INSIDE the
+       * firing one, so a metric hovering at the boundary cannot satisfy
+       * both on consecutive evaluations. This assertion used to be
+       * `expect(onlineFilter.value).toBe(tc.threshold)` — the two criteria
+       * exactly partitioned the range, which is the flapping configuration
+       * this suite existed to lock in.
+       */
+      expect(
+        hasRecoveryDeadBand(
+          {
+            filterType: offlineFilter.filterType,
+            value: offlineFilter.value as number,
+          },
+          {
+            filterType: onlineFilter.filterType,
+            value: onlineFilter.value as number,
+          },
+        ),
+      ).toBe(true);
 
       expect(offlineFilter.filterType).toBe(tc.offlineFilterType);
       expect(onlineFilter.filterType).toBe(tc.onlineFilterType);
@@ -268,4 +281,160 @@ describe("PodmanAlertTemplates", () => {
       expect(offline.data.alerts[0].autoResolveAlert).toBe(true);
     }
   });
+
+  /*
+   * Lifetime, monotonic counters. Nothing between OTLP ingest and the
+   * criteria evaluator converts one to a delta or a rate — ingest keeps
+   * aggregationTemporality/isMonotonic only as catalog metadata for the
+   * dashboard's rate-view hint, AggregationType has no rate/increase member,
+   * and CompareCriteria.reduceWindow offers only Average/Sum/Max/Min. So a
+   * "> N" criteria on one of these fires the first time the container ever
+   * breaches and NEVER clears: the recovery comparison is unreachable until
+   * the container is recreated. `podman-cpu-throttling` did exactly that on
+   * throttled_time and was removed for it; this guard stops it, or an
+   * equivalent, being pasted back in from DockerAlertTemplates.
+   */
+  const CUMULATIVE_METRICS: Array<string> = [
+    "container.cpu.throttling_data.throttled_time",
+    "container.cpu.throttling_data.throttled_periods",
+    "container.cpu.usage.total",
+  ];
+
+  test("no template thresholds a cumulative counter it cannot recover from", () => {
+    for (const template of getAllPodmanAlertTemplates()) {
+      const monitor: MonitorStepPodmanMonitor = getPodmanMonitor(
+        template.getMonitorStep(buildArgs()),
+      );
+      for (const queryConfig of monitor.metricViewConfig
+        .queryConfigs as Array<any>) {
+        expect(CUMULATIVE_METRICS).not.toContain(
+          queryConfig.metricQueryData.filterData.metricName,
+        );
+      }
+    }
+  });
+
+  test("podman-cpu-throttling is not registered", () => {
+    // Removed deliberately — see the note in PodmanAlertTemplates.ts.
+    expect(getPodmanAlertTemplateById("podman-cpu-throttling")).toBeUndefined();
+  });
+
+  test("podman-container-down fires on a low uptime, not on an unreachable zero", () => {
+    const step: MonitorStep = getPodmanAlertTemplateById(
+      "podman-container-down",
+    )!.getMonitorStep(buildArgs());
+    const [offline, online]: Array<any> = step.data?.monitorCriteria.data
+      ?.monitorCriteriaInstanceArray as Array<any>;
+
+    /*
+     * A stopped container emits no rows at all and a running one is never
+     * scraped at the instant it started, so an equality-to-zero comparison
+     * on container.uptime can never be satisfied in either direction.
+     */
+    expect(offline.data.filters[0].filterType).not.toBe(FilterType.EqualTo);
+    expect(offline.data.filters[0].value).toBeGreaterThan(0);
+
+    // Wider than the 30s scrape and the 60s evaluation interval combined.
+    expect(offline.data.filters[0].value).toBeGreaterThanOrEqual(120);
+
+    // And recovery sits strictly outside the firing threshold.
+    expect(online.data.filters[0].filterType).toBe(
+      FilterType.GreaterThanOrEqualTo,
+    );
+    expect(online.data.filters[0].value).toBeGreaterThan(
+      offline.data.filters[0].value as number,
+    );
+  });
+
+  test("cumulative-counter templates do not claim windowed semantics", () => {
+    /*
+     * container.restarts is a running total kept by the container engine and
+     * nothing in the alerting path converts it to a delta, so copy promising
+     * a per-window count describes behaviour the query does not implement.
+     * The criteria description is what the on-call engineer reads in the
+     * Evaluation Logs, so the correction has to live there, not just in the
+     * template's own name.
+     */
+    const step: MonitorStep = getPodmanAlertTemplateById(
+      "podman-restart-loop",
+    )!.getMonitorStep(buildArgs());
+    const offline: any = (
+      step.data?.monitorCriteria.data
+        ?.monitorCriteriaInstanceArray as Array<any>
+    )[0];
+
+    expect(offline.data.description).toMatch(/running total|cumulative/i);
+    expect(offline.data.description).not.toMatch(/in the monitoring window/i);
+    expect(offline.data.incidents[0].description).toMatch(
+      /running total|cumulative/i,
+    );
+    expect(
+      getPodmanAlertTemplateById("podman-restart-loop")!.description,
+    ).not.toMatch(/crash loop/i);
+  });
+
+  test("percentage gauges use the aggregation their catalog entry declares", () => {
+    /*
+     * container.cpu.utilization and container.memory.percent are already
+     * per-container percentages; PodmanMetricCatalog declares Avg for both
+     * and the Docker Swarm templates use Avg on the identical metrics at the
+     * identical thresholds. Max on a per-minute bucket turns a sub-minute
+     * burst into a whole minute above the threshold, which contradicts the
+     * word "sustained" in the copy — and with the fire side now evaluated
+     * over ALL values in the window, Max means "every minute's PEAK crossed",
+     * which is strictly weaker than sustained load.
+     */
+    for (const id of ["podman-high-cpu", "podman-high-memory"]) {
+      const monitor: MonitorStepPodmanMonitor = getPodmanMonitor(
+        getPodmanAlertTemplateById(id)!.getMonitorStep(buildArgs()),
+      );
+      const filterData: any = (
+        monitor.metricViewConfig.queryConfigs as Array<any>
+      )[0].metricQueryData.filterData;
+
+      expect(filterData.aggegationType).toBe(MetricsAggregationType.Avg);
+      expect(filterData.aggegationType).toBe(
+        getPodmanMetricByMetricName(filterData.metricName)!.defaultAggregation,
+      );
+    }
+  });
+
+  test("podman-high-cpu states the percent-of-one-core scale", () => {
+    /*
+     * PodmanMetricCatalog: "100% = 1 full CPU core". A container spread over
+     * several cores sits permanently above 80 while healthy, so copy that
+     * reads as "80% of the container's CPU allowance" is wrong.
+     */
+    const step: MonitorStep =
+      getPodmanAlertTemplateById("podman-high-cpu")!.getMonitorStep(
+        buildArgs(),
+      );
+    const offline: any = (
+      step.data?.monitorCriteria.data
+        ?.monitorCriteriaInstanceArray as Array<any>
+    )[0];
+
+    expect(offline.data.incidents[0].description).toMatch(/core/i);
+    expect(offline.data.description).toMatch(/core/i);
+  });
+
+  test("podman-high-memory does not promise a limit the metric may not have", () => {
+    /*
+     * container.memory.percent falls back to a percentage of HOST total for a
+     * container started without --memory, which is Podman's default. Copy
+     * that says only "of its limit", and builds an OOM narrative on it, is
+     * wrong for exactly the container most able to take the host down.
+     */
+    const step: MonitorStep =
+      getPodmanAlertTemplateById("podman-high-memory")!.getMonitorStep(
+        buildArgs(),
+      );
+    const offline: any = (
+      step.data?.monitorCriteria.data
+        ?.monitorCriteriaInstanceArray as Array<any>
+    )[0];
+
+    expect(offline.data.incidents[0].description).toMatch(/host/i);
+    expect(offline.data.description).toMatch(/host/i);
+  });
 });