Ever need to restart ES instances for a critical ES cluster?
To play safe, you need to run a long procedure. And Stay Alarmed! The whole procedure would take hours.
How about we do it from Jenkins? Kind of VisualOps.
Suppose you have a critical Elasticsearch cluster. You have to know how to backup it. Correctly and quickly.
It’s not too difficult. But there are something you’d better know. And those are quite common in most DB backup.
Check it out, before it bits you.
People may start their elasticsearch cluster with very few shards. Or even start with 1 somehow.
WATCH OUT! You might be in big troubles, when your data grows much bigger.
Like slow query performance. Endless service crash with out-of-memory issues. Even worse, adding more VMs won’t help!
And the cure? You have to re-index them. But it comes with a cost, which you wish not to pay. Trust me, it hurts. Badly.
To poll Elasticsearch db status, we usually need to learn and try many many REST API. When we’re new, it would take quite a while to put all the pieces together.
As Ops/DevOps, we are usually more concerned about cluster health and data inside. Enclosed is A Simple Step-By-Step Guide to check elasticsearch. Cluster, Nodes, Shards, Indices, Documents And Beyond.
Usually critical data is stored in DB. We can periodically poll and combine key metrics from DB into a data report, such as how many tables/collections in DB, how many items in each critical table, etc. Data report enables people to visualize the history and trend of key metrics.
Furthermore if the basic data report can be generated automatically, people can easily add more metrics, which may make more business sense. The most exciting part is that we can get a general solution which applies to different projects! So how we can get this idea started?
