As a production DBA, you can fall into a situation where you have to act on an environment you do not know.

It can be very difficult to understand how the architecture was designed, but if you know the right commands, you can get a quick overview and all the information you need to start working.

Today, I’m going to give you these basic commands that will help you understand how an Elasticsearch installation was performed on an RHEL system.

Startup parameters

The first step is to identify the configuration file used to start the Elasticsearch process.

The easiest way to obtain this information is to examine the service startup environment variables. If you do not know the name of the service, you can find it using many tips. My favorite is to list all the services and to find one with a name containing “elastic”:

[root@linuxlab01]# systemctl list-unit-files | grep elastic
elasticsearch.service                         enabled

Then, you just have to retrieve the systemd unit configuration file:

[root@linuxlab01]# systemctl show -p FragmentPath elasticsearch.service
FragmentPath=/usr/lib/systemd/system/elasticsearch.service

In this file, you can search for the following terms to locate the elasticsearch.yml configuration file (depending on the version of Elasticseach used):

• ES_HOME
• ES_PATH_CONF
• CONF_DIR
• CONF_FILE

In my case, the path is “/etc/elasticsearch/elasticsearch.yml”.

Once located, you need to find 2 important parameters:

• http.port: the port on which Elasticsearch is listening
• network.host: the network interface on which Elasticsearch is listening

Both parameters will be useful for building your queries against Elasticsearch.

Note: if the value of “network.host” is “0.0.0.0”, you can use any ip address to query Elasticsearch. If “http.port” is commented, Elasticsearch will listen on the default port (9200).

With this information, you can now query Elasticsearch using “curl” for an overview of the installation topology.

Get nodes list

[root@linuxlab01]# curl -s -X GET "localhost:9200/_cat/nodes?v"
host             ip             heap.percent ram.percent load node.role master name
linuxlab01.local xx.xxx.xxx.xxx           59          78 0.00 d         m      linuxlab01
linuxlab02.local xx.xxx.xxx.xxx           40          76 0.01 d         m      linuxlab02
linuxlab03.local xx.xxx.xxx.xxx           62          80 0.06 d         m      linuxlab03
linuxlab04.local xx.xxx.xxx.xxx           56          78 0.00 d         m      linuxlab04
linuxlab05.local xx.xxx.xxx.xxx           70          83 0.03 d         *      linuxlab05
linuxlab06.local xx.xxx.xxx.xxx           53          79 0.00 d         m      linuxlab06

Get indices list

[root@linuxlab01]# curl -s -X GET "localhost:9200/_cat/indices?v"
health status index                     pri rep docs.count docs.deleted store.size pri.store.size
green  open   test_index				 20   1  616618684    116975880    486.6gb        242.5gb

Get health information from the cluster

[root@linuxlab01]# curl -s -X GET "localhost:9200/_cat/indices?v"
health status index                     pri rep docs.count docs.deleted store.size pri.store.size
green  open   test_index				 20   1  616618684    116975880    486.6gb        242.5gb

Get information about indexes (size, number of documents, …)

[root@linuxlab01]# curl -s -X GET "localhost:9200/_nodes/stats/indices?pretty"
[...]

Get information about cluster nodes (configuration plugins,…)

[root@linuxlab01]# curl -s -X GET "localhost:9200/_nodes?pretty"
[...]

Get information about snapshots (backups)

[root@linuxlab01]# curl -s -X GET "localhost:9200/_snapshot/_all?pretty"
[...]

Perform a simple search on all indexed documents

[root@linuxlab01]# curl -s -X GET "localhost:9200/_search" -H 'Content-Type: application/json' -d'
{
    "query": {
    "match": {
      "_all": "mydbaworld"
    }
  }
}
'
[...]

Now things should be a little clearer for you 🙂

I hope you find this articled useful. Stay tuned for more DBA stuff!