Summary

When an Inventory threshold (metrics.alert.inventory.threshold) or Metric threshold alert fires, the alert document’s tags field can be corrupted if the underlying Elasticsearch source document has tags as a string (e.g. "beats_input_raw_event") instead of an array of keywords. The code path merges source tags with rule tags using spread syntax ([...additionalContext.tags, ...ruleTags]). Spreading a string iterates characters, so each character becomes a separate tag (e.g. b, e, a, t, s, _, …) alongside the real rule tags.

This is commonly seen with hosts indexed by Elastic Agent / Beats, where tags may be a single keyword string.

Observed on: ECK 3.3, Kibana 9.2 (customer); reproduction also confirmed on ECH 9.2.7 and 9.3.2.

Steps to reproduce

1. Index documents where tags is a string (not an array), e.g. tags: "beats_input_raw_event", with fields required for host CPU inventory/metric rules.
2. Create an Inventory threshold rule (or a Metric threshold rule) that can fire against those documents; give the rule normal tags (e.g. repro-tag-1, repro-tag-2).
3. Wait for the alert to fire.
4. Inspect the alert document (e.g. in Discover against .internal.alerts-observability.metrics.alerts-*, or the alert Metadata UI).

Expected behavior

Alert tags should reflect whole tag values from the source document (e.g. one tag beats_input_raw_event) merged with the rule’s tags, not character-level tokens.

Actual behavior

tags on the alert includes one entry per character of the string field, plus the rule tags, e.g.:

b, e, a, t, s, _, i, n, p, u, r, w, v, … and repro-tag-1, repro-tag-2.

Example from a repro query on the internal alerts index: kibana.alert.rule.tags stays correct (["repro-tag-1","repro-tag-2"]) while top-level tags is polluted with single-character entries.