A new version of the monitoring plugin check_es_system, a script to monitor Elasticsearch nodes and cluster, is available!
Version 1.7 introduces a new check type called master and a new optional parameter -e (expect master).
Every Elasticsearch cluster has one master node. This can be a data node, too. Or you can define a dedicated master node. By default all nodes in a cluster are eligible to become a master. This is configured in the Elasticsearch settings in elasticsearch.yml using the node.master option:
node.master = true
This is enabled by default and it is possible that this isn't even configured in elasticsearch.yml.
Depending on the cluster environment it is possible that one node is preferred over the others. There might be a couple of reasons why. For example a particular node has more resources (CPU or RAM) available and is therefore faster than the other nodes, able to do the additional master tasks quicker. Or a particular node is physically closer to an Internet link and has less latency to the applications.
Unfortunately as of today (November 4th 2019) there is no setting which would allow to prioritize which node should be elected master. If the current master goes down, a new master is elected between the remaining cluster nodes (as long as they have "node.master = true"). When the original master comes back up, the master election is not restarted and keeps the current master.
This is where the new master check may come in handy. It checks which node is currently the cluster's master node. And it can alert if the current master is a different node than given with the -e parameter. Practical example:
$ ./check_es_system.sh -H myescluster.example.com -u elastic -p secret -t master -e node1
ES SYSTEM WARNING - Master node is node2 but expected node1
Without the -e parameter the current master node is simply shown with an OK state:
$ ./check_es_system.sh -H myescluster.example.com -u elastic -p secret -t master
ES SYSTEM OK - Master node is node2
No comments yet.
AWS Android Ansible Apple Atlassian Automation BSD Backup Bash Bluecoat CMS Chef Cloud Consul Container Containers CouchDB DB DNS Database Databases Docker ELK ElasticSearch Elasticsearch Filebeat FreeBSD GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Icingaweb2 InfluxDB Internet Java Kibana Kubernetes LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Rancher SSL Security Shell SmartOS Solaris Surveillance SystemD TLS Tomcat Ubuntu Unix VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder