Important notice: With this release, we have changed the registration keys. As usual, the new keys are available for registered users from our Customer Portal.

Monyog MySQL Monitor v8.4.0 adds more alert and logging options and enhances the MONyog API. Further, we redesigned the settings page and a number of bugs were fixed.

Changes as compared to Monyog MySQL Monitor v8.3.2 include: Features:

Added more notification channels (Slack and Pagerduty) for Monyog alerts. (Read more) Option to write Monyog alerts in the Syslog of the machine where Monyog is installed. This option is only available for Linux. Option to edit the subject line for Monyog alerts. Added MONyog API to disable notification for a monitor based on a server/tag. ( …

You’ve already read it in What’s new in 5.7 (So Far) — the MySQL server now has new-and-improved supported for syslog (on unix-like systems) and EventLog (on Windows). In the next few paragraphs, we’ll take a look at what they are, what has changed, and how they can make your life easier.

The MySQL server supplies information in two main ways:

1. The client will receive a reply to every statement. If everything goes right, then we’ll see a simple OK for success, or a result set for SELECT, SHOW, etc.; and even a successful statement may be qualified by a set of warnings or notices. If the statement fails for some reason then we’ll receive an error regarding the failure.
2. On the server, we’ll see a variety of logs depending on the server configuration. Queries exceeding a certain execution …

When you use SHOW VARIABLES LIKE “have_%” to see whether a particular feature is enabled, you will note the value of NO for some, and DISABLED for others. These values are not intrinsically clear for the casual onlooker, and often cause confusion. Typically, this happens with SSL and InnoDB. So, here is a quick clarification!

• NO means that the feature was not enabled (or was actively disabled) in the build. This means the code and any required libraries are not present in the binary.
• DISABLED means that the feature is built in and capable of working in the binary, but is disabled due to relevant my.cnf settings.
• YES means the feature is available, and configured in my.cnf.

SSL tends to show up as DISABLED, until you configure the appropriate settings to use it …

Apache and syslog-ng

While logging to a database back-end has its benefits, the setup as it stands leaves us wanting. Some applications, such as Apache, do not log via syslog-ng by default. The good news is that this can be easily remedied, and there are a couple of different ways of doing this. First, the less good way:

Method #1: Changing the Apache configuration file.

First, we need to setup syslog-ng appropriately by creating a new source for apache, such as the following:

source s_apache {
 unix-stream("/var/log/apache2/apache_log.socket"
 max-connections(512)
 keep-alive(yes));
 };

log { source(s_apache); destination(d_pgsql); };

This recycles the original destination for …

By default, MySQL Cluster sends log data to a file but you can also send it to the console or to Syslog; this article explains how to send it to Syslog. The example given here is for LINUX.

In this example, I’ll use the “user” syslog facility name and so the first step is to make sure that syslog is configured to route those messages. If this hasn’t already been configured then add the following lines to /etc/rsyslog.conf:

# Log user messages to local files
user.*    /var/log/user

For the changes to take effect, restart the syslog service:

[root@ws1 etc]# service rsyslog restart
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]

Note that you should make those changes as root.

Still as root, start up a stream of  any additions to the new log file:

[root@ws1 etc]# tail -f /var/log/user

…