Network clarity.
Operational confidence.
On-premise, agentless network monitoring and management for multi-vendor enterprise networks. Discover devices, monitor health, understand topology, centralize alarms, analyze flows and logs, and protect configurations from one platform.
Polling + traps + flows
SNMP, ICMP, traps, NetFlow/IPFIX/sFlow, syslog and topology in one NMS.
On-premise by design
Telemetry stays on customer servers and the product is agentless on network devices.
One operating view
Bring monitoring, alarms, topology, logs and flow telemetry into one shared workspace.
Grafana analytics
Use provisioned dashboards for application health, syslog, NetFlow and alarms.
Where ArkayNMS fits
Strong fit
ArkayNMS is a strong match for on-premise, multi-vendor estates where network devices, links and services must be monitored together. It gives network teams one place to work with SNMP, traps, NetFlow, syslog and topology instead of switching between separate tools during an incident.
Good renewal trigger
It is especially useful when operators are spending too much time correlating data manually or navigating fragmented tools. Teams can use one shared operational view to move from a health alert to device context, topology, logs and flow evidence more quickly.
Not a forced fit
ArkayNMS is designed first for network operations, not as a replacement for every observability or service-management product. SaaS-only monitoring, Kubernetes-only environments, very small estates without a clear operational need, or teams seeking a complete ITSM/ITOM suite may be better served by another starting point.
How ArkayNMS works
ArkayNMS follows a practical network-operations workflow: bring devices into inventory, establish monitoring coverage, collect multiple signal types, correlate those signals during an issue, and preserve the information needed for follow-up. The platform is intended to keep day-to-day monitoring close to the infrastructure itself, while still giving operators a single place to move from a high-level health view into detailed evidence.
In normal use, an operator starts with the inventory and monitoring configuration, verifies that polling and telemetry are healthy, and then uses alarms, topology, logs, flows, or route information to investigate exceptions. This makes the system useful not only for detecting that something is wrong, but also for narrowing down what changed, where the impact is visible, and which device or path deserves attention first.
Connect
Discover and register devices, sites, vendors and device types. Use SNMP v1, v2c or v3.
Monitor
Collect parameters, reachability, traps, flow telemetry and syslog with reusable templates and rules.
Understand & act
Combine alarms, topology, Grafana analytics and configuration history into a single operating picture.
Architecture
• Collection & services: The web and API layers expose the operating interface, while SNMP parameters, traps, syslog, flow telemetry and ping collect evidence from the network. These inputs cover both periodic measurements and event-driven signals, so operators can work with normal health data as well as exceptions generated by devices.• Operations, data & analytics: Alarms, topology and configuration backup connect operational events with historical context. Postgres, Kafka, ClickHouse, Prometheus, Grafana and Alertmanager provide the supporting data and analytics path, allowing collected signals to be retained, processed, visualized and surfaced back to the operations team.
Deployment
Choose the appliance that matches the processor architecture of the machine that will run it. Before deployment, request the private ArkayNMS setup file from Arkay Data. The deployment process is appliance-based, so the first task is to prepare a compatible virtualized host, allocate the recommended resources, import the supplied image, and make the resulting VM reachable from the operator’s browser.
ArkayNMS provides separate AMD64 and ARM64 deployment paths. Keeping those paths distinct is important because the supplied appliance formats and boot requirements are different. The checks below are intended to help operators avoid importing the wrong image, starting with insufficient resources, or placing the VM on a host that cannot provide the required CPU architecture.
Click the Request Demo button or use the button below to request the private setup file from Arkay Data.
2. Requirements
Recommended appliance environment
- Host CPU: x86_64 / AMD64 (Intel or AMD).
- Virtualization: Oracle VirtualBox or another compatible x86_64 hypervisor.
- VM RAM: 16 GB recommended; 8 GB minimum.
- VM vCPUs: 4 recommended.
- Disk: approximately 100 GB of disk space; import the supplied OVA appliance and use the appliance disk as the primary boot disk.
- Network: bridged or NAT networking with browser access to the VM IP.
Recommended appliance environment
- Host CPU: ARM64 (Apple Silicon Mac, AWS Graviton, Ampere, Raspberry Pi 4/5 with enough RAM, etc.).
- Virtualization: KVM/QEMU, UTM, Parallels, or a cloud ARM instance with nested virtualization.
- VM RAM: 16 GB recommended; 8 GB minimum.
- VM vCPUs: 4 recommended.
- Disk: approximately 100 GB of disk space; attach the QCOW2 as the primary boot disk with UEFI boot; do not use legacy BIOS.
- Network: bridged or NAT networking with access to the VM IP from your browser.
3. AMD64 deployment — Oracle VirtualBox
Request the private setup file
Click Request Demo on the documentation page, or use the Request private setup file button above. Arkay Data will provide the private AMD64 appliance file.
Install Oracle VirtualBox
Install Oracle VirtualBox on the AMD64 / x86_64 host machine before importing the appliance.
Import the appliance
Open VirtualBox, click File → Import Appliance, select the supplied .OVA file, review the virtual hardware settings, and complete the import.
Power on the machine
Select the imported ArkayNMS VM in VirtualBox and click Start. Allow the appliance time to initialize its services.
Use the supplied credentials
When the appliance prompts for credentials after startup, use the ID and password provided by Arkay Data with the private setup file.
Open the NMS
Find the VM IP address from the guest or your hypervisor network information, then open http://<VM-IP>/ in your browser.
Verify access
Confirm that the NMS web UI is reachable, then continue with license activation and network device onboarding.
4. ARM64 deployment
Linux: KVM / QEMU
Create an ARM64 VM with UEFI firmware, select the supplied QCOW2 as the existing disk image, allocate the recommended resources, then boot the VM.
Parallels / cloud ARM
Use an ARM64-compatible virtualization or cloud environment, attach the QCOW2 as the primary disk, use UEFI boot, and provide network access to the VM.
4b. macOS (UTM) — step by step
- Open UTM → Create a New Virtual Machine.
- Choose Virtualize → Linux.
- Boot ISO: skip / none (the appliance boots from the supplied disk).
- Storage: import an existing drive → select the supplied ArkayNMS ARM64 QCOW2 file.
- Architecture: ARM64 (aarch64). Memory: 16384 MB. CPUs: 4.
- Start the VM: power on the machine and allow the appliance to initialize.
- Credentials: when prompted after startup, use the ID and password provided by Arkay Data with the private setup file.
5. First boot and networking
Bring the appliance online
- Power on the VM. First boot may take 5–15 minutes while the Docker containers start.
- Hostname inside the guest:
arkaynms. - Find the VM IP from the guest with
ip a, or check your hypervisor DHCP leases. - Open
http://<VM-IP>/in your browser.
Sign in and verify
- Use the ID and password provided by Arkay Data after installation.
- Confirm the NMS web UI responds before relying on individual container health indicators on slow emulators.
- Once the UI is reachable, continue with license activation and network device onboarding.
7. License activation (end to end)
ArkayNMS requires a valid license before full use. The activation flow uses a request file generated by the customer or operator and a license key generated by the ArkayNMS license administrator.
The process deliberately separates the machine-side request from the administrator-side license creation step. This lets the deployment generate a request tied to the installed environment while allowing the licensing workflow to define the client, device and user limits, and the validity period before the final license is imported back into the appliance.
Log in
Open http://<VM-IP>/ and sign in with the credentials provided by Arkay Data. If no license is installed, you are usually redirected to Manage License For Account.
Generate a license request
Click Generate New License Request. A .bin file such as license-request.bin is downloaded. Send the file to the ArkayNMS license administrator, or keep it if you are the administrator.
Create the license key
Log in as a user with Manage licence permission, open Settings → License management, click Create License, upload the request file, fill in the client name, license details, device/user counts and validity dates, then click Generate License.
Import the license key
Return to Manage License For Account, click Import License Key, select the generated license file, and complete the import. On success, you are redirected to the main NMS dashboard.
8. After activation — typical next steps
Add network devices
Add network devices using the SNMP community or credentials provided for the target devices.
Configure monitoring
Configure sites and monitoring parameter groups, then confirm polling is active for the required devices.
Review dashboards
Open Grafana at http://<VM-IP>:3000 and review the available monitoring dashboards.
Configure alerts
Configure the SNMP trap receiver on UDP 162 and set up email alerting in Grafana when required.
Discovery & Inventory
Discovery is the point where the network becomes an operational inventory rather than a collection of manually maintained device lists. Organize devices by site, region, branch or customer, scan subnets with SNMP, and register devices individually or in bulk. A well-structured inventory also gives later features such as topology, reporting and site-scoped access the context they need.
Before expanding monitoring coverage, it is useful to confirm that discovered devices have the correct address, vendor or device classification, site association and credentials. That small amount of structure pays off later because operators can troubleshoot from a device record rather than repeatedly reconstructing the same context from spreadsheets or separate systems.
SNMP auto-discovery
Scan IP ranges and subnets with SNMP v1/v2c/v3, identify reachable devices and register them into inventory. This provides a repeatable way to onboard a network segment while reducing the manual effort of entering every reachable device one by one.
Central inventory
Track IP, vendor, model, device type, credentials, site, polling intervals and status. Keeping these attributes together gives engineers a stable device record that can be used as the starting point for monitoring configuration, investigation and operational reporting.
MIB import
Upload vendor MIB files or CSV OID definitions and use them for polling and trap definitions without code changes or restarts. This is particularly useful in multi-vendor environments where device-specific objects need to be introduced into the monitoring model without modifying application code.
Device workspace
The device workspace brings the information associated with one device into a set of focused views. Instead of treating every monitoring signal as an isolated record, operators can use the workspace to move between identity, health, parameters, traps and configuration state for the same device.
For troubleshooting, the workspace is usually the most useful hand-off point after an alarm or topology investigation identifies the affected device. Use the summary to establish the current state, open the device-specific views that match the equipment type, and then move into parameters, trap configuration, or configuration history when deeper evidence is required.
| Workspace | Purpose |
|---|---|
| Device Summary | High-level health and identity overview, giving the operator a quick starting point before opening more detailed views. |
| Switch Details | Port status, bandwidth, stack health and performance for switch device types, helping engineers move from device-wide symptoms to interface-level evidence. |
| WLC Details | Wireless LAN controller parameter views for examining controller-specific monitoring information. |
| Configure Params | Attach parameter groups, set intervals and enable or disable monitoring for the selected device. |
| Configure Traps | Attach trap processor groups to devices so incoming trap events can be processed according to the intended rules. |
| View Params | View live and historical polled values, compare behaviour over time, and download monitoring data for further analysis. |
| Config Backup | Capture, compare and restore saved device configuration snapshots when change review or recovery requires a known configuration state. |
Features
Monitoring, visibility, alerting, topology, configuration protection and reporting work together in the same platform, so operators can investigate issues without jumping between disconnected tools.
Monitoring overview
ArkayNMS combines scheduled SNMP parameters, ICMP reachability, traps, flow telemetry, syslog and application-path testing into one operating picture. Each signal type answers a different operational question: polling shows measured device state, reachability shows whether the endpoint can be reached, traps capture device-generated events, flows explain traffic behavior, syslog records textual events, and route insights show where an application path is degrading.
The value of the combined model is contextual investigation. A single device alarm can be reviewed alongside topology, recent logs, interface or system parameters, traffic behavior and configuration history rather than forcing an engineer to assemble those pieces manually from disconnected tools.
SNMP monitoring
Reusable parameter groups hold scalar and table OIDs; groups can be attached per device, scheduled at chosen intervals, and used to create threshold alarms. This separates the definition of what to collect from the assignment of that monitoring to a particular device, making the same collection logic reusable across a fleet.
When introducing a parameter group, think in terms of an operational question rather than a list of OIDs: for example, whether an interface is saturating, whether system resources are approaching a threshold, or whether a device is behaving differently from its normal baseline. Historical values then provide the time-based evidence needed to understand whether the condition is isolated, persistent, or part of a larger event.
| Capability | What it does |
|---|---|
| Parameter groups | Reusable global OID groups; import/export as JSON. |
| Per-device monitoring | Attach groups to devices and set intervals per device. |
| Threshold alarms | Raise severity-based alarms when configured conditions are breached. |
| Parameter history | View live and historical polled values; download monitoring data. |
| SNMPv3 | Use authentication and privacy security levels for secure access. |
ServerInsight
ServerInsight extends ArkayNMS monitoring to the operating-system level by connecting host exporters to devices already managed in inventory. Instead of relying on SNMP for server-specific resource measurements, it uses Prometheus-compatible exporters to expose host metrics that can be analyzed through the same monitoring environment.
To set it up, register an exporter with its name, host or IP address, listening port, exporter type, and optional site. Use the built-in test action to verify that the exporter endpoint responds before associating it with a device. For supported on-host exporters, the installation instructions provide the command needed to deploy the exporter on the target system.
Register exporters
Add Linux/macOS Node Exporter or Windows Exporter endpoints to ServerInsight and record the connection details needed by the monitoring system. An optional site association can be used when the environment contains multiple locations.
Link to inventory
Open the relevant device and enable ServerInsight Monitoring, then select the exporter or exporters that represent that host. When the exporter host matches a device IP, and the site also matches when one is defined, the platform can automatically associate a newly registered exporter with that inventory device.
Analyze host metrics
Prometheus scrapes the registered exporter targets and adds device-oriented labels that can be used by Grafana dashboards. This provides visibility into host resources such as CPU, memory and disk alongside the network information already collected for the device.
Typical workflow
Add exporter
Create the exporter entry with host, port, type and optional site, then test the metrics endpoint.
Install when needed
Use the supplied installation instructions to deploy the exporter on the target Linux, macOS or Windows host.
Enable monitoring
On the inventory device, turn on ServerInsight Monitoring and select the exporter to use for that host.
Prometheus scraping
Prometheus adds the configured exporter as a scrape target and collects the exposed host metrics.
Open Grafana
Use Grafana dashboards to review host-resource behaviour and correlate it with network-side observations.
ServerInsight is particularly useful when network connectivity alone does not explain an issue. A server may remain reachable while CPU pressure, memory consumption or disk conditions affect an application. Host-level exporter data gives the operator another evidence source for deciding whether the problem is occurring on the host, in the network path, or across both layers.
SNMP traps
Receive, decode and enrich traps, persist the history, acknowledge trap-driven alarms and optionally forward traps to multiple destinations. Traps are useful when the device itself has already detected a significant event and can notify the NMS immediately instead of waiting for the next polling cycle.
In operations, trap history can be used to reconstruct what the device reported around the time of an incident. Acknowledgement separates the act of seeing an event from the work of responding to it, while forwarding allows the same event stream to be shared with external destinations when an existing operational workflow requires it.
Flow telemetry
Collect NetFlow v5/v9, IPFIX and sFlow v5 records, then turn traffic into useful views such as top talkers, protocols and exporter health. Flow telemetry provides a traffic-centric view that complements infrastructure polling: instead of only asking whether an interface is up, engineers can examine which sources and destinations are consuming bandwidth and which traffic types dominate a period.
This becomes especially useful during capacity or performance investigations. When a link is congested, flow records help determine whether the pressure comes from a small number of high-volume conversations, a specific protocol mix, or broader utilization across the environment. Exporter health also matters because incomplete flow data can otherwise look like a genuine traffic change.
Syslog
Receive syslog, analyze volume and severity, and turn matching patterns into unified alarms. Syslog is often where devices explain the event in operational language, so it adds detail that a simple up/down state cannot provide.
Use syslog during investigations to review bursts, recurring messages, severity patterns, and known text conditions that should become alarms. Matching rules can move important messages into the same alarm workflow used by other monitoring sources, reducing the chance that a relevant device event remains buried in a large stream of raw log entries.
Topology
ArkayNMS computes an interactive L2/L3 map using LLDP as primary discovery, CDP as fallback and FDB as a last resort. Layouts include ring, force-directed, hierarchy and grid. The goal is not simply to draw connections, but to provide a working topology that can be used to understand neighbourhood relationships, inspect paths, and move from a link or device relationship into the underlying device record.
Topology is most valuable when the map reflects current operational evidence. Because the engine uses scheduled SNMP and inventory information, the generated view can be reused for day-to-day investigation without requiring a fresh, expensive on-demand discovery operation each time an engineer opens the map.
Automatic
Shows verified discovery only—best for understanding what the latest evidence confirms today.
Semi-automatic
The default view: retain verified discovery while adding, replacing, or hiding links when operators need a correction.
Fully manual
Shows only user-defined links—ideal for planned diagrams, greenfield sites, or CSV-driven documentation.
Work with the map
Find and investigate
- Search by device name or IP, then highlight one-hop neighbours.
- Double-click a device to open its details; press Escape to clear a focused view.
- Use Tools to focus one to three hops or highlight the path between two devices.
Adapt the view
- Pan, zoom, fit, or use Immersive view for a larger canvas.
- Toggle labels, link capacity, and live link traffic where available.
- Save node positions independently for each site and map view.
Device health is refreshed from SNMP sysUpTime with ICMP ping fallback. Cross-site links can be shown as site stubs or full remote devices, and CSV export supports discovery reports and manual-link records.
Route Insights
See the actual network path from a site to a specific application or service. Compare the same destination across sites and quickly identify where latency, loss or degradation begins.
Route Insights is intended for situations where endpoint availability alone does not explain the user experience. An application may respond from one location while users in another location see slow or inconsistent performance. Looking at the path between the site and the destination adds another layer of evidence and can help distinguish endpoint problems from problems introduced somewhere in the network path.
A useful troubleshooting pattern is to compare a healthy site with an affected site against the same destination. Differences in latency, loss or the path itself can then guide the next investigation step instead of treating every report of slowness as an endpoint issue.
Application path visibility
Understand the route to the service instead of looking only at endpoint health.
Site comparison
Compare healthy and affected sites against the same application endpoint.
Faster troubleshooting
Use path-level evidence to focus investigation on the area of the network that is actually degrading.
Alerts & incidents
Unified alarms cover SNMP parameters, traps, ping, syslog rules, NetFlow rules and configuration-backup events. Active and historical views are separated, with real-time WebSocket updates.
The separation between active and historical alarms supports two different jobs: active alarms answer what still needs attention, while historical alarms help explain what happened earlier. During incident response, operators can acknowledge or work through current alarms while retaining a searchable record of previous events for review, handover, trend analysis and post-incident investigation.
Because multiple signal types feed the same alarm layer, an incident can be followed across different kinds of evidence. A reachability event may be followed by a trap, a syslog message, a topology change or a configuration event, giving engineers more context than any one signal would provide alone.
Configuration backup
Capture
Scheduled and on-demand running-config capture over SSH or Telnet.
Compare
Snapshot history with a configuration diff viewer and golden-baseline drift detection.
Restore
Apply a saved configuration back to a device when recovery requires it.
Dashboards & reporting
Dashboards give operators an immediate view of fleet and per-site health, helping them spot devices, links or services that need attention before users report an issue. A good dashboard acts as an operational starting point: it highlights exceptions, gives enough context to choose the next investigation step, and keeps commonly reviewed health indicators close at hand.
When an alert needs deeper investigation, Grafana provides views across application health, syslog, NetFlow and alarms so teams can compare different signal types over the same period. This is useful for distinguishing a brief spike from a sustained issue and for understanding whether multiple symptoms belong to one underlying event.
Operational and inventory reports can be exported to PDF or Excel for handovers, reviews and stakeholder updates. These exports turn live monitoring information into a portable record that can be shared with teams who do not work in the NMS every day.
Users, security and access
Administration controls who can access ArkayNMS, what they can do, and which parts of the monitored environment they are allowed to work with. The access model combines local authentication, enterprise SSO through Keycloak/OIDC, role-based privileges and site-scoped access.
For larger operations teams, this separation is useful because not every operator needs the same level of access. A monitoring user may only need to view devices and alarms, while an administrator or engineer may also need permission to change monitoring configuration, manage users, or work with device configuration backups.
| Capability | Details |
|---|---|
| Local authentication | Username/password login with JWT. |
| Keycloak SSO / OIDC | Enterprise single sign-on via Keycloak. |
| Users & roles | User management, password reset and role assignment. |
| RBAC | Fine-grained view/add/update/delete privileges across modules. |
| Site-scoped users | Restrict operators to assigned sites. |
| Data residency | Telemetry stays on customer servers. |
Settings
Settings bring the reusable and platform-wide configuration into one administrative area. This includes parameter groups and trap processor groups, notification providers, trap-forwarding destinations, retention TTLs, web alarm media, and NCB credentials/vendor collectors.
These settings shape how the platform behaves across the environment rather than only on one device. For example, a reusable parameter or trap group can be prepared once and then applied where needed, while notification and forwarding settings determine how important events leave the core monitoring workflow. Retention settings also matter because the useful value of operational history depends on keeping the right information for the right length of time.
When changing global settings, it is good practice to consider downstream impact: a change to a reusable group can affect several devices, a notification change can alter how operators receive alarms, and retention changes can affect the amount of historical data available during later investigations.
API Usage
REST API
ArkayNMS exposes a broad REST API surface with OpenAPI documentation. The API is intended for integrations and programmatic workflows that need to retrieve or work with data without requiring every operation to be performed manually through the web interface.
Typical uses include path and neighbour queries, operational integrations, inventory-related automation, and applications that need to consume information from the NMS as part of a wider engineering workflow. OpenAPI documentation provides the reference for available endpoints, request formats and response structures, so integrations can be built against the supported interface rather than depending on internal implementation details.
For automation, keep credentials and permissions aligned with the narrowest practical access required by the integration. Treat API changes as operational changes: test them against the intended environment, verify the returned data, and make sure an automated action cannot unintentionally alter monitoring or device state beyond its intended scope.