Find the capability your team needs.

Build a reliable monitored inventory through guided validation and review.

Operating context: Discover through guided scans, reconcile candidates and activate the approved estate with credential, capacity and entitlement checks. Discovery and Agent enrollment enter a review workflow; monitored activation also requires approval, entitlement, capacity and preflight checks. The ordinary scheduling workflow offers Run Now, Run Once, Daily, Weekly and Monthly options; unrestricted cron is outside that workflow. A monthly date that does not occur in a given month moves explicitly to that month’s last valid day. Preview the activated devices, monitoring policies and expected collection load before completing onboarding.

Keep one record of the estate as addresses, sources and ownership change.

Operating context: Maintain stable entity identity, ownership and lifecycle history across discovery, Agent, cloud and external-system observations. IP addresses and hostnames are observations; stable identity requires corroborating evidence. Discovery or CMDB absence prompts reconciliation rather than automatic deletion of an entity. Vendor lifecycle and support dates retain their source provenance. Lifecycle intelligence covers equipment and support context; vulnerability assessment and patch deployment are outside this scope.

Understand availability, utilization and monitoring quality at device and interface level.

Operating context: Monitor device and interface health, performance and collection quality through multi-vendor SNMP and technology-specific telemetry. Validate exact Counter64 preservation, rate calculation, counter wraps, resets and discontinuity handling for the selected collection profile. An SNMP timeout is collection evidence and does not alone establish that a device is down. Routine monitoring is read-only. SNMP SET requires its own privileged authorization and controls. Compatibility is specific to the device, firmware, MIB and technology pack.

Connect routing changes and protocol health to reachability and business impact.

Operating context: Connect routing, adjacency, redundancy and overlay state to reachability, path changes and affected services. Validate the required routing, adjacency, redundancy and overlay dimensions for the exact model and firmware. Protocol depth follows the device model, firmware and available observations in its Capability Pack.

Separate destination problems from path and locality failures.

Operating context: Use active probes, routing context and multiple vantages to distinguish destination, path and location-specific failures. An unresponsive intermediate hop does not establish end-to-end failure. ISP policy, MPLS and other network behavior can hide intermediate hops; incomplete paths remain visible as incomplete. Probe execution failures and target reachability failures remain separate outcomes.

Understand who communicates, how traffic moves and where capacity is consumed.

Operating context: Analyze traffic conversations, top consumers, interfaces and application classifications with exporter, sampling and source-quality context. Missing Flow records do not establish that no traffic occurred. Full URLs and deep application-payload interpretation require evidence beyond ordinary flow records and are outside this flow-analytics scope. A flow anomaly alone does not establish device failure or root cause. Sampling, packet loss, exporter coverage and privacy restrictions remain part of the interpretation.

Bring log and event evidence into the same investigation as metrics and changes.

Operating context: Search logs, syslog and operational events with shared entity identity, historical context and incident evidence. Operational log correlation is within scope; replacement of a full SIEM is outside scope. Collection is selected and bounded by source, volume, retention and privacy policy.

Compare site experience and connect poor service to the affected link or path.

Operating context: Monitor branch, WAN and vendor SD-WAN health, link experience and policy or path changes alongside provider evidence. Reverse-path visibility depends on the available vantage and network behavior. AmrudAi provides monitoring evidence; carrier bandwidth and service commitments remain with the provider agreement.

Expose wireless and voice infrastructure conditions alongside network incidents.

Operating context: Connect WLAN controllers, access points, client attachment and voice service observations to wireless, network and site experience. Voice conclusions depend on the available quality, session and network evidence from the monitored sources. Attachment history retains the source, observed time and identity context of each endpoint or client relationship.

Diagnose host health with local or governed remote collection.

Operating context: Monitor Windows and Linux resources with local Agents or governed remote collection and focused diagnostic evidence. Agent and remote collection offer different depths and must be evaluated for the required evidence. Credential, privilege or collection failure alone does not establish that the host is down. CPU, memory and network overhead depend on the enabled collection profile and must be measured for that profile.

Give operators inventory and control over what matters on an endpoint.

Operating context: Track installed-software facts and changes, and select the processes and services that need monitoring. Patch deployment, vulnerability scanning, software-licence metering and endpoint protection are outside this capability. Permission to monitor a process does not authorize restarting it. An explicitly selected monitoring profile remains separate from business-criticality changes.

Connect a service or process to its network symptoms without inspecting payloads.

Operating context: Use optional Linux eBPF evidence to relate process connections, retransmissions, resets and network timing to host and service symptoms. Payload capture, TLS decryption, HTTP/SQL content inspection, environment-variable reading and continuous profiling are outside scope. Base host monitoring continues when optional eBPF instrumentation is unavailable. Normal endpoint collection does not require a separate local LLM or GNN.

Correlate host and service symptoms with physical infrastructure evidence.

Operating context: Connect Redfish and supported hardware or environmental interfaces to power, thermal, chassis and storage health. This capability provides operational health monitoring; full BMS and DCIM workflows are outside scope. Chassis, RAID and power conclusions require the corresponding hardware evidence source.

Trace VM health through hosts, clusters, storage and virtual networks.

Operating context: Monitor VMware, Hyper-V, Nutanix and Proxmox, connecting VM, host, cluster, datastore and virtual-network evidence with optimization recommendations. Each hypervisor’s investigation depth requires separate validation; VMware depth does not establish equivalent coverage elsewhere. Monitoring and recommendations do not authorize autonomous VM or resource changes.

Identify storage pressure and fabric problems in service investigations.

Operating context: Monitor storage arrays and SAN fabrics through vendor profiles, with capacity, performance, controller, port and path context. Exact coverage depends on vendor interfaces, credentials, model/version compatibility and the selected pack. Autonomous storage remediation is outside this monitoring scope.

Link database health with the host, storage and services it depends on.

Operating context: Connect PostgreSQL, SQL Server, Oracle, MySQL/MariaDB, SAP HANA, MongoDB and other supported engine profiles to performance and service investigations. Custom SQL monitoring uses governed, bounded queries with explicit permissions. Autonomous database tuning is outside scope. Database monitoring does not include full application-transaction tracing.

Reconcile cloud resources and changes with the wider operational estate.

Operating context: Bring AWS, Azure, Google Cloud and OCI inventory, health, networking and change evidence into the shared operational model. Cloud flow logs require provider enablement and may incur account, ingestion or retention charges. Provider route-analysis depth and supported services must be checked individually. Provider resource identifiers are reconciled into the scoped inventory and do not bypass access controls.

See resource health and dependency context across cluster workloads.

Operating context: Connect clusters, nodes, workloads, pods, events and resource pressure with runtime service dependencies and operational telemetry. Monitoring Kubernetes does not require deploying AmrudAi on Kubernetes. Use bounded sampled span evidence for service dependencies; specialist developer APM workflows remain separately integrated.

Correlate service metrics and structured logs with network and infrastructure evidence.

Operating context: Receive OTLP metrics and structured logs, preserve trace context and use bounded sampled spans and trace-derived dependency summaries with resource and retention controls. Sampled span evidence is bounded by collection, cardinality, retention and query budgets; missing spans do not prove that a request did not occur. Full developer APM, continuous profiling, RUM, session replay and unlimited trace retention are outside scope; a dedicated trace database is not a deployment requirement.

Validate service reachability from the relevant location.

Operating context: Run structured HTTP/API tests, browser journeys and critical shared-service checks from the locations relevant to the service. A cURL import becomes a governed structured test; it does not authorize arbitrary shell execution. Browser journeys require a separately validated runtime, security and capacity profile. RUM and user-session recording are outside scope.

Investigate the relationships that existed when an incident occurred.

Operating context: Explore current and historical relationships across network, infrastructure and services, with observed, declared and inferred provenance. Observed, declared and inferred relationships retain distinct provenance and confidence. The deployment model does not require a separate external graph database.

Tune monitoring to business needs without source-code changes.

Operating context: Manage inherited policies, thresholds, adaptive collection and resource budgets using controlled, auditable configuration. Statistical anomalies contribute evidence; they do not alone establish root cause. Chart styling and presentation thresholds are separate from alert-policy changes.

Escalate actionable problems while retaining evidence of symptoms and uncertainty.

Operating context: Qualify events with source health, operating context and independent evidence, then group related symptoms and prioritize actionable incidents. Alert precision depends on source quality, policy and operating conditions; it requires evaluation on representative cases. Missing or stale telemetry remains a monitoring-quality state and does not automatically mean the target is down. Suppression preserves the underlying event and related evidence for investigation. Assess noise reduction against an agreed baseline and measured results.

Give operators a cause hypothesis, its evidence and the next useful action in one context.

Operating context: Investigate with deterministic RCA, learned correlation, Flight Recorder, Similar Incident Memory, active validation and connected evidence windows. LLM or GNN scores do not establish causality by themselves. Measure investigation time, precision and alert reduction against agreed scenarios and baseline data. Closing an external ticket does not establish monitored recovery.

Make complex operational evidence easier to search and explain while keeping authority explicit.

Operating context: Use learned baselines, GNN-assisted ranking and generative Copilot through local, private or approved hosted inference with explicit evidence and action governance. Normal Agents and Sensors do not host an LLM or GNN. Choose local, private or approved hosted inference with defined model, capacity, data-egress and operating policies. AI assistance does not grant privileges, run arbitrary commands or silently retrain production models.

Collect fresh, relevant evidence without leaving the incident or overloading the endpoint.

Operating context: Collect fresh trigger-specific endpoint and network evidence from authorized vantages within time, volume, concurrency and resource budgets. Endpoint snapshots contribute evidence; the endpoint does not become the authority for cross-system root cause. Unrestricted shell/PowerShell execution and always-on packet capture are outside scope. Diagnostic overhead and resource limits require measurement for the enabled profile.

AmrudAi NCM is a separate product for auditable configuration state, change risk and recovery evidence. Optional integration connects NCM with observability.

Operating context: Manage configuration backups, versions, semantic diffs, golden state, policy checks, governed CLI, mass changes, staged rollouts, remediation and firmware lifecycle with prechecks and postchecks. Semantic diff requires a compatible, validated parser for the configuration format. Rollback is available only where the device and adapter provide a validated safe mechanism. A CIS or STIG configuration check is distinct from an organizational compliance certification. Automated remediation follows authorized policies, target and blast-radius limits, preconditions, audit and post-action validation.

Connect address allocation, history and conflicts with the monitored estate.

Operating context: Manage IPv4/IPv6 address space, allocations, history and conflicts alongside DNS/DHCP integrations and canonical inventory. IPAM shares authoritative entity identity with the wider inventory. External adapters require explicit edition, API, version and workflow validation.

Let each team compose readable views without losing operational context.

Operating context: Compose role, team and customer workspaces with configurable panels, maps, queries, shared views and full-screen wallboards. Choose the role workspaces, panels and templates appropriate to the team’s operating responsibilities. Confirm panel data bindings, supported queries and freshness behavior with the intended monitoring sources. Team-owned definitions depend on supported team identity, membership and access reconciliation. Wallboard views preserve the active scope, time range, permissions and evidence freshness.

Turn operational evidence into reproducible service commitments and stakeholder reports.

Operating context: Author reports and measure SLA, OLA, SLO and provider commitments through versioned policies, calendars and evidence-backed calculations. Report artifacts are PDF and data-only CSV; XLSX, JSON and PowerPoint report exports are outside scope. Missing evidence remains explicit and does not become perfect compliance or assumed downtime. Measurement templates require an agreed contractual interpretation. Service credits and liabilities come from the applicable agreement. Team-based OLA attribution requires supported team identity and membership bindings.

Carry incident and change evidence into existing enterprise workflows.

Operating context: Connect ServiceNow, Jira Service Management, BMC Helix, ManageEngine, Ivanti, Freshservice, SolarWinds Service Desk, TOPdesk, SysAid and HaloITSM through governed incident, change and CMDB mappings. Coverage is specific to edition, API, version, authentication, permissions and workflow. External ticket closure does not override monitored recovery evidence. Mappings are declarative; unrestricted customer JavaScript or Python transforms are outside scope. CMDB integration uses explicit field authority and visible conflict resolution; full CMDB replacement is outside scope.

Bring the right action to authorized operators without creating another alert storm.

Operating context: Route notifications through role, customer, service, subscription and escalation policies with delivery evidence and controlled recipient scope. Reading a notification does not acknowledge or resolve its incident. A team subscription does not itself grant permission to the underlying resource. External channel availability depends on the adapter, destination account and provider policy.

Extend monitoring through governed definitions and testable mappings.

Operating context: Extend monitoring with versioned Capability Packs, MIB Studio, YANG model utilities and API Studio mappings that preserve provenance and compatibility. Exact coverage follows the product, version, protocol and workflow dimensions of the selected Capability Pack. Customer MIBs and other imported artifacts retain their provenance and redistribution limits. Extension workflows do not permit arbitrary executable customer scripts or customer-specific Core forks.

Control who can view evidence and act on each part of the estate.

Operating context: Govern identity, secrets, evidence access and privileged actions across dedicated enterprise and shared MSP deployments. Map security controls and their evidence to the independent assurance requirements that apply to your organization. Shared MSP operations apply tenant scope to data, secrets, resource use, reports and privileged actions. Connect approved identity providers and directory bindings, then review effective permissions for each role.

Preserve attributable decisions and operational history.

Operating context: Retain attributable decisions, policy changes, evidence access and privileged operations through controlled audit and retention workflows. Audit assurance includes durable storage, controlled access, retention and tamper evidence; application logs alone are insufficient. Regulatory certification requires separate, applicable assurance evidence.

Collect near the estate while keeping policy and evidence centrally governed.

Operating context: Place specialized Sensors near each estate, govern assignments centrally and preserve collection continuity through bounded buffering and replay. Store-and-forward continuity lasts while the defined local buffer and resource budget permit. Choose dedicated or combined Sensor roles according to the collection workload, resource profile and network placement. Flow and log collection use dedicated roles with separately sized workloads. Capacity figures are planning inputs until validated against the actual collection profile.

Run AmrudAi in the environment the organization controls.

Operating context: Choose standalone Core or exactly two Core nodes in Active/Standby, with dedicated or shared MSP operation, backup/restore and site-loss recovery. Core and Sensors run on Linux; endpoint Agents support Linux and Windows. Docker and Kubernetes are not mandatory for the native customer deployment. High availability and disaster recovery cover distinct failures and use explicit continuity and recovery procedures. Agree contractual RPO and RTO using the evaluated backup and recovery profile. Keep Core authority and customer data placement explicit in distributed deployments.

Keep collection useful and failures visible as data volume grows.

Operating context: Manage telemetry quality, data-class retention, storage pressure, archive destinations, evidence holds and query budgets. Ingestion, queries and retention are bounded by the configured and validated capacity profile. Evidence holds follow explicit emergency-capacity governance. Retention duration is selected by data class, storage capacity and policy.

Reduce onboarding and day-two operational friction.

Operating context: Import authorized inventory and policy data, review semantic mappings and support operational handover with runbooks and diagnostic evidence. Imported objects and policies require semantic review; migration outcomes distinguish imported, mapped, needs-review and unsupported items. Vendor adapters require authorized APIs or exports and validated semantics. Support hours, response targets and responsibilities must be defined in the applicable service agreement.

Make operational growth and entitlements understandable before they become disruptive.

Operating context: Track collection load, storage, entitlements and growth so teams can plan resources and commercial coverage before capacity becomes disruptive. Pricing, SKUs, included quantities and overage rules are established in the commercial proposal. Device-scale and cost comparisons require a defined workload, baseline and measurement method. Core and Sensor density figures require validation against the selected monitoring profile.