Wireless Access

Reply
New Contributor

Syslog date format

Standard Syslog messages should NOT include the year in the first few fields of a syslog entry.  Prior to our upgrade to v.6.1 syslog entries looked like this (emphasis added):

Jan 15 14:11:04 2009 [10.1.10.10] sapd[215]: <326091> <NOTI> |AP 1.3.4@10.1.30.98 sapd|  AM: Radio Stats: APs=2 STAs=0 Mon-APs=6 Mon-STAs=2
Jan 15 14:11:05 2009 [10.1.10.10] wms[521]: <316094> <WARN> |wms|  Could not create entry for station 00:1f:e1:1e:ee:cb
Jan 15 14:11:05 2009 [10.1.10.10] wms[521]: <316094> <WARN> |wms|  Could not create entry for station 00:18:de:b2:f7:34
Mar  2 09:10:56 2011 [10.1.253.5] authmgr[598]: <522008> <NOTI> |authmgr|  User authenticated: Name=jsmith MAC=c8:bc:c8:29:59:aa IP=100.100.160.249 method=802.1x server=iFolder role=pre-employee

After upgrading to 6.1, the format changed to the correct format (no year)

 

Nov 14 10:06:56 10.1.143.233 sapd[918]: <404074> <WARN> <10.1.253.5 10.1.253.5>  AM 00:24:6c:b0:6c:20: ARM - increasing power cov-index 6/1 tx-power 6 new_rra 6/7
Nov 14 10:08:41 Sandy3600 localdb[1569]: <133019> <ERRS> <Sandy3600 10.1.253.5>  User 40:6a:ab:1c:9d:77 was not found in the database
Nov 14 10:08:41 Sandy3600 localdb[1569]: <133006> <ERRS> <Sandy3600 10.1.253.5>  User 40:6a:ab:1c:9d:77 Failed Authentication

Now after upgrading to 6.2, the year is back in the messages. 

 

Dec 12 09:06:34 2013 Sandy3600 localdb[1764]: <133006> <ERRS> <Sandy3600 10.15.253.45>  User 60:fb:42:3c:18:66 Failed Authentication

 

Anyone have any idea how to disable the year being included in syslog messages? or why they might have reappeared with the 6.2 upgrade?  The year field really messes up our syslog server.

Re: Syslog date format

I'm happy to be challenged on this, but this is my understanding...

 

RFC 5424 requires the year.

 

RFC 3164 (obsolete) doesn't require the year.

 

So, whether or not it's in there depends what RFC the developer was following.

 

I don't believe the ability to format or follow as specific variant of RFC (by way of config) exists.

 

Having said that, doesn't upgrading to 6.2 resolve your issue (which I assume is to do with the syslog server parsing for information/alerting) based on what you've said?

Kudos appreciated, but I'm not hunting! (ACMX 104)
New Contributor

Re: Syslog date format

Hello,

 

What you state is not completly true.

It is correct that RFC 5424 obsoletes RFC 3164 but this also changes a lot of other things.

When you create a syslog server that follows RFC 5424 you have the option to follow one of the 4 following formats for the timestamp field in the message:

1985-04-12T23:20:50.52Z

1985-04-12T19:20:50.52-04:00

2003-10-11T22:14:15.003Z

2003-08-24T05:14:15.000003-07:00

 

When you stick with RFC 3164 the timestamp and following hostname format is very specific defined and doesn't leave any options open. The format MUST me:

 

Aug  7 17:45:30 hostname

 

The Aruba controller now does the following and this is very wrong:

 

Aug  7 17:45:30 2014 hostname

 

This is as far as I understand it so far after reading both RFC's.

 

Jan Hugo Prins

 

 

Super Contributor I

Re: Syslog date format

 

The end result of this is that anyone scratching their head looking for their controller syslogs who is running rsyslog and putting their logs in files based on the hostname should look for files called "2014.*".

 

There's no super-easy way to fix rsyslog for this nonstandard format.  You either have to build your own from source or play crazy games with variable reassignments.

 

New Contributor

Re: Syslog date format

I've run into this same issue. The fact that the year is included in the syslog message in its current format messes with the way the syslog server parses the messages.

 

What's odd is if you look at the messages locally using show log user-debug, for example, the output is here does not include the year and is what I would expect the syslog message to be.

 

Does anyone have a fix for this issue?

 

New Contributor

Re: Syslog date format

Managed to find a workaround for this.

 

We recently changed our syslog server to Elastic Stack.  The stack includes Logstash which ingests the syslog data and has powerful grok/regex filters.  Here's the filter I came up with to workaround this issue:

 

filter {
if [type] == "syslog" {
grok {
match => { "message" => "(?:%{SYSLOGTIMESTAMP:syslog_timestamp}|%{TIMESTAMP_ISO8601:syslog_timestamp})(?: %{YEAR:aruba_erroneous_year})? %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\/%{DATA:container_name}\/%{DATA:container_id})?(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
remove_field => ["message", "aruba_erroneous_year"]
add_field => [ "received_at", "%{@timestamp}" ]
add_field => [ "received_from", "%{host}" ]
}
syslog_pri { }
date {
match => [ "syslog_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss", "ISO8601" ]
}
dns {
reverse => [ "host", "syslog_hostname" ]
action => "replace"
}
}
}

If it finds an erroneous year after the timestamp, it puts it in a field called aruba_erroneous_year and then promptly removes the field.  Prior to this, the year was ending up in the syslog_hostname field.

 

Seems crazy, some may say arrogant, that Aruba chooses not to comply with RFC 3164 or its replacement, RFC 5424.

 

EDIT: Updated the filter to make one of the surrounding spaces around the erroneous year optional too, otherwise it wouldn't match on correctly-formatted syslog messages that didn't include the year :$

Also added support for ISO8601 date formats.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: