Tagging & auto-tagging

Tags are how you make a large estate navigable. In WatchTower15 every tag lives in a tag group (its key or category), and tags can be applied to servers, domains and services — then used to filter dashboards, scope log searches, and target alarms. The agent can also tag hosts automatically from the metadata they already carry, so a freshly-provisioned fleet arrives correctly labelled with no manual work.

Tag groups and tags

A tag is always a value inside a group. The group is the key; the tag is the value. For example, the group Environment might contain the tags production, staging and qa.

Every organisation is seeded with four system groups that cannot be renamed or deleted:

System group	Scope	Applies to
Organisation-wide	none	any resource type
Server	server	servers only
Domain	domain	domains only
Service	service	services only

You can create any number of your own groups; custom groups default to the none scope, meaning their tags can be applied to any resource type. A group’s scope is what enforces sensible assignment — a tag in a Domain-scoped group can’t be stuck on a server.

Note

Tag names are unique within a group, so Region:eu and Zone:eu happily coexist. There is no per-tag colour concept — organisation is by group, not by colour.

Auto-tagging (server-led tagging)

When enabled on a profile, the agent reads identity metadata from the host at enrollment and reports it as tags. The backend find-or-creates the matching groups and tags, so the tag key becomes the group name and the tag value becomes the tag — an AWS instance tag Environment=production becomes group Environment → tag production.

Sources the agent reads

Source	Detected when	Read from
AWS EC2 instance tags	instance metadata is reachable	IMDSv2 (token-authenticated) — the instance tags exposed at /latest/meta-data/tags/instance/
Docker environment	/.dockerenv exists	KEY=VALUE pairs from PID 1's environment, excluding system vars (PATH, HOME, HOSTNAME, TERM, SHELL, …)
Kubernetes pod labels	KUBERNETES_SERVICE_HOST is set	the Downward API labels file at /etc/podinfo/labels

All three sources are merged into one flat set of key/value pairs. Where the same key appears in more than one source, the later collector wins — in practice Kubernetes labels take precedence over Docker, which takes precedence over AWS. Metadata lookups are best-effort and time-boxed (a couple of hundred milliseconds for cloud metadata), so a source that isn’t present or is slow is silently skipped and never delays enrollment.

Keeping tags in sync

Auto-tagging isn’t a one-shot at install. On the system-information cadence the agent re-collects metadata, computes a delta, and reports only new keys or changed values. Updates are additive — the agent adds and updates tags but never removes them from a running host, so a transient metadata blip can’t strip a server’s identity.

A safeguard you should know about

To stop host metadata from polluting your domain/service taxonomy, enrollment rejects any server-reported tag whose key matches a Domain- or Service-scoped group. Server metadata can only ever create or fill server-appropriate groups.

Putting tags to work

Once resources are tagged you can:

• Filter any list or dashboard by one or more tags.
• Scope log searches to “every host tagged web-tier” without listing UUIDs (see log search).
• Target alarms and notification policies at a tag rather than at individual resources, so new matching resources are covered automatically.

Related

• Advanced tagging — include/exclude filter rules per profile.
• Fleet & profiles — where server-led tagging is switched on.