As a de facto standard for computer message logging, syslog has been around many years. Fundamentally, every Linux and Unix variant delivers some level of syslog message logging as a default.
Like any other logging capability, syslog must be enabled to work and the user needs to decide what to do with the data being logged. The choice of destination can be as simple as log files or you can use database logging, where syslog writes directly to a fully relational database engine.
Syslog is an IETF standards track protocol with reference document RFC 5424 first issued in 2009. As with any IETF standard, the current status and definitions can be found at the Official Internet Protocol Standards website. The information found in this standard obsoleted the original BSD Unix standard , RFC 3164, which was an informational document, rather than a standards proposal. Additional IETF standards documents cover TLS Transport Mapping for Syslog (RFC 5425) and Transmission of Syslog messages over UDP (RFC 5426).
Syslog-ng is an extension of the basic syslog protocol currently developed by Balabit IT Security. This open source code supports most distributions of Linux and Unix, both open source and proprietary. Some distributions install it as the default syslog, and there is even a Cygwin port for Microsoft Windows. Syslog-ng was the first version to support logging directly into a database, log to multiple files destinations, directing log messages to local applications, extract structured data from unstructured messages and a number of other features which are now consider standard to the syslog environment. Both open source and proprietary versions of syslog can be obtained on the Balabit IT Security website.
Rsyslog is the rocket-fast system for log processing, an open source project started in 2004 with the goal of building a faster and more flexible syslog implementation. Version 7 (currently version 7.6.3) was released in December 2013 and a re-engineered Version 8.2.0 in April 2014. Both versions are currently supported by the open source community and can be found on the rsyslog home page at www.rsyslog.com.
Because much of the development of syslog tools stared with the information RFC 3164 there are many branches which have incompatible extensions. One of the goals of rsyslog was to enable a service that would work with as many of the branches as possible as well as support the later RFC standards discussed earlier. The performance claims for rsyslog are also much greater than for other existing standardized implementations as well as the supported sources and destinations for data. Direct database logging to both open source and commercial databases is supported as well as source messaging from Linux, Unix, and Microsoft Windows devices. This graphic, from the rsyslog home, gives you some ideas of the logging capabilities.
Because of the flexibility of the syslog tools and the information that can be collected, there are a wide variety of common use cases. Security is probably the top of the list, as the data provided can be used to analyze everything from internal usage patterns of systems and services to tracking external (or internal) attempts to breach security on monitored systems.
This flexibility means syslog has also been proposed as a standard for maintaining certain aspects of regulatory compliance issues, such as HIPPA and the Sarbanes-Oxley Act, where regulations require organizations to track who touches files and how data is being handled. Syslog and its derivatives are naturally positioned as a data source for such tasks.
Syslog is also well suited for a fundamental job of IT: keeping systems up and running and heading off problems before they impact users. Data analysis, using log management tools such as Logentries, allows IT to track application and system behavior and performance and alerts IT to any changes or bottlenecks that might affect the user experience.
Syslog should be considered a basic tool for the IT administrator tasked with the oversight of Linux and Unix systems.