rsyslog on AWS – Applying Configuration Changes
Once you’ve updated the configuration of the AWS rsyslog application, it’s important to manually apply the new settings as rsyslog doesn’t do this automatically. This is to prevent partial changes from being loaded and potentially causing issues.
The AWS rsyslog AWS application provides a dedicated tool, rsyslogctl, which can be used to check and reload the configuration. During the reload process, rsyslogctl determines the most efficient way to apply the changes. For example, some changes like drop rules can be applied without interrupting message processing, while others require a full restart, causing a brief interruption.
Continue reading “rsyslog on AWS – Applying Configuration Changes”rsyslog on AWS – S3 file structure
The EBS disk included in the product is only used for day-to-day storage of logs. Persistent log storage is kept on an S3 store. This store also contains some other data items which should persist over upgrades of the rsyslog on AWS application.
The following prefixes/folders are used by rsyslog:
- /rsyslog.logstore/ – the actual logstore
This is synced with data from the local EBS disk once a day for the past day (in default settings). - /rsyslog.config/ – config data items.
This contains the user-based config which can be restored from here during an upgrade or on misconfiguration.
The users should select proper S3 policies based on her or his needs. Most importantly, Versioning and Retention Period should be set accordingly.
The S3 store to use can be configured during the cloud formation process and manually via the meta config.
rsyslog on AWS – an Overview
Our team at Adiscon offers a comprehensive paid full-service rsyslog product, available on the AWS Marketplace. As the same team that develops and supports the rsyslog open source project, we’re dedicated to providing exceptional service and ongoing innovation.
By purchasing our AWS Marketplace product, you’re also supporting the continued development of rsyslog. This ensures that the open source project remains robust, reliable, and up-to-date.
Our full-service rsyslog offering is designed specifically for organizations seeking a seamless and hassle-free way to collect syslog data on the cloud. We provide ongoing support and maintenance, along with regular updates to ensure the highest level of performance and security.
In summary, our AWS Marketplace product is the perfect solution for organizations that value simplicity, efficiency, and reliability when it comes to collecting syslog data in the cloud.
Documentation is available (and constantly being improved). Please follow these links:
Slightly Changed rsyslog Stable Release Cycle
For the past couple of years, rsyslog made scheduled releases every 6 weeks. We now changed this slightly to make version numbers easier to understand.
Remember, rsyslog versions are called 8.<yy><mm>.0, so the April 2020 release is 8.2004.0. When we release very six weeks, we get odd and even month numbers and, even more confusing, we sometimes seem to “skip” a month while at other times it looks like we craft a scheduled stable “every month”. To avoid this type of confusion, we have now decided to release every two month, and do that on even month.
We will usually try to release in the second half of the given month. However, we will no longer tell the exact target date. We need some flexibility here to avoid targeting “bad release periods”. As a concrete example, we will probably never do a December release during the holiday period. As such, December releases are more likely to happen in the first half of the month, which should give admins also some time to do all of their internal testing work ahead of the holidays.
We originally used the six week schedule to provide a balance between frequent bug fixes and not too frequent releases. With the appearance of daily stable releases a longer release cycle is no more a real concern. Everybody in need of a fix not yet present in the scheduled stable can just switch to the daily stable as needed. Remember that both are stable versions. The daily stable is often more stable as it contains the latest fixes.
Avoid overly-large in memory queues
Rsyslog provides the “queue.size” parameter to set a limit on the number of messages a queue can keep in memory. This is primarily meant to support peak traffic.
Note that this counter is given in number of messages, not bytes. A frequent mistake is to think in bytes and select very large values (e.g. 7 million frequently seen, maybe due to a web tutorial somewhere). If queues are that large there is a chance the rsyslog will be aborted by out of memory condition when the queue gets fuller and fuller.
An example. You send data to a remote syslog server. You define a very large queue on it. Usually, the queue keeps very slow. But when the system goes offline, the queue fills up. This will lead to sharply increasing memory usage. Depending on all circumstances this may not be a problem – or it may be! The likelihood of becoming problematic, and harder to reproduce, increases with the number of queues defined.
To avoid such misunderstandings, rsyslog starting at 8.1905.0 emits a warning message. It has probably lead you to this page. If the queue size is correct, you can ignore the warning message. You can also filter it out via regular rules, if you like. But if you did not intend to define such a large queue, please reconsider the value.
Note: rsyslog considers queues larger than 500,000 messages to be overly large – there seldom is a good reason to use sizes in excess of that.
solving rsyslog write errors
When rsyslog reports a write error, it includes the operating-system generated error message. It should hopefully give you a clue what the problem cause was. Unfortunately from time to time to root cause is not obvious.
In this case please check the following potential causes:
- Was OS/rsyslog config change applied but rsyslog not restarted? Rsyslog configuration changes are only applied when rsyslog is restarted. Similarly, many operating system process limitations (like file size and several permission settings) are only applied if process is restarted. If in doubt, do a restart of rsyslog. Doing so can potentially save you a lot of time.
- Is rsyslog configured to drop privileges? If so, the user or group dropped to may simply not have the right permission. Try to comment out the privilege drop to see if this is the root cause.
- Does SELinux prevent rsyslog to access the file? This is often the case if you write to non-standard locations. To check if this is the cause, you can disable SELinux on the system. If it then works, you know the root cause. But please do not run with SELinux disabled. Instead, configure it correctly.
- Are you using something similar to SELinux? For example AppArmor on Ubuntu? Investigate and check if it causes the trouble.
- Do you run rsyslog via systemd? Are there any limits specified in the service file? Most modern Linuxes use systemd, so this is for sure a place to check.
- Are there any global limits specified in the system configuration? Note: systemd ignores them, so if you use systemd, your really need to check the systemd configuration and rsyslog’s unit file!
- Are there any file system limitations?
- Did the system (temporarily) run out of space? This could especially be the case for intermittent problems.
This list probably is not conclusive but should give you a good idea of known trouble spots.
For a quick but rough check to find the culprit, you can run rsyslog in an interactive terminal window. Use the root account and do not drop privileges. If it works there, chances are pretty good that some other operating system component is causing the trouble.
rsyslog version numbering change
Rsyslog used a version number scheme of
8.<real-version>.0
where we incremented <real-version> every 6 weeks with each release. The 8 and 0 are constant (well, the 0 could change to 1 with a very important patch, but in practice we have only done this once).
While this scheme has worked pretty well since we introduced it, we often see people not understanding that there is really a big difference between 8.24 and e.g. 8.40. Followind recent trends in software versioning, we will make more clear how old a version really is. Begining with today’s release, we change the version number slightly to
8.yymm.0
where yy is the two-digit year and mm the two-digit month of the release date. We release every 6 weeks, so we will never have two releases within the same month.
So while you expected 8.41.0, you will now get 8.1901.0. To make things even more clear, rsyslog visible version output will be even more up to the point: rsyslog -v will now report “8.1901.0 (aka 2019.01)“.
Rainer Gerhards’ blog has more details on why we did this change and how we came to the new system.
rsyslog error 51 [warning]
File has been truncated
This is not a real error but rather a warning message. Most probably it occurs when monitoring files with imfile and “reopenOnTruncate” has been set to “on”. In this case, it indicates truncation of the file has been detected, and as such imfile begins to read it’s content from the beginning again.
Please see the imfile documentation for limitations of truncation processing.
message modification modules: why run in direct (queue) mode?
Message modificaton modules modify the message object, so the next actions can process the modified message. However, if the action that invokes the message modification module runs on a real queue (anything other than queue.type=”direct”), the message object is actually duplicated, and done so only for executing the action. In other words, the duplicated message object is immediately destroyed after the action completes. That means the modification made by the module will never be visible by anyone else.
So never run a message modification module on a non-direct queue. Message modification modules usually start with the letters “mm” (as in “mmjsonparse”).
Note that this is not a bug: rsyslog’s design is generic, and for most other actions the duplication of message is necessary in many cases. The config parser detects this kind of problems, but does not auto-correct it as the issue points to a potentially larger issue.
rsyslog error 2357
Warning parsing config file.
This unfortunately is a pretty generic error code which is emitted when there is a problem understanding the configuration files. The main configuration file is usually /etc/rsyslog.conf and it may include other configuration files. The error message names the file and the approximate location of the error.
The error text should describe what needs to be fixed. If that does not help, it may make sense to check out rsyslog support options.
This is a stub entry: If you have questions please post a comment or visit the github issue tracker.