A Quick Start Guide to MONyog Ultimate Enterprise Monitor

w: www.mariadb.com e: [email protected]

Page 1

A Quick Start Guide to MONyog Ultimate Enterprise Monitor

1 Objective Of This Guide MONyog Ultimate Enterprise Monitor (MUEM) is an efficient and easy to use monitoring tool used by thousands of Database Administrators (DBAs) to analyze their MariaDB and MySQL® Databases every day. This quick guide is aimed at providing users with information on MUEM -‐ specifically its main features -‐ and advice on how it can be used in real life situations. DBAs familiar with other tools can confidently use this guide to compare MUEM with other monitoring tools. A further investigation may require the installation of an evaluation copy of the tool. This guide can also be used by DBAs who are new to MUEM and want to get quickly started using the tool. DBAs who are familiar with previous versions of MUEM, can review what is new to the tool and take advantage of its new features. After reading this guide, DBAs will find easy to set up and monitor their database servers. More advanced tasks will probably require the use of online documentation. The features described in this guide refer to MUEM 5.1 or higher

2 What is MONyog Ultimate Monitor? MONyog Ultimate Enterprise Monitor (MUEM) is a powerful and flexible tool that helps MariaDB and MySQL® DBAs manage and monitor a vast number of servers with a single instance. Currently, the largest installation of MUEM includes more than 500 MariaDB or MySQL database instances monitored by a single server. MUEM makes it easier to find and fix problems that can arise on MariaDB and MySQL database applications. It provides tools, graphs, monitors and advisors that help MariaDB and MySQL DBAs to anticipate and prevent issues before they occur. MUEM takes a proactive approach to enterprise database monitoring, and through a combination of enterprise visibility, proactive monitoring and expert advice, provides guidance in problem identification and resolution. With MUEM, even DBAs with no MariaDB or MySQL database experience, can tighten security, optimize performance and reduce downtime of their MariaDB and MySQL powered systems.


Page 2

3 MONyog Ultimate Monitor Features Platform independent, MONyog Ultimate Monitor(MUEM) connects remotely to any MariaDB or MySQL database server, on any platform – Linux® (32 or 64 bit systems), Windows® (32 or 64 bit systems), Solaris®, Unix®, AIX®, BSD/FreeBSD etc. MUEM also uses industry standard protocols to interact with MariaDB or MySQL Servers, users and other monitoring tools. The most commonly used protocols include:

• HTTP • SSH Tunneling • SNMP • SMTP • SFTP

3.1 Fast Install and Setup MONyog Ultimate Monitor can be installed using a standard platform installation, such as Windows installer or Linux rpm. It can also be simply copied and decompressed into the desired folders on the monitoring server. The latter approach also allows the user to install MUEM in “automatic” or “silent” mode. MUEM does not require external dependencies, extra software or libraries to run. Rather, the installation package contains everything necessary to install and start the server in seconds. In fact, MUEM comes with an extremely lightweight web server that provides a web interface for the monitoring client. DBAs can connect to MUEM using any browser supporting AJAX and from any platform, including typical mobile devices. Once MUEM is installed and launched, it is extremely easy to register servers and set connection parameters. A powerful and really “time saving” utility provides the automatic discovery of complex Master/Slaves configurations. Once a master is registered, MUEM automatically registers all its slaves, including recursive or “relay” slaves. A simple click of the mouse can start of stop the data collection from a registered MariaDB or MySQL server, making it really easy for the DBA to troubleshoot his servers.

3.2 Users, Authentication and Security Support MUEM provides an authentication mechanism based on user profiles, using a standard combination of user name and password, through a secure connection. Users can be administrators (Admin) or regular users (Non-‐Admin). Administrators can control users’ access to a specific subset of the available servers, and they can control access to specific information on those servers.


Page 3

3.3 Performance and Tuning Optimization MUEM provides a comprehensive list of performance variables and tools for easily checking and monitoring the health and performance of MariaDB and MySQL servers in real-‐time. Because the interval between each data collection can be reduced down to 1 second, DBAs are able to apply a highly sophisticated level of troubleshooting, reducing the time necessary to fix database issues.

3.4 The Main Dashboard MUEM provides a simple, immediate, graphical view of the most important parameters and metrics on the monitored servers. Clicking on the Dashboard tab, once at least one server has been registered, can activate this view. Since the world is moving towards tablets and most of them don’t support Adobe Flash and dashboard charts were on Flash, MUEM 4.7 have switched to HTML5 charts and since then MUEM graphs not only work on all Smartphones and Tablets, but they are faster than Flash charts. Hence, desktop users also gain from this release. Flash charts used elsewhere in MUEM are also changed to slick HTML5 charts. The use of HTML5 helps DBAs to get a quick overview of the performance and load of their servers, combined with graphs that also provide information on system availability and CPU usage. In the Dashboard page, servers are presented side-‐by-‐side. This simple and intuitive view allows DBAs to easily spot servers that deviate from a standard behavior, especially when servers in a group are load balanced. Servers can also be monitored in groups or as single instances, and the view of these servers is configurable. For example, charts can be enabled, disabled or reordered, depending on the DBAs’ needs. Finally, all charts are easy to export in printable formats, such as PDF, JPG and PNG.

3.5 Alerts and Advisors MUEM provides more than 250 monitors and advisors, right out of the box. A “Monitors/Advisors” interface provides access to a detailed display of server parameters and metrics that can be fully customized by the DBA. The Monitors and Advisor interface is organized in columns. The left column displays the “counters” or “metrics”. As with the side-‐by-‐side view available on the Dashboard page, information is organized in columns for each registered server in the selected group. Some data will be displayed as cumulative values (accumulated over a time frame that can be predefined by the DBA); other data will be averaged over a time interval (typically per second). MUEM provides exhaustive on-‐line documentation for each metric. DBAs need only position their mouse over the name of each metric to display and a tooltip pops up explaining the formulas and calculations.


Page 4

Alerts and advisors are grouped together by topic, and topics are based on security, caching, connectivity, communication etc. Alerts are normally sent via e-‐mail and are fully customizable. MUEM can be set-‐up to send e-‐mails using an SNMP server whenever a problem occurs, or after the same problem has occurred repeatedly for a number of sample intervals. MUEM also manages events. An event occurs when a counter changes status, due to specified threshold. The status can be “Info” (white), “Warning” (yellow) or “Critical” (red). Events are also registered when a counter becomes “Stable”. As part of the Monitors and Advisors interface, MUEM provides a historical analysis of all the data collected. In this way, DBAs can verify the trend of a specific advisor and apply appropriate actions to upcoming issues.

3.6 The Query Analyzer MUEM can help fix issues related to the execution of SQL queries. SQL queries can be captured in many ways:

• General query log analysis -‐ Queries are captured by setting up a general query log. The log can be a file or a table.

• Slow query log analysis -‐ Queries are captured by setting up the slow query log. The log can be a file or a table.

• Process list analysis -‐ Queries are captured by analyzing the SHOW PROCESSLIST command. Although this mechanism does not collect all the relevant queries, it provides the quickest method to capture queries on a server.

• Query sniffer analysis -‐ Queries are captured using MySQL Proxy and a special LUA script provided by MUEM. This mechanism can capture all the queries sent to a MySQL server, but it can generate overhead.

3.7 Server Optimization MUEM provides other very important features that DBAs can use to optimize their MariaDB and MySQL Servers. The Disk Usage tab provides an overview of the storage used by the MariaDB and MySQL Servers. An appealing user interface provides a simple view to the disk space associated with schemas, indexes and tables. DBAs can also set up table size alerts to prevent tables from growing to rapidly. MUEM retrieves the configuration of the MariaDB and MySQL Servers and tracks changes applied to any parameter. The user interface provides a simple view that shows just the changes applied during a given period. Alternatively, it can also be used to compare parameters on multiple servers, side-‐by-‐side.


Page 5

All the information collected by MUEM can be easily exported in various formats. In addition to the previously mentioned print and graphical exports, MUEM also provides a simple interface to export data in CSV and Excel format. MUEM also provides an interface for analyzing the MariaDB or MySQL Server Error Log. DBAs can be notified about additions to the error log via alert sent in email.

3.8 Fully Customizable Parameters and Interface MUEM is fully customizable. Parameters, objects and thresholds can be modified and none of them are hard coded. Advisors, Alerts and Dashboard graphs are defined as JavaScript objects based on a very simple Object Model. DBAs can also create their own objects in order to monitor more elements of the server or even to create application-‐specific advisors and alerts.


Page 6

4 MONyog Ultimate Monitor Architecture MONyog Ultimate Monitor is powered by a MONyog, a monitoring tool developed by Webyog and arguably the most commonly used commercial solution for monitoring MariaDB and MySQL servers.

4.1 Differences Between MONyog Ultimate Monitor and Other Monitoring Tools Because the MariaDB and MySQL database has a large and vibrant community of developers, DBAs can count on a very rich offering of monitoring tools and solutions, either open or closed source, that allow them to monitor their systems, networks and databases, as well as manage security issues. Some of these monitoring tools are focused on performance, while others focus on a strong visual data presentation (graphs and charts) that can be very effective in “control rooms” on wide monitors. Still others give strong support in offline data analysis. Though each product aims at being exhaustive and complete, they ultimately have a distinctive feature and strength. Not all of the tools are available for every platform where MariaDB and MySQL is deployed. For example, not all the tools can monitor MariaDB or MySQL on FreeBSD, on IBM AIX or HP-‐UX. Some monitoring tools require the use of an agent process running on database production servers. Although the use of an agent can be useful, it is sometimes complicated to install additional software on the database servers. In the real world, system and DBAs often use more than one tool to control and monitor their database servers in the best possible way. MUEM is powerful, yet still very simple to use and extremely flexible. Troubleshooting is probably the most notable feature and strength of MUEM. With MUEM, DBAs have the ability to identify the issues that are affecting or will affect their databases. The combination of a complete set of alerts and a very high granularity in sampling data from servers, makes MUEM the most accurate monitor solution available on the market.

4.2 Architecture and Technologies The picture below shows how MUEM is deployed and which components are involved in a monitoring environment.


Page 7

4.2.1 Embedded Web Server MUEM comes with a lightweight web server built in. The web server is compatible with all of the most commonly used servers and offers the most effective technologies available today for feature-‐rich user interfaces.

4.2.2 MariaDB and MySQL® C-‐API Compiled in In order to capture MariaDB and MySQL Server data, MUEM has been built around the MySQL C-‐API. MUEM can connect to MariaDB and MySQL servers running on any platform. Because there is no abstraction layer -‐ such as ODBC, JDBC, ADO/.NET – involved, DBAs can be assured that a connection is always possible.

4.2.3 Agent-‐less MUEM does not require any other component to connect to the database server. MariaDB and MySQL servers can be configured on MUEM in seconds and the data collection starts immediately. MUEM allows DBAs to switch data collection on and off very quickly, without any other intervention. Also, MUEM will not use any additional resources on the database server.

Figure 1 - SkySQL Enterprise Monitor Deployment


Page 8

4.2.4 AJAX MUEM uses AJAX to communicate with the client browser. Pages are divided into independent objects that can be updated individually when required. This approach reduces the bandwidth consumption as compared to the traditional method of reloading the whole page: each HTML object in the pages refreshes automatically when new data are available. For this reason, it is easy to display and compare many MariaDB and MySQL servers simultaneously and independently. In this way, servers with a different collection interval have their HTML object refreshed only when necessary. MUEM also uses HTML5 technology to generate real-‐time graphs.

4.2.5 Embedded JavaScript Engine MUEM includes an embedded JavaScript (JS) engine. The logic behind alerts and advisors, such as the definition of thresholds or the calculation of performance metrics, is all based on JS objects. The complete source code of these JS objects is available to the user for customization. The JavaScript objects are fully editable, extensible and configurable.

4.2.6 Embedded SQLite database MUEM uses SQLite as a repository. All information collected from the database server is stored in the SQLite repository. For each database server, MUEM creates a SQLite database. The repository is based on a simple schema that allows advanced users to export and reuse with other tools the data collected.

4.2.7 Security MUEM does not rely on any external dependency or library to provide secure access to the tool. MUEM is practically immune to any kind of malicious code, whether they are unwanted pop-‐ups, advertisements, trojans, phishing or hijacking attempts. Since MUEM works as a black box, it does not provide any open port other than DBA access through a browser, and it can be safely used on fairly unsecure networks.

4.2.8 Query Analysis MUEM can analyze queries in many different ways. A LUA script is provided with MUEM to enable use of MySQL Proxy as data collector (as illustrated in the picture above), but this component is not strictly necessary.


Page 9

5 MONyog Ultimate Monitor At A Glance

5.1 Installation MUEM is available as an RPM package for Redhat/Fedora/CentOS/SUSE distributions, and as compressed tarballs for other distributions (Debian, Ubuntu etc.). On Windows systems, MUEM comes with a fully automated wizard installer. MUEM service can be managed as any other service through Windows Service Manager. After the installation, MONyog starts automatically as a daemon/service. DBAs can immediately start monitoring MariaDB and MySQL servers using Internet browser to connect to: http://<MY_HOST>:5555 For the very first login, DBAs can use the userID admin with no password. A trial version of the tool is available at www.mariadb.com. Fully functional for 30 days, the trial includes all of monitors and advisors of the Platinum Edition. At the end of the trial period, DBAs can uninstall the software or they can purchase a MariaDB Enterprise subscription. The new subscription will provide a license key that activates MUEM, the configuration, and the data collected to-‐date, for the period defined in the subscription.

5.2 Configuration

The message visible to the DBA soon after the first login is “No servers currently registered!”, followed by a link to register a server. Once registered, servers appear in a list of servers, grouped by tags. Tags will be very useful when executing a task to all the servers having the same tag. The picture shows the screen section used to add, select or unselect MariaDB or MySQL servers. MariaDB and MySQL Servers can be added with few clicks. MUEM provides a set of parameters, grouped on the left of the page. DBAs do not need to review or modify all the topics -‐ it is sufficient to provide an IP address, a DB user and a password to start collecting information.

Figure 2 - List of Servers


Page 10

The picture below shows the first page of how to register or modify the registration of a server. For systems running behind firewalls or in a secure environment, MUEM can send and receive encrypted authentication information, as well as monitoring data from MariaDB and MySQL using ssh tunneling. In this case, an operating system user is required for MUEM to connect to the MariaDB and MySQL Server and sshd must be active on the database server. When MUEM connects to a MariaDB or MySQL server for the first time, a new SQLite database is created in the repository.

The number of servers that can be registered with MUEM is limited by the MUEM subscription, but technically MUEM can register and monitor up to 512 servers. With a high number of servers, tags come extremely handy. Servers can be categorized in logical groups, and charts or reports can be displayed according to group.

Figure 3 - Server Registration

Figure 4 - SSH Tunnelling


Page 11

5.3 A Look at the Dashboard The MUEM Dashboard is a real-‐time graphical representation of the servers’ activity and health at a glance. The Dashboard displays all of the selected or tagged MariaDB and MySQL servers, their

Figure 5 - Dashboard


Page 12

availability, the number of connections, cache misses, statements and, if MariaDB or MySQL is running on a Linux distribution, a graph of the CPU usage on the system. The picture above shows an example of a dashboard view where two MariaDB or MySQL servers are monitored. Every green dot in the Monitor Availability area represents a collection of data retrieved from the servers. The dashboard displays data based on the 30 latest collections. The time interval between two successive collections (two dots) reflects the server-‐specific setting for the sample interval. The minimum collection value is one second. Different servers graphs can be compared if they have the same sample setting. This view is extremely useful to compare two or more servers “on the fly”. The Dashboard settings can be changed directly from the Dashboard page. It is easy to perform tasks like adding or removing graphs (on a per server basis), changing the graph order of each server, or changing the color and size of the charts. By hovering on the anchor points on the charts, it is possible to see the actual values; each anchor point represents a data collection. A very effective use of the dashboard is side-‐by-‐side monitoring of all the master servers (or all the slaves of a single master) in an enterprise environment and analyzes, for instance, how well they are load balanced.

5.4 Advisors, Alerts and Reports MUEM can rely on more than 250 server parameters and metrics used, through its reporting functionality, to constantly monitor the status of the managed servers. The advisors are designed to automatically examine a MariaDB or MySQL server’s configuration, security, and performance levels. They identify any problems and also provide the MariaDB or MySQL DBA with specific corrective actions. The Monitors/Advisors page shows a detailed display of server parameters and metrics. The left column lists the “counters” or “metrics” that MUEM displays by default. For every registered server, a column, with data pertinent to that server, is displayed. Some data will be displayed as cumulative values (accumulated over a time frame that you can specify) while others are averaged over a time interval (typically per second). The metrics are grouped by arguments and each metric is documented by the user interface itself. Special care was paid to the security group, which has over 30+ security advisors. Users can create not only new metrics, but also new groups. The simplest way to create a new metric is by duplicating an existing one and then changing some of its elements.


Page 13

To see how each metric is calculated, DBAs can simply hover their mouse over the name of each metric. The formula used by the calculation is displayed with description as a “tool tip popup”. The tool-‐tip also explains how the shown result is evaluated and how the value relates to an overall or to

server-‐specific performance metrics. The MUEM Advisor Rules are a set of best practices that allow DBAs to implement new MariaDB and MySQL servers with confidence and to pro-‐actively manage the dynamic nature of all of their MariaDB and MySQL servers over time. The Advisor Rules allow this by monitoring all MariaDB and MySQL servers and notifying the DBA with specific instructions on how to pro-‐actively address found exceptions to align with the best practices. MUEM allows a DBA automate each of the MariaDB or MySQL Advisor Rules unattended, for around the clock operations. This helps to minimize human errors, improves overall productivity and lowers the total cost associated with managing MariaDB and MySQL servers.

Figure 6 - Monitor: Connection History


Page 14

For all of the Advisors, Advisor Rule violations trigger notification events, details of which can be sent via email. MUEM also provides expert advice on the specific problem that has been reported. Users can get proactive alerts before problems start surfacing and MUEM, by default, sends alerts if the values for certain metrics go below or beyond certain thresholds. Historical data stored in the MUEM repository database can also be used to tune a server. For example, the picture below shows the Connection History alert page. The red and yellow dots that appear beside a metric, show the metric exceeds the set threshold value, as it has been defined in the JavaScript component used for each metric.

Figure 7 - Monitor In Line Tips


Page 15

The bell icon indicates that the corresponding counter is included in the e-‐mail alerts sent to the DBAs, provided that the email alerts are enabled for a specific server and that the value for either the ”current/all” or “latest” timeframe exceeds the set warning level.

A graph or chart is used to visually represent tabular numeric data and/or functions. Clicking on the graph icon displays a graph, depicting the current status of the metric. MUEM can also monitor the MariaDB or MySQL Error Log that contains information indicating when a MariaDB or MySQL server was started and stopped, as well as any critical errors that occur while the server is running. As such, monitoring the error log is crucial – changes to the log are indicative of disastrous outages. MUEM makes the task of monitoring the error log very simple. DBAs simply need to configure MUEM to trigger an alert for any change in the error log. If there is an entry of type [ERROR] in the log, MUEM can extract the corresponding message and send it over e-‐mail or SNMP.

5.5 History and Trend Analysis The ”History/Trend” option in the Monitors/Advisors interface allows DBASs to select any time interval for the counter/metrics display. This is a client side (browser specific) setting. The default setting is for

Figure 8 - System Parameters: CPU Usage


Page 16

the last 1 hour before the connection to MUEM was established. Common options like “last 1 hour”, ”today”, “this week”, etc. can also be selected, as well as a custom starts and end times.

There is also an option to group results into categories. This option displays the aggregated sum for the selected time-‐setting. The term ''trend analysis'' refers to the concept of collecting information and attempting to spot a pattern, or trend, in the information. Analyzing history reports provides a means of tracking trends and identifying problem areas in the network. This information can be used to find recurring problems, which will help in preventing future problems. This data can also help in planning maintenance schedules and equipment replacement. Some very common questions that can be answered by the trend analysis are:

• Was a MariaDB or MySQL server down in the last one month? • When did MariaDB or MySQL traffic peak in the last few days?

The answers to these questions can be easily found in the pictures below.

Figure 9 - Timeframe


Page 17

Figure 10 - Trend Analysis


Page 18

5.6 Processlist and Query Analyzer Processlist is a real time activity monitor for MariaDB and MySQL. MUEM can find problems on SQL queries by taking a snapshot of the SHOW FULL PROCESSLIST command at regular intervals. MUEM uses the processlist snapshot to show and collect what is running on the server at an exact point in time. The rows returned by SHOW FULL PROCESSLIST are stored in a repository table. The storage can be temporary, i.e. for the time the list is displayed, or permanent, when processlist is used to analyze the queries running on the MariaDB or MySQL servers. The Processlist module gives the user a manual control on the queries that are running on a server. Queries can be expanded, explained (using the EXPLAIN command) and in the event of issues on the server, killed directly from the browser.

Figure 11 - Processlist


Page 19

Processlist uses color-‐coding on queries according to their execution time. In this way, DBAs can immediately spot long queries. The default set of colors is shown in the picture below.

The Processlist view can also be filtered and sorted by columns. Columns include the connection ID, the connection's status, and the text of the current query. Filtering gives DBAs the unprecedented flexibility of displaying queries by using a standard SELECT command, but with the invaluable advantage of a browser interface. Filtering options are very powerful tools for troubleshooting. A basic filter in the Processlist display may be a command like: SELECT user, count(user) as no_of_queries, max(time) as running_longest FROM [processlist] WHERE user <> 'MONyog_user' AND command <> 'Sleep' GROUP BY user"; SHOW PROCESSLIST is not the only tool available in MUEM to review statistical information about the database queries. MUEM also provides a specific Query Analyzer tool, which can be used to find all the queries executed on the server or only the slow queries, i.e. the queries logged in the Slow Query Log.

Figure 12 - Processlist Query Colors


Page 20

In addition to the Processlist, Query Analyzer provides three mechanisms to collect queries: • The Slow Query Log • The General Query Log • The use of MySQL Proxy

Each mechanism has advantages and disadvantages; DBAs can decide to use one mechanism or another depending on the issues they want to fix. SHOW PROCESSLIST is available in all MariaDB and MySQL versions and it is the easiest query capture mechanism to setup. However, taking a snapshot of SHOW PROCESSLIST does not guarantee that all the queries will be captured. Many short-‐lived queries can be missed between two successive snapshots. Therefore, SHOW PROCESSLIST is a quick and easy way to find long running queries.

The log parsing requires some additional setup. Also, switching on the General Query Log puts a significant amount of load on the server. As a general rule, users should always keep the Slow Query Log switched on. The latter is probably the best and most efficient way to find bad queries. The use of MySQL Proxy gives the most accurate information on profiling SQL queries. However, this mechanism can be too intrusive for some applications. First of all, database clients must be redirected to MySQL Proxy, which in turn connects to MariaDB or MySQL server. The switching to MySQL Proxy usually requires a downtime and it adds latency to the database system, but it is the best way to spot short queries that are executed perhaps too many times. MUEM provides a LUA script that must be executed by MySQL Proxy.

Figure 13 - Query Analyzer


Page 21

Using the above tools to find problem SQL is almost always a post-‐mortem exercise. In certain situations, DBAs may want real-‐time notifications for long-‐running queries. MUEM can continuously monitor queries in real-‐time and send notifications (on mail or SNMP) for queries that take more than a specified amount of time to execute. As an option, such queries can be killed instantly. Note: The MUEM Sniffer taking snapshots of SHOW PROCESSLIST is different from the Processlist feature in that the Sniffer retains the information retrieved in a database for generation of reports and further analysis, whereas the Processlist feature just displays that information as is, without manipulating or storing it. In Query Analyzer, users can select which MariaDB and MySQL server and which type of log they want analyze. In the Query Analyzer, Identical queries are only listed once and the “count” column shows how many times the query was executed. The display can be sorted by clicking on the column head

Figure 14 - Query Analyzer Using the General Query Log


Page 22

Long queries can be killed manually or automatically. This is a unique feature provided by MUEM that relies on the use of a long query time threshold (maximum query execute time) set on each server. The

selected action can be Kill, Notify, or Both. Filters on queries are applicable also in this case.

5.7 Events An Event happens when any counter changes its status to WARNING (yellow) or CRITICAL (red) level. The Event is “over” when the counter becomes ”stable”. Events are stored in the repository in the EVENT table. An ”alert condition” (WARNING or CRITICAL) can be closed (or re-‐opened) for a specific server from the Events page, as well as from the Monitors/Advisors page.

5.8 Notifications MUEM can send alerts over email or SNMP. The alerting system uses the concept of "Delayed alert notifications" (i.e. a problem must persist for a number of sample intervals in order for the alert to be sent). DBAs can also choose to be notified when MUEM detects that a previously existing problem has been resolved.

Figure 15 - Query Analyzer Using Show Processlist of MySQL Proxy

Figure 16 - Event Table


Page 23

The JavaScript component defining each metric contains an attribute called ”MailAlert”. If ”MailAlert” is "yes" then the component is qualified to trigger a Mail Alert. Each metric has a ”WarmUpRequired” and a ”AlertCondition” option. If ”WarmUpRequired” is set, MUEM evaluates ”AlertCondition” to check if the server has been up for at least the required warm up time. The picture below shows an example of a typical MUEM MailAlert.

5.9 Tracking Parameter Changes One of the most useful features of MUEM is the easy management and analysis of the server parameters and in particular, the tracking of any change in the configuration. Server Config can compare MariaDB and MySQL configurations of multiple servers side-‐by-‐side, with all changes highlighted so that differences are visually discernible at a glance. Server Config can also track changes to the server configuration over a period of time.

Figure 17 - Mail Alert


Page 24

For example, in a scenario where two identical servers serving the same application do not perform in the same way, Server Config can help in comparing, side-‐by-‐side all the parameters: parameters with

different values are highlighted and DBAs can immediately spot the difference. Server Config can also track configuration changes. This feature acts as the version control of the MariaDB and MySQL server’s Global Variables, regardless of whether the variables have been set in a configuration file or if they have been set while the system was running. The configuration tracking is extremely helpful for checking the effect of a change in the MariaDB or MySQL Server. By simply analyzing the behavior of the server before and after the change, DBAs can apply corrective actions to improve the performance of the database.

Figure 18 - Server Configuration


Page 25

5.10 Wayback Machine Wayback Machine displays information about threads connected and the number of slow queries. The graph displays aggregating values on years/months/days/hours/ minutes depending on the data. If sniffer was running during this interval, aggregated sniffer information will be displayed for the time interval. Also shows first and last value of (optionally) all or changed variables aggregated values. The graph is zoomable by selecting a sub-‐interval with the mouse. Along with aggregated sniffer and changed variables it is also possible to get point-‐in-‐time information by clicking on a point in the graph.

Figure 19 - Wayback Machine: Threads


Page 26

When user clicks on a row in the query list of the Wayback machine a pop-‐up opens with information about thread-‐id, user and host along with full query.

The list of queries in Wayback Machine will not be rendered if there are more than 2000 queries in the time period. There is a user control that can be activated in such case. The reason is that every 1000

Figure 20 - Wayback Machine: Details

Figure 21 - Wayback Machine: List of Queries


Page 27

queries take around 1 second to render on an average desktop system. When we do a point in time select of one of the points on the graph, we get a bar chart that displays number of queries from the previous point to the point that is selected. Clicking on the bars will display queries running at that point in time.

5.11 Disk Info Disk Info is an easy to use disk space usage analyzer that shows which MariaDB or MySQL server, schema, table or index takes up the most space. Disk Info displays a number of schemas with their data and index sizes. It also provides a snapshot of the disk space occupied by MariaDB and MySQL database objects on the servers, as well as a graphical chart to quickly spot the largest schemas. The tool can drill down to a table level and monitor the space used by a single table to prevent an extra space usage. The Disk information is available at 3 information levels:

• Connection level • Database level • Table level

At the Database and Table level, space usage is illustrated by a graphical chart (a 'Doughnut' chart type) for easy analysis. If there are just a few objects (databases on a server or tables in a database), they are displayed in the graph. If there are many objects, only the largest objects will be displayed. Since MUEM 5.1 has been released a new feature has been added: clicking on a donut chart in the

Figure 22 - Disk Info


Page 28

Database level of a server will now drill down to table level.


Page 29

5.12 Custom SQL Objects (CSOs) Since MUEM 4.8 a new important feature has been added: Custom SQL Counters (“CSC”) and Custom SQL Objects (“CSO”). CSC are based on any user-‐defined SQL query returning a result set. The array returned by MariaDB and MySQL from the SQL query populates a ”Custom SQL Object” (CSO).

CSC and CSO allow users to utilize information available in Information_Schema (as well as Performance_Schema of MySQL 5.5+) that is not exposed in the basic SHOW statements that have been used till now. Information_Schema (I_S) is also accessed using a SELECT statement that makes sorting, filtering, JOINs, use of aggregate functions etc. possible. With this new feature it is possible to retrieve information from I_S that come from other MariaDB and MySQL forks, plugins or different storage engines for monitoring. CSO’s are not restricted to SELECT FROM I_S and SELECT FROM P_S. (Performance Schema), but, as said, any SQL-‐statement returning a result set may be specified. MUEM comes with 13 pre-‐defined CSO’s. In the below picture they are listed in the left menu.

Figure 23 - Custom SQL Object: Disk Info


Page 30

Figure 24 - New CSO in Monitor Parameters

When, for instance, we select the ‘DiskInfo’ item the User Defined SQL-‐query displays in the ‘SQL’ box. Sample interval and retention timeframe specific for this CSO may be changed and it is possible to define for which MariaDB or MySQL server (or servers) this CSO should be collected. Once the Save button has been clicked this query now executes on the MariaDB or MySQL server(s) and a MUEM object named ”DiskInfo’ will populate and be exposed for counter definitions. Now in the Monitors/Advisors page, it is possible to select the ‘Disk Info’ group that now displays at the bottom with 5 new counters in that group that in various ways reference the CSO’s just enabled

Note: Some of the predefined CSO’s require specific server versions and/or configurations (like the ‘InnoDB plugin’ with MySQL 5.1 (or MySQL 5.5+). The sample interval and retention frame setting for CSO’s are independent of the setting for built-‐in SHOW-‐based counters and also independent of each others, every CSO is handled by a separate thread by MUEM internally. The total number of CSC’s/CSO’s that can be enabled depends on the capabilities of the system and the number of servers registered and obviously many CSO’s collected with a short sample interval from a lot of MariaDB and MySQL servers will create additional load, mainly in I/O and network traffic.


Page 31

6 Conclusions This guide is not meant to be an exhaustive presentation of all the features available in MUEM. Hopefully, DBAs have found the features described here useful and representative of their day-‐by-‐day monitoring and operations. The MariaDB and the Webyog development teams are working hard to improve MUEM in order to make the tool even more efficient and helpful. Questions or comments are welcome and encouraged at www.mariadb.com.

A Quick Start Guide to MONyog Ultimate Enterprise Monitor

Documents