librelp 1.2.4

librelp 1.2.4 [download]

This version of librelp is a correction for the API/ABI change in v1.2.3. Everything else stays the same.

———————————————————————-
Version 1.2.4 – 2014-03-17
– correct API/ABI change in 1.2.3
My reasoning was flawed, and we could run into problems with
apps that required the new version but could not detect that an
older one was installed.
Thanks to Michael Biebl for pointing this out.
What we have done is:
– revert back to previous state (return void)
* relpSrvEnableTLS();
* relpSrvEnableTLSZip();
These functions are now deprecated.
– introduce new functions that return a state
* relpSrvEnableTLS2();
* relpSrvEnableTLSZip2();


sha256sum: cf4f26f9a75991eedf3eaf414280c8da3532c38e619a465d23008c714f5c1cf1

rsyslog 7.6.1 (v7-stable) released

This version is the first bug-fixing release for 7.6. In addition to bugfixes, it also offers some new, unintrusive, features. Most importantly, the way action suspension and resumption messages can now be configured on a finger grain basis. The action naming has been improved and kept consistent and imjournal can now better handle invalid entries in systemd journal.

This releases is a recommended update for all users of the 7.6 branch.

Note that now librelp 1.2.3 is required as we process it’s new error codes emitted when librelp does not support TLS.

ChangeLog:

http://www.rsyslog.com/changelog-for-7-6-1-v7-stable/

Download:

http://www.rsyslog.com/rsyslog-7-6-1-v7-stable/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Changelog for 7.6.1 (v7-stable)

Version 7.6.1 [v7.6-stable] 2014-03-13

  • added “action.reportSuspension” action parameter This now permits to control handling on a per-action basis rather to the previous “global setting only”.
  • “action resumed” message now also specifies module type which makes troubleshooting a bit easier. Note that we cannot output all the config details (like destination etc) as this would require much more elaborate code changes, which we at least do not like to do in the stable version.
  • better and more consistent action naming, action queues now always contain the word “queue” after the action name – add support for “tls-less” librelp we now require librelp 1.2.3, as we need the new error code definition See also: https://github.com/rsyslog/librelp/issues/1
  • build system improvements
    • autoconf subdir option
    • support for newer json-c packages Thanks to Michael Biebl for the patches.
  • imjournal enhancements:
    • log entries with empty message field are no longer ignored
    • invalid facility and severity values are replaced by defaults
    • new config parameters to set default facility and severity Thanks to Tomas Heinrich for implementing this
  • bugfix: ompipe did resume itself even when it was still in error See: https://github.com/rsyslog/rsyslog/issues/35 Thanks to github user schplat for reporting
  • bugfix: “action xxx suspended” did report incorrect error code
  • bugfix: ommongodb’s template parameter was mandatory but should have been optional Thanks to Alain for the analysis and the patch.
  • bugfix: only partial doc was put into distribution tarball Thanks to Michael Biebl for alerting us. see also: https://github.com/rsyslog/rsyslog/issues/31
  • bugfix: async ruleset did process already-deleted messages Thanks to John Novotny for the patch.

librelp 1.2.3

librelp 1.2.3 [download]

This version of librelp addresses the problem that RHEL and CENTOS provide too-old versions of GnuTLS to make support librelp’s TLS functionality. To “solve” this problem, TLS can now be disabled in librelp, so that base RELP functionality is also available on those platforms.

Note that librelp previously built on those platforms, but DID NOT WORK.

Version 1.2.3 – 2014-03-13
– add ability to build librelp without TLS
This is required on some platforms where GnuTLS is too old
Use –disable-tls to select this mode. If set, RELP_RET_ERR_NO_TLS
will be returned on calls that selected TLS mode.
See also: https://github.com/rsyslog/librelp/issues/1
– API change: two functions that used to return void now return state
these are:
* relpSrvEnableTLS();
* relpSrvEnableTLSZip();
This change is acceptable because the state must not necessary be
evaluated. If not, the same error is returned a bit later in the
calling sequence. Having it early, however, may help with better
error messages. So it’s still optional to check.
– bugfix: configure required too-old version of GnuTLS

  This lead to successful builds which later on would not execute.

sha256sum: c06e15f94f7e75d7c9f8c66faefaf5ab8808072c828ac6982c70825fe3aa20f1

LibLogging 1.0.2 released

liblogging 1.0.2 [download]

We have released liblogging 1.0.2.

This is the first release with a basically feature-complete liblogging-stdlog component. It is an enhanced replacement for the syslog(3) API which supports multiple channels, signal-safeness, and logging drivers for syslog, the systemd journal, unix sockets, and files. While this version is suitable for use with applications, we still invite comments and code reviews.

The man page for the standard logging library is available at
    https://github.com/rsyslog/liblogging/blob/master/stdlog/stdlog.rst

Please report issues and feature requests to
    https://github.com/rsyslog/liblogging/issues

Feedback of any kind is highly appreciated.

Note: if the journal driver is to be build (enabled by default), a new dependency libsystemd-journal exists. This is the required to use the journal API. You can turn off building the journal driver via the –disable-journal configure option.


sha256sum: 1fecfdc506ee937c21c30d868c76842506dc34ea5eb168b81fd11eb9483e4388

Output to Elasticsearch in Logstash format (Kibana-friendly)

Original post: Recipe rsyslog+Elasticsearch+Kibana by @Sematext

In this post you’ll see how you can take your logs with rsyslog and ship them directly to Elasticsearch (running on your own servers, or the one behind Logsene’s Elasticsearch API) in a format that plays nicely with Logstash. So you can use Kibana to search, analyze and make pretty graphs out of them.

This is especially useful when you have a lot of servers logging [a lot of data] to their syslog daemons and you want a way to search them quickly or do statistics on the logs. You can use rsyslog’s Elasticsearch output to get your logs into Elasticsearch, and Kibana to visualize them. The only challenge is to get your rsyslog configuration right, so your logs end up where Kibana is expecting them. And this is exactly what we’re doing here.

Getting all the ingredients

Here’s what you’ll need:

  • a recent version of rsyslog (v8+ is recommended for best performance, although the Elasticsearch output is available since 6.4.0). You can download and compile it yourself, or you can get it from the RHEL/CentOS or Ubuntu repositories
  • the Elasticsearch output plugin for rsyslog. If you compile rsyslog from sources, you’ll need to add the –enable-elasticsearch parameter to the configure script. If you use the repositories, just install the rsyslog-elasticsearch package
  • Elasticsearch :). You have a DEB and a RPM there, which should get you started in no time. If you choose the tar.gz archive, you might find the installation instructions useful
  • Kibana 3 and a web server to serve it. There are installation instructions on the GitHub page. To get started quickly, you can try the tar.gz archive from the download page that gets you Elasticsearch, too

Then, you’ll probably need to edit config.js to change the Elasticsearch host name from “localhost” to the actual FQDN of the host that’s running Elasticsearch. This applies even if Kibana is on the same machine as Elasticsearch. “localhost” only works if your browser is on the same machine as Elasticsearch, because Kibana talks to Elasticsearch directly from your browser.

Finally, you can serve the Kibana page with any HTTP server you prefer. If you want to get started quickly, you can try SimpleHTTPServer, which should be embedded to any recent Python, by running this command from the “kibana” directory:

python -m SimpleHTTPServer

Putting them all together

Kibana is, by default, expecting Logstash to send logs to Elasticsearch. So “putting them all together” here means “configuring rsyslog to send logs to Elasticsearch in the same manner Logstash does”. And Logstash, by default, has some particular ways when it comes to naming the indices and formatting the logs:

  • indices should be formatted like logstash-YYYY.MM.DD. You can change the pattern Kibana is looking for, but we won’t do that here
  • logs must have a timestamp, and that timestamp must be stored in the @timestamp field. It’s also nice to put the message part in the message field – because Kibana shows it by default

To satisfy the requirements above, here’s a rsyslog configuration that should work for sending your local syslog logs to Elasticsearch in a Logstash/Kibana-friendly way:

module(load="imuxsock")             # for listening to /dev/log
module(load="omelasticsearch") # for outputting to Elasticsearch
# this is for index names to be like: logstash-YYYY.MM.DD
template(name="logstash-index"
  type="list") {
    constant(value="logstash-")
    property(name="timereported" dateFormat="rfc3339" position.from="1" position.to="4")
    constant(value=".")
    property(name="timereported" dateFormat="rfc3339" position.from="6" position.to="7")
    constant(value=".")
    property(name="timereported" dateFormat="rfc3339" position.from="9" position.to="10")
}

# this is for formatting our syslog in JSON with @timestamp
template(name="plain-syslog"
  type="list") {
    constant(value="{")
      constant(value="\"@timestamp\":\"")     property(name="timereported" dateFormat="rfc3339")
      constant(value="\",\"host\":\"")        property(name="hostname")
      constant(value="\",\"severity\":\"")    property(name="syslogseverity-text")
      constant(value="\",\"facility\":\"")    property(name="syslogfacility-text")
      constant(value="\",\"tag\":\"")   property(name="syslogtag" format="json")
      constant(value="\",\"message\":\"")    property(name="msg" format="json")
    constant(value="\"}")
}
# this is where we actually send the logs to Elasticsearch (localhost:9200 by default)
action(type="omelasticsearch"
    template="plain-syslog"
    searchIndex="logstash-index"
    dynSearchIndex="on")

After restarting rsyslog, you can go to http://host-serving-Kibana:8000/ in your browser and start searching and graphing your logs:

kibana-screenshot

More tips

Now that you got the essentials working, here are some tips that might help you go even further with your centralized logging setup:

  • you might not want to put the new rsyslog and omelasticsearch on all your servers. In this case you can forward them over the network to a central rsyslog that has omelasticsearch, and push your logs to Elasticsearch from there. Some information on forwarding logs via TCP can be found here and here
  • you might want rsyslog to buffer your logs (in memory, on disk, or some combination of the two), in case Elasticsearch is not available for some reason. Buffering will also help performance, as you can send messages in bulks instead of one by one. There’s a reference on buffers with rsyslog&omelasticsearch here
  • you might want to parse JSON-formatted (CEE) syslog messages. If you’re using them, check our earlier post on the subject: JSON logging with rsyslog and Elasticsearch

You can also hook rsyslog up to a log analytics service like Logsene, by either shipping logs via omelasticsearch or by sending them via UDP/TCP/RELP syslog protocols.

Changelog for 8.1.6 (v8-devel)

Version 8.1.6 [devel] 2014-02-20

  • omfile: permit to set global defaults for action parameters
    Thanks to Nathan Brown for the patch.
    See also: https://github.com/rsyslog/rsyslog/pull/23
  • add capability to escape control characters in the C way of doing it
    adds new global parameter “parser.escapeControlCharactersCStyle”
    Thanks to Nathan Brown for the patch.
    See also: https://github.com/rsyslog/rsyslog/pull/13
  • parser global parameters can now be set using RainerScript global()
    Thanks to Nathan Brown for the patch.
    See also: https://github.com/rsyslog/rsyslog/pull/23
  • omprog: guard program-to-be-executed against CTL-C
    This can frequently happen in debug mode, where rsyslog is terminated
    by ctl-c. In any case, SIGINT is not meant to control the child process,
    so it should be blocked.
  • omprog bugfix: parameter “forceSingleInstance” is NOT mandatory
  • add new jsonr property replacer option
    Thanks to Nathan Brown for the patch.
  • added external plugin interface
  • ommongodb: add authentication support (untested)
    Thanks to JT for the patch.
    See also: https://github.com/rsyslog/rsyslog/pull/17
  • bugfix: json templates are improperly created
    Strings miss the terminating NUL character, which obviously can lead
    to all sorts of problems.
    See also: https://github.com/rsyslog/rsyslog/issues/27
    Thanks to Alain for the analysis and the patch.
  • ompgsql bugfix: improper handling of auto-backgrounding mode
    If rsyslog was set to auto-background itself (default code behaviour, but
    many distros now turn it off for good reason), ompgsql could not
    properly connect. This could even lead to a segfault. The core reason
    was that a PG session handle was kept open over a fork, something that
    is explicitely forbidden in the PG API.
    Thanks to Alain for the analysis and the patch.
  • bugfix: ommongodb’s template parameter was mandatory but should have
    been optional
    Thanks to Alain for the analysis and the patch.
  • bugfix: end of batch processing was not 100% correct. Could lead to
    outputs not properly wirting messages. At least omelasticsearch did not
    write anything to the database due to this bug.
    See: https://github.com/rsyslog/rsyslog/issues/10
    Thanks to Radu Gheorghe for reporting the issue.

rsyslog 8.1.6 (v8-devel) released

We have just released 8.1.6 of the v8-devel branch.

This is the release candidate for v8.2.0 stable. It contains a number if smaller enhancements as well as bug fixes. We plan to release 8.2.0 soon. So we would appreciate if you could report any bugs you find in that version.

ChangeLog:

http://www.rsyslog.com/changelog-for-8-1-6-v8-devel/

Download:

http://www.rsyslog.com/rsyslog-8-1-6-v8-devel/

Feedback is *very much* appreciated.

Best regards,
Tim Eifler

Scroll to top