Configuration: Tailor the inputs or the extractors and Syslog default formatting

[jochen]

@texas-bronius

Is there a rule of thumb that could be said: Let the application spit out whatever log and format it wants out of the box, and let the log analysis tool parse and chunk it per-application? This, as opposed to excessive customization of each application’s log to the extent to which we are given that control and with the likelihood that still some custom extractors will be required.

The more preprocessing your applications can do the better. Ideally use JSON or GELF and structured logging.
Check the Graylog Marketplace for existing GELF appenders for your logging frameworks:

the NEW Marketplace

@texas-bronius

There is no year in it…? From my reading on Extractors, I gather Graylog converts this timestamp into a date in this current year. Is this correct?

Yes, but that’s bad practice. Use the proper syslog message template in rsyslog and you’ll be much happier (and the syslog messages will contain a proper timestamp):

Graylog2/graylog-guide-syslog-linux/blob/master/README.md#rsyslog

@texas-bronius

How important is the syslog timestamp when we are most likely to include an event timestamp in our log files themselves? Does much of Graylog depend on this timestamp as being assumed to be about the same time as the event, or?

There’s a difference in the message timestamp and the time the message was received by Graylog. You usually want to have a proper (and correct) message timestamp, ideally ISO 8601 with date and time in UTC.