View the Dashboards
When all cluster monitoring components are installed, configured, and running, the Grafana dashboards can be used to monitor SingleStoreDB cluster health over time.
Each dashboard provides insights that can be used to identify trends that may require intervention, including:
Cluster View
Chart Name | What it shows | When to use it |
|---|---|---|
CPU Utilization by Database | The CPU cycles spent by each activity, grouped by database | To identify which databases incur the most CPU usage. Note: A blank database indicates system activity that is not related to a user database. |
CPU Utilization | The percentage of the host’s CPU that is being used:
| To understand CPU usage and host resource usage in general, or for a given workload. |
Memory Utilization | The percent of the host’s memory that is being used | To understand host memory usage for a given workload over time. |
Read/Write Queries per Second | The number of reads/writes per second of the queries running on the system | To understand typical (“normal”) cluster activity to benchmark workloads and their query rate and identify anomalies in the read/write workload. If the number of rows read or written is very high or uneven, it could indicate that some queries or operations are taking longer to process than others. This can be due to poor indexing, inefficient queries, or database design issues. |
Failed Read/Write Queries per Second | The number of reads/writes failed per second of the queries running on the system | |
Rows Read or Written | The number of rows read/written | |
Network Received or Sent Bytes | The network bytes sent and received | To understand network usage for a given workload, identify bottlenecks, and determine if any non-SingleStoreDB activity is affecting a host’s network. |
Detailed Cluster View by Node
Chart Name | What it shows | When to use it |
|---|---|---|
All Metrics in Cluster View Reported per Node | All metrics in cluster view reported per node | To understand resource utilization of a node and to ensure the workload is evenly distributed across nodes for ideal performance. |
Historical Workload Monitoring
Chart Name | What it shows | When to use it |
|---|---|---|
CPU time by Database | The CPU time spent by each query activity, grouped by database | To identify which databases incur the most CPU usage. Note: A blank database indicates system activity that is not related to a user database. |
Execution Count | The number of queries executed in a given time | To perform capacity planning for workloads and identify if workloads in general, or workload spikes in particular, are putting the workspace at risk of running out of memory. |
Metrics by Query Plan | The queries executed and their relative resource consumption | To identify which queries are expensive, including how long queries are taking to complete, their CPU times, failure rates etc. |
Memory Usage
Chart Name | What it shows | When to use it |
|---|---|---|
Total Memory Used vs. Total Limit | The memory in use compared to the total memory available (megabytes) | To perform capacity planning for memory and identify if the cluster is not performing optimally due to a shortage of memory. |
Query Memory vs. Total Limit | The query memory in use compared to the total memory available (megabytes) | To perform capacity planning for workloads and identify if workloads in general, or workload spikes in particular, are putting the cluster at risk of running out of memory. |
Data Memory Used vs. Total Limit | The data memory in use versus the total memory available (megabytes) | To perform capacity planning for data memory and identify if given write workloads are putting the cluster at risk of running out of memory. |
Internal Memory Allocators vs. Limit | The memory used by SingleStoreDB memory allocators (megabytes) | To identify why memory allocations have increased, or are anomalously large, when there are no other indicators of increased memory use, such as workload or data, and to discover where memory is allocated (table, query, etc.). |