MeshWatch Central — installation and integration

Overview

The front page, meant to be left open on a wall screen. Everything on it is counted from what Central already holds — nothing is estimated — and an empty panel says so, for example none in the last 24 hours, instead of showing a blank.

• Status strip — agents by state (reporting, connected, waiting; revoked tokens counted apart), devices down, unacknowledged critical alerts (all time), incidents and alerts in the last 24 hours with the change against the previous 24 hours, and unacknowledged alerts for the last 24 hours and for all time.
• Severity tiles — critical, error, warning and info in the last 24 hours, each with its change against the previous 24 hours.
• Alerts per hour — the last 24 hours as hourly bars stacked by severity, labelled in your local time zone. Hover a bar for its counts.
• Noisiest devices and Most frequent kinds — the top five of each over the last 24 hours.
• Devices down — only devices whose status a product reported directly. A device known only from alerts has no status, so it never appears here.
• Latest alerts — the ten most recent, each with an Acknowledge button.
• Last 24 hours by product — alerts per product against the previous 24 hours. Every product with a live token is listed, including one that has sent nothing.
• Latest correlated incidents — the five most recent.

Overview, Incidents, Alerts and Devices refresh every 30 seconds, but skip a refresh while you are typing or choosing in a field, so nothing you entered is wiped. Agents, Users and Settings never refresh by themselves — press Refresh at the top.

Alerts and incidents

An alert is one report a product sent — one row in Alerts. An incident is two or more different products reporting the same device within 30 minutes. Incidents are computed live from the alerts every time you look: they are never stored, have no open or closed state, and disappear when their alerts age out of retention. A single product repeating itself is not an incident — that is already visible in that product.

“The same device” is where it goes wrong. Each product names a device its own way: DeviceWatch sends the label you gave the device, SyslogWatch the host name from the syslog header, TrapWatch the IP address the trap came from. Central treats two names as one device only when they differ just by letter case or a domain suffix — core-sw-01.example.com and Core-SW-01 are both core-sw-01 — or when a product sends a matching host, IP or alias with its report. IP addresses are compared as written. Central does not guess beyond that: a label such as Core Switch stays a separate device from core-sw-01, because a wrong merge is worse than none.

If Incidents stays empty while two products watch the same device, open Devices. If the device appears on two rows, the products are naming it differently. Make the DeviceWatch label match the host name the other product uses — label the switch core-sw-01, not Core Switch. TrapWatch names a device by its IP address, so it correlates with a product that uses the same address.

Technical note: the report format accepts optional host, ip and aliases fields, and a product may send them. When one does, any name that matches links the rows as one device.

Alerts

Every alert from every connected product, newest first by the time the product put on it rather than when it arrived. Filter by Severity, Product and State (open or acknowledged). The Agent column shows which token sent each row and Kind the type of alert; if a product’s alerts appear under the wrong product, that token was issued for a different one. The tab shows the latest 200 matching alerts, and its title the real total.

Acknowledge works per alert and records who acknowledged it and when; the row then shows that name and time instead of the button. Operators and administrators can acknowledge; viewers see open.

Export CSV downloads the alerts that match the current filters, up to 500, with the columns When, Product, Agent, Device, Severity, Kind, Summary, Acknowledged At and Acknowledged By. Times in the file are UTC.

Incidents

One card per incident: the device, the worst severity among its alerts, the products involved, when it started and how many alerts over how many minutes. When the products used different names for the device, the others are listed after also reported as. The timeline below lists each alert in order, in your local time.

Download report saves a Markdown draft built only from that incident’s alerts; every time in it is UTC. Acknowledge all acknowledges every open alert in the incident in one go (operators and administrators). If the download says the incident is no longer available, its alerts have aged out.

Devices

One row per device, however many products report on it, with the columns Device, Label, Vendor, Reported by, Status and Last report. Other names the row was matched under are shown beneath the device name. Devices a product reports down sort to the top. The Product filter narrows the list to one product.

• Status — one pill per product. DeviceWatch: up or DeviceWatch: down is a status that product reported. from alerts means the product named the device in an alert but has never sent its status, so up or down is unknown.
• Last report — the time the product put on its latest report or alert. Hover the cell for when Central received it; a backlog delivered at once keeps its own times.
• Click a row for the device’s full alert history across every product; click again to close it.

Agents

Administrators only. One row per token, with Product, Label, Created, Last contact, Last report and State.

• waiting — the token has never contacted Central.
• connected — the product’s Test connection succeeded, but it has not sent anything yet. That is normal until something happens: ConfigWatch reports after a backup run, TrapWatch on the first trap.
• reporting — it has sent alerts or devices.

Products send no heartbeat, so Central never shows one as down. Last contact — the last time the token reached Central, whether a test or data — and Last report say when it was last heard from.

To issue a token, choose the product, type a label and press Issue token. The token is shown once, with a Copy button; press Done when it is pasted into the product, after which it cannot be shown again. Revoke makes Central reject everything sent with that token from then on; what it already sent stays. A revoked row can then be removed with Delete.

Users and roles

Administrators only. Three roles:

• viewer — read only.
• operator — can also acknowledge alerts.
• admin — everything: accounts, tokens, retention, update checks and the licence.

Passwords need at least 12 characters; user names 3–64 characters of letters, digits and . _ - @. The only administrator cannot be demoted or removed — promote someone else first. Every write is checked on the server, not merely hidden in the interface. The Audit log below the user list shows the latest 50 entries: sign-ins and failed sign-ins, acknowledgements, tokens issued and revoked, and user, settings and licence changes, each with who and when. A forgotten password is reset on the server with node src/server.js --reset-password <username> (in Docker, prefix it with docker exec -it meshwatch-central).

Settings

• Licence — state, organisation, expiry and days left. An administrator pastes a key and presses Activate (or Replace key, Remove key). When the trial or licence ends, Central stops accepting agent data; the console, existing data and the products themselves keep working.
• Data retention — Keep alerts for (days), 1 to 730. Older alerts are deleted, and incidents built from them go with them.
• Updates — off by default: Central makes no outbound connection until an administrator ticks Check once a day. When on, it requests one static file from meshwatch.app a day and sends nothing about your deployment. It can be locked off by policy. Central does not update itself; pull the new image and recreate the container.

Everyone can open Settings; only administrators can change it.

HTTPS

Put a reverse proxy in front for anything reachable outside a trusted network, then set MWC_SECURE_COOKIES=1. Setting that flag before HTTPS is in place will break login — session cookies get marked Secure and the browser will not send them over plain HTTP.

Backup

Everything lives in the data directory — /data in the container (mapped to the central-data volume) or whatever you set MWC_DATA_DIR to. Back that up and you have backed up Central: accounts, tokens, alerts and the audit log.

Retention

Configurable up to 730 days. The resource to plan for is disk space for retained alerts, which scales with how many devices you connect and how long you keep them.

If Central goes down

Nothing is queued to a server Central does not control, and no product depends on Central to do its own job. Each product keeps monitoring exactly as it did before Central existed; you lose the shared inbox and the correlation, nothing else. Products hold recent alerts in a small queue and send them when Central comes back.

The dashboard is all zeros

Nothing has been connected yet, or the connected product has not raised an alert since it was connected. Past alerts are not backfilled.

A product reports, but its rows are empty — and another product has them

That product is using a token issued for the other one. Central files reports under the product named on the token, so they land in the wrong place and nothing reports an error. Check the badge in each Agents row, then issue a token for the right product and revoke the wrong one. Current product releases refuse a mismatched token when you press Test connection and name the product it belongs to.

An agent shows “connected” but nothing arrives

That is not a failure. connected means the product’s Test connection succeeded and it has not sent anything yet; the row switches to reporting on its first real report, because a product sends only when something happens. ConfigWatch reports after one backup run, even when nothing changed; TrapWatch when the first trap arrives. waiting means the token has never contacted Central. There is no heartbeat, so Central never shows a product as down — the Last contact and Last report columns in Agents say when it was last heard from.

Incidents stays empty

Connect a second product. An incident needs two different products reporting the same device within 30 minutes. If two are connected, open Devices: a device on two rows is being named differently by each product — see Alerts and incidents.

The browser will not connect

Check http://, not https://. Then check that port 8443 is open on the server, and that you used the server’s address rather than localhost from another machine.

Test connection says bad-token

The token was mistyped, or revoked. Issue a new one from Agents. Tokens are shown once and cannot be read back.

Alerts are refused with “at is N minutes in the future”

Central answers with 400 when an alert is dated more than five minutes ahead of its own clock. The clock on the machine running the product is ahead: correct it, ideally with NTP. The message includes Central’s time for comparison. A refused alert does not count as a report, so the agent does not switch to reporting.