Generally speaking, the overall goal is to provide centralised logging services for the purposes of operations, compliance and audit. All systems should send log messages to the central server, where the logs will be kept in original form for the required period of time and the logs will be available for event, incident and problem management purposes.

There are several considerations for creating a centralised logging solution.

• What devices and operating systems will be sending logs.

• What applications will be sending logs.

• What protocol will be used to send log messages.

• What timezone are each of the devices sending logs in.

• What criticality of logs is required.

You should complete a table as below to catalogue all the devices which will be sending logs.

The following applications logs need to be send centrally.

syslog has proven to be a very robust protocol for large scale log management. 

TCP should where reliable logging is required, UDP works very well, 99.99% of the time.

The requirement is to send level 6 and above.

Full details for syslog severity levels https://en.wikipedia.org/wiki/Syslog#Severity_level

Handy cross reference: opEvents priority levels vs. NMIS and Syslog levels

There are two primary concerns about time, one clock drift the second is multiple timezones.

There are several options for handling timezone, the following are considered best practices for IT management in this regard:

• All devices should use NTP to ensure accurate time is set

• All devices should have their timezone set to their localtime or to a common timezone, e.g. UTC

• All devices should include the timezone when timestamping, ideally as an offset, e.g. +00

However it is often difficult to get all devices especially devices already installed to do all these things, so a great option is to make the logging server the authoritive time, NTP is setup a timezone is selected, and all logs received by it will be stamped with the time when the log is received.

The following diagram shows how a system can be implemented using syslog and Opmantek opEvents.

Open

The following table summarises how the logs will get from the source into the opEvents server.  Three basic techniques exist, native syslog transport supported by the operating system, a logging agent which monitors for data and sends the resulting data/events/log as a syslog.

There are several good choices for Windows, but NXLOG has proven to meet all the requirements, almost all other systems include embedded syslog systems

The best reference is: https://en.wikipedia.org/wiki/Syslog#Facility

We are primarily concerned with the facilities localX facilities.  Logs will also grow at different rates and having them in separate files will allow for more granular control.  The following table summarises which log files will end up in which files.

Alternate file naming can be supported if required, e.g. cisco.log instead of local7.log.

Translating all the above into the configuration the following are the most important parts.

It should be noted that trying to use the /etc/rsyslog.d scheme did not work.

By default (to prevent DOS) rsyslog is configured to not receive syslogs from remote servers.

Based on the table above the following would be the configuration

Based on the table above the following would be the configuration

Optionally handling things with the WORD LINUX in the tag

The following configuration shows how to create an rsyslog template and apply that to the logs being received, this example also adds high precision time, which is supported by opEvents.

All syslog received to the facility local5 will be timestamped with the receiving syslog servers high precision time.

The following is a config which sends logs from /var/log/messages using facility local6.

The following rsyslog config will send all syslogs which are sourced localy with a severity 0-6 to the remote server.

Here we are using a Linux Mnemonic like the Cisco Syslog so that we do not lose the original facility and severity when the message is fowarded.

Optionally send everything with the WORD LINUX in the tag

Open

In the example above all syslog messages received with a facility of local7 will be forwarded to the Primary server at 10.215.1.5.  When this message is forwarded from the poller to the Primary, the poller will insert its own timestamp into the message.

If the servers/nodes are in differnt time zones or the clocks are not correct opEvents may not by default accept the syslog message.  Setting the opEvents debug option to '1' will show the following message in /usr/local/omk/log/opEvents.log if this is the case.

As of opEvents 2.2.1 we can provision opEvents to allow these wildly out of date syslog messages and replace the origin timestamp with its own.

Setting the 'opevents_max_time_delta' to a value of 1800 seconds will instruct opEvents to do the following:

• If the syslog message has a timestamp that is more than 1800 seconds off from the current server time:

  • Accept the syslog message

  • Remove and replace the timestamp with its own time stamp.

https://en.wikipedia.org/wiki/Syslog#Facility

http://wiki.rsyslog.com/index.php/Sysklogd_drop-in_with_remote_logs_separated_by_dynamic_directory

http://man7.org/linux/man-pages/man5/rsyslog.conf.5.html

http://www.rsyslog.com/doc/v7-stable/configuration/property_replacer.html

http://www.rsyslog.com/doc/v7-stable/concepts/multi_ruleset.html

http://fibrevillage.com/sysadmin/221-rsyslog-rules-examples-on-linux

http://superuser.com/questions/532587/configure-rsyslog-server-to-log-incomming-messages-with-time-of-the-rsyslog-serv

http://people.redhat.com/pvrabec/rpms/rsyslog/rsyslog-example.conf

The version of rsyslog which is included in older CentOS and RedHat systems is problematic and should be upgraded, the steps to do so are included below.

Result:

• opEvents - Syslog Handling - Adding a New Vendor

• opEvents - Syslog Handling - Adding a New Format

• SNMP Traps with Cisco and Other devices

• High Volume SNMP Trap Processing