3. Monitoring
There are several areas in which MySQL Enterprise makes monitoring much easier for
the administrators of a complex infrastructure. These areas
include:
We will examine each of these in greater detail in the following
sections.
Note:
You can rename the servers using the Manage Servers option on
the Settings page. This allows you to use more meaningful names on the
Enterprise Dashboard while leaving the actual hostnames of the servers
unaltered.
You can also create groups to combine related servers. This can
be very handy, because the group is displayed on the various controls,
allowing you to collapse the group and alter the display as
needed.
3.1. Heat chart
As shown earlier, the heat chart to the right of the monitoring page of the
Enterprise Dashboard provides an at-a-glance look at the relative
health of your servers. The legend (which you can switch on or off)
shows a series of colors that indicate states of operation from online
and fully operational (green) to offline or not communicating (red).
Clearly, your eye can quickly take in the areas that demand further
inspection. Figure 3 shows an example of the
heat chart for the information infrastructure example.
Notice that the heading on the heat chart lists several
categories that represent critical monitoring areas. These areas cover
the critical aspects of monitoring (CPU, memory, etc.). Unlike those
manual monitoring methods, this chart presents a relative health meter
that allows you to read the status quickly.
Along with the general monitoring areas are MySQL-specific areas
such as lock contention, MyISAM cache utilization, query cache
utilization, and the number of table scans. MySQL Enterprise can and
does report on a lot more areas, as you will see, but these are the
most-watched areas.
To the right of these categories are columns that keep a count
of recent critical events, warnings, and informational
messages.
Note:
The values in the heat chart are updated periodically, so the
counts may rise and fall depending on the recentness and resolution
of the problems.
3.2. Alert details
The best thing about the heat chart, which may not be obvious, is that you can
click on any one of the dots or numbered entries to get more
information. For example, if you click the I/O usage dot for a server
encountering I/O problems, you will see a list of all of the alerts
for that system, as shown in Figure 4.
You can then click the most recent alert and get a detailed report
like the one shown in Figure 5.
This report indicates the server on which the alert occurred,
the time it occurred, and advice following the established best
practices. There are tabs across the top for closing the alert to
clear it from the display (which you can do once you have either fixed
or accepted the incident), seeing more details (such as an expanded
problem description), and an Advanced tab that shows how the alert was
triggered.
The alert reports make the MySQL Enterprise stand alone among
the monitoring options. This is what is meant by having a “virtual DBA
assistant.” The alerts will make your life much easier by trapping the
problems from servers all over your organization and reporting them in
a single place. This saves you the time and tedium of costly
diagnostic efforts or active monitoring and gives you tips on how to
solve problems quickly.
3.3. Consolidated server graphs
At the center of the Enterprise Dashboard display is a consolidated
set of graphs that show colored lines for each of the servers being
monitored (Figure 6). The
default settings keep these charts very small, but you can change both
the size and reporting time scales.
You can use these charts to get another pictorial view of the
health of the systems in your organization. Even at the small default
size it is easy to spot anomalies. Like with the heat chart, you can
click a consolidated server graph to see more details about each
event.
3.4. Server details
Another nice feature of the Enterprise Dashboard is that it lets you click on a
specific server in the list of servers to see more details about the
system. The server details report shows the version of the MySQL
server; when it was last started (uptime); where the data is located;
the host operating system; and CPU, memory size, disk space, and
network information.
You can use this information for inventory purposes (determining
what hardware is on your network) as well as for a quick look at what
operating system is running to give you a clue about how to fix a
problem. For example, you can remotely log into a server to fix
something and know its hostname, IP address, MySQL version, and most
importantly, the host operating system before you log in—all critical
information that most administrators memorize or write down in a
notebook. Figure 7 shows an example of
the server details portion of the Enterprise Dashboard.
3.5. Replication details
The Replication tab of the Enterprise Dashboard includes a list of all of your
servers participating in replication. The information is presented in
a list form and, like all lists in MEM, you can click on each item to
get more information. Figure 8 shows
a sample replication details report.
Notice that items in the list are grouped by topology (e.g.,
“XYZ Corporation,” which you can rename), including the type of
topology, what role(s) the server is performing, and critical
statistics about replication, including status of the threads, time
behind master, current binary log, log position, master log
information, and the most recent errors.
In this example, we see there is a problem on
dev_slave2, where an error occurred on query
execution. This is an excellent example of how you can get a quick
picture of your replication topology. The list shows the masters and
slaves grouped hierarchically. That is, a master is listed at a level
directly under the group and its slaves under each master. In Figure 13-9, it is easy to see the
development server has two slaves,
dev_slave1 and dev_slave2,
and the development server is a slave to the
production server. Having all the information
about replication in one location makes the tedious task of monitoring
replication on each server obsolete.
3.6. Advisors
What makes all of the alerts and pretty charts so informative are the best
practices implemented in the advisors. You can see all of the active
advisors (and create your own) on the Advisors tab in the Enterprise
Dashboard. Figure 9 shows the list of default
advisors for the platinum subscription.
Figure 9 shows the advisors that are
active for a specific server on your network. You can enable, disable,
or unschedule any of the advisors (unscheduling removes the data
collected).
Perhaps the most useful feature of this page is adding your own
advisors. This feature allows you to expand the MEM to meet your
specific needs. It also gives you the one thing you need most when
migrating from a manual monitoring solution: the ability to preserve
your hard work.
For example, if you create a reporting mechanism that monitors a
custom application, you can create an advisor for it and add alerts to
the Enterprise Dashboard. The specific details of how to add new
advisors and alerts are covered in the MySQL Enterprise Monitor manual
on the Enterprise subscription portal. This customization feature is
one the most powerful and underutilized features of MySQL Enterprise.
