Monitoring Infohub and Its Health
The Monitor in Flow Config, what "caught up" looks like, and building estate-wide health visibility for many instances.
"Is Infohub healthy?" is answerable, but the answer lives in several places, and one of them — the Monitor — has never been documented. This article covers watching one instance well, and the realistic options for watching thirteen.
The Monitor#
Inside Flow Config's Deployment view, the Monitor surfaces what the engines are actually doing: per-object activity, the backlog of pending work — including pending measure event periods — and the faulted items. This is where sites should look before concluding anything is stuck, and it is the screen that answers "is it behind, or is it broken?"
How to read it:
- A backlog that is falling is an engine catching up — after maintenance, after a backfill, after an outage. Time, not intervention.
- A backlog that is flat or growing while sources are healthy is a throughput or contention problem — see Engine Performance and Tuning.
- A pending count that climbs forever on one item is a retry loop: one object failing every pass. Find that period in the engine log — the repeating error names the cause.
- Faulted items listed here are the same faults the deployment dots show — the Monitor is where you enumerate them rather than hunting the tree. Drilling into a pending measure-event-period entry identifies which scheme/measure the backlog belongs to.
The Monitor shows activity, not history: for "what happened last night", the engine log and the maintenance duration records are the record.
One known blind spot. Engine move operations (transferring model objects between engines on a large instance) can take tens of seconds with no Monitor indication that work is in flight — a long-standing gap. If Config appears hung right after an engine reassignment on a big model, give it a minute before killing anything.
The daily health picture, one instance#
Five checks, all cheap, all scriptable:
- Deployment status — nothing Different, nothing Faulted. (
--deployment-status; the CI recipes include the exact script.) - Newest values are current — sample measures across areas; the newest period should be the current one, allowing refresh lag.
- Monitor backlog near zero and not trending up.
- Engine log — no repeating error, and warnings read, not just errors.
- Maintenance ran — last night's window completed, all steps (see The Maintenance Window).
Building health measures — Infohub watching itself#
The most robust pattern sites have adopted: model the health signals as ordinary measures, then alarm and dashboard them like anything else.
- Data freshness per critical chain: a calculated measure of "minutes since the newest value" on each key retrieved measure, with a High limit. This catches a stuck chain within one interval, instead of when a person notices a flat chart.
- Throughput proxies: daily counts of values written per area (a Count-style aggregation on a heartbeat tag per source) — a collapse identifies which source went quiet.
- Integration liveness: a measure per critical consumer tracking last-successful-send age (see When Integration Fails).
- A watchdog tag: one simulator or constant-source tag retrieved every interval; if it stops, the problem is engine/platform, not any particular source — a one-measure differential diagnosis.
The engine also maintains a TimeScheme watchdog per engine internally (its poll/WDT pair) — the pattern above is the modeller-visible equivalent, and it has the advantage of being alarmable through the ordinary Message Engine.
Watching an estate#
For one instance, the above suffices. For a fleet (the question was asked verbatim by a 13-site operator), the realistic options:
- Roll health measures up like any other measure. Each site models the watchdog/freshness measures; a central instance receives them via the Flow consumer and one dashboard shows every site's freshness, backlog proxy, and last-maintenance age. This keeps the tooling inside Infohub and is the recommended default — the staleness measure at the centre also covers the replication link itself.
- Scrape deployment status externally. The CLI's
--deployment-status --output-format jsonper site, on a schedule, into whatever monitoring stack the organisation already runs (the nightly-snapshot recipe in CLI Recipes is the skeleton). Right when the estate's monitoring must live in Grafana/Zabbix/etc. alongside everything else. - Windows-level checks — the
Flow Bootstrapservice up, theFlowevent log error rate — catch the layer below Infohub. Necessary but not sufficient: a running service with a wedged scheme set passes these and fails the freshness measure.
Whichever combination: alarm on staleness, not absence of errors. Every serious silent failure in this KB's troubleshooting sections — stuck scheme sets, expired credentials, wedged integrations — presents as stale data with no error, and only freshness checks catch that class.