UTC is the so-called “universal coordinated time”. UTC was formerly referred to as “GMT” (Greenwich Mean Time) and is the basis of the international time zone system. For example, New York, USA is 5 hours behind UTC. So if it is 12 noon in New York, the UTC time is 5pm.

The MonitorWare line of products often uses UTC. UTC has the fast advantage of providing one consistent time notation, even if devices are across multiple time zones. This is extremely valuable if a centrel location is to consolidate events from senders in multiple time zones.

Using UTC might not be appropriate if a whole system is contained within a single time zone. As such, most time parameters inside the MonitorWare line of products can be configured to work with local time instead of UTC.


A non-reliable IP transport protocol. It provides best effort delivery. Typically, in LAN environments UDP packets are never lost. However, in WAN scenarios or with heavily loaded LANs, UDP packets might be lost.

Syslog Facility

Syslog Facility is one information field associated with a syslog message. It is defined by the syslog protocol. It is meant to provide a very rough clue from what part of a system the message originated from. Tradidionally, under UNIX, there are facilities like KERN (the OS kernel itself), LPD (the line printer daemon) and so on. There are also the LOCAL_0 to LOCAL_7 facilities, which were traditionally reserved for administrator and application use.

However, with the wide adaption of the syslog protocol, the facility field contents has become a little less clear. Most syslog enabled devices nowadays allow configuring any value as the facility. So it is basically left to distinguise different classes of syslog messages.

The facility can be very helpful to define rules that split messages for example to different log files based on the facility level.

Facility values are defined in RFC 3164:

The Facilities and Severities of the messages are numerically coded
with decimal values. Some of the operating system daemons and
processes have been assigned Facility values. Processes and daemons
that have not been explicitly assigned a Facility may use any of the
“local use” facilities or they may use the “user-level” Facility.
Those Facilities that have been designated are shown in the following
table along with their numerical code values.

 Numerical Facility

 0 kernel messages
 1 user-level messages
 2 mail system
 3 system daemons
 4 security/authorization messages (note 1)

 5 messages generated internally by syslogd
 6 line printer subsystem
 7 network news subsystem
 8 UUCP subsystem
 9 clock daemon (note 2)
 10 security/authorization messages (note 1)
 11 FTP daemon
 12 NTP subsystem
 13 log audit (note 1)
 14 log alert (note 1)
 15 clock daemon (note 2)
 16 local use 0 (local0)
 17 local use 1 (local1)
 18 local use 2 (local2)
 19 local use 3 (local3)
 20 local use 4 (local4)
 21 local use 5 (local5)
 22 local use 6 (local6)
 23 local use 7 (local7)

 Table 1. syslog Message Facilities

Note 1 – Various operating systems have been found to utilize
Facilities 4, 10, 13 and 14 for security/authorization,
audit, and alert messages which seem to be similar.
Note 2 – Various operating systems have been found to utilize
both Facilities 9 and 15 for clock (cron/at) messages.


The “Simple Mail Transfer Protocol”. This is an Internet standard for sending email messages. Virtually all major email systems are either based on SMTP or at least offer gateways to SMTP capable systems.

SMTP is used for sending email. It can not be used to pick up email messages. For this purpose, protocols like POP3 or IMAP4 are required.

SMTP is highly standardized. As such, a standard email client can work with all SMTP compliant servers. In the public Internet, almost all providers offer SMTP compliant mail servers for their customer’s use.

New Logo Selected

The rsyslog community selected a new logo! The winner is logo 1, also shown here to the right. That logo won with an overwhelming majority, and lead the polls on the mailing list, our original logo selection post as well as a dedicated poll we created for easier and anonymous voting.

The logo was originally contributed in 2014 by “robert s”, whom unfortunately I am no longer able to contact. While before we never officially adopted it, it went into widespread use and is already often used to represent rsyslog. So in a sense the now-official selection let’s us keep consistent.

We are glad to have the community decision. I am right now implementing the new logo all over rsyslog web spaces. It will also be available via the rsyslog website github project (PR just created).

Many thanks to all who voted. It was a pleasant experience for us. This may have also set stage for future polls on different topics.

What are your thoughts regarding current and potential rsyslog support channels?


Traditionally the rsyslog community has sought and provided support through three main channels:

  • mailing list
  • forums
  • ticketing system (at one time Bugzilla, now GitHub)

Over the years, the community support options have shifted to the point that we are considering retiring the forums in order to best direct users that post there to other, more current options that better fit their needs. It would appear that aside from specific cases, the time of the web forum has passed.

That said, we would like to get your feedback to best determine the way to move forward. What follows are some initial ideas to get the conversation started. Please feel free to respond here, via Twitter, the mailing list or on GitHub. Thank you for your time.

Potential Support options

The following items are all “whiteboard” topics, listed in no real order in an effort to start discussion. Neither the order or presence in the list indicates that a decision has already been made by the team to pursue the support option. Please feel free to suggest your own entries.

Keep the forums, send notifications of new posts made on the forums to the mailing list

  • Note: Attempts to respond to those notifications would not result in the replies being posted to the original topic on the forums.
  • Would this truly result in any additional responses to those forum posts than are currently being provided now?

Set forums to read-only, direct visitors to GitHub for support

  • Could GitHub serve as a replacement for the forums? If so, what do you think about mixing general questions with bug reports in the main project (rsyslog/rsyslog)?
  • Would a dedicated “project” (e.g., rsyslog/rsyslog-support) be useful?

Set forums to read-only, direct visitors to StackOverflow

It would appear there is already solid participation there for questions tagged with rsyslog:


Official Twitter presence

followers are encouraged to retweet rsyslog related questions, guides, etc to their followers.

This is actually a “trick” entry of sorts! We already have a Twitter account that you can follow and interact with: @rsyslog

  • Do you already follow that account?
  • Would you retweet content from others?
  • Would you respond to help requests that are retweeted
  • If links to active GitHub issues are posted, will you take the time to go view them?

Official Facebook presence

Would you participate in discussions and support requests made there?

IRC, XMPP, Slack, …

  • Would you participate?
  • Do you feel this could replace the forums?
  • Would this be more useful to you than the mailing list?

Help select a logo…

We need a new, a real logo. We have some candidates. Note that  logo 1 was originally contributed in 2014 by “robert s” (whom I no longer able to contact…). Unfortunately, we did never officially adopt it, primarily due to failure on my part. Nevertheless it got pretty popular on the Internet and is often associated with rsyslog.

Please let us know what you like by leaving either a comment here or posting to the mailing list. Alternatively, you can also cast your ballot via this online vote form.

We are of course open for any additional suggestions. We are also not upset if you let us know that we are not great logo designers – we know we are not 😉

In order to avoid past errors, I ask anyone to provide feedback within one week, so we will draw a “winner” by Feb, 8th 2018. To help facilitate the decision I will experimentally put logo 1 into some places tomorrow if there is no strong objection in doing so.

If  you want to have a look at our old old ugly logo have a look at e.g. https://hub.docker.com/u/rsyslog/)

My personal 2cts: I as rsyslog maintainer (@rgerhards) have to admit that I have a strong preference for either logo 1 or logo 2.  Pro-logo 1 speaks IMHO that it is already associated with rsyslog. Together with its stylish simplicity, this makes it an excellent choice. I also need to say that I am a bit skeptic in regard to logo 6, simply because it breaks “r” and “syslog”.

MonitorWare Agent 11.3c Released

Build-IDs: Service, Client


  • Property Engine: Fixed a bug that caused the first dynamic property to be missing when using XML report format. This bug also affected the SETP Sender and the Syslog TCP File-Caching feature (%rawsyslogmsg% missing).

You can download Free Trial Version of MonitorWare Agent.

RSyslog Windows Agent 4.3c Released

Adiscon is proud to announce the 4.3c release of Rsyslog Windows Agent.

This release contains some a minor bugfix.

Detailed information can be found in the version history below.

Build-IDs: Service, Client

Version 4.3c is a free download. Customers with existing 3.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.


  • Property Engine: Fixed a bug that caused the first dynamic property to be missing when using XML report format. This bug also affected the Syslog TCP File-Caching feature (%rawsyslogmsg% missing).