This article describes how to send system log data to a Devo relay using the basic syslog standard.
Earlier versions of the syslog standard protocol, including those used for MacOS X implementations, only support UDP for transport. However, later syslog versions also support TCP. Since UDP lacks congestion control mechanisms, we recommend enabling TCP for all syslog transmissions in order to prevent possible data loss during transmission.
Due to its inability to apply tags to events and to implement security, syslog should only be used to send events to a Devo In-House Relay - and wherever possible, using TCP. The relay can apply rules to tag the inbound events and forward them outbound over a secure channel to the Devo Cloud.
Edit the syslog.conf file
To send system log data to a Devo Relay using TCP, open the /etc/syslog.conf file and add the following line to the end of the file where
DEVO-RELAY is the IP address or server name of the relay and
PORT is the port enabled to receive the events.
To view a list of active relays, go to Administration → Relays in the Devo web application. Remember that you will have to set up a rule on the relay that will recognize the inbound events from the data source, apply the appropriate Devo tag, and forward the events to the Devo Cloud.
If the syslog version does not support TCP, then the line should contain just one at symbol (@) to specify UDP instead.
After editing the configuration file, you will need to restart syslog for the changes to take effect:
To restart syslog on a MacOS X, use the following commands:
Test the connection
If at this point you have already set up a rule on the Devo Relay that will recognize, tag, and forward the events that it receives from this source, you can test the connection. Use the logger command to write test messages to the system log.
In the Devo web application, go to Data Search, locate the box.unix table and make sure that the logger messages appear in the table.
If the system has SELinux enabled in enforcing mode (run the getenforce command to check the status), it may be necessary to add exceptions to the SELinux policy. See SELinux configuration conflicts for more information.