TrackMe Use Cases Referential — Overview¶

What this referential is

This is a comprehensive, cross-cutting map of everything TrackMe can be used for, organised so an existing customer (or a prospective one) can audit their current footprint against the full capability surface and spot what they are not yet leveraging.

It is not a tutorial — for step-by-step walkthroughs, see the Quickstart and the various white papers. It is not a feature pitch either — every entry maps to a concrete TrackMe component, configuration touchpoint, and (where applicable) a pre-built use case template that ships in the product.

Audience:: TrackMe administrators auditing coverage, Splunk SREs scoping a TrackMe rollout, architects and team leads prioritising which features to enable next.
Last updated:: TrackMe v2.3.23

Why a referential¶

Most TrackMe customers use a fraction of what the platform offers. The combination of:

six monitoring components (DSM, DHM, MHM, FLX, FQM, WLK),
a deep library of cross-cutting features (policies, ML outliers, stateful alerting, impact scoring, virtual tenants, configuration guardian, AI Assistant, remote Splunk fleets, SOAR integration, …),
65 pre-built FLX use case templates that ship with the product,
a growing ecosystem of companion add-ons (Cribl Stream / Edge, Google SecOps, lookups, XSOAR, conf-manager, SOAR connector),

means that “what TrackMe can do” is genuinely hard to summarise on a single page. This referential breaks it into five layers, each answering a different question.

The five layers¶

1. Use Cases by Intent

“What do I want to monitor?” — organised by user goal: ingestion freshness, Splunk platform health, license / cost, scheduled-search health, field-parsing quality, custom KPIs, non-Splunk systems, intelligent alerting, multi-tenant scale, downstream integrations. The shortest path from a real-world question to the TrackMe component that answers it.

TrackMe Use Cases — Organised by User Intent

2. Capability × Component Matrix

“Which features apply to which monitoring components?” — every cross-cutting capability (priority policies, SLA, variable delay, ML outliers, hybrid trackers, AI status reports, …) mapped against the six components, with one-line use cases unlocked and the configuration touchpoint for each.

TrackMe Capability × Component Matrix

3. FLX Template Catalog

“What pre-built use cases can I enable today?” — the full catalog of the 65 FLX templates shipped in the product, grouped by category (Splunk infrastructure, license, Splunk Cloud, SOAR, Cribl Stream / Edge, good practices, host OS, …) with metrics, schedule, source data, dependencies, and ML-outlier flag per entry. Closes with a gap-analysis checklist.

FLX (Flex Objects) Use Case Template Catalog

4. Ecosystem & Companion Add-ons

“What else can I plug in?” — the companion technology add-ons and the SOAR connector that extend TrackMe beyond Splunk: Cribl Stream / Edge, Google SecOps, lookup files, Cortex XSOAR, resilient configuration replay, and Splunk SOAR playbook orchestration of TrackMe entities.

TrackMe Ecosystem — Companion Add-ons

5. Adoption Roadmap

“What should I focus on next?” — the six-phase customer journey we typically see (DSM feeds → DHM hosts → ML volume outliers → optional WLK interlude → FLX expansion and third-party → steady state). Descriptive, not prescriptive; each phase opens with the customer question that triggers it, calls out anti-patterns to avoid, and notes Foundation / Enterprise / Unlimited edition variants.

TrackMe Adoption Roadmap

How to use this referential¶

For a coverage audit of an existing TrackMe deployment, work through the layers in this order:

Start with the FLX template catalog (layer 3) — the most concrete “what am I missing?” pass. The gap-analysis checklist at the bottom of that page walks you through every domain (license, indexer cluster, ingestion, SH workload, good practices, data quality, Cribl, SOAR, host OS) one question at a time.
Then read the capability matrix (layer 2) — once you know which components and templates you are using, cross-reference whether you have priority policies, SLA classes, ML outlier detection, logical groups, disruption queues, smart status investigations, AI status reports, etc. wired in for those components. The matrix shows you the per-component support and the configuration touchpoint.
Use the by-intent catalog (layer 1) when a stakeholder asks a question in plain English (“can we monitor X?”) — find the goal, follow the cross-references.
Consult the ecosystem chapter (layer 4) when your scope extends beyond a single Splunk instance — Cribl, Google SecOps, SOAR / XSOAR integration, lookup-file monitoring, etc.
Cross-check the adoption roadmap (layer 5) to position yourself — “we are solid on phase 1 and phase 2, just starting on phase 3” — and to see what we typically teach customers about next.

For scoping a new TrackMe rollout or planning an extension, the adoption roadmap (layer 5) is the right starting point — it tells you which capabilities to focus on first and which to defer. Then use the capability matrix to set expectations, by-intent to align on goals with stakeholders, the FLX catalog to identify quick wins from pre-built templates, and the ecosystem chapter for integrations and external data sources.

How TrackMe is structured (recap)¶

The referential assumes you are familiar with TrackMe’s core concepts. If not, the very short recap below is enough to navigate the five layers; each concept also links to its deeper documentation.

The six monitoring components¶

Every TrackMe entity belongs to one of six monitoring components. The three-letter codes are load-bearing — they appear in REST paths, KV collections, filenames, and the wizard UI.

Code	Full name	What it monitors
DSM	Data Source Monitoring	Data feeds modelled as `(index, sourcetype)` combinations — the fundamental “is my data flowing” axis. Also supports a `lookups` search mode that tracks CSV / KVstore lookups as entities.
DHM	Data Host Monitoring	Per-host × per-sourcetype activity — “who is sending what”. Hybrid trackers in 2.3.23+ support an optional `breakby_extra_fields` dimension on top of the combo grain.
MHM	Metric Host Monitoring	Hosts sending metric data, grouped by metric category — the counterpart of DHM on metric indexes.
FLX	Flex Objects	Any Splunk SPL turned into tracked entities with custom KPIs. Sixty-five pre-built templates ship in the catalog (layer 3).
FQM	Field Quality Monitoring	Field parsing quality and CIM compliance — coverage %, success %, per-field metrics.
WLK	WorkLoad Knowledge	Scheduled-search execution health — skip rate, error count, execution delay, version drift, orphan owners, app enablement.

Virtual Tenants¶

Every TrackMe deployment is sliced into Virtual Tenants — isolated containers each with their own KV collections, RBAC roles, indexes, scheduling, default thresholds, and (optionally) a remote Splunk deployment target. Components are enabled per tenant. See Creating a tenant and Managing tenants.

State, scoring, alerting¶

Every entity is in one of four states — green (healthy), orange (warning), red (critical), or blue (protected by group or grace window). The state is determined by a hybrid score that adds a rolling base_score from the metrics index to per-condition impact scores and threshold scores. See QUICK START - TrackMe Impact-Based Alerting (IBA) and Stateful alerting.

Stateful alerting¶

State transitions (green → orange / red, red → green, …) drive a single stateful record per (entity, alert configuration). The alert action fires “Alert Opened”, “Update”, and “Alert Closed” notifications — optionally enriched with embedded SVG → PNG charts and LLM-generated AI status reports. See Stateful alerting.

License editions¶

Feature availability is gated by license edition. The referential calls out edition-specific gates inline where relevant. The short version:

Edition	Type	Notes
Foundation	Subscription / 90-day trial	DSM, DHM, MHM only. No FLX, no WLK. No remote deployments. No hybrid trackers.
Enterprise	Subscription	All six components. FLX and WLK enabled. Hybrid trackers capped at 8 per tenant.
Unlimited	Subscription	All features, unlimited scale, remote deployments.
Developer	Self-service / 30 days	All features for local development; max 3 activations per instance.

See EULA License and License registration for details.

What this referential does NOT replace¶

Step-by-step walkthroughs. The Quickstart and the white papers remain the right place to learn TrackMe.
Component-specific deep dives. Each component has dedicated admin / user guide pages: FLX — Flex Objects, WLK — Workload Knowledge, Use Case Demo: Fields Quality (CIM and non-CIM), Use Case Demo: This is All About Feeds, etc.
REST API documentation. See REST API reference and the in-product REST API Reference page.
Release notes. See Release notes.

The referential complements those documents by giving you a single flat map of the capability surface, with cross-references back into the existing documentation wherever you want depth.

Conventions used across this referential¶

Component codes (DSM, DHM, …) are rendered as inline code.
KV collection names are rendered as inline code: kv_trackme_dsm_tenant_{tenant_id}.
REST endpoints use the /trackme/v2/... prefix and are rendered as inline code.
Cross-references to other documentation pages use Sphinx :ref:`<label>` so they stay live across documentation versions.
FLX template references use their uc_ref (filename without .json) — for example splk_license_pool_usage corresponds to package/lib/flx_library/splk_license_pool_usage.json.