Posts in this series:
- Introduction to Redis Labs Enterprise Cluster (RLEC)
- Getting started with RLEC – How to Install and Setup
- Getting started with RLEC – Installing on AWS Cloud
- Getting started with RLEC – How to Create and Configure a Database
- Getting Started with RLEC – Viewing Graphs & Metrics
Now that you have your RLEC environment running and databases created (refer to the links above) you can view the different dashboards and metrics related to the cluster, nodes, databases, and database shards.
One of the great advantages of using RLEC vs. open source Redis is the rich UI support you get to manage and monitor your databases, the nodes that make up the cluster, and the cluster as a whole.
In our previous post we showed how the configuration view of the database looks. Below is a screenshot of the Database Metrics page showing the different database related graphs.
Above the graphs, on the left side of the page, you have a toggle button that enables you to choose whether to view the database related metrics, or the shard related metrics. By default the database view is open. To the right of the toggle button, you can choose the time range for which you would like to view the data – from the last minute all the way to a full year back.
The dashboard is split into two main sections:
- Two large graphs that you can use to inspect specific metrics in detail
- A group of small graphs representing all metrics relevant to the database
You can click on any of the small graphs to choose which metrics are shown in the left or right large graphs at the top. By hovering your cursor over the large graphs, you can inspect specific points in time and have the relevant metric value displayed in the graph’s top left corner.
At the bottom of the two large graphs you can see summary statistics of the metric such as the minimum, average, maximum and last value, for the chosen time range. Similarly, by hovering over any of the small graphs at the bottom of the page you can view the same statistics as a tooltip.
All the different dashboard pages for the different entities in the system (database, shard, node, cluster) use the same basic logic as described above.
Below is a screenshot of the Database Shards Metrics page showing the different database shard related graphs. The screenshot below is for a database that has Database Clustering enabled and is configured to have eight shards. Replication for this database is disabled, so there are no slave shards.
The Database Shard Metrics page also features two large graphs at the top of the page that you can use to inspect specific metrics in more detail, and a series of small graphs at the bottom. However, this page differs from the Database Metrics page in that it has two groups of small graphs:
- Resources – These show metrics for the database as a whole, as well as eight graphs representing the shards that the database is sharded to. If Replication was enabled for the database, then we would also show an additional eight small graphs representing the slave shards (shown with the title “Slave”).
- Metrics – These show individual metrics relevant to each shard (similar to what is provided on the Database Metrics page).
Each shard graph also displays:
- Its role, i.e. Master or Slave
- The hash slot it is mapped to (a certain range between 1 – 4096, depending on the number of shards)
- The node the shard resides on
Note: Slave shards have the same hash slot range as their Master shard and will never be placed together with it on the same node.
You can choose which resources and which metrics are shown in the two large graphs at the top of the page. This enables you to easily make different types of comparisons, like comparing a single metric across two different resources, or comparing two different metrics from the same resource. For example, you can compare the ops/sec on two different master shards in order to see how the load is distributed between the shards, or compare the ops/sec and hit ratio on the same shard to see how they relate.
Node dashboard & configuration
The Node Metrics page shows graphed metrics that are applicable to a node. You can see an example in the screenshot below.
Similar to the Database Metrics page, you can choose which two metrics you’d like to view in the top two graphs.
In addition, below is a screenshot of the Node Configuration page.
In the Node Configuration page you can see additional node related information and metrics, such as:
- The duration of time the node has been up
- The RLEC version as well as Redis and Memcached versions
- The rack / zone that the node is mapped to
- The operating system
- The hardware architecture
- Total and used RAM, persistent storage and ephemeral storage
Cluster dashboard & configuration
Last but not least, you can view similar graphs and metrics for the cluster as a whole. The cluster is a logical grouping of all of the nodes that make it up.
The Cluster Metrics page looks and functions very similar to the Database Shards Metrics page in that they both have a “Resources” section and a “Metrics” section, but in the Cluster Metrics page, the resources correspond to the cluster and nodes, and the metrics are those ones relevant for nodes.
You can see an example with a cluster made up of two nodes in the screenshot below.
In addition, below is a screenshot of the Cluster Configuration page.
As you can see, this page displays similar information as in the Node Configuration page, but here it is summed up for the cluster as a whole.
That’s it. I hope that through these screenshots and explanations you got a taste of the wealth and breadth of information that can be easily obtained from the RLEC UI. Such information enables you to understand exactly what is going on in the cluster, the nodes, the databases, and even each and every shard.
If you haven’t noticed, the database performance shown in the screenshots above is that of a database running over 1M ops/sec with sub-millisecond latency, which is pretty impressive! In the next post I will show you how to set up a database and run a benchmark to get your own database running over 1M ops/sec with sub-millisecond latency 🙂
(BTW, you can also view a webinar with my colleague and Redis guru, Itamar Haber, explaining the same concept)
If you would like to learn more about RLEC and how to enable more advanced functionality, please refer to our documentation here: https://redislabs.com/redis-enterprise-documentation/overview
If you have any feedback or questions please don’t hesitate to reach out to me at: email@example.com.