Readiness before activation
Review site and Sensor placement, credential reachability, entitlement, capacity and effective policy before approving the monitored estate. Keep per-item discovery decisions and failures visible during bulk onboarding.
Architecture that follows your estate
Keep collection close. Bring operations together.
Plan an AmrudAi deployment around your sites, workloads and recovery needs. Centralize policy and investigation in Core, place Sensors near the systems they observe, and choose the appropriate Agent or agentless collection profile for each environment.
The application experience
Migration and readiness
See the complete workspace. Enlarge any image to inspect its panels, navigation and evidence at actual size.
Migration Studio — illustrative product view with sample data. Illustrative product view · Sample data
Reconcile imported identities, mappings and unsupported items before governed adoption. One Sensor & Monitoring Policies — illustrative product view with sample data. Illustrative product view · Sample data
Auto-select collection roles while retaining effective policy, capacity and failover context. HA, Sensor Redundancy & Recovery — illustrative product view with sample data. Illustrative product view · Sample data
Inspect authority transitions, Sensor reassignment, alternate paths and restore evidence. Complete the operational workflow
More context. More useful decisions.
Migration with reconciliation
Map imported identities and source-system definitions to the canonical estate, review conflicts and retain the adoption record. Validate dashboards, collection, notifications and service context against representative operating workflows.
The capability in detail
Design collection around your environment.
Choose your hosting boundary
Deploy native Linux Core and Sensor services on virtual machines or bare metal in your data center, private cloud or public cloud. Use the offline installation bundle for isolated environments.
One Core for operational authority
Bring inventory, policies, assignment, alerts, graph context, deterministic RCA, reporting and access control into a central Core. Modular services share a governed data model; edge collection does not depend on synchronous database requests across the WAN.
Sensors placed by reachability and capacity
Place Network, Infrastructure, Flow and Log Sensors in eligible local pools. Assess actual reachability, latency, isolation and workload headroom; keep heavy streaming workloads from starving scheduled monitoring. Plan redundant collection capacity for each isolated pool.
Agent and agentless collection profiles
Enroll Linux and Windows Agents through Core and direct telemetry to the assigned Sensor. Choose governed SSH or WinRM collection where appropriate, and enable optional Linux eBPF using the compatible operating-system, kernel and privilege profile.
Authenticated enrollment and transport
Establish unique identities with controlled enrollment, certificate trust, rotation and revocation. Use mTLS on Sensor and Agent telemetry paths, HTTPS for the application, and an exportable connectivity matrix based on the actual Sensor vantage.
Bounded buffering and accountable replay
Retain authorized collection state and durable local queues during temporary disconnection. Validate application acknowledgements before deleting accepted segments, preserve original event times during replay, and expose late, rejected, duplicated or deliberately shed records.
Size the workload, not just the inventory
Model polling cadence, interfaces, protocol cost, event and flow rates, retention, concurrent queries, reports and enabled analytics. Separate Core and Sensor budgets, simulate policy changes, and validate headroom against a representative workload before committing capacity.
Signed native and offline packages
Review independently versioned Core, Sensor and Linux Agent DEB/RPM packages and the Windows Agent MSI. Release evidence includes signatures, checksums, dependency provenance, SBOM and compatibility metadata; offline bundles include required dependencies and documentation.
Supervised recovery with visible health
Register required services for boot startup and bounded recovery. Assess readiness, backlog, freshness, certificate status, storage and dependency health. Unsafe state and repeated crash loops remain visible, with sanitized support bundles and an operator runbook.
Controlled upgrades and rollback
Check compatibility, capacity and signatures; back up state, drain work, apply migrations and validate health. Stage Sensor, Agent and Pack rollout. Rollback depends on schema compatibility, while one-way migrations require an explicit restore plan. Normal uninstall preserves customer state unless a separate purge is authorized.
Recovery plans for distinct failure scopes
Verify encrypted backup manifests, data integrity, restore compatibility and site-loss activation procedures. Use controlled endpoint redirection and replay, with separate validation of standalone recovery and two-Core Active/Standby continuity.
Retention with protected evidence
Set retention by data class and resolution, with local, NFS or S3-compatible archives as appropriate. Complete required rollups and archives before normal deletion, protect applicable holds, and forecast growth. At the mandatory 80% threshold, reclaim eligible data under separate audited emergency policy; surface capacity conflicts.
From information to action
A connected operational workflow.
- 01
Map the environment
Identify sites, isolated networks, data boundaries, target technologies, credentials, recovery objectives and the collection methods each system permits.
- 02
Build a workload profile
Estimate protocol and telemetry cost, choose Sensor pools, define retention and reserve capacity for incidents, queries and temporary disconnection.
- 03
Validate the deployment
Check exact package and technology versions, enrollment, actual-vantage connectivity, permissions, ingestion, time correctness and representative monitoring load.
- 04
Prove recovery and operate
Rehearse reboot, disconnection, restore and the applicable upgrade path. Review platform health, reconciliation drift, lifecycle policy and release evidence as the estate changes.
Plan your deployment
Fit the way your team operates.
Run AmrudAi with one authoritative standalone Core or exactly two Core nodes in Active/Standby, supported by distributed Sensors and endpoint Agents. Dedicated and shared MSP deployments use the same governed evidence model.
- Select the operating-system profile, collection roles, technology packs, workload and recovery procedures for the environment you operate.
- Core and Sensors run as native Ubuntu or RHEL services; endpoint Agents support Linux and Windows. Docker and Kubernetes are not customer installation prerequisites.
- Use 4 GB RAM per vCPU as the Core sizing ratio and an advisory Network Sensor starting point. Account for interfaces, polling cost, Flow and log volume, retention, query concurrency and optional analytics when sizing the workload.
- Local queues provide bounded store-and-forward continuity. Monitor backlog age, buffer use and freshness; choose retention and recovery objectives that fit the available storage and network conditions.
- Two-Core Active/Standby uses controlled authority transfer and positive fencing. Backups, restore verification and site-loss recovery remain separate parts of the continuity plan.
What should you confirm before deployment?
Where does AmrudAi collect data?
The architecture places collection on Sensors close to the monitored networks and on Agents where endpoint collection is appropriate. Core owns policy, assignments and operational reasoning. Agentless collection and external connectors use separately governed profiles.
Does installation require Kubernetes or Docker?
No. Core, Sensors and Linux Agents run as native Linux services, and Windows Agents run as a Windows service. Monitor container platforms without making a container orchestrator a prerequisite for AmrudAi itself.
What happens when a site loses connectivity to Core?
Sensors and Agents continue authorized collection and buffer locally within configured capacity and durability limits. Replay preserves original event time. Queue age, freshness and loss risk remain visible, and resource protection can shed lower-priority telemetry if a prolonged interruption exhausts capacity.
What determines the capacity we need?
Devices are only one input. Interfaces, polling frequency, Flow and log volume, retention, query concurrency, path checks and optional analytics also affect capacity. Use a representative workload and the deployment sizing profile to establish the required resources.
Does a second Core replace backups or disaster recovery?
No. Active/Standby continuity addresses defined Core failures. Backups, restore checks and site-loss activation protect different failure scenarios. Define the recovery point and recovery time objectives for the complete deployment and operating procedure.
Can I deploy in an isolated environment?
Yes. Offline distribution includes the packages, dependencies, signatures, notices, compatibility information and operational documentation needed for the selected deployment. Use local or private inference where permitted; collection and deterministic RCA remain available without an external language-model service.
Will an upgrade or uninstall delete my history?
The lifecycle contract requires a backup and compatibility check before upgrade. Rollback is supported only where package and schema compatibility permit it, and one-way migrations need a restore plan. Normal uninstall preserves customer state and configuration; destructive purge is separate, confirmed and audited.
Technical authorship & review
Publisher: AmrudAi . This content is checked against documented product architecture and cited technical sources. Content updated: . Descriptions of planned or adapter-dependent capabilities are not a release certification. Confirm the supported version and acceptance evidence during evaluation.
See the workflow in your environment.
Explore the technology, service dependencies and operating requirements that matter to your team.