I think that this was by design. This can probably be changed so that even info level messages are logged to syslog.

Yes, it's by design that debug and info level messages are not logged to syslog. The rationale was that as those are very numerous and are used only for debugging some particular problem it's better not to write them to syslog.

Thanks for the feedback. Here's a very detailed comment from the person who ran into this problem:

The choice of logging mechanism (i.e. file, syslog etc), the message severity (info, notice, error, warn, debug etc), and the log level (severity at which messages will actually be logged) are three different concepts.
Therefore, one wouldn't expect to see a difference in the selection of messages between file logging and syslog when configuring a certain level.

And though it usually doesn’t make much sense to forward debug messages to a central syslog server due to the large amount of messages, I can easily imagine situations where that might come in handy.
When debugging issues on a set of machines, it’s much more convenient to forward all messages to a central log aggregation system (e.g. ELK, Graylog, Splunk etc), allowing to run queries over the log stream coming from the entire setup instead of grepping around in a file on a single host.

So personally, I would prefer if you'd adhere to the standard concepts of syslog, i.e. not make the selection of messages implicitly dependant on the logging mechanism.

However, if you’re afraid of overwhelming syslog infrastructures with debug messages (our prod environment generating around 1 GB of log_info messages per MaxScale per hour), maybe you could make the logging behaviour configurable by adding a config option log_info_messages_to_syslog_like_one_would_expect=0 or something, so people could enable it at their own risk?

And if you don’t feel like implementing any of that, you should at least update your documentation. Reading through the following KB article for example, there’s just no mention of log_info not applying to syslog, while all other log settings apparently do: https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-21-mariadb-maxscale-configuration-usage-scenarios/ <https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-21-mariadb-maxscale-configuration-usage-scenarios/>

Thanks Geoff, since this is an issue I opened, I'll gladly join the discussion here directly to represent the Ops side of things.

To give you a bit of context, we went live with a rather large MaxScale / MariaDB setup last week, and since we prefer to aggregate our logs via syslog, that's what we enabled, setting maxscale=0 because logging the same thing twice isn't much use.
Next, wondering about some issues in production, we wanted to get some deeper insight into what MaxScale was up to, so we set log_debug, only to realize that's not implemented in GA releases (see #MXS-1814). So after being told by support that "log_info" was actually the debug level setting we wanted, we spent another while wondering why that didn't generate any additional messages either in our syslog-only setup.

So while I do have some understanding for your original design decision, it somewhat deviates from system engineering standards, which makes the logging configuration a bit non-intuitive.

Taking a step back, and combining #MXS-1814 and #MXS-1819, I would love to see a solid piece of enterprise-grade software

• offer various logging options (e.g. file, syslog, json, structured-log-format-of-the-day)
• properly apply the concepts of (syslog) message priorities/severities
• allow various levels of logging verbosity (e.g. error, warn, info, debug)
• call the most verbose (and possibly disruptive) log level "debug" instead of "info"

us Well argued, we'll change the behavior so that info-level messages are logged just like all other messages.

Now info level messages are logged to syslog just like any other messages.