Network gear is too often a blind spot — logs going to a box nobody reads, health invisible until a user complains. This guide onboards a device end to end: forward its syslog for normalised, searchable security events that feed detections, and poll it over SNMP for live metrics you can alert on. The result is a firewall or switch that is part of your SIEM, your monitoring, and your topology map — not an island.
A network device produces two fundamentally different kinds of signal, and you want both. Its logs tell you what it did — what it blocked, what changed, who connected. Its operational counters tell you how it is — how saturated its links are, whether errors are climbing, whether an interface is flapping. Onboarding a device means capturing both, and the platform treats each appropriately.
The log stream arrives by syslog and is normalised to a shared security schema, so a FortiGate block, a Palo Alto session, and a Cisco config change all become consistent, searchable events regardless of how each vendor phrases them. That normalisation is what lets the detection packs — including the infrastructure-and- network health pack — run over network events the same way they run over application logs, so a suspicious firewall pattern becomes a detection, and a detection becomes an investigated incident.
The metric stream arrives by SNMP polling. The collector queries the device on an interval and turns its counters into metric series — interface status, throughput, errors, saturation — that behave exactly like host or application metrics. That means you can chart them, watch trends, and set threshold alerts on them, so a link nearing saturation or an error counter climbing becomes an incident before a user notices the slowness it causes.
Together, the two streams turn a device from a blind spot into a fully-observed, fully-defended part of your estate — present in your search, your detections, your alerts, and your topology map. The rest of this guide is how to set up each stream.
A configuration change on the device, not an agent install — point its logs at the ingest endpoint and they become normalised security events.
Every enterprise network device can forward syslog, and onboarding the log stream is a matter of telling it where to send. The exact syntax differs by vendor, but the concept is identical everywhere — set the destination to your ingest endpoint and enable forwarding. On a FortiGate, for example, it looks like this:
# On the device, point syslog at the 24Observe ingest endpoint # (FortiGate example — concept is the same for Palo Alto, Cisco, etc.) config log syslogd setting set status enable set server "<your-ingest-endpoint>" set port 514 end
Palo Alto, Cisco, and other operating systems have their own equivalent of this, but the shape is the same: a syslog server destination and an enable. Once events start flowing, they are normalised to the shared security schema on arrival, so you do not have to write per-vendor parsers — a field means the same thing whether it came from a FortiGate or a Cisco. Confirm the events are landing under Explore, filtered to the device, before moving on.
From that moment the device's security-relevant activity is part of your platform. The detection packs evaluate it, so a pattern worth worrying about opens an incident the analyst investigates; you can search it alongside your application and host logs; and you can build your own detections over it in the same readable query language you use everywhere else. The blind spot is now a watched surface.
Give the collector a device address, read-only credentials, and a profile, and its health counters start arriving as metric series.
To capture the health stream, configure SNMP polling for the device. You provide its address, read-only SNMP credentials, a polling interval, and a profile that matches the device type — a switch profile collects interface and throughput counters, a firewall profile collects its relevant health metrics, and so on:
Device: core-switch-2 Address: 10.0.0.2 Profile: switch (interfaces, throughput, errors, saturation) Interval: 60s Credentials: stored encrypted, scoped to read-only polling
The collector queries the device on the interval and converts its counters into named metric series in the platform. The credentials you provide are stored encrypted and scoped to read-only polling — the platform only ever reads the device's counters, never changes anything on it. Within a polling cycle or two, the device's metrics appear under Metrics, ready to chart and alert on.
With metrics flowing, set threshold alerts on the series that matter — a saturating interface, a rising error rate, a link that goes down — exactly as you would on a host's disk or a service's latency. The metric and SNMP alerting guide covers the threshold setup, including the sustain duration that keeps a momentary blip from paging anyone. Now the device's health is not just visible but watched: a problem opens an incident before the slowness it causes reaches a user.
It is worth understanding why network gear ends up unobserved so often, because the reasons explain why fixing it pays off. Network devices predate the modern observability stack and speak their own protocols — syslog and SNMP rather than the application-centric telemetry most tools are built around — so they tend to be handled by a separate tool, or by no tool, sitting outside the platform where the rest of the signal lives. The result is a structural gap: when an incident has a network cause, the evidence is in a system the application team never looks at, and the network team is debugging from logs disconnected from the application impact. Each side sees half the picture.
Bringing the device into the same platform closes that gap. The firewall's block and the application's failed request are on one timeline; the switch's saturating interface and the service's rising latency are in one view. When the analyst investigates an incident, it can reason across the network and application layers together, because they are no longer in separate worlds. For the common case where a network problem is the root cause of an application symptom, that unification is the difference between a fast diagnosis and a cross-team finger- pointing exercise that burns an hour before anyone looks at the switch.
A sensible rollout does not try to onboard the entire estate at once. Start with the devices whose failure would hurt most — the core switches, the perimeter firewalls, the links your critical services depend on — and get both streams flowing for them: syslog into detections, SNMP into metrics and thresholds. Prove the value on those, watch a real interface trend or a firewall pattern surface as an incident, and then widen to the rest of the estate the same way. Because the setup is the same for every device, each additional one is fast once you have done the first.
A couple of practical notes save time. Confirm each stream independently — check that syslog events are landing under Explore before you worry about detections, and that the SNMP series appear under Metrics before you build thresholds — so that if something is misconfigured you know which half to fix. Use read-only SNMP credentials always; the platform never needs write access to a device, and giving it none is the right least-privilege posture. And lean on the shared schema: because vendor events are normalised on arrival, a detection you write for one firewall vendor generally works for another, so you are building portable coverage, not per-device parsers.
Done this way, your network stops being the layer everyone forgets until it breaks and becomes a first-class, watched, defended part of the same platform as everything else — which, for any team that runs its own gear, is one of the highest-leverage pieces of coverage they can add. The NOC and ops teams who live closest to this feel it most; the NOC solution covers the broader picture of running network and ops on one platform.
It is worth saying that this is one of the highest-leverage additions a team can make precisely because network gear is so commonly neglected. The same organisation that meticulously instruments its applications will often have firewalls logging to a file nobody reads and switches whose health is a mystery until something stops working — not because the team does not care, but because the gear sits outside the platform where the rest of the attention lives. Closing that gap does not require a network-monitoring specialist or a separate product; it requires the two configuration steps above, done once per device. For the effort involved, few things expand your coverage as much as bringing the network into the same platform as everything else.
Forward syslog for normalised security events, poll over SNMP for health metrics, and get detections, alerts, and a place on the topology map — for every firewall and switch you run.