The seven components at a glance¶

A component is the kind of thing an entity is. It determines what TrackMe measures, which thresholds apply, and what “healthy” means. Every entity belongs to exactly one component, and the seven codes — DSM, DHM, MHM, VOL, FLX, FQM, WLK — appear throughout the interface, the metrics, and the REST API.

Code	Component	What it tracks	Use it to answer
DSM	Data Source Monitoring	`(index, sourcetype)` data feeds — delay, latency, volume, quality.	Is my data flowing?
DHM	Data Host Monitoring	Host × sourcetype activity per endpoint.	Who is sending, and what?
MHM	Metric Host Monitoring	Hosts sending metric data, by metric category.	Are my metrics arriving?
VOL	Volume Outliers	Licensed volume per index — drops, spikes, inactivity, trend and projection.	Is my license volume normal?
FLX	Flex Objects	Anything you can express in SPL, with custom KPIs.	Is this custom thing healthy?
FQM	Field Quality Monitoring	Field extraction quality and CIM compliance.	Is my data well-parsed?
WLK	Workload Knowledge	Scheduled-search execution health.	Are my searches healthy?

DSM, DHM, and MHM form the Splunk Feeds family and share a delay/latency model. FLX, FQM, and WLK share a dynamic-thresholds + metrics model. VOL stands on its own: one entity per index fed by the license usage logs, with ML outliers as its state.

Note

UAM — User Activity Monitoring (Beta) is not an eighth entity component but a dedicated tenant type, outside the seven: it has no entities, no state and no scoring — it answers who is doing what on my Splunk? with findings about accounts and their scheduled searches, activity and resource usage. See UAM — User Activity Monitoring (Beta).

The shared entity model¶

However different the seven components look, every entity has the same shape and lifecycle.

An entity always has:

an object — its canonical, unique key (what it identifies differs per component);
an alias — an editable display name;
a state — 🟢 green / 🟠 orange / 🔴 red / 🔵 blue (see Entity State & Scoring);
a score, thresholds, anomaly fields, and a cache of its latest metrics.

And every entity goes through the same lifecycle each cycle:

DISCOVER  →  TRACK  →  EVALUATE  →  ALERT / LIFECYCLE
a tracker     each run    decision maker   stateful alerting,
enumerates    refreshes   sets state +     acknowledgment,
units and     metrics     score from       purge of inactive
creates       & times     thresholds       entities
entities

Note

Trackers are scheduled searches, usually running every five minutes. The freshness of a delay measurement is therefore only as precise as the tracker cadence — a five-minute schedule can report a delay up to five minutes after the fact. Entities can also be declared before they exist (see expected sources / hosts for DSM and DHM); a declared entity starts red until real data arrives.

Choosing a component¶

You want to track…	Use
The freshness and volume of an index + sourcetype feed	DSM
Which hosts are sending, and what sourcetypes, per host	DHM
Hosts sending data to a metrics index	MHM
The licensed volume of every index — drops, spikes, silence, trend, projection	VOL
Field parsing quality / CIM coverage	FQM
Scheduled-search execution health (skips, errors, delay, cost)	WLK
Anything else you can write a search for	FLX

What every component shares¶

These concerns apply to all seven and are documented once, in their own parts:

Classification — priority, tags, labels, and SLA (Classification & Protection).
Protection — logical groups, the disruption queue, and acknowledgments (Classification & Protection, Alerting).
Stateful alerting — one state machine for all seven (Alerting).
Scoring — one hybrid score; the per-anomaly weights differ per component (Entity State & Scoring).
ML outlier detection — a natural fit for DSM and FLX, and the very purpose of VOL; less useful, and off by default, for DHM, MHM, FQM, and WLK (Machine Learning).
Topology graphs — every component except VOL can render its entities as an interactive link / network graph (see Topology graphs below).

Where the components differ¶

A few capabilities are specific to certain components. Keep this map in mind:

Capability	Available for
Variable delay & lagging classes	DSM, DHM (MHM uses static thresholds)
Data sampling, elastic sources, lookup monitoring	DSM only
Expected-sources / hosts injection & coverage-gap analysis	DSM, DHM
Dynamic, time-sliceable metric thresholds	FLX, FQM
Versioning, orphan detection, app enablement, SVC cost	WLK
Free-form KPIs, template catalog, converging trackers	FLX
ML outliers as the primary state, detection direction per index (drops / spikes / both)	VOL
Inactivity policy (static or by day-of-week / hour-of-day), history backfill, month projection, Global license usage analytics	VOL

Topology graphs¶

Every component except VOL can render its entities as an interactive topology graph — open it from the graph icon in the Tenant Home header (the icon is contextual to the component tab you are viewing). The modal offers two views, a Link graph and a Network graph, and lays the tenant’s entities out as a hierarchy:

Component	Hierarchy
DSM	tenant → index → entity
DHM	tenant → host → index → sourcetype (→ extras)
MHM	tenant → host → metric category
WLK	tenant → app → entity
FQM	tenant → data model → entity
FLX	plus dedicated converging and use-case graphs (tenant → service / group → members)

Note

VOL has no Tenant Home topology graph — one entity per index leaves no hierarchy to draw. VOL entities can still be placed in Topology Studio views like any other component.

Each node is coloured by status (🟢 / 🟠 / 🔴 / 🔵), and a parent rolls up to the worst status among its descendants — so a single red leaf turns its whole branch red, letting you trace a problem from the tenant down to the offending entity at a glance. You can search the graph, filter to All / Down / Up, and cap the number of leaf nodes drawn (default 150) on large tenants.