@oneuptime/common 12.0.32 → 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/MonitorStepDatabaseMonitor.test.ts

@@ -0,0 +1,243 @@
+import { DatabaseMetricGroup } from "../../../Types/Monitor/DatabaseMetricCatalog";
+import { JSONObject } from "../../../Types/JSON";
+import MonitorStepDatabaseMonitor, {
+  DEFAULT_DATABASE_CONNECTION_TIMEOUT_IN_MS,
+  DEFAULT_DATABASE_METRIC_GROUPS,
+  DEFAULT_DATABASE_STATEMENT_TIMEOUT_IN_MS,
+  MonitorStepDatabaseMonitorUtil,
+} from "../../../Types/Monitor/MonitorStepDatabaseMonitor";
+import {
+  MAX_SQL_CONNECTION_TIMEOUT_IN_MS,
+  MAX_SQL_STATEMENT_TIMEOUT_IN_MS,
+} from "../../../Types/Monitor/MonitorStepSqlMonitor";
+import SqlDatabaseType from "../../../Types/Monitor/SqlDatabaseType";
+import { describe, expect, test } from "@jest/globals";
+
+describe("MonitorStepDatabaseMonitorUtil", () => {
+  describe("getDefault", () => {
+    test("starts on PostgreSQL with its own port and validated TLS", () => {
+      const config: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.getDefault();
+
+      expect(config.databaseType).toBe(SqlDatabaseType.PostgreSQL);
+      expect(config.port).toBe(5432);
+      // Opting out of chain validation must be a decision, never a default.
+      expect(config.rejectUnauthorizedSsl).toBe(true);
+      expect(config.useWindowsIntegratedAuthentication).toBe(false);
+    });
+
+    test("collects every metric group by default", () => {
+      /*
+       * Safe to default on only because a group the login cannot read
+       * reports itself unavailable instead of failing the check. If that
+       * contract ever changes, this default has to change with it.
+       */
+      const config: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.getDefault();
+
+      expect(config.enabledMetricGroups).toEqual(
+        DEFAULT_DATABASE_METRIC_GROUPS,
+      );
+      expect(config.enabledMetricGroups).toHaveLength(
+        Object.values(DatabaseMetricGroup).length,
+      );
+    });
+
+    test("returns a fresh group array each time", () => {
+      // A shared array would let one monitor's edit reconfigure every other.
+      const first: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.getDefault();
+      const second: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.getDefault();
+
+      first.enabledMetricGroups.pop();
+
+      expect(second.enabledMetricGroups).toEqual(
+        DEFAULT_DATABASE_METRIC_GROUPS,
+      );
+      expect(DEFAULT_DATABASE_METRIC_GROUPS).toHaveLength(
+        Object.values(DatabaseMetricGroup).length,
+      );
+    });
+
+    test("defaults to a tighter statement timeout than a user query would get", () => {
+      /*
+       * Health queries are introspection and should return in milliseconds.
+       * If pg_stat_activity takes ten seconds the useful signal is "this
+       * server is in trouble", not a longer wait.
+       */
+      const config: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.getDefault();
+
+      expect(config.statementTimeoutInMs).toBe(
+        DEFAULT_DATABASE_STATEMENT_TIMEOUT_IN_MS,
+      );
+      expect(config.statementTimeoutInMs).toBeLessThan(
+        MAX_SQL_STATEMENT_TIMEOUT_IN_MS,
+      );
+      expect(config.connectionTimeoutInMs).toBe(
+        DEFAULT_DATABASE_CONNECTION_TIMEOUT_IN_MS,
+      );
+    });
+  });
+
+  describe("sanitizeMetricGroups", () => {
+    test("keeps recognized groups and drops anything else", () => {
+      expect(
+        MonitorStepDatabaseMonitorUtil.sanitizeMetricGroups([
+          DatabaseMetricGroup.Locks,
+          "Telepathy",
+          DatabaseMetricGroup.Storage,
+          42,
+          null,
+        ]),
+        // Canonical order, not input order: Locks precedes Storage.
+      ).toEqual([DatabaseMetricGroup.Locks, DatabaseMetricGroup.Storage]);
+    });
+
+    test("normalizes to the canonical order regardless of input order", () => {
+      // Keeps the config form and the collector iterating in one order.
+      expect(
+        MonitorStepDatabaseMonitorUtil.sanitizeMetricGroups([
+          DatabaseMetricGroup.Maintenance,
+          DatabaseMetricGroup.Connections,
+        ]),
+      ).toEqual([
+        DatabaseMetricGroup.Connections,
+        DatabaseMetricGroup.Maintenance,
+      ]);
+    });
+
+    test("de-duplicates repeated groups", () => {
+      expect(
+        MonitorStepDatabaseMonitorUtil.sanitizeMetricGroups([
+          DatabaseMetricGroup.Locks,
+          DatabaseMetricGroup.Locks,
+        ]),
+      ).toEqual([DatabaseMetricGroup.Locks]);
+    });
+
+    test.each([
+      ["an empty list", []],
+      ["a list of only unknown values", ["nope", "also-nope"]],
+      ["a non-array", "Locks"],
+      ["undefined", undefined],
+      ["null", null],
+    ])("falls back to every group for %s", (_label: string, input: unknown) => {
+      /*
+       * A monitor that silently collects nothing is worse than one that
+       * collects what it can, so an unusable list means "everything"
+       * rather than "nothing".
+       */
+      expect(
+        MonitorStepDatabaseMonitorUtil.sanitizeMetricGroups(input),
+      ).toEqual(DEFAULT_DATABASE_METRIC_GROUPS);
+    });
+  });
+
+  describe("fromJSON", () => {
+    test("round-trips a full configuration through toJSON", () => {
+      const config: MonitorStepDatabaseMonitor = {
+        ...MonitorStepDatabaseMonitorUtil.getDefault(),
+        databaseType: SqlDatabaseType.MicrosoftSqlServer,
+        host: "sql.internal",
+        port: 1433,
+        databaseName: "orders",
+        username: "monitoring",
+        password: "{{monitorSecrets.dbPassword}}",
+        useSsl: true,
+        enabledMetricGroups: [
+          DatabaseMetricGroup.Connections,
+          DatabaseMetricGroup.Replication,
+        ],
+      };
+
+      const restored: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.fromJSON(
+          MonitorStepDatabaseMonitorUtil.toJSON(config),
+        );
+
+      expect(restored).toEqual(config);
+    });
+
+    test("preserves a monitor-secret reference verbatim", () => {
+      /*
+       * The server resolves {{monitorSecrets.name}} on the way to the probe.
+       * Any mangling here turns into an authentication failure that looks
+       * like a wrong password.
+       */
+      const restored: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.fromJSON({
+          host: "db.internal",
+          password: "{{monitorSecrets.dbPassword}}",
+        } as JSONObject);
+
+      expect(restored.password).toBe("{{monitorSecrets.dbPassword}}");
+    });
+
+    test("clamps timeouts to the shared SQL ceilings", () => {
+      const restored: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.fromJSON({
+          statementTimeoutInMs: 999999,
+          connectionTimeoutInMs: 999999,
+        } as JSONObject);
+
+      expect(restored.statementTimeoutInMs).toBe(
+        MAX_SQL_STATEMENT_TIMEOUT_IN_MS,
+      );
+      expect(restored.connectionTimeoutInMs).toBe(
+        MAX_SQL_CONNECTION_TIMEOUT_IN_MS,
+      );
+    });
+
+    test("falls back to safe values for an empty payload", () => {
+      const restored: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.fromJSON({});
+
+      expect(restored.databaseType).toBe(SqlDatabaseType.PostgreSQL);
+      expect(restored.rejectUnauthorizedSsl).toBe(true);
+      expect(restored.enabledMetricGroups).toEqual(
+        DEFAULT_DATABASE_METRIC_GROUPS,
+      );
+    });
+
+    test("treats an explicitly false rejectUnauthorizedSsl as a real choice", () => {
+      /*
+       * Distinguishing "absent" from "false" matters: absent must default to
+       * validating the chain, but a user who turned validation off for a
+       * self-signed certificate must keep that setting.
+       */
+      expect(
+        MonitorStepDatabaseMonitorUtil.fromJSON({
+          rejectUnauthorizedSsl: false,
+        } as JSONObject).rejectUnauthorizedSsl,
+      ).toBe(false);
+
+      expect(
+        MonitorStepDatabaseMonitorUtil.fromJSON({}).rejectUnauthorizedSsl,
+      ).toBe(true);
+    });
+
+    test("normalizes an unusable group list rather than trusting it", () => {
+      expect(
+        MonitorStepDatabaseMonitorUtil.fromJSON({
+          enabledMetricGroups: ["Locks", "not-a-group"],
+        } as JSONObject).enabledMetricGroups,
+      ).toEqual([DatabaseMetricGroup.Locks]);
+    });
+  });
+
+  describe("toJSON", () => {
+    test("copies the group array instead of aliasing it", () => {
+      const config: MonitorStepDatabaseMonitor =
+        MonitorStepDatabaseMonitorUtil.getDefault();
+
+      const json: JSONObject = MonitorStepDatabaseMonitorUtil.toJSON(config);
+      (json["enabledMetricGroups"] as Array<DatabaseMetricGroup>).pop();
+
+      expect(config.enabledMetricGroups).toEqual(
+        DEFAULT_DATABASE_METRIC_GROUPS,
+      );
+    });
+  });
+});

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

@@ -113,6 +113,7 @@ describe("MonitorStep.getDefaultMonitorStep telemetry sub-config seeding", () =>
       MonitorType.SyntheticMonitor,
       MonitorType.CustomJavaScriptCode,
       MonitorType.SQLQuery,
+      MonitorType.Database,
       MonitorType.Manual,
       MonitorType.Profiles,
       MonitorType.Kubernetes,

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

@@ -124,6 +124,7 @@ describe("MonitorTypeHelper", () => {
       MonitorType.DNSSEC,
       MonitorType.Domain,
       MonitorType.ExternalStatusPage,
+      MonitorType.Database,
     ])("returns true for %s", (monitorType: MonitorType) => {
       expect(MonitorTypeHelper.isProbableMonitor(monitorType)).toBe(true);
     });

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

@@ -12,7 +12,7 @@ import {
 } from "../../../UI/Components/CardSelect/CardSelect";
 
 /*
- * The monitor type picker offers 29 types. Whether someone finds the right one
+ * The monitor type picker offers 31 types. Whether someone finds the right one
  * comes down to whether the words they already use - "k8s", "postgres",
  * "heartbeat", "tls" - are attached to the card, because none of them appear
  * in its title or its copy. These are the searches this catalog promises to
@@ -192,8 +192,8 @@ describe("MonitorType keywords", () => {
   describe("card copy is scannable", () => {
     /*
      * Every description used to open with "This monitor type lets you
-     * monitor", so the first five words of all 29 cards were identical and
-     * carried nothing. Reading the grid meant skipping them 29 times.
+     * monitor", so the first five words of every card were identical and
+     * carried nothing. Reading the grid meant skipping them on every card.
      */
     test("no description opens with the old boilerplate", () => {
       for (const props of allProps) {
@@ -230,10 +230,19 @@ describe("MonitorType keywords", () => {
       ["k8s", MonitorType.Kubernetes],
       ["kubernetes", MonitorType.Kubernetes],
       ["eks", MonitorType.Kubernetes],
-      ["postgres", MonitorType.SQLQuery],
-      ["postgresql", MonitorType.SQLQuery],
-      ["mysql", MonitorType.SQLQuery],
-      ["database", MonitorType.SQLQuery],
+      /*
+       * Both database cards answer to the engine names. Someone typing an
+       * engine into a monitoring product wants its health series, not the
+       * escape hatch for a query they have to write themselves - so the
+       * engine words rank Database Health first, and SQL Query keeps the
+       * searches that describe what only it does.
+       */
+      ["postgres", MonitorType.Database],
+      ["postgresql", MonitorType.Database],
+      ["mysql", MonitorType.Database],
+      ["database", MonitorType.Database],
+      ["query", MonitorType.SQLQuery],
+      ["row count", MonitorType.SQLQuery],
       ["heartbeat", MonitorType.IncomingRequest],
       ["cron", MonitorType.IncomingRequest],
       ["webhook", MonitorType.IncomingRequest],