Solutions · Monitoring system

BrainWhale Pulse

The system watches the hardware of a video surveillance network around the clock — switches, cameras, radars, servers and storage — and shows in one panel what works, what is degrading and what is down. The operator sees the problem and gets an alert before the call "the camera is not recording" arrives. It runs inside the closed network of the site: no internet access, and nothing is installed on the cameras or switches themselves.

What is being watched

Switches

Availability and uptime, the state and link speed of every port, traffic and CRC errors, VLANs, neighbouring devices, the MAC address table. The front panel is drawn with the real port layout, and configuration history is kept.

Cameras

Whether the camera is reachable, whether the video stream is running and whether the management service answers. A dropped stream on a live camera is a separate alarm: "online but not recording".

Servers and storage

CPU and memory load, disk usage, service state, RAID arrays and disk health via SMART — a warning about a disk before it fails.

Radars

Two independent states: the link to the device and the calibration deadline. An expired calibration means legally invalid measurements, so it is tracked separately.

Network map

The network diagram builds itself — from what the switches report

The system polls the switches, collects their neighbours over CDP and LLDP and draws the links between devices. Nobody has to draw the diagram by hand or keep it up to date: the map is rebuilt on demand and shows how the network is actually wired, not how it was planned on paper.

Neighbours over CDP and LLDP
From every switch the system reads the neighbouring devices and the ports that connect them. If LLDP is disabled on a switch, the system enables it and repeats the collection.
What sits on every port
Using the MAC address table and ARP data the system works out which device is plugged into a given port and matches it with the one registered in the system — a camera, a server, a workstation.
A live diagram, not a picture
Nodes and links are interactive: search by name or address, an offline-only filter, zoom, and a click on a node or a link opens its details.
Rebuilt on demand
The map is rebuilt whenever the network changes, and the data comes from the switches themselves — so the diagram shows the actual wiring, not an outdated drawing. Grouping alarms by dependency is a separate mechanism: it relies on parent-child links defined during setup.

✔ The practical gain: when a camera stops answering you can see which port of which switch it is plugged into — no walking to the rack to trace the cable.

How it checks

Six kinds of checks, each on its own schedule. All of them are implemented inside the system, without third-party libraries — which is why it works on a network where nothing can be installed.

01
Six probing methods
Host response every 30 seconds, port availability every minute, SNMP for ports and traffic every minute, live RTSP stream every two minutes, ONVIF camera query every five minutes, servers over SSH every minute.
02
An alarm is not raised on the first miss
A device is declared down after several failed checks in a row. A single lost packet does not raise a false alarm or wake the duty engineer at night.
03
Threshold warnings
Disk usage, overheating, a rising CRC error count on a port — a warning in advance, not an alarm after the failure.
04
Event severity
Critical, major, warning, info. Severity decides whether the alert leaves the system at night and how soon the reminder repeats.
# fleet state
● sw-core-01 48/48 ports up
● cam-07 rtsp ok · onvif ok
● nvr-02 disk 87%
● sw-gate-04 no link
○ cam-18 … cam-33 behind an unreachable switch
✔ This is how dependency grouping works: once the parent-child links are set in the system, devices behind a failed switch are greyed out and raise no separate alarms — the operator gets one signal about the cause, not sixteen about the consequences.

How this differs from an availability check

Plain monitoring answers one question: does the address respond. That is not enough on a real site — you must not raise a hundred alarms for one cause, nor wake the duty engineer over a single dropped packet.

Dependencies
Once parent-child links are set, devices behind a failed switch are marked unreachable because of their parent and raise no separate alarms: one signal instead of an avalanche. The links are defined during setup.
Debouncing
An alarm only after several misses in a row. A network blink does not become an incident.
Maintenance mode
Alerts for a device are muted while work is in progress — planned work does not look like a failure.
Quiet hours
At night only critical alarms leave the system. The rest waits for the morning and stays visible in the panel.
Acknowledgement
Until the duty engineer marks an alarm as accepted, the reminder repeats. Nothing gets lost in the feed.
History and charts
States and metrics are stored over time: the disk usage trend, the growth of port errors, how often streams drop.
Metrology

A radar calibration register — something ordinary monitoring does not have

A measuring device has not only a link but also a calibration deadline. Once it expires the device may work perfectly while its measurements are legally invalid. The system tracks this as a separate state.

✓ Each radar has its own calibration interval; dates are entered from the certificate and the scan is stored in the system.
✓ Reminders 60, 30, 14 and 7 days before the deadline, and daily afterwards with critical severity.
✓ The calibration history is kept, including replacement of the laser unit serial number.

What the operator sees

A web panel with a section per equipment type. The map is built in and works without internet.

Overview Map Switches Servers Cameras Radars Events
Alerts arrive three ways: a pop-up in the browser, an email and a Telegram message. Until the duty engineer acknowledges an alarm, the reminder repeats. Rights are split by role and logins are recorded.

Specifications

thousands
of devices on one server: polling runs in parallel, up to 200 checks at once
no internet
runs on an isolated network, including its own offline map
zero
external dependencies: SNMP, RTSP and ONVIF are implemented in-house
Linux
one server on the site network; the poller and the panel are separate services

What the system deliberately does not do: mass writing of settings to production switches. Configuration is only read and kept in history, so monitoring cannot take the network down. Traffic flow analysis (NetFlow) is not there today: per-port traffic and errors are visible, but not the composition of the flows.

Alongside surveillance and analytics

Monitoring keeps the infrastructure alive; the surveillance system provides live video and the archive; analytics turns the stream into events. Three parts of one delivery, each of which also works on its own.

Video surveillance system →

See it on your own network

We connect the system to your equipment and show what your fleet looks like in the panel.