Tags

Every integration already labels things: Kubernetes labels, DataDog host and monitor tags, AWS and Azure resource tags, Cloudflare zone metadata. ISE pulls all of it into one normalised pool — so the estate can be read by what things are for rather than by what they’re called.

This is the counterpart to the estate, which reads by identity and relationship.

One pool, with provenance

A tag in ISE carries where it came from. When both DataDog and Kubernetes claim service:checkout on the same workload, that’s recorded as two sources agreeing — not collapsed into an anonymous label. Every tag badge can tell you who asserts it, by what method, and when it was last confirmed.

Tags arrive on entities (a workload’s labels) and on signals (a monitor’s own tags plus the scope tags of the group that fired), which is what lets a tag be a bridge between “what exists” and “what is going wrong”.

The tag cloud

The tag cloud shows every live tag, sized and coloured by how many alerts touched it in your chosen window — 24 hours, 7 days, or 30. A tag heats up either by being carried by an alert directly, or via the entity that alert names; the two are combined so one alert counts once.

Practical notes: the view is capped at the hottest 200 tags and says so on screen, and narrowing by text filters what you see without re-fetching — re-basing the heat scale against a filtered subset would change a tag’s colour as you type, which makes the scale meaningless.

Click any tag for its drilldown: which integrations assert it estate-wide, which entities carry it (with per-entity provenance), and the in-window alerts heating it. Your window and integration filters travel with you, so you keep the view you were reading.

Groups: tags that become real things

Admins define tag rules — AND-ed predicates, optionally scoped to one integration — that materialise group entities in the estate:

• service:kora → the group “Kora”
• cluster:g5 and env:prod → “Public customer-facing applications”

These are real entities in the graph, with rule-provenance membership edges — which is what lets an incident say which service is affected rather than just which pod, and what dashboard services are built from.

The tag dictionary

Sources spell things differently. env:Prod, env:production, and env:prod are usually one idea wearing three hats.

The dictionary is to tags what aliases are to entities: many raw names, one canonical identity, with the link explicit and reversible. A governed key has a canonical name, a description, key aliases, and a value mode — defined keys carry a list of standard values (each with its own aliases), while open keys like service: accept anything while still mapping synonyms.

The dictionary maps; it never rewrites. env:Prod resolves to env:prod inside ISE, and DataDog still says Prod. That is deliberate — ISE should be useful without editing anyone else’s systems.

Fixing tags at the source

Mapping leaves the underlying mess intact, and every other consumer of those tags — cost allocation, dashboards, someone’s Terraform — keeps seeing it. So several integrations carry a tag-write action (set_host_tag, set_label, set_resource_tag) that fixes the label where it actually lives.

These run through the ordinary governed pipeline — a proposed change with a tier, an approval where policy demands one, and an audit record. Retagging is deliberately treated as a real change rather than a quiet convenience: it writes configuration that persists, that other systems key off, and that ISE itself reads back as a knowledge source.

Next

• Dashboards — services built from these groups.
• The estate — the identity side of the same picture.
• Actions & approvals — how a tag write is governed.