Our syslog volume increased from roughly 2.4 million events per day to 7.2 million over about a week, despite no configuration changes or new equipment. The collector only shows the aggregate total, so I had to export seven days of data and group it by host manually. Two switches accounted for 56% of the traffic, largely because of one repeated warning between them, and the investigation took most of a day.
For environments with multiple vendors feeding logs into shared collectors and relays, is there a built-in per-source counter or dashboard you rely on? I'm especially interested in a way to map sender IPs, relay names, and event hostnames back to the actual devices before the short retention window expires.
3 Answers
Start with a seven-day aggregation grouped by the original sender, then sort by event count and compare it with the previous time period. Don’t rely only on the collector’s source label when several devices share a relay or hostname. Preserve the original sender IP, hostname, and relay metadata so you can trace the noisy source back to the actual device.
The exact approach depends on the syslog collector and query system, since different products expose source counters and dashboards differently. It would help to identify the software in use, but regardless, a useful setup should retain the original sender fields and provide a per-source rate or count view rather than only showing one combined total.
Most SIEM and log management platforms can report volume by sender, log type, and time range. A basic query that counts messages by source and sorts them descending should make the biggest contributors obvious. Even a searchable stack such as Elasticsearch, OpenSearch, Graylog, or a monitoring platform can handle this without needing a full SIEM.
That’s also the bigger question: if the logs can’t be searched and broken down quickly when something spikes, the collection system isn’t providing much operational value.
That’s essentially what I did. Counting by sender was quick, but the slow part was resolving hostnames, IPs, and relay addresses back to the physical devices. With only seven days of retention, the investigation also started after a significant part of the useful window had already expired.