@oneuptime/common 12.0.23 → 12.0.25

package/Types/Monitor/MonitorCriteriaInstance.ts

@@ -68,7 +68,14 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
       filters: [
         {
           checkOn: CheckOn.IsOnline,
-          filterType: undefined,
+          /*
+           * Seed the condition too, matching
+           * getNewMonitorCriteriaInstanceAsJSON. A filter with no filter
+           * type shows an empty "Filter Condition" dropdown in the form
+           * and never matches anything at evaluation time, because every
+           * comparator in CompareCriteria switches on the filter type.
+           */
+          filterType: FilterType.True,
           value: undefined,
         },
       ],
@@ -83,6 +90,35 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
     };
   }
 
+  /*
+   * The monitor types whose criteria MonitorCriteriaEvaluator hands to
+   * MetricMonitorCriteria. That evaluator reads exactly one thing -
+   * CheckOn.MetricValue - so these types share a single pair of defaults:
+   * a metric that is reporting a value means online, a metric that has
+   * gone to zero means offline.
+   *
+   * Kept in step with the routing list in MonitorCriteriaEvaluator and
+   * with the check-on narrowing in the dashboard's CriteriaFilter util,
+   * which offers these types the metric value and nothing else. A type
+   * missing here falls through to `new MonitorCriteriaInstance()` and
+   * ships an unnamed criteria whose "Is Online" filter no evaluator on
+   * this path reads - a rule that can never fire and cannot be saved,
+   * since getValidationError requires a name and a description.
+   */
+  public static isMetricBackedMonitorType(monitorType: MonitorType): boolean {
+    return (
+      monitorType === MonitorType.Metrics ||
+      monitorType === MonitorType.Kubernetes ||
+      monitorType === MonitorType.Docker ||
+      monitorType === MonitorType.Host ||
+      monitorType === MonitorType.Podman ||
+      monitorType === MonitorType.DockerSwarm ||
+      monitorType === MonitorType.Proxmox ||
+      monitorType === MonitorType.Ceph ||
+      monitorType === MonitorType.IoTDevice
+    );
+  }
+
   public static getDefaultOnlineMonitorCriteriaInstance(arg: {
     monitorType: MonitorType;
     monitorStatusId: ObjectID;
@@ -232,7 +268,7 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
       return monitorCriteriaInstance;
     }
 
-    if (arg.monitorType === MonitorType.Metrics) {
+    if (MonitorCriteriaInstance.isMetricBackedMonitorType(arg.monitorType)) {
       const monitorCriteriaInstance: MonitorCriteriaInstance =
         new MonitorCriteriaInstance();
 
@@ -254,7 +290,7 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
                   ? arg.metricOptions.metricAliases[0]
                   : undefined,
             },
-            value: 0, // if there are some logs then monitor is online.
+            value: 0, // the metric is reporting above zero, so the monitor is online.
           },
         ],
         incidents: [],
@@ -269,7 +305,7 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
       return monitorCriteriaInstance;
     }
 
-    if (arg.monitorType === MonitorType.Kubernetes) {
+    if (arg.monitorType === MonitorType.Profiles) {
       const monitorCriteriaInstance: MonitorCriteriaInstance =
         new MonitorCriteriaInstance();
 
@@ -279,19 +315,9 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
         filterCondition: FilterCondition.Any,
         filters: [
           {
-            checkOn: CheckOn.MetricValue,
+            checkOn: CheckOn.ProfileCount,
             filterType: FilterType.GreaterThan,
-
-            metricMonitorOptions: {
-              metricAggregationType: EvaluateOverTimeType.AnyValue,
-              metricAlias:
-                arg.metricOptions &&
-                arg.metricOptions.metricAliases &&
-                arg.metricOptions.metricAliases.length > 0
-                  ? arg.metricOptions.metricAliases[0]
-                  : undefined,
-            },
-            value: 0,
+            value: 0, // if profiles are arriving then the monitor is online.
           },
         ],
         incidents: [],
@@ -1130,7 +1156,7 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
       };
     }
 
-    if (arg.monitorType === MonitorType.Metrics) {
+    if (MonitorCriteriaInstance.isMetricBackedMonitorType(arg.monitorType)) {
       monitorCriteriaInstance.data = {
         id: ObjectID.generate().toString(),
         monitorStatusId: arg.monitorStatusId,
@@ -1148,7 +1174,15 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
                   ? arg.metricOptions.metricAliases[0]
                   : undefined,
             },
-            value: 0, // if there are no logs then the monitor is offline
+            /*
+             * A reported value of zero, not an absent one. When the window
+             * holds no samples at all the evaluator honours
+             * metricMonitorOptions.onNoDataPolicy, which defaults to
+             * Ignore, so silence alone does not fire this - a user who
+             * wants "stopped reporting" to page has to opt into
+             * NoDataPolicy.Trigger or TreatAsZero on the filter.
+             */
+            value: 0,
           },
         ],
         incidents: [
@@ -1179,25 +1213,16 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
       };
     }
 
-    if (arg.monitorType === MonitorType.Kubernetes) {
+    if (arg.monitorType === MonitorType.Profiles) {
       monitorCriteriaInstance.data = {
         id: ObjectID.generate().toString(),
         monitorStatusId: arg.monitorStatusId,
         filterCondition: FilterCondition.Any,
         filters: [
           {
-            checkOn: CheckOn.MetricValue,
+            checkOn: CheckOn.ProfileCount,
             filterType: FilterType.EqualTo,
-            metricMonitorOptions: {
-              metricAggregationType: EvaluateOverTimeType.AnyValue,
-              metricAlias:
-                arg.metricOptions &&
-                arg.metricOptions.metricAliases &&
-                arg.metricOptions.metricAliases.length > 0
-                  ? arg.metricOptions.metricAliases[0]
-                  : undefined,
-            },
-            value: 0,
+            value: 0, // if no profiles are arriving then the monitor is offline
           },
         ],
         incidents: [
@@ -1482,39 +1507,62 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
       return `Description is required for criteria "${value.data.name}"`;
     }
 
-    for (const incident of value.data.incidents) {
-      if (!incident) {
-        continue;
-      }
-
-      if (!incident.title) {
-        return `Incident title is required for criteria "${value.data.name}"`;
-      }
+    /*
+     * Each "when filters match, ..." action is validated only while its own
+     * switch is on.
+     *
+     * The criteria form keeps the incident / alert rows it seeded when a
+     * switch was turned on, so that turning the switch back on restores what
+     * was typed - the same retained-but-inert config that
+     * MonitorStepsReferenceExtractor documents for project references. The
+     * evaluator ignores those rows entirely while the flag is off
+     * (MonitorIncident.criteriaMetCreateIncidentsAndUpdateMonitorStatus,
+     * MonitorAlert.criteriaMetCreateAlertsAndUpdateMonitorStatus), so
+     * validating them anyway only blocked the form: the row is rendered only
+     * while its switch is on, which left the user staring at "Incident title
+     * is required" with no field on screen to type it into and no way past
+     * Next (issues #3410, #3413).
+     *
+     * The predicate is the falsy one the evaluator uses, not `!== false`, so
+     * a criteria saved before these flags existed - populated rows, no flag -
+     * is treated as off here exactly as it already is at runtime.
+     *
+     * Title and severity are the two fields the form marks required; the
+     * description is not one of them. It sits in a collapsed section labelled
+     * "Optional incident description" / "Optional alert description", and both
+     * Incident.description and Alert.description are nullable columns. So it is
+     * not required here either - demanding it stuck the form on a field the UI
+     * calls optional and keeps folded away, which is the second half of #3410.
+     */
+    if (value.data.createIncidents) {
+      for (const incident of value.data.incidents) {
+        if (!incident) {
+          continue;
+        }
 
-      if (!incident.description) {
-        return `Incident description is required for criteria "${value.data.name}"`;
-      }
+        if (!incident.title) {
+          return `Incident title is required for criteria "${value.data.name}"`;
+        }
 
-      if (!incident.incidentSeverityId) {
-        return `Incident severity is required for criteria "${value.data.name}"`;
+        if (!incident.incidentSeverityId) {
+          return `Incident severity is required for criteria "${value.data.name}"`;
+        }
       }
     }
 
-    for (const alert of value.data.alerts) {
-      if (!alert) {
-        continue;
-      }
-
-      if (!alert.title) {
-        return `Alert title is required for criteria "${value.data.name}"`;
-      }
+    if (value.data.createAlerts) {
+      for (const alert of value.data.alerts) {
+        if (!alert) {
+          continue;
+        }
 
-      if (!alert.description) {
-        return `Alert description is required for criteria "${value.data.name}"`;
-      }
+        if (!alert.title) {
+          return `Alert title is required for criteria "${value.data.name}"`;
+        }
 
-      if (!alert.alertSeverityId) {
-        return `Alert severity is required for criteria "${value.data.name}"`;
+        if (!alert.alertSeverityId) {
+          return `Alert severity is required for criteria "${value.data.name}"`;
+        }
       }
     }
 
@@ -1523,6 +1571,18 @@ export default class MonitorCriteriaInstance extends DatabaseProperty {
         return `Filter Type is required for criteria "${value.data.name}"`;
       }
 
+      /*
+       * A filter with no condition is silently dead: every comparator in
+       * CompareCriteria switches on the filter type and returns "no
+       * match" for one it does not recognise, so the criteria never
+       * fires. The empty dropdown is easy to walk past when every field
+       * around it is filled in, so refuse the save instead of accepting
+       * a rule that can never be true.
+       */
+      if (!filter.filterType) {
+        return `Filter Condition is required for criteria "${value.data.name}" on filter type: ${filter.checkOn}`;
+      }
+
       if (
         monitorType === MonitorType.Ping &&
         filter.checkOn !== CheckOn.IsOnline &&

package/Types/Monitor/Recommendation/MonitorRecommendationSeverityMapper.ts

@@ -108,7 +108,8 @@ export default class MonitorRecommendationSeverityMapper {
    *
    * Returns undefined when the mapping has no entry, which callers must treat
    * as "leave the template's own severity alone" rather than as "no severity"
-   * — a criteria instance with a populated incident and no severity id fails
+   * — a criteria instance that creates incidents (`createIncidents`) and has a
+   * populated incident with no severity id fails
    * `MonitorCriteriaInstance.getValidationError` and the whole create fails.
    */
   public static resolveSeverityId(data: {

package/Types/SecurityEvent/DetectionFindingConstants.ts

@@ -18,6 +18,17 @@ export const DETECTION_RULE_NAME_ATTRIBUTE: string =
   "oneuptime.detection.rule_name";
 export const DETECTION_MATCH_COUNT_ATTRIBUTE: string =
   "oneuptime.detection.match_count";
+// Present only on findings from rules with a distinctCountField set.
+export const DETECTION_DISTINCT_COUNT_ATTRIBUTE: string =
+  "oneuptime.detection.distinct_count";
+
+/*
+ * Save-time bounds for DetectionRule.matchCountThreshold — one home for
+ * the server validator and the dashboard form, so the two ranges cannot
+ * drift apart.
+ */
+export const DETECTION_MATCH_COUNT_THRESHOLD_MIN: number = 1;
+export const DETECTION_MATCH_COUNT_THRESHOLD_MAX: number = 1000000;
 export const DETECTION_GROUP_VALUE_ATTRIBUTE: string =
   "oneuptime.detection.group_value";
 export const DETECTION_SIGMA_ID_ATTRIBUTE: string =

package/Types/Telemetry/LlmConventions.ts

@@ -16,6 +16,65 @@
  * lookup helpers return the first key that is present.
  */
 
+/**
+ * The prefix OTLP ingest stamps onto every RESOURCE attribute before the
+ * attributes map reaches any extractor.
+ *
+ * This is not cosmetic and it is the difference between a feature that works
+ * and one that silently reports nothing. All three ingest services flatten
+ * resource attributes through
+ * `TelemetryUtil.getAttributes({ items, prefixKeysWithString: "resource" })`
+ * — OtelTracesIngestService, OtelMetricsIngestService and
+ * OtelLogsIngestService alike. So an operator who sets
+ * `OTEL_RESOURCE_ATTRIBUTES=team.id=platform` does NOT produce an attribute
+ * called `team.id`; they produce one called `resource.team.id`.
+ *
+ * OtelTracesIngestService already learned this the hard way for session
+ * replay (see its `sessionIdAttributeKeys`, which lists both spellings and
+ * whose comment notes that reading only the bare key "would look correct in a
+ * unit test and fail in production"). Identity is the same trap, one tier
+ * worse: identity is precisely the kind of value a fleet stamps ONCE on the
+ * resource rather than on every span, and Cursor documents `cursor.user.id` /
+ * `cursor.team.id` as resource attributes outright.
+ */
+export const RESOURCE_ATTRIBUTE_KEY_PREFIX: string = "resource.";
+
+/**
+ * Widen a key list so it matches both the span-attribute spelling and the
+ * resource-attribute spelling of every key in it.
+ *
+ * The bare block comes FIRST in its entirety, then the resource-prefixed
+ * block, because a span attribute is strictly more specific than a resource
+ * attribute: the resource describes the whole process, the span describes one
+ * call. Preserving each block's internal order keeps the documented
+ * preference ordering intact within each tier.
+ *
+ * Pure and exported so the widening is one tested function rather than a
+ * hand-maintained second copy of every list that drifts the first time
+ * somebody adds a key.
+ */
+export function withResourcePrefixedKeys(keys: Array<string>): Array<string> {
+  return [
+    ...keys,
+    ...keys.map((key: string) => {
+      return `${RESOURCE_ATTRIBUTE_KEY_PREFIX}${key}`;
+    }),
+  ];
+}
+
+/*
+ * Note what is deliberately NOT widened: every list below that carries a
+ * per-CALL value — system, operation, models, tokens, cost, conversation id,
+ * tool name, request parameters, prompts and completions. Those describe one
+ * LLM request and have no business being set on a resource, which describes
+ * the whole process; a resource-scoped `gen_ai.request.model` would be a
+ * misconfiguration, not a convention to support. Widening them would double
+ * the number of map lookups on the hottest ingest path to chase a spelling
+ * nobody emits. Only the IDENTITY lists — user id, user email, team, and the
+ * end-user EXCLUSION list — are widened, because identity is exactly the
+ * value an operator sets once via OTEL_RESOURCE_ATTRIBUTES.
+ */
+
 // Provider / system, e.g. "openai", "anthropic", "aws.bedrock".
 export const LlmSystemAttributeKeys: Array<string> = [
   "gen_ai.system",
@@ -96,6 +155,202 @@ export const LlmAgentNameAttributeKeys: Array<string> = [
   "agent.name",
 ];
 
+/*
+ * ---------------------------------------------------------------------------
+ * WHO ran this call — the EMPLOYEE, never the employee's own customer.
+ * ---------------------------------------------------------------------------
+ *
+ * The LLM feature was born trace-only and had no concept of a human being, so
+ * "which of our engineers burned $4k on Opus last month" was unanswerable. The
+ * three lists below make the human actor a first-class span dimension, so
+ * spend can be grouped by person and by cost centre.
+ *
+ * THE CORRECTNESS RULE, and it is not a stylistic one: an LLM span can carry
+ * TWO different humans. The employee who made the call, and the DOWNSTREAM
+ * CUSTOMER on whose behalf the call was made (OpenAI's `user` request
+ * parameter, which instrumentations echo back as gen_ai.user / llm.user, and
+ * LiteLLM's end-user id). Those two are not interchangeable. Mapping a
+ * downstream customer into the employee columns produces internal chargeback
+ * that is not merely imprecise but WRONG — a support bot serving 40k
+ * customers would manufacture 40k phantom "employees", and the engineer who
+ * actually owns that spend would appear to have spent nothing.
+ *
+ * So the customer-identity keys are enumerated separately in
+ * LlmEndUserAttributeKeys below and are deliberately NOT read into any
+ * column. The exclusion is pinned by a test; if someone later wants
+ * downstream-customer analytics it must land in its OWN column, never by
+ * appending a key to the lists below.
+ */
+
+/*
+ * The employee / internal actor id.
+ *
+ * Provenance, preferred first:
+ *   - user.id      OTel general semantic conventions; THE canonical key for
+ *                  the human actor and the one to standardize on.
+ *   - enduser.id   Also still an ACTIVE semconv attribute — the 1.25
+ *                  deprecation removed enduser.role and enduser.scope only,
+ *                  so this remains a legitimate, widely-emitted spelling.
+ *   - litellm.metadata.user_api_key_user_id  /  metadata.user_api_key_user_id
+ *                  LiteLLM proxy: the internal user who OWNS the virtual key
+ *                  the request authenticated with. Note the sibling key
+ *                  user_api_key_end_user_id is the CUSTOMER and is excluded.
+ *
+ *                  BOTH spellings are required, and the bare one is the one
+ *                  that actually fires for most deployments. LiteLLM's
+ *                  default `otel` callback (v1) stamps its metadata with a
+ *                  bare "metadata." prefix — see METRIC_METADATA_KEYS and the
+ *                  `common_attrs[f"metadata.{key}"]` assignment in
+ *                  litellm/integrations/opentelemetry.py. The "litellm."
+ *                  namespace only appears under OpenTelemetry v2, which is
+ *                  OFF by default (LITELLM_OTEL_V2, `enabled: default=False`).
+ *                  Recognizing only the v2 spelling meant a stock LiteLLM
+ *                  proxy — the exact "one virtual key per employee" setup our
+ *                  docs recommend as the cleanest chargeback architecture —
+ *                  produced ZERO attribution, silently, with every gateway
+ *                  dollar landing in Unattributed and no error to explain it.
+ *   - traceloop.association.properties.user_id   OpenLLMetry.
+ *   - langfuse.user.id                           Langfuse.
+ *   - user.account_uuid / user.account_id        Claude Code (and Codex for
+ *                  the latter) stamp the signed-in account onto every span.
+ *   - cursor.user.id   Cursor's OTel export; an opaque team-scoped integer,
+ *                  which is why it sorts last — it needs the Cursor admin API
+ *                  to resolve to a person, unlike the keys above.
+ *
+ * The `Base` list is the SPAN-attribute spelling only. Consumers must import
+ * LlmUserIdAttributeKeys, which adds the resource-attribute tier — see
+ * withResourcePrefixedKeys. The base list is exported solely so tests and
+ * docs can cross-check the two tiers against each other.
+ */
+export const LlmUserIdBaseAttributeKeys: Array<string> = [
+  "user.id",
+  "enduser.id",
+  // LiteLLM OTel v2 spelling, then the v1 default. Both are needed — see above.
+  "litellm.metadata.user_api_key_user_id",
+  "metadata.user_api_key_user_id",
+  "traceloop.association.properties.user_id",
+  "langfuse.user.id",
+  "user.account_uuid",
+  "user.account_id",
+  "cursor.user.id",
+];
+
+export const LlmUserIdAttributeKeys: Array<string> = withResourcePrefixedKeys(
+  LlmUserIdBaseAttributeKeys,
+);
+
+/*
+ * The employee's email address — in practice the only identity value a
+ * manager can read without a lookup table, which is why it gets its own
+ * column rather than being folded into the id.
+ *
+ * user.email is the OTel general-semconv key and is emitted NATIVELY by
+ * Claude Code, Gemini CLI and OpenAI Codex, so for the coding-agent fleet
+ * this list is usually the one that hits.
+ *
+ * The two LiteLLM spellings matter more than their position suggests: the
+ * proxy carries the key owner's email in its metadata (user_api_key_user_email
+ * is in METRIC_METADATA_KEYS), so a gateway issuing one virtual key per
+ * employee yields a real, human-readable email with no lookup table and no
+ * per-application instrumentation. That is the cleanest chargeback setup
+ * available today, and it is what our AI-gateway guide recommends. As with
+ * the id list, the bare "metadata." spelling is the DEFAULT one and the
+ * "litellm." namespace only appears under the opt-in OpenTelemetry v2 mode.
+ *
+ * Because this column holds real PII, TraceScrubRuleService scrubs it under
+ * the Attributes scope exactly as it scrubs the attribute it was derived from
+ * — see the identity-column pass in scrubSpan. A denormalized column that
+ * skipped the scrub pass would make a customer's email-redaction rule
+ * silently ineffective on the very column most likely to hold an email.
+ */
+export const LlmUserEmailBaseAttributeKeys: Array<string> = [
+  "user.email",
+  // LiteLLM OTel v2 spelling, then the v1 default. Both are needed — see above.
+  "litellm.metadata.user_api_key_user_email",
+  "metadata.user_api_key_user_email",
+  "traceloop.association.properties.user_email",
+  "enduser.email",
+];
+
+export const LlmUserEmailAttributeKeys: Array<string> =
+  withResourcePrefixedKeys(LlmUserEmailBaseAttributeKeys);
+
+/*
+ * The team / cost centre the spend charges to.
+ *
+ * The first four are not emitted by any instrumentation on their own: they
+ * are what an organization sets via OTEL_RESOURCE_ATTRIBUTES on the agent
+ * process (OTEL_RESOURCE_ATTRIBUTES=team.id=platform,cost_center=RD-114), and
+ * are conventionally the ONLY way a coding-agent CLI learns which budget it
+ * belongs to. The remaining entries are the gateway/vendor spellings that
+ * arrive without any operator configuration.
+ *
+ * That first sentence is exactly why the resource tier is not optional here:
+ * OTEL_RESOURCE_ATTRIBUTES sets a RESOURCE attribute, which ingest delivers
+ * as `resource.team.id`. A list of bare keys alone would mean the one
+ * mechanism the docs present as THE way to attribute spend to a cost centre
+ * never matches a single row.
+ */
+export const LlmTeamBaseAttributeKeys: Array<string> = [
+  "team.id",
+  "team",
+  "cost_center",
+  "department",
+  // LiteLLM OTel v2 spellings, then the v1 default. See the id list above.
+  "litellm.metadata.user_api_key_team_id",
+  "litellm.team.id",
+  "metadata.user_api_key_team_id",
+  "cursor.team.id",
+];
+
+export const LlmTeamAttributeKeys: Array<string> = withResourcePrefixedKeys(
+  LlmTeamBaseAttributeKeys,
+);
+
+/*
+ * DELIBERATELY EXCLUDED — the DOWNSTREAM CUSTOMER, not the employee.
+ *
+ * Exported so the exclusion is a documented, testable decision rather than an
+ * omission somebody "fixes" later:
+ *
+ *   - gen_ai.user / llm.user
+ *       Both carry the OpenAI `user` REQUEST PARAMETER, which the API
+ *       documents as the caller's own end user, sent for abuse monitoring. On
+ *       a SaaS product's spans this is the SaaS product's customer.
+ *   - litellm.metadata.user_api_key_end_user_id  /
+ *     metadata.user_api_key_end_user_id  /  litellm.end_user.id
+ *       LiteLLM's explicit end-user id, distinct from the key-owner id above
+ *       (which IS the employee and IS recognized). All three spellings are
+ *       listed for the same reason the employee lists carry two: the bare
+ *       "metadata." form is what the DEFAULT v1 otel callback emits, while
+ *       "litellm.end_user.id" is the dedicated attribute the opt-in v2 mode
+ *       defines in litellm/integrations/otel/model/semconv.py. Excluding only
+ *       the v2 metadata spelling would leave the two spellings a real
+ *       deployment actually produces free to be mistaken for an employee.
+ *
+ * None of these is denormalized into a column by this change. They remain
+ * available in the raw attributes map for anyone who queries them directly.
+ *
+ * This list is resource-widened too, and for the OPPOSITE reason to the
+ * lists above. Here the widening does not make anything match — it makes the
+ * EXCLUSION hold. The exclusion is enforced as a set relation ("no end-user
+ * key appears in an employee list"), so if this list stopped at the bare
+ * spellings while the employee lists carried both tiers, a future
+ * `resource.gen_ai.user` could be appended to an employee list and every
+ * exclusion test would still pass. Both tiers here, both tiers there.
+ */
+export const LlmEndUserBaseAttributeKeys: Array<string> = [
+  "gen_ai.user",
+  "llm.user",
+  "litellm.metadata.user_api_key_end_user_id",
+  "metadata.user_api_key_end_user_id",
+  "litellm.end_user.id",
+];
+
+export const LlmEndUserAttributeKeys: Array<string> = withResourcePrefixedKeys(
+  LlmEndUserBaseAttributeKeys,
+);
+
 export const LlmToolNameAttributeKeys: Array<string> = [
   "gen_ai.tool.name",
   "tool.name",