@oneuptime/common 12.0.13 → 12.0.14

package/Server/Utils/Monitor/MonitorIncident.ts

@@ -37,10 +37,10 @@ import MonitorSummarySnapshot from "../../../Types/Monitor/MonitorSummarySnapsho
 import MonitorSummarySnapshotUtil from "../../../Utils/Monitor/MonitorSummarySnapshotUtil";
 import { IncidentMemberRoleAssignment } from "../../../Types/Monitor/CriteriaIncident";
 import { PerSeriesCriteriaMatch } from "../../../Types/Probe/ProbeApiIngestResponse";
-import MonitorClusterContextUtil, {
-  MonitorClusterContext,
-} from "./MonitorClusterContext";
-import SeriesResourceLinker from "./SeriesResourceLinker";
+import MonitorResourceContextUtil from "./MonitorResourceContext";
+import SeriesResourceLinker, {
+  SeriesResolvedResourceIds,
+} from "./SeriesResourceLinker";
 
 export default class MonitorIncident {
   @CaptureSpan()
@@ -364,15 +364,17 @@ export default class MonitorIncident {
     }
 
     /*
-     * Proxmox/Ceph monitors: resolve the monitored cluster once per
-     * evaluation (lookup-only, from the step config's clusterIdentifier)
-     * so every incident created below is attached to it. Series labels
-     * cannot supply this — they carry datapoint labels (`id`,
-     * `ceph_daemon`, `pool_id`), not cluster identity, and ungrouped
-     * templates have no series at all. No-op for other monitor types.
+     * Resolve the resources this monitor's own config names — its host,
+     * cluster, fleet, telemetry services, or the resource its metric
+     * filters scope it to — once per evaluation, so every incident
+     * created below is attached to them. Series labels cannot supply
+     * this: they only exist for grouped criteria, and most monitors
+     * (every shipped Host/Docker/Podman template, all Logs/Traces/
+     * Exceptions monitors) are ungrouped. No-op, and no round-trip, for
+     * monitor types whose config names no resource.
      */
-    const clusterContext: MonitorClusterContext =
-      await MonitorClusterContextUtil.resolveClusterContextForMonitor({
+    const resourceContext: SeriesResolvedResourceIds =
+      await MonitorResourceContextUtil.resolveResourceContextForMonitor({
         monitor: input.monitor,
       });
 
@@ -656,19 +658,20 @@ export default class MonitorIncident {
             model: incident,
             seriesLabels,
             projectId: input.monitor.projectId!,
+            monitorType: input.monitor.monitorType,
           });
         }
 
         /*
-         * Deterministic Proxmox/Ceph cluster link from the monitor's
-         * step config (resolved once above). Runs for both grouped and
-         * ungrouped incidents and merges with anything the series-label
-         * path resolved, so the per-cluster Activity tabs always see
+         * Deterministic resource link from the monitor's step config
+         * (resolved once above). Runs for both grouped and ungrouped
+         * incidents and merges with anything the series-label path
+         * resolved, so the per-resource Activity tabs always see
          * monitor-created incidents.
          */
-        SeriesResourceLinker.attachClusterContext({
+        SeriesResourceLinker.attachResolvedResources({
           model: incident,
-          clusterContext,
+          resolved: resourceContext,
         });
 
         incident.onCallDutyPolicies =

package/Server/Utils/Monitor/MonitorResourceContext.ts

@@ -0,0 +1,107 @@
+import Monitor from "../../../Models/DatabaseModels/Monitor";
+import logger from "../Logger";
+import MonitorStepResourceIdentity from "./MonitorStepResourceIdentity";
+import { SeriesResourceRefs } from "./SeriesResourceLabels";
+import SeriesResourceLinker, {
+  SeriesResolvedResourceIds,
+} from "./SeriesResourceLinker";
+
+/*
+ * Incidents and alerts created by a monitor must be attached to the
+ * resources that monitor watches — the per-resource Activity pages, the
+ * SideMenu badge counts, the "Affected Resources" card, the affected-
+ * resources filter, and resource owner/label inheritance all query those
+ * relations on Incident/Alert.
+ *
+ * Series labels cannot supply that identity on their own. They exist
+ * only when the criteria is GROUPED, and most monitors are not: every
+ * shipped Host / Docker / Podman / RUM template is ungrouped, the
+ * Kubernetes templates group by node/pod (never by cluster), and
+ * Logs / Traces / Exceptions monitors have no series concept at all. An
+ * ungrouped monitor therefore linked nothing, which is why a metric
+ * monitor scoped to one service with
+ * `oneuptime.service.name = checkout-api` opened alerts that showed "No
+ * resources affected".
+ *
+ * The deterministic source is the monitor's own step config, which
+ * always carries whatever the user picked when they built the monitor:
+ * a hostIdentifier, a clusterIdentifier, a fleetIdentifier, a set of
+ * telemetryServiceIds, or a metric attribute filter. This module reads
+ * it once per evaluation and resolves it to real rows.
+ *
+ * This supersedes the old MonitorClusterContext, which did the same
+ * thing for exactly four cluster types (Proxmox / Ceph / Docker Swarm /
+ * IoT) with a hand-rolled findOneBy per identifier.
+ */
+export default class MonitorResourceContextUtil {
+  /*
+   * Resolve the resource rows the monitor's configuration names.
+   *
+   * Lookup-only — row creation belongs to ingest discovery
+   * (findOrCreateByName); a monitor pointing at a host that never sent
+   * data simply links nothing. Lookups are ALWAYS project-scoped:
+   * `isRoot` bypasses row-level access control, so a stale or hostile
+   * identifier must never be able to pull a row in from another tenant.
+   *
+   * Returns empty for every monitor type whose config names no resource
+   * (Website, API, Ping, Synthetic, ...) without touching the database.
+   */
+  public static async resolveResourceContextForMonitor(input: {
+    monitor: Monitor;
+  }): Promise<SeriesResolvedResourceIds> {
+    const empty: SeriesResolvedResourceIds = this.emptyContext();
+
+    if (!input.monitor.projectId) {
+      return empty;
+    }
+
+    /*
+     * Resource linking is best-effort context — a failure must never
+     * block incident/alert creation, which runs inside the probe and
+     * telemetry queue workers where a throw retries the whole job
+     * forever. The EXTRACTION is inside the try as well as the lookup:
+     * it reads free-form, unvalidated step JSON, so a monitor saved
+     * through the API or an import can hand it a shape it cannot parse.
+     */
+    try {
+      const refs: SeriesResourceRefs =
+        MonitorStepResourceIdentity.extractResourceRefsFromMonitor({
+          monitor: input.monitor,
+        });
+
+      if (MonitorStepResourceIdentity.isEmpty(refs)) {
+        return empty;
+      }
+
+      return await SeriesResourceLinker.resolveResourceRefs({
+        refs: refs,
+        projectId: input.monitor.projectId,
+        /*
+         * The identifiers here were typed by a user into the monitor
+         * form, while the rows' names were stamped by an agent at
+         * ingest; the two legitimately differ by case.
+         */
+        nameMatch: "caseInsensitive",
+      });
+    } catch (err) {
+      logger.error(
+        `Failed to resolve affected resources for monitor ${input.monitor.id?.toString()}: ${err}`,
+      );
+      return empty;
+    }
+  }
+
+  public static emptyContext(): SeriesResolvedResourceIds {
+    return {
+      hostIds: [],
+      dockerHostIds: [],
+      podmanHostIds: [],
+      kubernetesClusterIds: [],
+      serviceIds: [],
+      proxmoxClusterIds: [],
+      cephClusterIds: [],
+      dockerSwarmClusterIds: [],
+      iotFleetIds: [],
+    };
+  }
+}

package/Server/Utils/Monitor/MonitorStepResourceIdentity.ts

@@ -0,0 +1,442 @@
+import Monitor from "../../../Models/DatabaseModels/Monitor";
+import { JSONObject } from "../../../Types/JSON";
+import MetricQueryConfigData from "../../../Types/Metrics/MetricQueryConfigData";
+import MetricsViewConfig from "../../../Types/Metrics/MetricsViewConfig";
+import MonitorStep from "../../../Types/Monitor/MonitorStep";
+import MonitorType from "../../../Types/Monitor/MonitorType";
+import ObjectID from "../../../Types/ObjectID";
+import SeriesResourceLabels, {
+  SeriesResourceRefs,
+} from "./SeriesResourceLabels";
+
+/*
+ * The step-config twin of SeriesResourceLabels.
+ *
+ * SeriesResourceLabels answers "which resources does this BREACHING
+ * SERIES point at" by reading the labels of one grouped series. That
+ * only works when the criteria is grouped — an ungrouped monitor emits
+ * no series labels at all, so it linked nothing, and the vast majority
+ * of monitors (every shipped Host / Docker / Podman / RUM template, and
+ * every Logs / Traces / Exceptions monitor, which cannot be grouped in
+ * the first place) are ungrouped.
+ *
+ * This module answers the same question from the other, always-present
+ * side: "which resources does this MONITOR'S OWN CONFIGURATION point
+ * at". A host monitor names its host, a Kubernetes monitor names its
+ * cluster, a log monitor names its telemetry services, and any monitor
+ * with a metric query can carry resource identity in its attribute
+ * filters (e.g. `oneuptime.service.name = checkout-api`). None of that
+ * depends on the criteria being grouped.
+ *
+ * Both modules emit the SAME `SeriesResourceRefs` shape, so the single
+ * nine-way resolver in SeriesResourceLinker serves both, and the two can
+ * never drift into disagreeing about what identifies a resource.
+ *
+ * Pure: no database access, no I/O.
+ */
+
+/*
+ * Which relation a monitor type's own step config speaks for. Held as an
+ * exhaustive-by-construction map so a new infra monitor type is a
+ * one-line addition next to its siblings rather than a new `if` branch
+ * buried in the extractor.
+ */
+type NameRefKey = keyof Pick<
+  SeriesResourceRefs,
+  | "hostNames"
+  | "dockerHostNames"
+  | "podmanHostNames"
+  | "kubernetesClusterNames"
+  | "proxmoxClusterNames"
+  | "cephClusterNames"
+  | "dockerSwarmClusterNames"
+  | "iotFleetNames"
+>;
+
+export default class MonitorStepResourceIdentity {
+  /*
+   * Every resource the monitor's configuration names, unioned across its
+   * steps and deduped. A monitor with three host steps names three
+   * hosts: the creation path does not know which step fired, and the
+   * alternative — attributing nothing — is what this module exists to
+   * fix.
+   */
+  public static extractResourceRefsFromMonitor(input: {
+    monitor: Monitor;
+  }): SeriesResourceRefs {
+    const refs: SeriesResourceRefs = this.emptyRefs();
+
+    const monitorType: MonitorType | undefined = input.monitor.monitorType;
+
+    if (!monitorType) {
+      return refs;
+    }
+
+    const monitorSteps: Array<MonitorStep> =
+      input.monitor.monitorSteps?.data?.monitorStepsInstanceArray || [];
+
+    for (const monitorStep of monitorSteps) {
+      this.collectFromStep({
+        monitorStep: monitorStep,
+        monitorType: monitorType,
+        refs: refs,
+      });
+    }
+
+    return this.dedupeRefs(refs);
+  }
+
+  private static collectFromStep(input: {
+    monitorStep: MonitorStep;
+    monitorType: MonitorType;
+    refs: SeriesResourceRefs;
+  }): void {
+    const stepData: MonitorStep["data"] = input.monitorStep.data;
+
+    if (!stepData) {
+      return;
+    }
+
+    /*
+     * 1. The declared resource identifier — the field the user picked in
+     *    the monitor form. Validation makes it required for each of
+     *    these types (see MonitorStep's validation), so this is the
+     *    strongest signal available.
+     */
+    const declared: { key: NameRefKey; value: string | undefined } | null =
+      this.getDeclaredIdentifier({
+        stepData: stepData,
+        monitorType: input.monitorType,
+      });
+
+    /*
+     * `typeof` rather than a truthiness check: step JSON is not
+     * schema-checked, so an identifier written by the API, a seed or an
+     * import can be a number or an object, and `.trim()` on those throws
+     * out of the incident/alert creation path.
+     */
+    if (declared && typeof declared.value === "string") {
+      const identifier: string = declared.value.trim();
+
+      if (identifier.length > 0) {
+        input.refs[declared.key].push(identifier);
+      }
+    }
+
+    /*
+     * 2. Telemetry services. Real `Service._id` values written by the
+     *    monitor form's service picker — a primary key, not a name, so
+     *    this is the most precise identity in the whole module. Metric
+     *    monitors carry the field too (RUM recommendation monitors set
+     *    it), where it is optional.
+     */
+    for (const serviceId of this.getTelemetryServiceIds({
+      stepData: stepData,
+    })) {
+      input.refs.serviceIds.push(serviceId);
+    }
+
+    /*
+     * 3. Metric attribute filters. A generic metric monitor names its
+     *    resource nowhere else: it scopes itself with filters like
+     *    `oneuptime.service.name = checkout-api`, which is exactly the
+     *    key map SeriesResourceLabels already owns. Reusing that map
+     *    means a filter and a group-by on the same attribute resolve to
+     *    the same row.
+     */
+    this.collectFromMetricFilters({
+      stepData: stepData,
+      monitorType: input.monitorType,
+      refs: input.refs,
+    });
+  }
+
+  private static getDeclaredIdentifier(input: {
+    stepData: NonNullable<MonitorStep["data"]>;
+    monitorType: MonitorType;
+  }): { key: NameRefKey; value: string | undefined } | null {
+    const stepData: NonNullable<MonitorStep["data"]> = input.stepData;
+
+    switch (input.monitorType) {
+      case MonitorType.Host:
+        return {
+          key: "hostNames",
+          value: stepData.hostMonitor?.hostIdentifier,
+        };
+      case MonitorType.Docker:
+        return {
+          key: "dockerHostNames",
+          value: stepData.dockerMonitor?.hostIdentifier,
+        };
+      case MonitorType.Podman:
+        return {
+          key: "podmanHostNames",
+          value: stepData.podmanMonitor?.hostIdentifier,
+        };
+      case MonitorType.Kubernetes:
+        return {
+          key: "kubernetesClusterNames",
+          value: stepData.kubernetesMonitor?.clusterIdentifier,
+        };
+      case MonitorType.Proxmox:
+        return {
+          key: "proxmoxClusterNames",
+          value: stepData.proxmoxMonitor?.clusterIdentifier,
+        };
+      case MonitorType.Ceph:
+        return {
+          key: "cephClusterNames",
+          value: stepData.cephMonitor?.clusterIdentifier,
+        };
+      case MonitorType.DockerSwarm:
+        return {
+          key: "dockerSwarmClusterNames",
+          value: stepData.dockerSwarmMonitor?.clusterIdentifier,
+        };
+      case MonitorType.IoTDevice:
+        return {
+          key: "iotFleetNames",
+          value: stepData.iotMonitor?.fleetIdentifier,
+        };
+      default:
+        return null;
+    }
+  }
+
+  private static getTelemetryServiceIds(input: {
+    stepData: NonNullable<MonitorStep["data"]>;
+  }): Array<string> {
+    const stepData: NonNullable<MonitorStep["data"]> = input.stepData;
+
+    /*
+     * Read from every telemetry sub-config present rather than switching
+     * on monitorType: only one of them is ever populated for a given
+     * monitor, and this way a step written by an older build (or by the
+     * API, a seed, or an import) with a mismatched type still resolves.
+     */
+    const idLists: Array<Array<ObjectID> | undefined> = [
+      stepData.logMonitor?.telemetryServiceIds,
+      stepData.traceMonitor?.telemetryServiceIds,
+      stepData.exceptionMonitor?.telemetryServiceIds,
+      stepData.profileMonitor?.telemetryServiceIds,
+      stepData.metricMonitor?.telemetryServiceIds,
+    ];
+
+    const serviceIds: Array<string> = [];
+
+    for (const idList of idLists) {
+      /*
+       * `Array.isArray` rather than a truthiness check: an unchecked
+       * step written by the API or an import can hold an object or a
+       * number here, and `for...of` on those throws out of the
+       * incident/alert creation path.
+       */
+      if (!Array.isArray(idList) || idList.length === 0) {
+        continue;
+      }
+
+      for (const id of idList) {
+        /*
+         * An entry can be a bare string rather than a rehydrated
+         * ObjectID, for the same reason. `String()` covers both; empty
+         * values are dropped so they can't widen the lookup, and a
+         * non-scalar is dropped rather than stringified into a garbage
+         * "[object Object]" lookup key.
+         */
+        if (
+          id !== null &&
+          typeof id === "object" &&
+          !(id instanceof ObjectID)
+        ) {
+          continue;
+        }
+
+        const idString: string = String(id ?? "").trim();
+
+        if (idString.length > 0) {
+          serviceIds.push(idString);
+        }
+      }
+    }
+
+    return serviceIds;
+  }
+
+  private static collectFromMetricFilters(input: {
+    stepData: NonNullable<MonitorStep["data"]>;
+    monitorType: MonitorType;
+    refs: SeriesResourceRefs;
+  }): void {
+    const filterAttributes: JSONObject = this.collectMetricFilterAttributes({
+      stepData: input.stepData,
+    });
+
+    if (Object.keys(filterAttributes).length === 0) {
+      return;
+    }
+
+    const filterRefs: SeriesResourceRefs =
+      SeriesResourceLabels.extractResourceRefs(filterAttributes);
+
+    /*
+     * `resource.host.name` belongs to Host in the label key map, but on
+     * a Docker or Podman monitor the worker writes that same attribute
+     * from the step's `hostIdentifier` — which names a DockerHost /
+     * PodmanHost row, not a Host row. Honouring the map here would
+     * attach the wrong model and surface the event on an unrelated
+     * Host's Activity tab, so the declared identifier (collected above,
+     * into the right bucket) is the only host identity these two types
+     * get.
+     */
+    const suppressHostRefs: boolean =
+      input.monitorType === MonitorType.Docker ||
+      input.monitorType === MonitorType.Podman;
+
+    if (suppressHostRefs) {
+      filterRefs.hostIds = [];
+      filterRefs.hostNames = [];
+    }
+
+    this.mergeRefs({ target: input.refs, source: filterRefs });
+  }
+
+  /*
+   * The attribute filters of every metric query on the step, merged.
+   * Each infra monitor type keeps its metric view config under its own
+   * key, so read them all — exactly the set MonitorStep's own
+   * metric-view-config resolver knows about.
+   *
+   * Values accumulate into an ARRAY per key rather than overwriting: a
+   * step can hold several queries, and two of them filtering
+   * `oneuptime.service.name` on different services both name a real
+   * resource. Last-write-wins would silently drop one of them.
+   * SeriesResourceLabels.collectLabelValues already flattens
+   * array-valued labels, so the multi-value shape needs nothing extra
+   * downstream.
+   */
+  private static collectMetricFilterAttributes(input: {
+    stepData: NonNullable<MonitorStep["data"]>;
+  }): JSONObject {
+    const stepData: NonNullable<MonitorStep["data"]> = input.stepData;
+
+    const viewConfigs: Array<MetricsViewConfig | undefined> = [
+      stepData.metricMonitor?.metricViewConfig,
+      stepData.hostMonitor?.metricViewConfig,
+      stepData.kubernetesMonitor?.metricViewConfig,
+      stepData.dockerMonitor?.metricViewConfig,
+      stepData.podmanMonitor?.metricViewConfig,
+      stepData.proxmoxMonitor?.metricViewConfig,
+      stepData.cephMonitor?.metricViewConfig,
+      stepData.dockerSwarmMonitor?.metricViewConfig,
+      stepData.iotMonitor?.metricViewConfig,
+    ];
+
+    const valuesByKey: Map<string, Array<string>> = new Map<
+      string,
+      Array<string>
+    >();
+
+    for (const viewConfig of viewConfigs) {
+      const queryConfigs: Array<MetricQueryConfigData> = Array.isArray(
+        viewConfig?.queryConfigs,
+      )
+        ? viewConfig.queryConfigs
+        : [];
+
+      for (const queryConfig of queryConfigs) {
+        const queryAttributes: unknown =
+          queryConfig?.metricQueryData?.filterData?.attributes;
+
+        if (!queryAttributes || typeof queryAttributes !== "object") {
+          continue;
+        }
+
+        for (const [key, value] of Object.entries(
+          queryAttributes as Record<string, unknown>,
+        )) {
+          /*
+           * Only plain string filters identify a resource. A filter can
+           * also hold a Search or Includes instance (substring / set
+           * matching), and neither is an identity we can resolve to one
+           * row — a `Search("prod")` filter names no specific service.
+           */
+          if (typeof value !== "string" || value.length === 0) {
+            continue;
+          }
+
+          const existing: Array<string> = valuesByKey.get(key) || [];
+
+          if (!existing.includes(value)) {
+            existing.push(value);
+          }
+
+          valuesByKey.set(key, existing);
+        }
+      }
+    }
+
+    const attributes: JSONObject = {};
+
+    for (const [key, values] of valuesByKey) {
+      /*
+       * A single value stays a bare string so the common case reads
+       * exactly like a series label; only a genuinely multi-valued
+       * filter becomes an array.
+       */
+      attributes[key] = values.length === 1 ? values[0]! : values;
+    }
+
+    return attributes;
+  }
+
+  private static mergeRefs(input: {
+    target: SeriesResourceRefs;
+    source: SeriesResourceRefs;
+  }): void {
+    for (const key of Object.keys(input.target) as Array<
+      keyof SeriesResourceRefs
+    >) {
+      input.target[key].push(...input.source[key]);
+    }
+  }
+
+  private static dedupeRefs(refs: SeriesResourceRefs): SeriesResourceRefs {
+    for (const key of Object.keys(refs) as Array<keyof SeriesResourceRefs>) {
+      refs[key] = Array.from(new Set<string>(refs[key]));
+    }
+
+    return refs;
+  }
+
+  public static emptyRefs(): SeriesResourceRefs {
+    return {
+      hostIds: [],
+      hostNames: [],
+      dockerHostIds: [],
+      dockerHostNames: [],
+      podmanHostIds: [],
+      podmanHostNames: [],
+      kubernetesClusterIds: [],
+      kubernetesClusterNames: [],
+      dockerSwarmClusterNames: [],
+      proxmoxClusterNames: [],
+      cephClusterNames: [],
+      iotFleetNames: [],
+      serviceIds: [],
+      serviceNames: [],
+    };
+  }
+
+  /*
+   * True when the monitor's configuration names nothing at all — the
+   * common case for the ~17 monitor types that have no resource
+   * identity (Website, API, Ping, Synthetic, ...). Callers use it to
+   * skip the lookup entirely so those monitors keep costing zero
+   * database round-trips per evaluation.
+   */
+  public static isEmpty(refs: SeriesResourceRefs): boolean {
+    return Object.values(refs).every((values: Array<string>): boolean => {
+      return values.length === 0;
+    });
+  }
+}

package/Server/Utils/Monitor/SeriesResourceLabels.ts

@@ -74,7 +74,7 @@ export const PodmanHostNameLabelKeys: ReadonlyArray<string> = [
  * Like Proxmox/Ceph, the shipped Swarm alert templates group by
  * datapoint labels (`container.name`), so their series labels do NOT
  * carry this key; the deterministic cluster link for those monitors
- * comes from the monitor step config instead (see MonitorClusterContext).
+ * comes from the monitor step config instead (see MonitorResourceContext).
  * These keys cover user-built monitors that group by the cluster
  * attribute.
  */
@@ -105,7 +105,7 @@ export const KubernetesClusterNameLabelKeys: ReadonlyArray<string> = [
  * datapoint labels (`id`, `ceph_daemon`, `pool_id`), so their series
  * labels do NOT carry these keys; the deterministic cluster link for
  * those monitors comes from the monitor step config instead (see
- * MonitorClusterContext). These keys cover user-built monitors that
+ * MonitorResourceContext). These keys cover user-built monitors that
  * group by the cluster attribute, exactly like the K8s keys above.
  */
 export const ProxmoxClusterNameLabelKeys: ReadonlyArray<string> = [
@@ -127,7 +127,7 @@ export const CephClusterNameLabelKeys: ReadonlyArray<string> = [
  * alert templates group by the datapoint label `device.id`, so their
  * series labels do NOT carry these keys; the deterministic fleet link
  * for those monitors comes from the monitor step config instead (see
- * MonitorClusterContext). These keys cover user-built monitors that
+ * MonitorResourceContext). These keys cover user-built monitors that
  * group by the fleet attribute.
  */
 export const IoTFleetNameLabelKeys: ReadonlyArray<string> = [