Obviously, Paramedic in my previous post is one of my favorite as it relates to the overview of the cluster. However, it is limited in the fact that its only live data coming in and limited to the statistics at a very basic level. I started looking into things that could provide more depth on monitoring and stats.
After some extensive searching and trying to find something a little more from a health and feature perspective I landed on ElasticHQ.
Elastic HQ – http://www.elastichq.org – boasts many features. I am a fan of companies that can have a little fun with their audience. Elastic HQ does that on their features page. They give you the non-geek version http://www.elastichq.org/features.html – or for the nerdier folks that want to geek out – http://www.elastichq.org/feature_list.html.
Let’s keep this non-geek friendly.
First, the install Elastic HQ has a few options:
1. In the Cloud – It’s free, no software installs, and Easy-to-Use. This option may work for most home labs, however, if you have a home lab, then you can afford to install this on your elastic search nodes. It’s another lightweight plugin. My opinion is not to use this method.
2. As a Plugin – Easy to install, no firewall issues, and it’s secured behind your firewall. Just like Paramedic, this is the easiest to install with the built-in plugin installer. It’s as simple as running the following:
/bin/plugin -install royrusso/elasticsearch-HQ.
Once the install completes, you navigate to http://domain:port/_plugin/hq/, then you’re able to hit connect in the top left corner, and it will connect to the cluster.
Features that I leverage in the home lab are pretty limited to mostly the diagnostics Elastic HQ provides.
The Cluster Overview page is the landing page once you connect. The major components you will leverage on this page are highlighted in red. If you have a node in your cluster down and out, then you will see Initializing Shards and Unassigned Shards numbers growing. These stats are telling you that ElasticSearch is having issues distributing the shards to additional nodes meaning your cluster is having issues. I use this all the time. For instance when a service dies because the default java heap space isn’t very large and it crashes the service. Or when a node is rebooting, and at a glance, you can quickly tell when the nodes are back and ElasticSearch as distributed the shards properly.
The Node Diagnostics Information page is a wealth of information. This page is my got to for a health check. If a node is having issues, you can stop in on this page and diagnose exactly why. If you hover over a statistic, it shows you how it’s getting that number. It’s perfect for learning what some of the best practices are. Maybe the reason your response time is slow is due to disk performance? Maybe the latency is too high, because of the block size that is was written to the underlying media?
I also leverage the Indices section. This page allows me to access index specific information as well as some basic index management and cleanup. I have used the Administration page to remove and or delete an index that is having issues.
This plugin is another must have in my opinion in a home lab or the enterprise.