DHM — Data Host Monitoring

Data Host Monitoring tracks host × sourcetype activity — which hosts are sending data, and what they are sending. Where DSM watches feeds, DHM watches the senders, which makes it the natural component for forwarder fleets and for declaring the hosts that should be reporting.

What DHM tracks

Each entity is a host, carrying the index × sourcetype combinations it sends. DHM shares DSM’s delay/latency model:

• Delay and latency against the configured thresholds.

• Volume outliers per host/sourcetype (off by default — host volume is noisy).

• Future events and distinct-host drift.

Note

The asset field. Each host also carries an asset field — a de-duplicated set of every known variation of the host name (canonical value, alias, short hostname, FQDN). TrackMe uses it to match short names against fully-qualified ones, so a host is not tracked twice as web01 and web01.corp.example.

Per-host granularity

DHM lets you choose how finely a host is broken down, via the tracker’s break-by mode:

Mode	Grain
Standard	Combos at (index, sourcetype).
Merged	Sourcetype collapsed — (index, all sourcetypes).
Custom	Keyed by any single field you choose (for example cmdb_ci), with up to five extra ordered metadata dimensions (such as source).

Declaring hosts that should be sending

DHM’s signature feature is expected-hosts injection — telling TrackMe which hosts ought to be reporting, so a host that goes silent (or never starts) is visible as a problem rather than an absence.

• Declare hosts from a Splunk lookup (local or remote, CSV or KV Store). For DHM only the host field is required.

• The wizard previews the lookup, maps fields, and simulates the import (reporting how many rows are new, existing, or already tracked) before you commit. Imports can run once or on a recurring schedule.

• Injected hosts appear red until data arrives; their index/sourcetype placeholders fill in automatically — and clean up automatically — once the DHM tracker sees real data.

• Existing entities are never duplicated; the asset field makes the matching short-name/FQDN aware, and large lookups are batched automatically.

Host coverage-gap analysis complements injection: a read-only reconciliation of a reference host list (a CMDB lookup, or a tstats / raw search) against the hosts TrackMe tracks — returning the hosts only in your reference (the coverage gap), only in TrackMe, and in both.

Shared with DSM

DHM shares DSM’s configuration model: root constraint, allowlist/blocklist, variable delay, lagging classes, adaptive delay, threshold lock, the AI Feed Lifecycle Advisor delay mutex, and the delayed/inactive-entity inspector. See DSM — Data Source Monitoring for those.

Note

DHM has no data sampling and no elastic sources — those are DSM-only. On large fleets (10k+ hosts), keep SLA thresholds moderate to avoid alert storms, and remember that inactive hosts are auto-disabled after the tenant’s auto-disablement period.

See also

• Feeds thresholds (delay & latency) — delay & latency thresholds (shared with DSM): static, lagging classes, adaptive (ML), and variable delay.

• Expected sources & hosts — in depth — inject expected hosts so a host that stops sending turns red.

• DSM — Data Source Monitoring — the feed-centric counterpart and the shared delay model.

• Integrations & Remote Deployments — CMDB enrichment for host metadata.

• Entity State & Scoring — thresholds and scoring.

• Metrics reference — the DHM host metrics.