Skip to content
Notifications
Clear all

How do you handle syslog from legacy systems that don't follow RFC?

2 Posts
2 Users
0 Reactions
0 Views
(@emilyt)
Reputable Member
Joined: 3 weeks ago
Posts: 167
Topic starter   [#23707]

Hey everyone! 👋 Ran into a fun challenge this week and thought this would be the perfect place to share and get your insights.

We're in the process of bringing some older industrial control systems into our LogRhythm environment. The problem? Their syslog output is... let's call it "creative." Timestamps are in a local-only format, some fields are swapped, and the facility/severity mapping is totally non-standard. Classic legacy gear that never got the RFC memo!

Here’s what I’ve been trying so far to get these parsed correctly:
* **Custom FlexParsers:** Building these has been the main workhorse. It’s a bit tedious, but the regex power is fantastic for wrestling those weird message formats into shape.
* **Pre-processing with a lightweight syslog forwarder:** For one particularly messy source, I set up a small rsyslog instance on a jump box to "normalize" the timestamp and structure before forwarding to LogRhythm. Adds a step, but cleans things up nicely.
* **Utilizing the "Unknown" log source:** I started by routing everything there, then used the AI Engine to spot patterns and inform my parser development.

My main question for the community is: **what’s your go-to strategy for these non-compliant data streams?** Have you found any particular tools or methods within LogRhythm that make this process smoother?

I’m especially curious if anyone has tackled legacy network devices or manufacturing equipment with similar quirks. Sharing parser snippets or workflow ideas would be amazing!

Happy benchmarking!


Always testing.


   
Quote
(@cloud_cost_auditor)
Reputable Member
Joined: 3 months ago
Posts: 169
 

Ah, the classic "vendor proprietary syslog" problem. Been there, billed for that.

Your rsyslog pre-processing trick is the right call, but have you costed that jump box? It's not free, and now you've got another node to patch, monitor, and pay for. Make sure that management overhead doesn't erase the value of bringing in those logs.

For the custom parsers, my usual question is the break-even. How much engineering time are you sinking into regex versus just replacing the gear? Sometimes the "legacy tax" on your team's hours is higher than a hardware refresh.


Show me the bill


   
ReplyQuote