Core concepts and vocabulary¶

TrackMe has a small, consistent vocabulary. These dozen terms appear on every page of this guide and in the interface itself. Learn them once here.

The mental model in one sentence¶

TrackMe tracks entities (grouped into components, isolated inside virtual tenants); on every cycle a decision maker gives each entity a state and a score, policies classify it, and alerting turns critical states into notifications.

Everything below expands one word of that sentence.

Entity¶

An entity is the fundamental unit TrackMe monitors — one data source, one host, one metric feed, one scheduled search, or one custom object you defined. Each entity has an object_id (its identity, e.g. an index|sourcetype pair), a current state, a score, and the metadata attached to it (priority, tags, labels, SLA, and so on).

There is no global list of entities — every entity lives inside exactly one virtual tenant.

Component¶

Every entity belongs to one of six components, which decide what is measured: DSM, DHM, MHM, FLX, FQM, WLK. The component determines the metric axes (delay, latency, volume, quality, execution health…) and the tracking logic applied. See What is TrackMe? for the one-line description of each, and Part 3 for the deep dives.

Virtual Tenant¶

A virtual tenant is an isolated monitoring domain — typically one customer, one environment, or one team. Each tenant has its own entities, its own configuration and policies, its own set of Splunk roles, and optionally its own remote Splunk deployment to monitor.

Tenants are the unit of isolation and the unit of scale: you create, scope, experiment with, and destroy them independently. Everything else in TrackMe is scoped to a tenant.

Virtual Group¶

A virtual group is a read-only card that aggregates entities from several tenants into a single cross-tenant view — useful for a NOC screen that spans many customers. A virtual group is not a tenant: it does not run monitoring of its own, it only summarises what the underlying tenants already computed.

Entity state¶

At every cycle each entity is assigned an object state — one of four colours:

State	Meaning
🟢 green	Healthy — no active anomaly.
🟠 orange	Warning — a non-critical anomaly is active (score above zero, below critical).
🔴 red	Critical — the entity has crossed the critical threshold.
🔵 blue	Suppressed — the entity is protected from alerting (logical-group protection, a disruption grace period, or maintenance), even though an anomaly may be present.

The state machine and the blue “protected” state are covered in Part 4.

Impact score¶

The state is derived from a numeric impact score. TrackMe adds up the contributions of everything that is currently wrong with an entity — delay breach, latency breach, ML outliers, breached dynamic thresholds — into a single total_score:

total_score == 0 → green
0 < total_score < 100 → orange
total_score ≥ 100 → red

The weight of each contribution is configurable per tenant and can be overridden per entity, so you decide whether (say) a latency breach matters more than a volume drop. Impact scoring is covered in Part 4.

Tracker¶

A tracker is a scheduled search that runs on a cycle and feeds the decision maker. Trackers are what make TrackMe active rather than a static dashboard — they periodically re-evaluate every entity. Most are managed for you; advanced users can add hybrid trackers (Part 7) to inject extra signals.

Decision maker¶

The decision maker is the shared engine that, each cycle, reads an entity’s metrics and metadata and computes its state and score. It is the single place where “is this entity healthy?” is answered, so the answer is consistent across the UI, alerts, and the API.

Policy¶

Manually setting priority or SLA on thousands of entities does not scale. A policy assigns metadata automatically using a rule — a regex, a Splunk lookup, or an SPL search. Three policy families exist: priority, tags, and SLA. Policies suggest; a manual override always wins, and removing a policy auto-cleans the assignments it made. Policies are covered in Part 5.

Priority, tags, labels, SLA¶

These are the four kinds of classification metadata you attach to entities:

Priority — critical / high / medium / low / pending. How much an entity matters.
Tags — free-form string metadata for filtering and grouping.
Labels — a curated, colour-coded catalogue of chips (distinct from tags: different storage, different UI, and assignable by rules).
SLA class — platinum / gold / silver with associated thresholds.

Note

Tags and labels are not the same feature. Both are chip-style metadata, but tags are free-form strings while labels come from a managed, coloured catalogue and can be assigned automatically by rules. Part 5 shows them side by side.

Logical group¶

A logical group clusters N entities and judges them collectively. If the percentage of green members stays above a threshold, struggling members are demoted from red to blue (“group protection”) — so one flaky member of a healthy cluster does not page you.

Disruption queue¶

The disruption queue is a grace period. When an anomaly first appears, the entity is held in blue until the anomaly has persisted for a configured minimum time — absorbing transient blips so only sustained problems escalate to red.

Acknowledgment (ACK)¶

An acknowledgment suppresses further notifications for an entity you already know about. Sticky ack stays until you clear it; unsticky ack expires automatically after a set period. Ack can be revoked automatically if the underlying anomaly reason changes.

Notable event¶

A notable event is the traditional Splunk alerting output — an event written for Enterprise Security or a custom correlation workflow. It is one of several delivery channels TrackMe’s stateful alerting can drive; see Part 6.