AxoSyslog can send log messages to Sumo Logic, a cloud-based log management and security analytics service, by using the sumologic-http() and sumologic-syslog() destinations.
Prerequisites
Currently, using the sumologic-http() and sumologic-syslog() destinations with AxoSyslog has the following prerequisites:
Your configuration must also contain @include "scl.conf", which the default configuration file already does. If the SCL files are missing, AxoSyslog fails to start with an unexpected LL_IDENTIFIER error.
Terminal window
@include "scl.conf"
The sumologic-http() driver is a reusable configuration snippet (SCL). For details on using or writing such configuration snippets, see Reusing configuration blocks. You can find its source in scl/sumologic/sumologic.conf on GitHub.
A verified connection and client configuration with the Sumo Logic service.
Warning
To avoid potential data loss, we strongly recommend that you verify your connection and client configuration with the Sumo Logic service before you start using the sumologic-http() or sumologic-syslog() destination with AxoSyslog in a production environment.
(Optional) For using the sumologic-http() destination, you need a HTTP Hosted Collector configured in the Sumo Logic service.
(Optional) For using the sumologic-http() destination, you need the unique HTTP collector code you receive while configuring your Host Collector for HTTP requests.
Limitations
Currently, using the sumologic-syslog() and sumologic-http() destinations with AxoSyslog has the following limitations:
The minimum required version of AxoSyslog is version 3.27.1.
Message format must be in RFC 5424-compliant form. Messages over 64KB in length are truncated.
For more information about the message format limitations, see the Message format section on the official Sumo Logic website.
64 characters long Sumo Logic tokens must be passed in the message body.
Note
Although RFC 5424 limits the structured data field (SD-ID) to 32 characters, Sumo Logic tokens are 64 characters long. If your logging client enforces the 32 characters length limit, you must pass the token in the message body.
In addition, the sumologic-http() destination also has the following options.
batch-bytes()
Accepted values:
number [bytes]
Default:
none
Description: Sets the maximum size of payload in a batch. If the size of the messages reaches this value, AxoSyslog sends the batch to the destination even if the number of messages is less than the value of the batch-lines() option.
Note that if the batch-timeout() option is enabled and the queue becomes empty, AxoSyslog flushes the messages only if batch-timeout() expires, or the batch reaches the limit set in batch-bytes().
Available in AxoSyslog version 3.19 and later.
batch-idle-timeout()
Type:
time in milliseconds
Default:
0 (disabled)
Available in AxoSyslog 4.24 and later.
Description:batch-idle-timeout() measures the elapsed time since the last message was added to the batch (batch-timeout() defines the maximum time used to collect a batch, starting from the first message). If either batch-idle-timeout() or batch-timeout() expires, AxoSyslog closes and sends the batch.
batch-lines()
Type:
number
Default:
1
Description: Specifies how many lines are flushed to a destination in one batch. The AxoSyslog application waits for this number of lines to accumulate and sends them off in a single batch. Increasing this number increases throughput as more messages are sent in a single batch, but also increases message latency. To disable batch-lines(), set it to 0.
For example, if you set batch-lines() to 100, AxoSyslog waits for 100 messages.
If the batch-timeout() option is disabled, the AxoSyslog application flushes the messages if it has sent batch-lines() number of messages, or the queue became empty. If you stop or reload AxoSyslog or in case of network sources, the connection with the client is closed, AxoSyslog automatically sends the unsent messages to the destination.
Note that if the batch-timeout() option is enabled and the queue becomes empty, AxoSyslog flushes the messages only if batch-timeout() expires, or the batch reaches the limit set in batch-lines().
For optimal performance, make sure that the AxoSyslog source that feeds messages to this destination is configured properly: the value of the log-iw-size() / max-connections() of the source must be higher than the batch-lines() * workers() of the destination. Otherwise, the size of the batches cannot reach the batch-lines() limit.
batch-timeout()
Type:
time in milliseconds
Default:
-1 (disabled)
Description: Specifies the time AxoSyslog waits for lines to accumulate in the output buffer. The AxoSyslog application sends batches to the destinations evenly. The timer starts when the first message arrives to the buffer, so if only few messages arrive, AxoSyslog sends messages to the destination at most once every batch-timeout() milliseconds.
ca-dir()
Accepted values:
Directory name
Default:
none
Description: The name of a directory that contains a set of trusted CA certificates in PEM format. The CA certificate files have to be named after the 32-bit hash of the subject’s name. This naming can be created using the c_rehash utility in openssl. For an example, see Configuring TLS server authentication on the AxoSyslog clients. The AxoSyslog application uses the CA certificates in this directory to validate the certificate of the peer.
This option can be used together with the optional ca-file() option.
ca-file()
Accepted values:
File name
Default:
empty
Description: Optional. The name of a file that contains a set of trusted CA certificates in PEM format. The AxoSyslog application uses the CA certificates in this file to validate the certificate of the peer.
Example format in configuration:
Terminal window
ca-file("/etc/pki/tls/certs/ca-bundle.crt")
Note
The ca-file() option can be used together with the ca-dir() option, and it is relevant when peer-verify() is set to other than no or optional-untrusted.
Description: Custom HTTP headers to include in the request, for example, headers("HEADER1: header1", "HEADER2: header2"). If not set, only the default headers are included, but no custom headers.
The following headers are included by default:
X-Syslog-Host: <host>
X-Syslog-Program: <program>
X-Syslog-Facility: <facility>
X-Syslog-Level: <loglevel/priority>
Starting with AxoSyslog 4.18, you can use templates in the headers. Note that when using batching in the destination adn templates in headers(), the value of the template is calculated from the first message of the batch. Make sure to set the worker-partition-key() option properly to group similar messages.
If you want to use literal dollar signs ($) in headers(), escape them like $$.
Note
The headers() option is a required option for the sumologic-http() destination.
time-reopen()
Accepted values:
number [seconds]
Default:
60
Description: The time to wait in seconds before a dead connection is reestablished.
tls()
Type:
tls options
Default:
n/a
Description: This option sets various options related to TLS encryption, for example, key/certificate files and trusted CA locations. TLS can be used only with tcp-based transport protocols. For details, see TLS options.
In version 4.0 and newer, using the tls() option is optional, and Sumo Logic servers are verified using the system certificate store by default. In earlier versions, this was a required option.
In addition, the sumologic-syslog() destination also has the following options.
ca-dir()
Accepted values:
Directory name
Default:
none
Description: The name of a directory that contains a set of trusted CA certificates in PEM format. The CA certificate files have to be named after the 32-bit hash of the subject’s name. This naming can be created using the c_rehash utility in openssl. For an example, see Configuring TLS server authentication on the AxoSyslog clients. The AxoSyslog application uses the CA certificates in this directory to validate the certificate of the peer.
This option can be used together with the optional ca-file() option.
ca-file()
Accepted values:
File name
Default:
empty
Description: Optional. The name of a file that contains a set of trusted CA certificates in PEM format. The AxoSyslog application uses the CA certificates in this file to validate the certificate of the peer.
Example format in configuration:
Terminal window
ca-file("/etc/pki/tls/certs/ca-bundle.crt")
Note
The ca-file() option can be used together with the ca-dir() option, and it is relevant when peer-verify() is set to other than no or optional-untrusted.
Description: Optional. This option sets the port number of the Sumo Logic server to connect to.
tag()
Type:
string list
Default:
“tag”
Description: Optional. This option specifies the list of tags to add as the tags fields of Sumo Logic messages. If not specified, AxoSyslog automatically adds the tags already assigned to the message. If you set the tag() option, only the tags you specify will be added to the messages.
tls()
Type:
tls options
Default:
n/a
Description: This option sets various options related to TLS encryption, for example, key/certificate files and trusted CA locations. TLS can be used only with tcp-based transport protocols. For details, see TLS options.
In version 4.0 and newer, using the tls() option is optional, and Sumo Logic servers are verified using the system certificate store by default. In earlier versions, this was a required option.
token()
Type:
string
Default:
Description: Required option. The Cloud Syslog Cloud Token that you received from the Sumo Logic service while configuring your cloud syslog source.