MHM — Metric Host Monitoring¶

Metric Host Monitoring is the metric-index counterpart of DHM. It tracks hosts sending metric data, grouped by metric category, answering “are my metrics still arriving for every host that should be emitting them?”

The MHM Tenant Home — metric hosts by priority and state, the enabled/in-alert/not-monitored counters, and the entities table with an expanded host showing its key information and status

What MHM tracks¶

Each entity is a host × metric category pair (for example os.cpu or os.mem). The host is the group; its categories inherit the host’s state. MHM watches:

Metric lag per category — the freshness of each category.
Inactivity — a host or category that has stopped sending.
Missing expected categories — a host no longer emitting a category it used to.

MHM is scoped to a metrics index and queries it with mstats. The creation wizard enumerates the hosts in that index, groups their metric categories, and lets you choose which to track. A host’s Overview tab summarises its lag, impact score and SLA, and the metrics availability table lists every metric category with its last-seen time, lag, and state:

An MHM host entity overview — the lag summary, impact score and SLA cards, the state distribution, and the metrics availability table listing each metric category with its last-seen time, lag, allowed lag, and state

How MHM differs¶

Important

MHM is deliberately simpler than DSM/DHM:

Static thresholds only — no variable delay, no lagging classes.
No data sampling, no elastic sources.
Outlier detection is not available — unlike the other components, MHM does not support the native ML outlier engine at all (see Outlier detection).

Tip

Many infrastructure metrics report on an irregular cadence, which produces “metric lag” false positives. If a host legitimately emits a category intermittently, raise its lag threshold or disable that entity.