Monitoring your ElasticSearch cluster and getting it right

By November 28, 2012 Technical 3 Comments
Today’s post is all about ElasticSearch. We’re hiring at the moment, so you should get in touch if this sort of large scale infrastructure is your cup of tea.

ElasticSearch is a search service built on Lucene. One of its big claims to fame is that it’s distributed – you can run it over a cluster of servers for high performance and availability.

So you’ve got this cluster of ElasticSearch servers. Specifically, we have this cluster, and we’re managing it for the customer. That means we’re monitoring it with Nagios to make sure it’s working properly. We’re monitoring it every which way and collecting metrics so we can see how it’s performing and how it’s used.

Clusters are, by nature, a complex thing. This means that when it breaks, any extra information is really useful to get it fixed ASAP.

How to get this wrong

An ElasticSearch cluster can host multiple indices for searches. Each index is broken into shards, which are distributed over the cluster. Shards have replicant copies scattered around the cluster for redundancy, in case a server stops working.

ElasticSearch is nifty in that it has a simple red/yellow/green health status for its shards. The overall health of the cluster is derived by taking the worst of all index states, which in turn is the worst of all its shard states.

This maps very cleanly to Nagios’ idea of service health – red/yellow/green is a parallel to Critical/Warning/OK in Nagios. The problem is that this is where everyone else’s monitoring stops.

Our question is: If it’s 2am and your cluster health goes from green to red, what do you need to do to fix it?

Doing it right

ElasticSearch exposes a fair bit of extra information through its API, which can be inspected to derive the health of the cluster much more comprehensively. Having access to this data means that Nagios can give us much more meaningful report when a problem is detected.

Which would you find more useful: This?

WARNING: Index `cat_pictures` health is yellow

Or:

WARNING: One or more indexes are missing replica shards:
    Index 'cat_pictures' replica down on shard 0
    Index 'cat_pictures' replica down on shard 1

That’s good, but we don’t stop there. All our monitoring is comprehensively documented. If a sysadmin needs to deal with this situation and they’ve never touched ElasticSearch before, they have guidance to tell them just what this means, where to look, and how to go about fixing it. If they get stuck, the documentation tells them who to call (our resident expert).

In this case, it means a server has probably gone down. You’ll be getting plenty of SMSes to alert you to this fact. :)

The code

We’re not putting up all the support docs just yet, but if you’re interested in the code then it’s available. We’ve pushed it to a Github repo, so go clone it and go for your life.

Any questions/bugs/requests? Let us know.

3 Comments

Leave a Reply

Looking for greater competitive advantage? We can help. Ask us how.
Before you go..
Keep up to date with Anchor! Subscribe now and receive $100 credit towards your first month's hosting on Magento Fleet or OpenCloud.

We'll keep you in the loop with news about Cloud Hosting, OpenStack, Amazon Web Services & Fleet for Magento.

Anchor will never, ever, share your information.
x
Are you an online retailer using Magento?
Trial Fleet today!

Fleet is an auto-scaling hosting platform that will save your developers significant time, allow you to move faster - and vastly improve the uptime and performance of your store.

  • Blue-green deployments minimise risk
  • Automated code deployment saves time
  • Self-service - but fully supported by Anchor
  • Auto-scaling, HA design across multiple AWS AZs
  • On-demand test/staging environments identical to production
  • Hourly billing means that you only pay for what you use