Temporal topology, operational graph & service relationships
The useful map explains how a service works and what a failure can affect. AmrudAi connects physical, logical, runtime and business-service relationships with time, provenance and health so operators can investigate the environment as it exists now—or as it existed during the incident.
The application experience
See the complete workspace. Enlarge any image to inspect its panels, navigation and evidence at actual size.
Today’s map cannot explain yesterday’s outage.
Temporal topology preserves how devices, paths, workloads and services were connected when a fault occurred. Use relationship evidence, redundancy and change history to understand blast radius without assuming that every adjacent component is a cause.
The capability in detail
Reconcile observations from network protocols, APIs, Agents, Flow, logs and configuration into canonical entities. The same physical or logical resource retains a connected identity, reducing fragmented views across monitoring domains.
Explore physical connectivity, L2/L3 relationships, routing, MPLS, VXLAN/EVPN, SD-WAN and traffic views. Move between layers to understand whether an apparent service problem originates in access, transport, overlay or another dependency.
Follow clusters, hosts, VMs, containers, datastores, databases and cloud resources through their relevant dependencies. A common graph lets teams trace a shared resource across the infrastructure boundaries that separate their consoles.
Enrich service dependencies from ingress, workload, OpenTelemetry and observed runtime communication evidence. Connect application services to databases, caches, queues and external APIs while keeping the evidence behind inferred edges visible.
View relationships within their validity period and compare graph state before, during and after an incident. A later migration, pod replacement or route update does not have to overwrite the topology that explains the original problem.
Inspect where a relationship came from, when it was observed or verified and how certain the association is. Distinguish observed, inferred, provisional and governed relationships so the map communicates both knowledge and uncertainty.
Model critical, optional, redundant, active/standby, quorum and weighted dependencies. Service health can account for the role of a failed component and the surviving paths, giving operators a more useful impact assessment than a simple component rollup.
Connect services with criticality, site, technical and business owners, support teams and provider context. Project the affected scope through supported dependency relationships to focus escalation and explain the service consequence.
Build operational views using sites, groups, services, links and labels, with layouts suited to the audience. User-defined relationships retain their declared source, and CMDB reconciliation preserves the boundary between observed technical state and governed inventory.
Open the relevant incident, timeline, path, Flow or configuration evidence from a selected entity or relationship. Preserve the service and time context so the map becomes a working investigation surface rather than a separate diagram.
From information to action
Open the appropriate service or infrastructure map using the period in which the symptom occurred.
Move through the relevant physical, logical or runtime dependencies and review source, freshness and confidence.
Evaluate redundant, optional or quorum dependencies together with the observed service evidence.
Attach the relevant historical view and evidence references, then link ownership, diagnostic or change actions.
Built around your operating environment
Use discovered and governed relationships together, with explicit identity, evidence and service-health semantics.
Connect the workflow
Both contexts are supported. The operational graph shows current observations with freshness, while temporal relationships allow investigation of the network or service graph during a selected incident window.
Service-health logic can account for criticality, optional dependencies, redundancy, active/standby behavior, quorum and weights. The model evaluates the service's functioning paths and evidence rather than blindly selecting the worst component state.
Yes. Governed logical relationships and custom maps can express business context. Their declared source remains distinguishable from automatically discovered relationships, so manual mapping does not silently overwrite observed technical evidence.
Observed operational relationships retain provenance, confidence and time; governed CMDB information carries reconciliation and administrative authority. Both can inform the connected view while explicit mapping rules resolve shared fields and relationships.
Explore the technology, service dependencies and operating requirements that matter to your team.
Search the complete website · Esc to close · Tab to navigate results