From nothing to monitoring, in about a minute.

First run

1. Run the binary. On Windows a console window opens; on Linux it runs in the foreground.
2. The interface is at http://localhost:8080. It opens automatically on Windows.
3. You'll be asked to create an admin account. Do it before anything else — until you do, the interface is open to anyone who can reach the port.
4. Go to Discover, confirm the subnet it suggests, and let it sweep.
5. Tick the devices worth watching and add them. That's it — polling starts immediately.

Where things are kept

Credentials live in a separate file from the config on purpose: it means the config can be copied, diffed, version-controlled or attached to a support ticket without dragging secrets along with it. The diagnostic bundle never reads the credentials file at all.

Command-line options

netriva -listen :8080      override the listen address from config
netriva -config PATH       use a specific config file
netriva -open=false        don't open a browser on start
netriva -version           print the version and exit

There is no -data flag. The data directory is derived from the config file's location, so point -config at a different path to run a second isolated instance.

Adding devices

Three ways, all equivalent — they end up in the same list:

• Discover sweeps a subnet and identifies what it finds by ARP, reverse DNS and MAC vendor lookup. Fastest for a network you've just walked into.
• Add manually when you know exactly what you want and don't want to wait for a sweep.
• Edit config.yaml if you'd rather do it in bulk. The file is re-read without a restart.

Per device you can override the SNMP community and port, the vendor, the SSH user, and which metrics to collect. Overrides apply live.

SNMP

ICMP tells you a device is alive. SNMP tells you what it's doing — interface status, error counters, bandwidth, CPU, memory, disk. It's read-only and worth the five minutes it takes to switch on.

Set a community string in Settings, or per device if they differ. The Help section in the app has the exact enable commands per vendor. A quick check from the monitoring machine:

snmpwalk -v2c -c public 192.0.2.10 sysDescr

If that returns nothing, the device isn't listening, the community is wrong, or a firewall is in the way — in that order of likelihood.

Syslog

The built-in receiver accepts RFC3164 and RFC5424 on UDP 514, stores messages with a retention window you set, and gives you search and filtering by host, severity, facility and time.

Point your devices at the monitoring machine's IP on port 514. On Windows, the app offers to open the firewall port for you rather than making you find the right netsh incantation.

Port 514 is privileged on Linux. Either grant the capability or use a higher port:

sudo setcap 'cap_net_bind_service,cap_net_raw+ep' /usr/local/bin/netriva

Running as a service

Linux — systemd

[Unit]
Description=AI NetRiva
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=netriva
Group=netriva
ExecStart=/usr/local/bin/netriva -open=false
Restart=always
RestartSec=5
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/netriva

[Install]
WantedBy=multi-user.target

Save as /etc/systemd/system/netriva.service, then:

sudo useradd --system --no-create-home netriva
sudo mkdir -p /var/lib/netriva && sudo chown netriva:netriva /var/lib/netriva
sudo systemctl enable --now netriva

Note -open=false. Without it the service tries to launch a browser on a machine that may not have one.

Windows

Any service wrapper works — NSSM and WinSW are both fine. Point it at the executable with -open=false and set it to restart on failure. Run it as a service account with network access rather than LocalSystem.

The AI assistant

Off until you add an API key. Pick a provider in Settings, paste your key, and ask questions in the search bar at the top of any page — “which devices are flapping”, “what changed on the core switch this week”.

The key is stored in the credentials file, not the config. Requests go straight from your machine to the provider; they don't pass through us. If you'd rather nothing left the building, point it at a local Ollama instance instead. See Privacy for exactly what's sent where.

There's an optional propose-then-approve mode where the assistant can suggest configuration changes that a human must explicitly apply. It's off by default and should stay off unless you've decided otherwise on purpose.

When something doesn't work

A device shows as down but you can ping it

ICMP is usually the cause. On Linux the binary needs cap_net_raw; on Windows, check that the host firewall isn't blocking outbound echo requests. Some devices also rate-limit ICMP and will drop a fast poll — raise the interval for that device.

SNMP says "does not implement"

That message means the device answered but doesn't expose the OID being asked for, which is normal for consumer kit and some embedded devices. It's different from a timeout, and the app distinguishes the two.

Nothing arrives in syslog

Check in this order: is the firewall open on UDP 514, is the device pointed at the right IP, and is it configured to send at a severity that isn't being filtered out. The in-app troubleshooting tools include a port check that answers the first question in a click.

The interface is slow or freezes

Browsers allow only about six connections per origin, and each open tab holds one for live updates. Close spare tabs. If it persists, send us a diagnostic bundle — Help → Report a bug builds a redacted one and shows you exactly what's in it first.

Upgrading

Stop the app, replace the binary, start it again. Configuration and data are untouched. The app tells you when a new release exists but never installs anything on its own — a monitor that restarts itself mid-show is worse than one that's slightly out of date.