There are many ways to send syslog to Loggly. We have specific guides available for Linux systems, Windows systems, and Network Devices and Routers. This page describes more generically our syslog endpoints and accepted log formats.
We have two syslog endpoints available that accept both UDP and TCP syslog. Please see the advanced options section for instructions on how configure your specific systems.
For standard syslog please use:
For secure syslog encrypted with TLS please use:
We only accept syslog events with a RFC5424 compliant header. Within the header there must be a structured data set that includes your Customer Token and the Loggly private enterprise number (PEN) which is 41058. Here’s an example of a compliant syslog header:
<34>1 2003-10-11T22:14:15.003Z server1.com sudo - - [8bf8cc10-4140-4c3e-a2b4-e6f5324f1aea@41058]
If you use syslog, we can guarantee that your syslog headers and structured data will be extracted, independently of the actual message contents, provided you use our standard syslog configuration. These configs are based on the Syslog Protocol RFC5424, and we will extract the following fields (using RFC names):
PRIVAL, Facility, Severity, VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, MSGID
Our standard config also allows you to define tags in the STRUCTURED-DATA part of the message. As an example, if your structured data looks like this:
[01234567-89ab-cdef-0123-456789abcdef@41058 tag="foo" tag=bah]
we will extract "foo" and "bah" as tags, which you can then use to refine searches using tag:foo for example, and which you can also use in the Trending tab.
Notice that we support unquoted values, even though the RFC says these values must be quoted.
Many people think of logs as files, but you can also stream logs using syslog over the network without needing agents or writing logs to a file. There are many reasons to do this including for performance reasons if writes are too slow for your app, if you don’t have access to the file system, to create a centralized local log server, to log from network devices like routers or switches, or just for applications that stream syslog. Many applications are able to log directly to syslog including logger, Nginx, Apache error logs, and more. You can also write custom applications to log directly to syslog using libraries like syslog4j.
You can configure rsyslog and syslog-ng to accept syslog over localhost, or over your network from one or more servers or network devices. The syslog daemon will include headers with the LogglyFormat if necessary. If you send over TCP it will retry, and you can additionally configure a local in-memory queue. Added to the default configuration supplied by configure-syslog or the rsyslog manual configuration, this will configure rsyslog to accept events from the network interface and forward them to Loggly.
# Receive syslog over UDP module(load="imudp") # needs to be done just once input(type="imudp" port="514") # Receive syslog over TCP module(load="imtcp" MaxSessions="500") input(type="imtcp" port="601")
- Logging from Linux Systems – send syslog from Linux systems
- Logging from Windows Systems – send syslog from Windows systems
- Network Devices and Routers – send events from network devices and routers to Loggly
- Send secure syslog over TLS – encrypt the data transmission
- Send Apache error logs over syslog – may offer faster notification of errors
- Configuring Java with syslog4j – send directly from your java apps to Loggly without an agent
- Logging from Applications – more application configurations
If you don’t see any data show up, then check for these common problems.
Check Your Syslog Daemon:
Still Not Working?
- Search or post your own syslog endpoint questions in the community forum.
When the APM Integrated Experience is enabled, Loggly shares a common navigation and enhanced feature set with the other integrated experiences' products. How you navigate the product and access its features may vary from these instructions. For more information, go to the APM Integrated Experience documentation.
The scripts are not supported under any SolarWinds support program or service. The scripts are provided AS IS without warranty of any kind. SolarWinds further disclaims all warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The risk arising out of the use or performance of the scripts and documentation stays with you. In no event shall SolarWinds or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the scripts or documentation.