Resilience across Core, Sensors and recovery
AmrudAi supports observability high availability & resilience for enterprise operations. Combine a two-Core Active/Standby architecture with resilient Sensor pools, local buffering and a defined recovery plan. Protect monitoring continuity across component failures while keeping failover decisions, spare capacity and operational evidence visible.
The application experience
See the complete workspace. Enlarge any image to inspect its panels, navigation and evidence at actual size.
Keep observability available when a component fails.
Two full Cores provide Active/Standby HA. Distributed Sensor pools share collection work and reassign it to eligible capacity when a Sensor becomes unavailable. Safe ownership, a stable Core endpoint and buffered replay help the NOC retain continuity and understand any remaining gaps.
Fencing prevents the old assignment from continuing after ownership moves.
Receiver changes, backlog and unreachable targets remain diagnosable.
The capability in detail
The HA deployment uses two full Core nodes: one Active and one Standby. Both carry the required Core software and state, while a single active authority keeps policy, incidents and operational decisions consistent.
Users, Sensors and Agents connect through the stable Core HA endpoint. When the active node changes, clients reconnect through the same endpoint without manually updating every Sensor or Agent configuration.
Synchronize the required persistent state between the Core pair and promote the standby only after the active peer is safely considered failed or fenced. When failure is ambiguous, prevent conflicting active authorities instead of forcing an unsafe promotion.
Choose N+1, N+2, N+K, a dedicated 1:1 arrangement or active-active pooled Sensor capacity to fit the estate. Reserve enough eligible capacity to absorb the intended failure within each reachable site or locality.
Sensors retain the policy and assignment state needed to continue current authorized collection during temporary Core or WAN interruption. Local queues and storage protection make the available continuity window visible.
Keep assignment ownership explicit when work moves between Sensors. Reconnect, preserve telemetry sequence identity and replay unacknowledged data with duplicate-aware processing so recovery does not create conflicting work or misleading counts.
Inspect the active Core, standby readiness, synchronization lag, failover reason and history, Sensor headroom, queue age and telemetry freshness. Distinguish a collection-path problem from a failure of the monitored service.
Protect against wider site loss with backup, restore, recovery readiness, documented runbooks and verification. Define the recovery objectives and activation process for your deployment alongside the HA and Sensor-pool design.
From information to action
Identify the Core deployment, independently reachable sites, critical workloads and recovery requirements.
Configure the Active/Standby Core pair and the appropriate Sensor-pool redundancy with usable headroom.
Keep one active Core authority, continue eligible local monitoring and reassign work under controlled ownership.
Reconnect, replay buffered telemetry, review freshness and validate the service and recovery record.
Choose resilience for your failure domains
Core high availability, Sensor-pool redundancy and disaster recovery solve different operational problems. Combine them according to the locations, access paths and recovery requirements of your deployment.
Connect the workflow
No. The Core pair has exactly one Active and one Standby. Active-active pooled collection applies to Sensors. Keeping these distinct preserves one authoritative control plane while allowing monitoring capacity to be distributed.
No. The standard HA topology is two full Core nodes. The design maintains one active authority and uses controlled state synchronization, failure handling and promotion within that topology.
Start with the eligible capacity required for the normal workload in each reachable pool. Add the spare capacity needed for the failures you want to absorb, accounting for collection role, network access, credentials, workload and maintenance. A global spare does not automatically cover isolated sites.
Sensors continue current authorized polling while local resources remain available. They buffer telemetry and reconnect through the stable Core endpoint. Central UI and control-plane access follow the failover process, and the visible queue and freshness state show the recovery progress.
The system prioritizes preventing two authoritative active Cores. An ambiguous partition can delay promotion while the failure is resolved, preserving consistent ownership and avoiding conflicting operational decisions.
No. Core HA addresses the supported component-failure scenarios within its deployment. Wider site loss needs the separate backup, restore, readiness and recovery plan, with objectives agreed for your environment.
Explore the technology, service dependencies and operating requirements that matter to your team.
Search the complete website · Esc to close · Tab to navigate results