patterns/{ecs-v1,legacy}/grok-patterns: SYSLOGFACILITY pattern is misleading
efd6 opened this issue · comments
While looking into a test case for a PR in elastic/beats (not actually a binary file, just a file with null line termination, relevant diff quoted here for convenience):
- <14.2>Aug 14 2019 14:02:38 platformSettingEdit.cgi: siem-management: admin@10.0.255.31, Devices > Platform Settings > Audit Log Settings > Modified: Send Audit Log to Syslog enabled > Disabled
+ <14>Aug 14 2019 14:02:38 platformSettingEdit.cgi: siem-management: admin@10.0.255.31, Devices > Platform Settings > Audit Log Settings > Modified: Send Audit Log to Syslog enabled > Disabledfor a fix for elastic/integrations#3507, I found that the SYSLOGFACILITY pattern matches a dot-separated number pair.
This does not agree with any syslog line that I have seen and does not agree with either of the syslog RFCs, RFC3164 and RFC5424 (also note that it calls this FACILITY where the angle bracketed token is the priority in the RFCs).
I have tracked the origin of this as far back as this change in the original grok project, and have followed up with the author to find the history of this. He agrees that this is probably a mistake, but can't remember the origin (unsurprisingly given the age of the change).
The existence of this pattern leads to a proliferation of SYSLOGFACILITY and SYSLOGPRIORITY pattern definitions in pipelines and as we see in the diff above, test cases that don't appear to have any real valid provenance (I have asked about the origin of the original state of that line and it also doesn't have a clear history).
I'm not entirely sure how to address this, but one option would be to deprecate this pattern and provide a correct SYSLOGPRIORITY pattern as SYSLOGPRIORITY <%{NONNEGINT:priority:int}>.
The requested pattern is already available in the linux-syslog file: