Metricbeat as docker container, is a decent monitoring solution to monitor other docker containers in conjunction with Elasticsearch and Kibana. Additionally metricbeat can monitor the docker system itself. You might run into some problems, which I would like to share.
I have two ramp up for two data-centers each a Apache Kafka cluster. Maintaining the cluster with the Kafka Manager GUI by Yahoo is pretty comfortable. Since both data-centers are protected by firewall, a web-proxy must forward it for my remote access.
If you are using X-Pack Monitoring you have a good overview of your Kibana performance. Sometimes it is necessary to know more. Packetbeat can monitor your http traffic between Kibana and the Elasticsearch node.
X-Pack Reporting allows to automate and generate daily reports on pre-existing dashboards or visualizations in Kibana. To keep security tight I have created a reporting user. The first run with the reporting user gave me some mystery. Reporting complained Dashboard with id 'AWLOnWVZLaWygeBEGxLJ' not found. I did some digging and found the reason, which I am going to elaborate about in this post.
Using Python on Windows is not my first choice but if you have to, here are some recipes how to use pip behind a proxy. This post assumes that you are using CNTLM as running proxy.
On Unix and Unix-like computer operating systems, a zombie process or defunct process is a process that has completed execution (via the exit system call) but still has an entry in the process table: it is a process in the “Terminated state”.
Elasticsearch X-Pack Alerting or aka Watcher offers the capability to alert on specific events/constellation in the Elasticsearch data. Watcher can retrieve data from the cluster where it runs (on the master node), or fetch data from Restful Web-Services via the http input. Preferably having a production cluster, you should report the monitoring data to a dedicated Elasticsearch monitoring cluster. This monitoring cluster can also run watches. The watch I’am going to introduce is the cluster health watch.
Shards are parts of an Apache Lucene Index, the storage unit of Elasticsearch. An index may consists of more than one shard. Elasticsearch distributes the storage to its nodes. In a regular case each shard (as primary) has a replica. Primary and Replica are never stored on the same node. If a node fails, the replica takes over as primary and Elasticsearch tries to allocate a replica shard in the remaining cluster nodes. Cluster Shard Allocation is a pretty decent mechanism to ensure high availability. This post gives some insights and recipes how to deal with cluster shard allocation in a hot-warm architecture.