Topology & CMDB Integration
A red metric is only half an answer. The other half — what does this affect, and who owns
it? — comes from topology: a graph of your business services, applications, components,
hosts, and databases, and the metrics bound to them. Topology is what lets an alert say "the
Mobile Banking service is degraded" instead of just "metric database.health breached."
Topology in Lumetry is built for one job above all: incident correlation. Its goal is to turn a low-level signal into the chain that matters during an incident —
Alert → Host → Component → Application → Business Service
— so you can see what is affected, who owns it, and (when many alerts fire at once) what the single probable cause is.
The four layers
Topology is a directed graph of nodes joined by edges. The intended spine is four layers, from the business down to the metal:
| Layer | What it represents | Example |
|---|---|---|
| Business Service | A service consumed by a customer or business unit — the unit of impact. | Mobile Banking, Internet Banking, ATM Services |
| Application | The logical representation of a business application. | Mobile Application, Internet Banking Application, ATM Application |
| Component | An operational deployment unit — a runtime boundary that emits telemetry. | Web Farm, API Tier, Authentication Tier |
| Host | A machine where workloads run — server, VM, or node. | host01, host02, web-vm-07 |
Two more node types refine the spine where it helps:
- Database — a data-tier dependency (Oracle, PostgreSQL, a managed cloud database).
- Cluster — a redundancy group ("farm") of like members, so Lumetry can tell "1 of 3 members down" (degradation) apart from "the whole tier is down" (outage).
What a Component really is
A Component is an operational deployment unit: a runtime boundary that can independently generate telemetry, alerts, and incidents. It does not have to be a single microservice or code module. All of these are valid Components:
- Web Farm / API Farm
- Authentication Tier / Middleware Cluster
- Kafka Cluster / MQ Cluster
- Oracle RAC
- Kubernetes Deployment
A Component runs on one or more Hosts, can sit alongside other Components on the same Host, can depend on other Components, and is the boundary at which alerts and incidents are produced. Pick the type by the behavior you want: use Component for any operational unit, promote it to Cluster when you want redundancy awareness, or use Database for a data-tier dependency.
Relationships
Edges connect nodes and come in four kinds:
contains— hierarchy. Business Service contains Application, Application contains Component. This is the tree you browse.runs_on— hosting. Component runs on Host (or Cluster). A near-certain link: if a Host fails, everything that runs on it fails.depends_on— runtime dependency. Application depends on Database, Component depends on Component. A softer link — retries, caches, and partial degradation are possible.routes_to— load-balanced distribution to redundant members, used with a Cluster to express "N of M members affected."
Relationships are validated when created: hierarchy must make sense, and runtime direction is enforced — logical things run on or depend on infrastructure, never the reverse. Invalid relationships are rejected rather than silently stored.
Components and hosts are many-to-many
A Component can run on many Hosts, and one Host can carry many Components. This is the common case, not an edge case:
Mobile Frontend runs_on host01, host02, host03
Internet Frontend runs_on host01
Here host01 carries two Components. If it fails, Lumetry knows both the Mobile Frontend
and the Internet Frontend are affected — and can trace each up to its business service.
Binding metrics to topology
The link between data and the graph is a metric binding: an association between a metric and a topology node. Once a latency metric is bound to your API Tier component, any alert on that metric resolves to that component — and, by walking the hierarchy upward, to the owning application and business service.
This is exactly what populates the related service and related CI on alerts and the primary service/CI on incidents (see Violations, Alerts & Incidents). Topology is the machinery behind "what does this affect."
Incident correlation and business impact
Because topology models hosting and dependency, Lumetry can do more than label a single alert — it can reason across a storm:
- Business impact. An alert on
host01rolls up to Mobile Frontend → Mobile Application → Mobile Banking, so an operator immediately sees that a customer-facing service is at risk, not just that a box is unhealthy. - Shared-cause attribution. When a shared database degrades and every dependent component alerts at once, Lumetry walks the dependency and hosting graph among the alerting nodes and points at the most-downstream node that explains the others — the probable root cause — instead of leaving you with a wall of sibling alerts.
- Redundancy awareness. If only 1 of 3 members of a farm is alerting, modeling it as a Cluster tells Lumetry that this is degradation, not a full outage, so it does not over-escalate.
CMDB integration: don't rebuild what you already have
Most enterprises already maintain this graph in a CMDB (ServiceNow, BMC Helix, Device42, …). Re-entering it by hand would be pointless and immediately stale. Instead, a CMDB pushes topology into Lumetry through a bulk-push API with three defining properties:
- Idempotent. Everything upserts by your own stable IDs, so a CMDB can push on every sync run safely — re-sending the same payload changes nothing.
- External-ID addressed. Clients reference everything by their own IDs; they never need Lumetry's internal IDs.
- Transactional. The whole payload applies in one transaction. If any part fails validation, nothing is written — you never get a half-imported graph.
The push is upsert-only: it creates and updates, but does not prune nodes or edges absent from a later payload. Removing objects is a deliberate, separate action, so a partial export can't accidentally delete half your topology.
Host agents also reconcile themselves to the matching Host node automatically, so the graph your CMDB pushes and the machines your agents report converge on one node per machine. When you place an agent in a topology Cluster, Lumetry keeps that Cluster-to-Host membership visible in the same graph instead of maintaining a separate agent-only grouping model. If network discovery first sees a private endpoint before its host agent enrolls, Lumetry uses a temporary endpoint node. When one agent later claims that address uniquely, the dependency is moved to the reconciled Host automatically; ambiguous address claims are left unchanged.
Why this is a differentiator
Cloud-native monitoring tends to ignore the CMDB world; traditional enterprises live in it. By making topology a first-class graph, binding metrics to it, accepting CMDB pushes natively, and using the whole chain for correlation, Lumetry answers the question that matters most during an incident — who and what is affected, and what is the probable cause — for estates that the cloud-native tools serve poorly.