Syslog

Syslog as event context, on the same timeline

Routers, APs, and switches already emit syslog — link flaps, OSPF adjacency changes, login attempts, DHCP events, config commits. Most of that signal is thrown away or shipped to a logging silo nobody correlates with the device it came from. ISPAgents treats syslog as an event context channel and converges it into the same tenant and device timeline as TR-069, SNMP, RouterOS reads, and the audit trail — so a log line sits next to the metric and the change it explains.

This is event context for ISP operations, not a full SIEM. Syslog answers "what did this device say happened, and when" alongside everything else on the device timeline — it is not positioned as a security analytics platform.

A standards-based receiver

ISPAgents runs an RFC 5424 / 3164 syslog receiver that accepts the common formats network equipment actually sends, over the transports an ISP needs — including encrypted transport for senders that cross untrusted links.

Incoming messages are classified by source IP, severity, and facility, so an operator can filter the timeline to one device, one severity band, or one subsystem rather than scrolling raw text.

Tenant policy controls collection

Syslog collection is governed by tenant policy, so an operator decides what is accepted rather than letting any sender flood the timeline. Collection is tenant-scoped from the start, consistent with the rest of the platform's isolation model — a tenant only sees its own devices' logs.

• Policy controls which sources are collected and retained.
• Classification by source IP, severity, and facility makes the stream filterable instead of a wall of text.
• Logs merge with device audit into one timeline, so an operator-driven change and the device's own log of that change line up.

Attributing unknown senders

Syslog arrives by IP, and not every sender is already a known device. ISPAgents includes an operator-attribution UI for unknown sources: when an unrecognized sender appears, an operator can match it to an existing device or create a new one — so an unattributed log stream becomes a real device on the timeline instead of orphaned noise. This is the same identity discipline the platform applies everywhere: strong evidence maps an observation to one canonical device.

Coexist with the rest of the timeline

Syslog is one input among several, and it is strongest when it lands next to the others. Pair it with the SNMP integration for infrastructure and managed-edge polling, feed both into network monitoring and alerts so a log line and a threshold breach show up together, and rely on canonical subscriber and device identity so every syslog source resolves to the one subscriber, site, and device it belongs to.