Centralizing Network Device Logs: Collecting Syslog from Switches, Firewalls, and Load Balancers

Network devices — switches, firewalls, load balancers — fail in the quietest ways. Interface flapping, ACL blocks, a full session table: none of these show up in your application logs, only in syslog. Pulling network syslog into OBSERVE lets you correlate the network and application layers while troubleshooting, instead of flipping between two consoles and hoping the timelines line up. Here's the end-to-end setup, from the device all the way to the alert.

Device side: point syslog at the collector

On a typical switch, enabling remote logging is two lines:

info-center loghost 10.0.8.20 facility local6
info-center source default channel 2 log level warning

Firewalls (including domestic ones) usually expose this in the GUI under something like "Logging — Syslog": enter the server address, port 514, protocol UDP, and set the record level to "warning and above." Load balancers work the same way. A useful habit is to assign a distinct facility per device type — local5 for switches, local6 for firewalls, local7 for load balancers — so parsing can tell them apart without maintaining per-device labels. Decide this convention before you configure the first device; retrofitting facility mapping across a hundred devices later is tedious and error-prone.

Receiver side: rsyslog or Collector

For small setups, rsyslog writing to files that the collector tails is enough and requires nothing new on the network:

$template RemoteLogs,"/var/log/network/%HOSTNAME%/%PROGRAMNAME%.log"
local6.* ?RemoteLogs
& stop

With a larger fleet, use the OpenTelemetry Collector's syslog receiver to produce structured data directly, skipping the write-then-read middle step and giving you per-message attributes to route on:

receivers:
  syslog:
    tcp:
      listen_address: "0.0.0.0:514"
    protocol: rfc3164
processors:
  attributes/device:
    actions:
      - key: device.facility
        from_attribute: syslog.facility
exporters:
  otlphttp:
    endpoint: "https://ob.jjhub.cn/otlp"

The Collector approach scales better because each message is parsed once, in one place, and enriched with attributes before it ever reaches storage. Once you pass a few hundred devices, the write-then-read rsyslog path starts to feel like extra moving parts you don't need.

Parsing and alert rules

Map facility to device type and severity to alert level, then build alerts around keywords. A few high-value rules: interface flaps (%LINEPROTO-5-UPDOWN), firewall session-count over threshold, load-balancer backend down, and login failures (Failed password or login failure). In OBSERVE, aggregate these as "same device, same keyword, more than five times in ten minutes" rules — much quieter than alerting on every single line, and on-call chases one root cause instead of fifty pages. A flapping interface that fires once looks harmless; the same interface flapping ten times in five minutes is a failing transceiver, and aggregation is what surfaces that difference. Set up a mapping early: facility local5 to device_type=switch, local6 to firewall, local7 to load_balancer, and map syslog severity (emerg, alert, crit, err, warning, notice, info, debug) onto your existing alert levels, so a crit from a firewall doesn't land in the same bucket as a debug from a switch. If your devices emit vendor-specific formats — some firewalls prefix messages with a connection serial or a custom tag — strip those in the parse step so the keyword rules stay stable across firmware upgrades.

Two practical tips

First, UDP drops packets. For larger fleets, switch to TCP or TLS syslog so "the log never arrived" doesn't become "the failure was never seen." Second, give network logs their own index with 30-day retention — enough for security audits and troubleshooting without competing with business logs for storage. Before cutting everything over, pilot one switch and verify facility mapping and timezone correctness, so you don't discover misaligned timestamps and scrambled fields after a fleet-wide rollout. Two more operational details worth getting right. First, synchronize NTP across both the devices and the collector: network gear often ships with the wrong timezone, and a switch logging in UTC while your servers log in local time will scramble every correlation you attempt later, so set a single timezone convention before rollout. Second, when you move to TLS syslog, pin the certificate chain on the collector side — most devices let you upload a CA or client certificate, which lets you run the listener on plain TCP without fearing spoofed or tampered messages. And name your sources deliberately: a hostname like sw-core-03 beats the default 10.0.8.20 in every query, so spend ten minutes setting real hostnames on the devices themselves.