Inspecting the cluster

Bo Andersen
A free video tutorial from Bo Andersen
Lead Developer
4.5 instructor rating • 4 courses • 62,433 students

Lecture description

Let's take a moment to see what the cluster that we started up looks like internally.

Learn more from the full course

Complete Guide to Elasticsearch

Learn Elasticsearch from scratch and begin learning the ELK stack (Elasticsearch, Logstash & Kibana) and Elastic Stack.

12:10:23 of on-demand video • Updated September 2020

  • How to build a powerful search engine with Elasticsearch
  • The theory of Elasticsearch and how it works under-the-hood
  • Write complex search queries
  • Be proficient with the concepts and terminology of Elasticsearch
English Alright, now that you know the very basics of what an Elasticsearch cluster looks like, let's take a moment to inspect the one that we have running. To do that, let's open up the Console tool in Kibana. You can find it by clicking the "Dev Tools" menu item. This is the first time that we will send a request to Elasticsearch, at least through Kibana. As you might remember, an Elasticsearch cluster exposes a REST API, which is what we will be communicating with. Essentially this means that the HTTP verbs differ depending on what we need to do. By HTTP verbs, I am referring to GET, POST, PUT, and DELETE. Although we will be typing in our query within Kibana's Console tool, Kibana still uses the REST API under the hood. On the Elasticsearch end of things, an HTTP request is received. This request is treated the same, regardless of where it was sent from. As long as the request is valid, we can access the REST API from any HTTP client of our choice, such as cURL, Postman, etc. You will see an example of this in the next lecture, but for now, let's use the Console tool The format in which we need to enter queries within Console, is to start by specifying the HTTP verb. Let's begin by retrieving information about the cluster's health. Since we’ll be retrieving data, we will use the “GET” verb. Next, we need to specify the request path, being the part following the address. When using the Console tool, we should not specify the address, since this is specified within Kibana's configuration, and will be prepended to the resulting HTTP request automatically. To retrieve a cluster's health, we use the following request path. As the first thing, I want to mention that the leading forward slash is not required when using the Console tool; if you leave it out, Kibana will add it before sending the HTTP request. So whether or not you include it is up to how explicit you want to be when writing your requests. I like to include it, but that doesn't mean that you have to. Alright, so let's briefly talk about the request path that we specified. The “_cluster” part specifies the API that we want to access, whereas the “health” part specifies the command. APIs begin with an underscore by convention. In place of "health," there are a number of other commands that can be used to retrieve detailed information about the cluster and its nodes. These commands yield results that are too complex to get into right now, so let's stick to the "health" command and run the query. On the right-hand side of the screen, we can see the results of the query, being a JSON object containing information about the cluster. The cluster's name is set to "elasticsearch," which is the default value. You can configure this to a more meaningful name, which you learned how to do a bit earlier. We can also see that the status of the cluster is set to "green." You probably won't be surprised that this means that everything is okay and that the cluster is healthy. We will revisit the cluster's status in a couple of lectures, where you will see a situation in which the status is no longer "green." Let's continue exploring the cluster, this time listing the nodes that are part of it. For that, there is an "_cat" API, which outputs data into a human readable format. Within the "_cat" API, there is a command named "nodes" which does what we are looking for. So let's type the request out. Before running the query, I will just add a query parameter named "v." This query parameter instructs Elasticsearch to include a descriptive header within the output, so we can identify each piece of information. Let's run the query. The results show some basic information about the single node that we have running, including its IP address, name, as well as some performance measures. In Elasticsearch, a node has a number of roles associated with it, specifying which actions it can perform within the cluster. We can also see that the node is a so-called master node. I will get back to both of these things fairly soon, so don't worry about those for now. We can actually retrieve lots of other information about the cluster's nodes with this command, by specifying a comma-separated list of columns for a query parameter named "h." Right now we don't need that, so I'll leave you to explore that if you want to. You can find a link to the documentation attached to this lecture. As a quick side note, there is an API named "_nodes," which returns the same data and much more, in JSON. You can use it to inspect nodes in a lot of detail if you need to do some debugging at some point. I don't want to confuse you with an information overload, so you can see the command on your screen now, or check out the attached link to the documentation. As the last thing for this lecture, let's check out which indices we have within our cluster, by using the "indices" command, also for the "_cat" API. You might be surprised to see that our cluster does actually contain indices. Specifically, two indices that are related to Kibana. So what's that all about? As you know, Kibana is just a web interface for Elasticsearch. If you set up a dashboard or configure machine learning jobs, this configuration needs to be persisted somewhere. Kibana doesn't ship with a database of any kind, so where does it store this data? You probably guessed it; within Elasticsearch! Kibana persists data into Elasticsearch indices, which is what you see here. This means that if you set up a fresh instance of Kibana and point it to an existing Elasticsearch cluster, all of the existing Kibana data will be loaded. That's much more convenient than having to manage some other kind of data store. In case you were wondering, the leading dot is used to hide indices within the Kibana interface. That's just a convention, similar to how directories and files are hidden on Linux based operating systems. Alright, that's all I wanted to show you in this lecture. We've run our first query against our Elasticsearch cluster, and we've taken a brief look at the inside. We'll get into more detail in the following lectures, so I'll see you there!