rsyslog statistic counter plugin omelasticsearch

Plugin – omelasticsearch

This plugin maintains global statistics, which accumulate all action instances. The statistic is named “omelasticsearch”. Parameters are:

  • submitted – number of messages submitted for processing (with both success and error result)
  • fail.httprequests – the number of times a http request failed. Note that a single http request may be used to submit multiple messages, so this number may be (much) lower than fail.http.
  • fail.http – number of message failures due to connection like-problems (things like remote server down, broken link etc)
  • fail.es – number of failures due to elasticsearch error reply; Note that this counter does NOT count the number of failed messages but the number of times a failure occured (a potentially much smaller number). Counting messages would be quite performance-intense and is thus not done.

The fail.httprequests and fail.http counters reflect only failures that omelasticsearch detected. Once it detects problems, it (usually, depends on circumstances) tell the rsyslog core that it wants to be suspended until the situation clears (this is a requirement for rsyslog output modules). Once it is suspended, it does NOT receive any further messages. Depending on the user configuration, messages will be lost during this period. Those lost messages will NOT be counted by impstats (as it does not see them).

Note that some previous (pre 7.4.5) versions of this plugin had different counters. These were experimental and confusing. The only ones really used were “submits”, which were the number of successfully processed messages and “connfail” which were equivalent to “failed.http”.

 

Back to statistics counter overview

rsyslog 8.1.2 (v8-devel) released

We have just released 8.1.2 of the v8-devel branch. This is primarily a maintenance release, but offers some improvements. Thanks to Pavel Levshin, mmnormalize now offers higher performance and we have added the ability to link directly to jemalloc. Also, usability of queue settings has been improved by using better (and dynamic) defaults for a range of settings.

ChangeLog:

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

Download:

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

Feedback is *very much* appreciated.

Best regards,
Florian Riedl

Changelog for 8.1.2 (v8-devel)

Version 8.1.2 [devel] 2013-11-28

  • support for liblognorm1 added – results in performance improvements
    Thanks to Pavel Levshin for his work in this regard.
  • support for jemalloc added via –enable-jemalloc
    Thanks to Pavel Levshin for suggesting jemalloc
  • queue defaults have changed
    •   high water mark is now dynamically 90% of queue size
    •   low water makr is now dynamically 70% of queue size
    •   queue.discardMark is now dynamically 98% of queue size
    •   queue.workerThreadMinimumMessage set to queue.size / num workers

    For queues with very low queue.maxSize (< 100), “emergency” defaults will be used.
    Note that build system is experimental at this stage.

  • bugfix: disk queues created files in wrong working directory
    if the $WorkDirectory was changed multiple times, all queues only used the last value set.
  • bugfix: legacy directive $ActionQueueWorkerThreads was not honored
  • bugfix: mmrfc5424addhmac: “key” parameter was not properly processed

rsyslog 7.5.7 (v7-devel) released

This is primarily a bug-fixing release, but offers some improvements in worker thread handling (thanks to Pavel Levshin!) as well as usability improvements when working changing queue sizes.

More detailed information is available in the changelog.

ChangeLog:

http://www.rsyslog.com/changelog-for-7-5-7-v7-devel/

Download:

http://www.rsyslog.com/rsyslog-7-5-7-v7-devel/

As always, feedback is appreciated.

Best regards,
Tim Eifler

rsyslog 8.1.1 (v8-devel) released

This is the first bugfixing release for v8. It enhances overall stability and also re-enables some output modules. It is
highly suggested that v8 users upgrade to this release. Please note that it is still experimental code.

 

ChangeLog:

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

Download:

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

Feedback is *very much* appreciated.

Best regards,
Florian Riedl

Changelog for 8.1.1 (v8-devel)

Version 8.1.1 [devel] 2013-11-19

  • bugfix: STOP/discard(~) was mostly NOT honored
    This lead to execution of config code that was not meant to be executed.
  • bugfix: memory leak on worker thread termination
  • bugfix: potential segfault in omfile under heavy load
    Thanks to Pavel Levshin for alerting us.
  • bugfix: mmsequence: instance mode did not work
    Thanks to Pavel Levshin for the patch
  • bugfix: segfault on startup when certain script constructs are used
    e.g. “if not $msg …”
  • omhiredis: now supports v8 output module interface and works again
    Thanks to Pavel Levshin for the patch
  • mmaudit: now supports v8 output module interface and work again
  • bugfix: potential abort on startup in debug mode
    This depends on template type being used. The root cause was a non-necessary debug output, which were at the wrong spot (leftover from  initial testing).
    Thanks to Pavel Levshin for alerting us and providing a patch proposal.

How to use impstats

This summary was contributed by David Caplinger through the mailing list.

First, enable the module with something like:

module(load="impstats" interval="660" severity="7")

This will start generating logs tagged with “rsyslogd-pstats” every 600 seconds. If you like, you can use that tag to filter them into their own file:

if $syslogtag contains 'rsyslogd-pstats' then { 
     action(type="omfile" queue.type="linkedlist" queue.discardmark="980" 
            name="pstats" file="/var/log/pstats") 
     stop 
}

You’ll wind up with several log lines at each interval, all showing current counters (since rsyslog restart). So to determine inter-interval deltas, you’d have to import these into a spreadsheet. (Newer rsyslog can emit just the deltas in the log lines, but that’s in v7.5.x I believe.)

For example, if you want to filter based on some property (such as source IP address) and send the matching logs to both a local file and on to a remote destination, you might use something like:

if $fromhost-ip ==
     [ "1.1.1.1", 
       "2.2.2.2" ] 
then {
     action (type="omfwd" queue.type="linkedlist" queue.discardmark="980" 
             action.resumeretrycount="-1" name="NET.forward" target="10.10.10.10" 
             port="514" protocol="tcp")
     action (type="omfile" queue.type="linkedlist" queue.discardmark="980" 
             name="NET.local" file="/var/log/messages")
     stop
}

Which is a log flow like:

source -> imudp -> main Q -> NET.local (to local files) & NET.forward (to remote)

Here’s an example of a batch of pstats output (re-ordered slightly) from the above config:

Nov 13 14:31:35 loghost rsyslogd-pstats: imudp(*:514): submitted=23035
Nov 13 14:31:35 loghost rsyslogd-pstats: main Q: size=15 enqueued=89624087 full=0 discarded.full=0 discarded.nf=0 maxqsize=444
Nov 13 14:31:35 loghost rsyslogd-pstats: NET.local: size=0 enqueued=11541 full=0 discarded.full=0 discarded.nf=0 maxqsize=7
Nov 13 14:31:35 loghost rsyslogd-pstats: NET.local: processed=11541 failed=0
Nov 13 14:31:35 loghost rsyslogd-pstats: NET.forward: size=0 enqueued=11541 full=0 discarded.full=0 discarded.nf=0 maxqsize=7
Nov 13 14:31:35 loghost rsyslogd-pstats: NET.forward: processed=11541 failed=0
Nov 13 14:31:35 loghost rsyslogd-pstats: pstats: size=0 enqueued=65508 full=0 discarded.full=0 discarded.nf=0 maxqsize=25
Nov 13 14:31:35 loghost rsyslogd-pstats: pstats: processed=65500 failed=0

In this case we have:

1) A UDP input (imudp)

This logs message counts “submitted” to rsyslog via UDP port 514.

2) A main queue (main Q)

This shows messages entering the queue (enqueued), as well as any dropped messages (discarded.full=0, discarded.nf=0). It also shows how many times the queue has become completely full (full=0) and it keeps a running total of the maximum size the queue has ever hit (maxqsize=444). (All these counters are since rsyslog startup.)

3) Two output/action queues (NET.local, NET.forward)

These logs queue stats like above, as well as successfully “processed” (via omfile and omfwd in this case), indicating successful delivery to their final destination (local file or remote TCP receiver, in this case).

4) Another queue to handle pstats output itself (as I described above)

This example doesn’t happen to include DA-mode, which adds another pstats log line for the DA portion of the associated action queue.

If you don’t give your action queues names, you’ll wind up with pstats logs referring to things like “action 2”, and have a hard time figuring out what is going on.

A well-behaved queue will have zero discarded.full and discarded.nf, and a low maxqsize, meaning that everything entering the queue is leaving promptly. In a backlog situation, you’ll see size and maxqsize for an action/output queue increase over time, until maxqsize hits your configured queue.size parameter. Then the main Q will start increasing in size (and maxqsize) until it approaches and exceeds full. Then the discarded.nf and discarded.full counters will start climbing.

Scroll to top