Configure MemSQL Monitoring min read


Info

You may continue to use the historical monitoring, MemSQL’s former monitoring solution, if you are currently unable to migrate to MemSQL’s native monitoring solution.

Please note that historical monitoring has been deprecated in favor of MemSQL’s native monitoring solution and may no longer function in future versions of MemSQL.

MemSQL’s native monitoring solution is designed to capture and reveal MemSQL cluster events over time. By analyzing this event data, you can identify trends and, if necessary, take action to remediate issues.

If you are currently using historical monitoring, MemSQL’s former monitoring solution, and have upgraded to MemSQL 7.1.8 or later, you may continue to use the former monitoring solution without taking any additional action. You may use this guide if you prefer to migrate to this new monitoring solution.

Terminology

Throughout this guide, the cluster that is being monitored will be referred to as the “Source” cluster, and the cluster that stores the monitoring data will be referred to as the “Metrics” cluster. The databases that store monitoring data will be referred to as the metrics database.

MemSQL Native Monitoring Solution High-Level Architecture

image

In MemSQLs native monitoring solution, the Metrics cluster utilizes a MemSQL pipeline to pull the data from the exporter process on the Source cluster and stores it in a database named metrics. Note that this metrics database can either reside within the same cluster as the Source cluster, or within a dedicated cluster. Note that this metrics database can either reside within the same cluster as the Source cluster, or within a dedicated cluster.

When these event data is then analyzed through the associated Grafana dashboards, trends can be identified and, if necessary, actions taken to remediate issues.

The provided Grafana dashboards include:

Dashboard Description
Active session history Aggregated resource consumption by activity and activity type
Activity history Resource consumption by a specific activity over time
Detailed cluster view A “birds-eye view” of a single MemSQL cluster
Information schema view Provides a view into information_schema views PROCESSLIST, TABLES, and TABLE_STATISTICS
Memory usage Granular breakdown of memory use for a host
MemSQL status and variables view Collected status variables from each host in the cluster
Node breakout System metrics from each host in the cluster
Node drilldown System metrics from each host in the cluster, with the ability to focus on a specific metric subsystem

Prerequisites

Info

These instructions have been developed for MemSQL clusters that have been installed and deployed via .rpm or .deb packages as a sudo user.

If your cluster was deployed via tarball as a non-sudo user, change to the directory (cd) in which memsql-toolbox was untarred, and run all memsql-admin commands as ./memsql-admin.

Note that the Grafana instructions will require a user with sudo access to install and configure the associated Grafana components.

  • A MemSQL 7.1.8 or later cluster to monitor (the Source cluster).
  • Optional: A separate MemSQL 7.1.8 or later cluster to collect monitoring data (the Metrics cluster).
    • This can be the same as, or separate from, the Source cluster.
    • If you opt to use a separate cluster, we recommend a cluster with two aggregator nodes and two leaf nodes, each with 2TB disks and with high availability (HA) enabled.
  • Clusters are managed with MemSQL Toolbox 1.7.0 or later.
  • A Grafana 6.0.0 or later instance that can access the Metrics cluster.
  • MemSQL Toolbox is recommended for managing the clusters as automation during setup is provided through memsql-admin commands. While monitoring can be enabled through a series of SQL commands, the preferred method is to use MemSQL Toolbox.

Port Configuration

Default Port Used by Invoked by
3000 Grafana User browser
3306 MemSQL memsql_exporter
8080 MemSQL Studio User browser
9104 memsql_exporter MemSQL pipelines