Table of Contents
Depending upon your use of MySQL Enterprise Monitor, you might perform some or all of these tasks after installation.
This section describes some of the general tasks which may be required after installation or upgrade.
Groups and Connections: Groups have always been used to define Event handling and Advisor scheduling policies; in this release Groups can also be used to restrict visibility and access to specific MySQL instances and their hosts. Before you create Connections and set up Groups, we recommend you first read the note immediately following on Users, Roles, and Access Control
To create a Connection, select MySQL Instances from the Dashboard menu. Create new monitoring connections either by processing the unmonitored instances already discovered by MEM or by manually specifying connection parameters for each MySQL Instance you will monitor. See Section 15.2, “MySQL Instance Details” for more information on creating connections in the User Interface.
Use the new Group Editor on the Settings menu to collect your MySQL instances into Groups.
Users, Roles, and Access Control (ACLs): Before using the Settings menu to create User accounts, see Chapter 23, Access Control and Chapter 24, Access Control - Best Practices.
Will you provide open access to all monitored resources for all Users? Or will you define Roles granting access to specific groups of MySQL Instances? If you intend to restrict access in this way, you must first create Groups of MySQL instances, see Chapter 16, Managing Groups of Instances. Only after you create groups can you create group-specific Roles.
Finally, assign users to your Roles.
You can also map users to Roles defined in LDAP or Active Directory.
Configure Event Handling and Notification policies: Open Event Handling from the Settings menu. Complete, and test, the SMTP, or SNMP, configuration. See Chapter 20, Events and Event Handling for more information.
Overview Dashboard: Select Overview from the Dashboard menu. Set the defaults for the groups you want to view, the time range, and graphs to display.
Advisors: You can accept the defaults defined, or select Advisors from the Settings menu and customize the threshold for groups, or individual MySQL Instances. For more information, see Chapter 19, Advisors.
SQL Performance Tuning - If you are monitoring instances of MySQL running version 5.6.14 or later, make sure to see the rich SQL performance tuning data available in the Query Analyzer. (If you are monitoring earlier MySQL versions, make sure to download a Query Analyzer plugin so you can see SQL performance data as well.)
I/O and Lock Contention - If you are using MySQL 5.6 or later consider deploying the sys schema, and making use of the new Database File I/O and Lock Waits reports from the Reports & Graphs menu. These will help you identify who or what is using the most I/O, and whether there is any lock wait contention within your MySQL Instance. See the Database File I/O and Lock Waits reports documentation for more information.
Update Agents: If you have not done so already, we recommend updating your Agents before continuing. See Chapter 6, Upgrading MySQL Enterprise Monitor Installations.
Users, Roles, and Access Control (ACLs): This release introduces Access Control Lists (ACLs). Built-in Roles have replaced the privileges previously defined in Manage Users in version 3.0. Your system already has been migrated, however we strongly recommend reviewing Chapter 23, Access Control and Chapter 24, Access Control - Best Practices.
You can continue to permit 3.0-style open access to all monitored resources for all Users who login; but you can now also define Roles that allow visibility and access to specific Groups of MySQL Instances and grant those Roles only to selected Users. If you’re using external services like LDAP or Active Directory, you can optionally map users to roles you’ve defined there.
If you’re going to use ACLs to restrict visibility or access, we suggest you review your existing Groups with that in mind. The new Group Editor is located in the Settings menu. For an explanation of how 3.0 privileges have been migrated to 3.1, see Section 23.6, “Default Users and Roles”.
Overview Dashboard: If you haven’t already done so, select the Dashboards menu, click on Overview and set defaults for which Group you want to view, the graph time range, and the set and order of Graphs to display. See Chapter 16, Managing Groups of Instances.
SQL Performance Tuning: If you are monitoring instances of MySQL running version 5.6.14 or later, make sure to see the rich SQL performance tuning data available in the Query Analyzer. (If you are monitoring earlier MySQL versions, make sure to download a Query Analyzer plugin so you can see SQL performance data as well.)
I/O and Lock Contention: If you are using MySQL 5.6 or later consider deploying the sys schema, and making use of the new Database File I/O and Lock Waits reports from the Reports & Graphs menu. These will help you identify who or what is using the most I/O, and whether there is any lock wait contention within your MySQL Instance. See tSection 18.2, “Database File I/O and Lock Waits” for more information.
The self-signed certificates are generated by the MySQL Enterprise Monitor installation or upgrade process, and are set to expire after 365 days. In the unlikely event you are running a version of MySQL Enterprise Service Manager using the default certificates for more than a year, you must generate new certificates. If you do not generate new certificates, the SSL connection between MySQL Enterprise Service Manager and the repository fails. This section describes how to generate those certificates.
These instructions guide you through the process of installing SSL certificates for your MySQL Enterprise Monitor installation.
All certificates and keys are stored in the Tomcat keystore. To check the certificates stored in the keystore, run the following command:
keytool -keystore $INSTALL_ROOT/apache-tomcat/conf/keystore -list -v
For information on using keytool, see
Java
Keytool.
To generate the certificate and add it to the default keystore, run the following command:
$INSTALL_ROOT/java/bin/keytool -genkey -keyalg RSA -sigalg SHA256withRSA -keystore$INSTALL_ROOT/apache-tomcat/conf/keystore -alias tomcat -validity 365 -keysize 2048
This generates a 2048-bit, RSA private key, and certificate. Further, this is the same command as used by the MySQL Enterprise Monitor installers.
When prompted for the key password, if you enter a password,
rather than accepting the default by pressing Enter, you must
also add the new password in the Tomcat configuration file,
server.xml.
To install an SSL certificate for the MySQL Enterprise Service Manager you must
use the Java keytool to import the
certificate into the keystore.
To import your certificate, run the following command:
keytool -import -trustcacerts -alias mycertificate -file cert.pem -keystore myKeystore
If you want to import an existing certificate, which is password protected, you must convert it to a format understood by the Java keytool. The certificate must be converted from X509 to pkcs12 format using the openSSL toolkit and the following command:
openssl pkcs12 -export -in [path-to-x509Cert] -inkey [path-to-cert-private-key]
-out [path-to-cert-to-import-for-keystore] -name tomcat
The certificate name must be set to Tomcat, or match the name used in the key generation steps.
To import the converted certificate, run the following command:
$INSTALL_ROOT/java/bin/keytool -importkeystore
-srckeystore [path-to-cert-to-import-for-keystore] -srcstoretype pkcs12
-destkeystore $INSTALL_ROOT/apache-tomcat/conf/keystore
-deststoretype jks -srcalias tomcat -destalias tomcat
Restart the service manager. For more information about stopping and starting the service manager, see the instructions for Unix/Mac OS X and Microsoft Windows.
For information on SSL and MySQL Server, see Creating SSL and RSA Certificates and Keys.
To configure SSL-related options for the Agent, the following
values may be placed in
:
$INSTALL_ROOT/etc/bootstrap.properties
Table 7.1 SSL Configuration Options For The Agent's
bootstrap.properties
| Parameter | Values | Description | Removed |
|---|---|---|---|
ssl-verify-hostnames | true or false | Verify that the hostname of the service manager that the Agent is connected to matches what is in the SSL certificate, Default is false, as we are only using SSL for confidentiality | |
ssl-allow-self-signed-certs | true or false | If set to true self-signed certificates are
permitted. If set to false,
self-signed certificates are not permitted. Default
value is true. | |
ssl-verify-host-certs | true or false | Default false, but to support self-signed certificates, a commercial certificate, or if the CA certificate has been imported into a keystore, then set to true | 3.0.20 |
ssl-ca-keystore-path | String | Path to keystore with CA cert(s), if
ssl-verify-host-certs is true | |
ssl-ca-keystore-password | String | Password for the CA keystore, if
ssl-verify-host-certs is true |
An example bootstrap.properties SSL
certification section:
ssl-verify-hostname=false ssl-verify-host-certs=true ssl-ca-keystore-path=/path/to/keystore ssl-ca-keystore-password=password123
To import a CA certificate in PEM format to a new keystore on the Agent, execute the following:
$INSTALL_ROOT/java/bin/keytool -import -file /path/to/ca/ca.pem -alias CA_ALIAS -keystore $INSTALL_ROOT/etc/cacerts
The tool responds with the certificate details. For example:
Enter keystore password: (the keystore will require at least a 6 character password)
Re-enter new password:
Owner: CN=serverName.com, O=MySQL AB, ST=Uppsala, C=SE
Issuer: O=MySQL AB, L=Uppsala, ST=Uppsala, C=SE
Serial number: 100002
Valid from: Fri Jan 29 12:56:49 CET 2010 until: Wed Jan 28 12:56:49 CET 2015
Certificate fingerprints:
MD5: E5:FB:56:76:78:B1:0C:D7:B0:80:9F:65:06:3E:48:3E
SHA1: 87:59:80:28:CE:15:EF:7E:F1:75:4B:76:77:5E:64:EA:B7:1D:D1:18
SHA256: F4:0B:79:52:CF:F3:A1:A4:7F:B2:D7:C1:65:60:F0:80:93:87:D2:68:9A:A1:
84:F4:06:6E:8E:CF:C1:F6:1B:52
Signature algorithm name: MD5withRSA
Version: 1
Trust this certificate? [no]: (type yes + enter)
Certificate was added to keystore
You must edit the ssl-ca-* configuration
values in bootstrap.properties accordingly,
to use the path to the keystore and password.
SSL configuration for LDAP is configured at the MySQL Enterprise Service Manager Java VM level. That is, it is configured in the keystore of the Java VM bundled with your MySQL Enterprise Monitor installation.
The JVM shipped with MySQL Enterprise Service Manager does not support the AES256 cipher. This can prevent you using LDAP servers which implement that cipher.
To connect to LDAP servers which implement the AES256 cipher, you must download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 package. This package is available from: Java Cryptography Extension.
The steps described in this section assume your LDAP server is correctly configured and you have a root CA certificate which was used to generate the LDAP server's certificate.
To enable SSL for LDAP and MySQL Enterprise Service Manager, you must do the following:
Convert the LDAP server's root CA certificate from PEM to DER format, if necessary. If the CA certificate is already in DER format, continue to the next step.
openssl x509 -in cacert.pem -inform PEM -out ~/cacert.der -outform DER
Import the CA certificate, in DER format, into the
MySQL Enterprise Service Manager Java keystore. Run the following command
from the bin directory of your
MySQL Enterprise Service Manager's Java installation:
keytool -import -trustcacerts -alias ldapssl -file ~/cacert.der -keystore lib/security/cacerts
Restart MySQL Enterprise Service Manager with the following command:
mysql/enterprise/monitor/mysqlmonitorctl.sh restart
The SSH Host key is used to distinguish monitored hosts, there should not be duplicate SSH keys. A key can be duplicated if a server is cloned. This section describes how to change the SSH host key for a particular host, eliminating the events and alerts generated when duplicate hosts are detected.
The following steps must be performed:
Generate a new SSH key for the monitored host.
Edit the monitoring agent's configuration.
Edit the hostid in the MySQL Enterprise Service Manager
repository.
On UNIX, Linux and Mac OS platforms, use the
ssh-keygen utility. On Microsoft Windows
platforms, there are several tools, but this example uses
puttygen.
To generate a new SSH key for the monitored host, do the following:
On the monitored host, generate an SSH key. For example:
$ ssh-keygen -t rsa -N ''' -f /etc/ssh/ssh_host_key
If using puttygen, click
Generate and follow the instructions
on-screen.
The key can be generated using RSA (SSH1 or SSH2), DSA, or ECDSA. All are supported by MySQL Enterprise Monitor.
Retrieve the key fingerprint.
The fingerprint is an alphanumeric string similar to the following:
5a:86:16:fb:2e:16:e8:21:ef:07:ee:6c:fc:4f:84:e5
On UNIX-based platforms, retrieve this value with the following command:
$ ssh-keygen -l -f /path/to/key/filename.pub
On Windows platforms, using puttygen, this
value is in the Key Fingerprint field.
Stop the monitoring agent.
Open the monitoring agent's
bootstrap.properties configuration file,
and add, or edit, the following value:
agent-host-id=ssh:{New SSH Fingerprint}For example, using the fingerprint listed above:
agent-host-id=ssh:{5a:86:16:fb:2e:16:e8:21:ef:07:ee:6c:fc:4f:84:e5}
On the MySQL Enterprise Service Manager machine, edit the
hostid value in the repository:
mysql> UPDATE mysql.inventory SET VALUE = 'ssh:{New SSH Fingerprint}' WHERE name = 'hostId';
Restart the monitoring agent.