Syslog Onboarding with Skewed Event Times
Your team is onboarding a new perimeter firewall that sends syslog over UDP to a LogRhythm Mediator at roughly 3,000 events per second. The log source appears in the Client Console and records are searchable, but almost every record has an Origin Date equal to collection time, not the firewall's event time. Fields such as Source IP, Destination IP, and Rule Number are blank, even though the raw syslog payload contains them. About 8% of records appear in the next hourly bucket. The Mediator is at 68% CPU and reports no dropped packets. The same firewall vendor is already integrated in another data center using the built-in log source type and works correctly there. The new site uses a nonstandard syslog header with a local time zone and a custom message format. You need to correct parsing and time normalization without reprocessing the entire day's data or disrupting other log sources on the Mediator.
1. Which LogRhythm processing components would you inspect first to separate a date-parsing failure from an MPE field-mapping failure, and what specific evidence would confirm each cause?
Read the worked answer
Normalization depends on the Log Source Type's Date Parser and MPE rules, with Registry overrides for time zone. I would compare a raw syslog sample to the normalized record and inspect the assigned Log Source Type. If every record has Origin Date equal to collection time and no parsed timestamp, the Date Parser is not matching the custom header and the platform is falling back to receipt time. If some records have correct dates but Source IP, Destination IP, and Rule Number are blank, the Date Parser is working and the MPE rule regex is failing on the custom message body. The built-in type working elsewhere points to a format difference, not a Mediator fault. I would clone the working Log Source Type rather than edit the built-in, then adjust the Date Parser for the local time zone or set a Registry override, and update the MPE rule to extract the missing fields. The 8% next-hour records are consistent with a time-zone offset, not packet loss, because the Mediator reports no drops.
2. How would you validate the corrected parser and time zone in production with minimal risk, and what would you monitor after the change?
Read the worked answer
I would create a test copy of the Log Source Type, bind it to a temporary log source on the same Mediator, and replay representative raw messages including daylight-saving, malformed-header, and missing-field cases. I would compare normalized Origin Date, field values, and classification against expected output, then move one firewall cluster member or one site to the corrected type before changing all devices. After the change I would monitor parse-error rate, records with fallback timestamps, blank-field percentage, EPS, Mediator CPU, and duplicate records. I would not reparse the whole day unless corrected timestamps affect an investigation or compliance obligation. If reparse is required, I would scope it to the affected log source and coordinate with retention owners, because broad reindexing can create duplicates and add index pressure.